During the e10+ event Monday at the RSA Conference, Rich and Mike moderated a panel on Optimizing Your Security Program. One of the contested topics was how to position security to upper management. Every CIO and CISO falls into the trap of having to say ‘No’ to some new idea that occurs to executive management, and then take blame for being “Negative Nancy”, “Dr. No”, “The Knight who says NEE”, or some collection of the Seven Dirty Words. I was surprised that so little has changed, as these were exactly the same problems I had a dozen years ago. While security threats were far simpler and fewer then, so was acknowledgement of the need for security. I guess it’s human nature that we still fall into the same traps.

For example, I remember the principal VC of one of the many start-ups I worked at, stating we needed to take credit cards – I responded that it was too risky given our (total lack of) site security. He looked at me as though I was stupid, insubordinate, and insensitive to customer requirements. I remain convinced it was one of the reasons I was one of the first people let go during a series of cost cutting RIFs. At the brokerage there was a bi-polar attitude, that 9 days out of 10 I needed to get the sales staff what they need to do their jobs, and make things as easy as possible so the sales conversations were aided rather than hindered by technology. Day ten was a hair-on-fire security exercise because some broker was printing out the entire database to bring to a competitor.

On the tenth day you will be asked by the CEO, “What are you doing to protect my data?” The correct answer is not, “making it super easy for people to get access,” or “exactly what you told me to.” As a CIO your priroity is service, but you are responsible for security.

I managed accordingly, or at least I started out that way. I figured I had the authority to nix projects that compromised data security. I felt it was my responsibility, as champion of security, to halt new projects until they addressed data and compliance issues. Outsiders felt security turned simple ideas into complex – and costly – projects. In reality, though most new ideas were not fleshed out, and failed to account for total build costs – much less the cost to clean up messes down the road. Still, complexity was “my fault”. This resulted in complaints, mid-level mangers trying to bypass me altogether, and bosses realigning my bonus incentives based on project completion and satisfaction of IT users.

Running IT services for popularity is dangerous, and results in bizarre feature-based prioritization of improvements, with user satisfaction hinging almost purely on system stability. You add shiny toys of no consequence and you make sure things are reliable – no more. I only recommend this if you want to ‘earn’ some short term bonuses and promotions, then quickly move to your next employer. If you want to succeed in the job for more than a couple consecutive quarters, avoid being a feature firewall, and avoid having your merit judged on convenience and system uptime.

Features and new ideas are more likely to come from outside your organization than inside, and no one else wants security, so you have to field these challenges. Trying to spin security as a business enabler is great conceptually but rarely works in the real world. I used three approaches to avoid being the bad guy for advocating security:

  1. The Security Porcupine: When I started working with sales people, I learned many sales techniques. One of the best tactics I ever learned was the ‘Porcupine’ strategy from Tom Hopkins, which I bastardized a bit to help with IT projects. In essence, you don’t catch a porcupine when it’s thrown at you – instead you deflect it. Ask the originator how they feel the problem should be addressed. “What a great idea! How would you like to handle [security/compliance/auditng] requirements we must meet?” This is a choice-based strategy. It gives the person who had the idea some responsibility by recognizing their idea carries a security burden; they can then help scale back their idea, or accept security controls as part of the plan. Either way, security becomes a facet of their project.
  2. The Hidden Security Project: If it’s your responsibility to form the IT deployment plan, take responsibility for it and build security in. Weave security into the project plan, subtly or otherwise, such that it is difficult to discern core function from security or operations. Costs and functions are bundled, and a detailed presentation makes it look like you have invested time into understanding how to get the project done. Present the plan and let the executive team decide if the investment is worth it. If it passes, you have both budget and executive buy-in. If not, the work you put into the plan saved you from disaster down the road.
  3. The Gauntlet: Accept the proposal and enter a “requirements phase”. As the project undergoes scruitiny from your team, raise security as an outstanding question. Also make sure internal compliance, security, and external auditors review the plan. It’s likely someone else will have the same security concerns you do – in addition to compliance and procedural issues you never thought of. If the idea is truly worthy, it will pass these tests. Either way, don’t fight it head-on. Most ideas die in the process, and nobody gets egg on their face when the initial state of euphoria passes over to critical reasoning. It’s a transparent pass-the-buck ruse in smaller organizations, but can harden and flesh out good ideas in larger firms.

I hate to advocate shenanigans, but business is business, and people will turn you into road pizza if you don’t protect yourself.

Share: