Jesper's Blog

Obligatory file photo: I am a Senior Security Strategist in the Security Technology Unit at Microsoft. My job is to explain to our customers how to run Microsoft products securely, and to the extent that it is needed, help the product groups figu

Blogs

Structuring Infosec Organizationally

  • Comments 17
  • Likes

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
  • I think removing availability from the list of goals is a typical sign for security folks who lost contact with reality.

    It is after all the number one goal for the business to be able to work with the secure data. If you dont want to have your secured data available, you can just not store it.

    Backups and Sobotage Prevention is a key point in most data driven business. And of course there is kind of problem to keep data available and secure but that exactly is what a good security officer has to care for.

    You cant go the easy road and deny the fact that your data is needed. (In fact in germany for example it is forbidden to have person related data which is not needed).

    Gruss
    Bernd

  • 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.

  • 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...

  • Organisational divisions are, as you suggest with the phrase "logical for many organizations", going to be dependent on how the organisation is structured.
    What's important is to make those decisions with an appropriate understanding of the risks that you have to manage.
    When you first talk about security, in reference to computing, most people think that you're talking only about preventing a hacker from logging on and accessing data. There's so much more to it than that.
    Reliability/stability; accessibility; data retention; data destruction; auditing; theft prevention, detection, prosecution; forensic analysis; separation of duties; etc, etc.
    The one that seems to be frequently missed by most security discussions is that of logging or tracing, so that after a security event has happened, its parameters can be measured and reported on.
    An example of this is the "flatten and pave" methodology for fighting viruses - unless you have an idea how the virus got in, and address that, the new machine will get infected in exactly the same way.

  • 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.

  • 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?

  • "Khan's thinking is two-dimensional".
    We're so used to thinking of an org-chart, where employees sit "under" a structure, that we forget that there are jobs that don't really fit that structure.
    IT has always been one of those fields where there is a requirement for a "generalist", who is nominally an IT employee, but gets farmed out to various other branches / departments to discern need, to assess products, to implement solutions, to train co-workers, and then to move on to the next project.
    InfoSec is another - in a document-heavy environment, maybe InfoSec resides with document retrieval / retention / destruction, or maybe the other way around, with document management being a subset of InfoSec under IT.
    Corporate organisational structure is - or should be - fluid.  Each year, you investigate what you do as an organisation, what you should do as an organisation, and each component department should do the same.  Who are your customers?  Who should they be?  What services and products do you provide?  What services and products do you consume?  Where should you be getting those services from?
    Then assess whether your organisation closely or loosely fits that description of where it wants to be going, and make the fit closer.

  • 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, ...)

  • 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!?



  • The role of infosec spans across execution and assurance. It is not the responsibility of just one guy or one department. It spans across departments.

    I was once an IT Security officer who worked under the IT department. I wore 2 hats. On one hand, I led IT security projects to implement various safeguards enhance the overall security level. On the other hand, I assessed the effectiveness of controls. The roles were in fact conflict to each other, i.e., I was auditing myself. But since there was trust between me and the management, they were happy with the results and they have never queried my independence.

    Now I am working under the internal audit department. My life is simpler. We have an IT security policy. The IT department is responsible to execute the policy, i.e., implement respective controls and practices into its daily operations to deliver systems and services with reasonable security level. I, as an IT Security Officer, have to assure that these controls are effective and comply with Company’s policy (smell like an IT auditor). Now, I don't need to worry schizophrenia any more.

  • 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.

  • 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.

  • "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."

    Bingo. Yet you propose to remove "availability " from the triad of concerns for the people who bother with "security" and "integrity". So, you propose making the situation worse, rather than making it better by ensuring that each department has a security policy for its own responsibilities, and CAN'T pass the buck.



    "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?"

    The skills required to do their job. In any company, they are the ONLY ones trained to accomplish their jobs.

    Given groups:

    accountants
    IT people
    security guards
    programmers
    cleaning staff
    janitorial staff

    And domains:

    payroll information
    IT systems (firewall rules, virus update rollouts, etc)
    locations
    in-house programming code
    dangerous cleaning chemicals
    explosive fuels

    Which of the above domains that you feel should NOT be the responsibility of the people involved, and instead should be centralised under the responsibility of another party?

    Now, I gather from your talk transcripts and your writings here that your usual concern is the "Very Large Companies", and that you have little experience or interest in small to medium enterprises.

    And I concede that in a vast company like Microsoft, or a petrochemicals company, having someone who's sole job is to be in overall charge of overall security is probably a good plan.

    And even to spit IT in two: user support and system administration, is fine. But to create a new field, "security team", is taking it too far, and does not work in practice (in my experience at least)

  • Sometimes I have my workspace among the helpdesk operators and I learn what's happening there. Sometimes I have my workspace on the infrastructure desk and I learn stuff there. I'd like to sit among the project people and learn stuff from them, but they don't like it. Apparently I get in the way of implementations.

    I think you're absolutely right. Risk inherent in processing information needs to be managed by the risk team, and that should be out of the operations reporting line. But most information risk management tools amount to simple rules like locking files up at night, not faxing the customer list to the competition, separating roles and vetting new hires -- it's mostly in IT that it blossoms into this huge intricate web of process, policy, practice, audit and rectification. That is an IT job, and if it's left to people whose job description doesn't have Security at the top, it won't get done.

    So my view is that the Information Risk Manager works for risk, and there's a technician in IT feeding the IRM with risks and changes, authorising some of the touchier changes and pursuing the endless cycle of rectification and policy. That technician's job is impossible for the reasons you describe, but it can still make a difference.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment