"Security": Whose Responsibility?
I assume readers of this blog are familiar with the "CIA" triad of information security: confidentiality, integrity, and availability. Having spent time with many companies in consulting and corporate roles, it occurred to me recently that two or even all three of these functions are no longer, or may never have been, the responsibility of the "security" team.
The diagram at left depicts this situation, so let's examine each item in turn.
Availability is probably the defining aspect of IT. If the resource isn't available, no one cares about much else. Availability problems are almost exclusively the responsibility of IT, with "uptime" being their primary metric.
One would expect confidentiality to be fairly central to any "security" team's role. Exfiltration of data is partly a confidentiality problem. However, the biggest headache in the confidentiality world has been disclosure of customer personally identifiable information (PII) via loss or theft of physical assets (laptops, backup tapes) or electronic exposure. Companies now employ dedicated Privacy teams, usually staffed predominantly by lawyers, to specifically address the handling of customer PII. One might have thought the "Security" team should have had responsibility for this subject. Instead, a legal problem ("Do we have to disclose the breach to customers and/or the public?") is being addressed by lawyers.
Integrity is the last of the three, and originally I thought it would be the core "security" task for the "Security" team. Then I remembered Sarbanes-Oxley and Section 404. I wondered if the Audit Staff's requirement to assess the "integrity" of records meant they had a more institutionalized role in this area than the "Security" team.
So what does this mean for "Security" teams? Looking at the problem in one way, you might think there is no need for a Security team. CIA is covered by three groups, so Security is redundant. This is a mistake for the following reasons.
I believe this state of affairs leaves the Security team as the one group that has the proper mindset, subject matter expertise, and ability to implement defensive operations to preserve CIA. This mission is not one the Security team accomplishes by itself, if that ever were possible. Rather, Security will (if not already) need to pair itself with IT, Audit, and Privacy in order to be effective. One could say the same for and Compliance groups, Governance officers, and/or Physical Security teams, although I'm less worried about those ties right now.
It should be clear at this point that it doesn't make sense for the Security team to work for IT, given the role it must play. A Security team working for IT is likely to be stuck supporting the Availability aspect of "security" at the expense of the other CIA elements. Furthermore, it could be difficult for Security to build the necessary bonds with Audit and Privacy if those groups see the Security team as "just part of IT," or "technologists."
In this light, it makes sense for Security (CISO) to be next to IT (CTO) in the corporate hierarchy, both working for the CIO. Ultimately the CIO is responsible for the company's information, so I don't see a way for [information] Security to be beyond the CIO's reach.
How does this review compare to your own experience?
The diagram at left depicts this situation, so let's examine each item in turn.
Availability is probably the defining aspect of IT. If the resource isn't available, no one cares about much else. Availability problems are almost exclusively the responsibility of IT, with "uptime" being their primary metric.
One would expect confidentiality to be fairly central to any "security" team's role. Exfiltration of data is partly a confidentiality problem. However, the biggest headache in the confidentiality world has been disclosure of customer personally identifiable information (PII) via loss or theft of physical assets (laptops, backup tapes) or electronic exposure. Companies now employ dedicated Privacy teams, usually staffed predominantly by lawyers, to specifically address the handling of customer PII. One might have thought the "Security" team should have had responsibility for this subject. Instead, a legal problem ("Do we have to disclose the breach to customers and/or the public?") is being addressed by lawyers.
Integrity is the last of the three, and originally I thought it would be the core "security" task for the "Security" team. Then I remembered Sarbanes-Oxley and Section 404. I wondered if the Audit Staff's requirement to assess the "integrity" of records meant they had a more institutionalized role in this area than the "Security" team.
So what does this mean for "Security" teams? Looking at the problem in one way, you might think there is no need for a Security team. CIA is covered by three groups, so Security is redundant. This is a mistake for the following reasons.
- The IT staff is not equipped to resist attacks, especially advanced ones. IT usually does a good job keeping resources functioning when equipment failure, provisioning woes, or misconfiguration causes downtime. IT is usually ill-equipped to stop intelligent adversaries who are three steps ahead of overworking administrators.
- If an IT staff can't handle attackers, there's no way lawyers can. Lawyers tasked with security responsibilities usually outsource everything to high-priced consultants. Legal teams have the budgets for this, but it's not a sustainable situation. Privacy teams focus on salvaging the company brand and market value after a breach; they are not positioned to resist or detect incidents.
- Auditors look for problems and effect change, but they do not implement change. They look for weaknesses in processes and configurations, not intruders who have exploited those vulnerabilities.
I believe this state of affairs leaves the Security team as the one group that has the proper mindset, subject matter expertise, and ability to implement defensive operations to preserve CIA. This mission is not one the Security team accomplishes by itself, if that ever were possible. Rather, Security will (if not already) need to pair itself with IT, Audit, and Privacy in order to be effective. One could say the same for and Compliance groups, Governance officers, and/or Physical Security teams, although I'm less worried about those ties right now.
It should be clear at this point that it doesn't make sense for the Security team to work for IT, given the role it must play. A Security team working for IT is likely to be stuck supporting the Availability aspect of "security" at the expense of the other CIA elements. Furthermore, it could be difficult for Security to build the necessary bonds with Audit and Privacy if those groups see the Security team as "just part of IT," or "technologists."
In this light, it makes sense for Security (CISO) to be next to IT (CTO) in the corporate hierarchy, both working for the CIO. Ultimately the CIO is responsible for the company's information, so I don't see a way for [information] Security to be beyond the CIO's reach.
How does this review compare to your own experience?
Comments
I think you are right about the optimal functional placement. You have a sound argument. I just think that capable leaders can find ways to work around obstacles like organizational hierarchy.
You've probably looked at other factors that lead to optimal performance for that role. Do you see hierarchical placement as a critical factor or are you just attempting to present a justification for what makes most sense?
1.) There is usually an assumption of equal value to an organization, i.e. valueofC=valueofI=valueofA. This is generally false.
2.) The value of C,I,A to an organization isn't easily quantified, so they end up getting an ordinal scale. What follows can only be described as logical carnage, exercises that make the brain ignore so many fallacies that you'd have to be lobotomized or on prozac to noddingly accept the gross arithmetic sadism.
As far as corporate hierarchy is concerned - I can see where the CISO function might be beholden to the CRO or CFO if they are ultimately responsible for ERM.
If I had to choose, I would agree that Security (all functions) should be it's own island and not dissected among IT/IRM & ERM/Physical Operations.
The problem is one of perception. So long as security is not independent of IT, it will never be seen as the arbiter of all three corners of the triangle, capable of balancing the privacy concerns of the lawyers with the availability concerns of IT and the integrity concerns of the audit function.
That's what security needs to be. The professionals who bring together the three teams to arrive at an optimal result; in protection from attack, in detection of attacks and in investigation and remediation after successful intrusions.
Systems, applications, and networks must be designed from the start to afford complete visibility, so as to effectuate total control. There is no way that a siloed security group can adequately support these objectives.
There's certainly a case to be made for a distinct opsec group who respond in real-time, but again, they can't be divorced from IT operations, else they'll be disbanded the first time they botch a response and end up making things worse.
Interesting dilemma. :) In my own thoughts (but not experiences as of yet), it would seem self-defeating to have security outside of IT. To me, that seems to remove so much technical ability, access, and insight from the security team.
On that same note, the CIO must be willing to hear the news that may go against the operational needs of the division. If he/she cannot accept the fact that there may be legal/privacy/security issues with an existing/new IT product, then the security department is doomed to remain in the back seat and never to be truly integrated within the company. This also brings other issues up though such as the security department ensuring it has a consistent and reasonable method for evaluating these risks. That’s a different topic altogether though.
I have heard many arguments through the years that IT Security should fall outside of IT. There are pros and cons to both sides. Personally, if you can have a good relationship with (and the respect of) the CIO and have the business integration within the division, then I feel it is more advantageous to exist within IT. Being within the division enables the team to be closer to the issues at hand and therefore part of the solution. Again though, that is dependant upon many factors but primarily the division’s acceptance of the department and security’s inclusion with ongoing projects. Being outside the division distances you further away with a function (or maybe perception) more like an audit agency. It also strains the ongoing challenge for your technical staff to work with the operational IT teams for the purpose of on-the-job training. That’s a difficult enough task as it is for security.
I would find it interesting to know of departments who do fall outside the more common IT division tree to hear how they overcome these issues.