Structuring Infosec Organizationally
Last week I visited a customer and was greeted by two people who introduced themselves, respectively, as the "Chief Information Security Officer" and the "Chief IT Security Officer." Yes, they had two separate functions for this, one to secure information, and one to secure IT. This immediately seemed like something that would be logical for many organizations. The threats to the infrastructure are obviously different to the threats to the information itself, especially when your business is based on providing one or both to customers.
This stirred me to think more about something I have been mentioning in many of my recent presentations: where does Infosec (both IT and Information for ease of discussion) belong organizationally? When I spoke to a bank recently I asked them where Risk Management sits organizationally and they mentioned there was a VP in charge of that, but that Infosec was sitting in the IT department.
I am not sure I have the right answer about how to structure organizations, but I am pretty certain that putting Infosec under IT causes certain problems. As far back as the Fundamental Tradeoffs article, and even further, I have made the argument that security and IT management are fundamentally two different disciplines. IT management has as a primary objective to make the technology work, to be transparent to people, to ensure the information is simply there when users want to use it. All of those can be summed up in the phrase "to stop the phone from ringing." Any IT manager knows that he phone usually does not ring when things are working; it only rings when something is broken.
Security is, obviously, about restricting access to things. As far as the business is concerned, Infosec provides no intrinsic value. Spending money on Infosec is done to ensure that nothing happens. Success is measured by the absence of events, which could of course be because the efforts of the Infosec folks were successful, or simply because there were no events at all; or possibly because we failed to notice. IT at least provides a valuable business function that is tangible in its absence. The absence of any benefits from the spend on Infosec may be attributed to something extrinsic to the Infosec group; and the benefits are extremely difficult to quantify a priori
This inherent conflict of objectives has been acknowledged before, most famously in the "Confidentiality/Availability/Integrity" triad. However, I would argue that the "Availability" dimension was added by IT management, not by the security folks, because it goes entirely counter to the other two dimensions. Those other two dimensions are best achieved by reducing availability, first to illegitimate users, and then to legitimate users to avoid a spill-over of information to the illegitimate ones. In fact, the CIA triad reflects the historical perception that Infosec somehow belongs in IT. I don't think that is correct, at least not any longer, but maybe it never were.
So why am I writing this? I am writing it because I would like to stir some debate about where Infosec belongs. I think it should sit wherever Risk Management sits (which of course means the organization needs a Risk Management group to start with). The whole purpose of Infosec is risk management. The group that has risk management as its responsibility has oversight ability, it has the skills to assess and quantify risk, and it has a mandate to influence other groups. That group also does not have to be restricted by pecuniary and functional concerns that restrict the service delivery organizations. Infosec obviously needs a deep relationship with IT, but also with other groups. I have seen far too many organizations that have caved to the pressures of service delivery or inaccurate vendor claims and implemented extremely bad security architectures. Invariably, the Infosec folks at the table were too few, too restricted by the organizational structure, too confined in a career dependent on service delivery and not security, and too worried about rocking the boat politically to put a stop to the problems.
Freeing Infosec from IT would allow IT to focus on delivering IT services, and it would allow Infosec to make itself heard and not be voted down by a much larger service delivery constituency in the mainstream IT group.
Comments
Anonymous
January 01, 2003
PingBack from http://www.secure-software-engineering.com/2008/03/02/structuring-infosec-organizationally/Anonymous
June 04, 2006
The comment has been removedAnonymous
June 05, 2006
Bernd, I am not advocating removing availability from the goals. You misunderstand. I am simply advocating considering that goal separately from the others, possibly making it a goal for a different organization. The point of my argument is that a dialectic process between availability and the other two goals is extremely useful to arrive at the right trade-off, but if the security folks are also goaled on availability, they risk neglecting the other two goals. Availability is so tangible to everyone who needs the information or services, while the other two are not, that it risks overshadowing the other two. By not forcing the same people to be measured on both dimensions it is possible that we will come up with a more thorough and valuable decision making process. I am not sure about that, but I have seen many organizations make decisions that compromise confidentiality or integrity, or both, and when I inquire as to why, it turns out the security group was goaled on availability and got swept up in the mainstream of IT that considered only that.
Ideally we would of course have people who could internally make decisions about the three dimensions without forgetting one or the other. Realistically, each person will focus on one end of the spectrum or the other though.Anonymous
June 05, 2006
Jesper, yes I was not implying that you want to remove that goal. I just wanted to point at the typical vie point of some security proessionals. Some even think that the user is the main security problem... instead of accepting the fact that it is the main reason for their job to exist... enable people to work...Anonymous
June 05, 2006
The comment has been removedAnonymous
June 05, 2006
All very good points Alun. So does that mean you think Infosec belongs in IT, or simply that we do not think broadly enough about Infosec? I'd agree with the latter, but maybe that is the reason Infosec does not belong in IT?
As I said, I am not convinced my argumentation is correct. I am simply trying to explore it and see if we can generate some thoughtful discussion about it and thereby come up with a good recommendation.Anonymous
June 05, 2006
Bernd, I am still chuckling at your comment. I presume you saw this: http://www.microsoft.com/technet/technetmag/issues/2006/07/SecurityWatch/default.aspx?
I think a big part of the problem is myopic thinking among otherwise very smart people. I've started thinking about that a lot too. Thinking broadly is important, but many people have a hard time doing it; particularly when it comes to relating experiences from one field to problems in another. Maybe it is our modern, western, organizational management style, focusing us primarily on our "commitments" or "goals" for the year that is causing that?Anonymous
June 05, 2006
The comment has been removedAnonymous
June 05, 2006
IT adopters 25 years back had the IT departement attached to the OU which invested in the application (typically Financials). This trend continued some time and sometimes the internal organisation departement has also run the IT. In more modern organisations IT and controlling are the only cross section OUs anymore. And IT was defacto pretty close to some business processes, even if they never admited it.
There are now two trends in IT:
a) to get into the mediator role and do process coaching (because of deep process and analytical know how)
b) to get out of the content business and be only the anabling infrastructure platform because it is "such an easy problem domain".
The second position is quite understandable, and it is the same thing you find in some security positions. But I think it is not good to stay away from the work. So Security Professionals: get your hands dirty!
Gruss
Bernd
PS: Jesper, I am not a people person eighter, but at least I feel able to design solutions which expect the human factor (i.e. do not over regulate, dont think humans make no error, never stop someone from doing work, expect resitance, ...)Anonymous
June 07, 2006
Jesper,
The only problem I see in separating Infosec from IT is that both are interconnected and so dependent on each other, that disjoining them would actually start causing conflicts. My ideal I.T. Department would consist of valuable employees who are good at, "making the technology work" AND "ensuring that nothing happens." = )
As you have mentioned in your book "Protect your Windows Network", a System Administrator is not a Security Administrator. So where can we find that perfect balance?
Furthermore, when you say that, "freeing Infosec from IT would allow IT to focus on delivering IT services" wouldn't you agree that security and administration are very very hard to seperate making the "System Administrator cannot be a Network Administrator" theory only a theory and a very hard one to implement at that!?Anonymous
June 08, 2006
The comment has been removedAnonymous
June 08, 2006
You suggest dividing infosec into two independent groups:
Group A's role: ensure workers can work with data.
Group B's role: ensure bad people don't get data.
Both groups have administrative access to the systems.
"What would the world be like if this were true?"
Using your knowledge of corporate organisation, and of the requirements for an IT system, would either of the folowing be INCREASED under this system:
Security
Accessibility
I would argue that group A would in general not feel terribly obliged to inform group B of changes (new wifi access points, new servers, new laptops, new operating systems, new ports opened in firewalls, etc, installed to get people working). Even if they did inform group B, group B would always be one step behind, informed after the fact if at all. Group A's job is basically "undo or get around what group B did".
So, because security is not part of group A's thinking, it is no longer a factor in their decisions. It is "someone else's problem".
Group B in the meantime will tie things down impossibly tight, and will be slow to react to group A's needs. This will reduce accesibility, and increase
You're clearly not a people person if you think that giving different groups opposing criteria will accomplish either criterion better.
Yet this organisational structure exists, I've worked in it on the security side.
As an example of problems: rather than have both parties responsible for the firewall, only the security side were. Which meant that the IT dudes set up VPN tunnels through the firewall, from internal hosts to external hosts, in order to get people working NOW, rather than fill out a route-add-request-form and wait to see if it would be permitted.
I have also worked in places where every user was responsible for the security of the thing they manage: accountants are responsible for the security of the information they manage, IT people for the security of the systems on which the data resides, security guards for the security of the rooms, programmers for the security of the software used to manipulate the data. This is IMHO the correct solution since there is no conflict: you get maximum productivity and maximum security.
The answer is not to hive off security to its own little department that obstructs and is hated and bypassed by everyone: the answer is to have security as a central aim of every user, and a priority for every user's manager.Anonymous
June 09, 2006
Dewi, I never said that both groups would have administrative access to the systems. There is no reason for entire departments to have administrative access to all systems. That would be a very poor implementation.
You say that "group A" would not consider security because "it is someone else's problem." The concern is that this is already the case, even when it is their problem, because it is not the main problem they are solving.
The problems you cite are exactly the same kinds of problems we have today, with existing structures where security and IT are within the same groups. VPN tunnels through firewalls came about because the security folks failed to recognize that if they did not provide what was perceived as required business functionality the business would find a way to do so in spite of them.
Your solution that you mention where people are responsible for the security of what they manage is not a bad idea on the surface, but what skills do these people have in managing security? Now you would truly need an environment where more people than necessary have administrative access, including many who do not recognize what that means.
Instead, the data owner should classify their information based on a classification structure provided by the information security function. The information security function would also define the controls necessary for each class of data and the systems that control it, and this classification will be implemented by the IT department, which is audited by an audit function likely under the information security function.Anonymous
June 09, 2006
The comment has been removedAnonymous
June 10, 2006
The comment has been removedAnonymous
June 13, 2006
Maybe we need to think of IT Security accross the entire spectrum of business and of the IT lifecycle.
Certainly the idea of keeping the Information Security and IT Security as seperate entities works in theory if they both work as indepentant units. However the strict guidelines based on business and legal requirements also need to be designed, implemented, adhered to and reviewed.
Looking futher afield we need to ensure that all IT staff are performing there jobs correctly and adhereing to these guidelines. How often have a seen a helpdesk member to provide access to information to a specific user becuase he's or her manager has demanded it happen. This is not an uncommon practise in some large organisations as the helpdesk personal reside at the same level as the sandwich guy on the organisational chart. Yet this creates a problem for IT security personal.
An IT Security and Information Security delegate should really be an appover of all Change requests with an organistation and also have buy in to a number of other process boards including availability, incident and configuration management.
Finally the cooperation of Human Resouces to be prepared to tightly integrate IT security into induction and clauses for dismissal for all employees would help to ensure the guidelines are adhered too.
IT Security shouldn't be (to non technical people) a pain or frustration but reassurance that their information is safe and only available to authorised personel