With today’s news about Mudge joining Twitter as the head of security and reporting directly to Jack, it sparked memories of thoughts I’d nearly forgotten. That is, thoughts about how the current security organization model that is most common among corporations also plays a contributing factor to a number of the security issues those organizations are plagued by. Building a silo of security expertise into divisions like “corporate security” and “product security”, resulting in increased barriers between teams implementing things and teams meant to secure those things.
I’ve been told before that this reorganization generally doesn’t work. I’ve been told that it won’t get support. I’ve been told that the downsides outweigh the benefits. I’ve been told many things in defense of the status quo, with little in the way of evidence provided. Being a professional think-outside-the-boxer, I shrug such unjustified claims off in pursuit of the alternate. The status quo prioritizes the centralization of security talent, presumably for alleged efficiency benefits that happen when organizations optimize for one thing, but the security expertise is second to that which they are securing. As a result, secondary security organizations will spring up where they are needed and be largely separated from the existing security organizations. While I am sure that what I am to suggest does, in fact, have downsides, I have not yet been presented with them. I welcome you to challenge my proposal in pursuit of a better security industry.
As may have been hinted in the opening sentence of this piece, the gist of this proposal is that the security organization should report independently either directly to the CEO, or to the Board of Directors. This enables the security organization to operate independently without downward pressure from organizations whose entire purpose is to get products out the door faster or make as few changes as possible to maintain service uptime. I took business classes, I have a business degree, I know that businesses care about making money and that security doesn’t make money. However, that does not mean that we can’t improve upon the efficacy, efficiency, and accountability of the security organization.
Excuse me while I put on my best Bill Nye impression…
Scenario
Your corporate IT team is about to deploy a new agent to all workstations in order to collect key statistics about those workstations and migrate off an expensive licensed product. They are at the tail end of their deadline and the CIO is applying downward pressure to deliver. The CISO, who often reports to the CIO, is in charge of securing the corporate assets, and is also feeling the downward pressure to get this software deployed before the licensed product is up for renewal, potentially costing millions of dollars.
The security assessment gets scheduled for the week before the deployment date, because they needed plenty of time to test reliability, stability, impact on the rest of the system. The security assessment turns up a critical vulnerability that impacts the deployment of this agent. The security team reports back to it’s shareholders and they have to make a decision - halt the deployment for an uncertain amount of time, causing the organization to miss deadlines that upper management was adamant about, or roll out the deployment and try to fix it after the fact.
This may sound implausible, especially if you’ve not worked in a large organization, however this is very often exactly how technical debt comes to be - in this case it is simply applied in a security context. The CISO is under pressure from the CIO, and the CIO wants this deployed so that they can provide some key statistics to the CEO or to the Board. The chain of command dictates that the CIO can overrule the CISO, and in fact pressures can be applied to hide the very existence of the vulnerability.
Perhaps this is less likely to happen in a corporate IT environment, where it’s less likely to have a direct impact on the bottom line. But one place where it is almost certain to happen is in products and services that are customer facing. Products that are shipping to customers, services that are deployed for customers to use. The choice to not deploy something (usually) has (somewhat) clearly defined monetary losses. So the pressure from your product teams will be to get things out the door as quickly as possible to ensure the corporate earnings report still looks good.
Because of the way security organizations are largely siloed from the organizations they are meant to secure, they are frequently brought in for security advice long after the design phase has completed, even in your beloved “but we shifted left” organizations. Even when security organizations are meant to interface with teams early and often, there are resourcing constraints to consider. Limited security resources being pulled in many different directions results in things slipping through the cracks more frequently. Teams end up waiting on security to get back to them, or moving forward without security and assuming that they can simply retrofit security’s advice. We’ve likely all seen how well that works out.
Proposal
I believe, for the integrity of the security industry, we need to hold ourselves more accountable to our organizations. The Chief Information Security Officer should report directly to the CEO as a first order “Chief”. The reporting structure should be entirely independent of those organizations they are chartered to secure, however the personnel should be closely integrated with their partner teams. Everyone responsible for security in the company belongs to this security organization, but works on a daily basis primarily with people who do not belong to the security organization.
You may be tempted to say “We can make a security champion program!” But, dear reader, this misses the point almost entirely. While I will concede that having a security champion program across your company is better than not having those security contacts across the company, it does not improve the accountability of the security organization. Security Champion programs most typically recruit from non-security personnel who have an interest or knack for security and then give them additional volunteer responsibilities for which they are not additionally compensated. These personnel still report to whoever they reported to in the first place, and therefore still have downward pressure to look the other way if something could get in the way of the S.S. Ship It.
The important elements of this newly renovated security organization are their independence, their accountability, and their integration with the rest of the company.
Integration
Consider this new organization a corporate security network; a network of distributed teams that work closely with their partner organizations to ensure security is involved in the very first roadmap meetings, the very first design meetings, all the way through to the final approval to ship the product. Instead of having a security architecture team that works with everyone to implement security architecture on a wide range of products and services that they don’t necessarily know very well, you’ll have numerous security architects that work closely with a family of products or services and know them extremely well.
Independence & Accountability
Next, we talk about the independence and accountability, which go hand in hand. These teams all report up through the CISO as an independent entity, such that if a product wants to ship with known security flaws, decisions are made at the executive or vice president level. Those known security flaws are then well documented internally, independent of the engineering organization who wants to ship them. An exception process for engineering teams should be made so that security flaws are clearly documented and the appropriate people in both management chains (security and engineering) have signed off on them as known and accepted risks. If you want to get really crazy, consider requiring a remediation plan and timeline for the exception to be approved.
Exceptions
Now, there are some security teams where this model will struggle - primarily those that are often served by the corporate IT/Security teams, such as threat and vulnerability management or detection and incident response roles. There should be a few well staffed teams reporting to the CISO that handle these functions in a uniform manner for the entire organization. Similarly, there should be a dedicated team that is responsible for setting, maintaining, and communicating security standards and policies across the entire organization - different departments should not be given the responsibility of creating their own standards. A company with disparate security standards that each apply to different teams makes it incredibly difficult to effectively manage. It creates more cracks, and those cracks are where the accidents happen. The headlines won’t care that Company A Subsection B got hacked, they will leave it at Company A.
I didn’t include Offensive Security, my home team, in the above list. I admit that I am on the fence about where to put Offensive Security. There are clear (to me) benefits to having a distributed red team that lends their offensive insights during the design and development phase, as a form of adversarial analysis or adversarial design review. Pentest teams (these are not the same as red teams, a topic for countless debates and blog posts) should also be relatively independent, however for the most effective use of resources, I believe it would behoove pentests to be conducted by a mix of people who know the architecture well and those who bring a completely outside-the-box approach.
Errata
It is likely that there are some other teams that I am forgetting. I am not forgetting compliance because compliance is, or should be, a separate independent entity from security, for the same accountability reasons that I am proposing for security organizations. If I forgot your team, please write me a long email berating me for this unintentional slight in your general direction. My email address is dev null at actual crimes dot org.
Conclusion
If I may leave you with one piece of parting wisdom (for varying definitions of “wisdom”), let it be this: Your security organization is not the place for the proverbial yes-man. Organizational culture should encourage your security personnel to feel comfortable explaining why something is a bad idea, whether to an engineering team, to a sibling security team, or even to the CEO directly.