Structuring Infosec Organizationally

Interesting Finds: June 4, 2006 AM edition

Jason Haley — Sun, 04 Jun 2006 18:05:54 GMT

re: Structuring Infosec Organizationally

Bernd Eckenfels — Mon, 05 Jun 2006 01:33:24 GMT

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

re: Structuring Infosec Organizationally

jesper — Mon, 05 Jun 2006 09:23:53 GMT

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.

re: Structuring Infosec Organizationally

Bernd Eckenfels — Mon, 05 Jun 2006 16:26:24 GMT

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

re: Structuring Infosec Organizationally

Alun Jones — Mon, 05 Jun 2006 18:15:33 GMT

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.

re: Structuring Infosec Organizationally

jesper — Mon, 05 Jun 2006 20:21:56 GMT

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.

re: Structuring Infosec Organizationally

jesper — Mon, 05 Jun 2006 20:30:35 GMT

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?

re: Structuring Infosec Organizationally

Alun Jones — Mon, 05 Jun 2006 22:42:04 GMT

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

re: Structuring Infosec Organizationally

Bernd Eckenfels — Tue, 06 Jun 2006 02:07:55 GMT

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

re: Structuring Infosec Organizationally

Yuri — Wed, 07 Jun 2006 22:43:26 GMT

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

re: Structuring Infosec Organizationally

Adrian Sit — Thu, 08 Jun 2006 07:45:40 GMT

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.

re: Structuring Infosec Organizationally

Dewi Morgan — Thu, 08 Jun 2006 19:04:45 GMT

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.

re: Structuring Infosec Organizationally

jesper — Fri, 09 Jun 2006 08:51:18 GMT

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.

re: Structuring Infosec Organizationally

Dewi Morgan — Sat, 10 Jun 2006 01:43:37 GMT

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

re: Structuring Infosec Organizationally

umacf24 — Sun, 11 Jun 2006 03:21:27 GMT

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.

re: Structuring Infosec Organizationally

Mick — Tue, 13 Jun 2006 07:01:21 GMT

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

Structuring Infosec Organizationally | Secure Software Engineering Blog

Structuring Infosec Organizationally | Secure Software Engineering Blog — Sun, 02 Mar 2008 22:12:35 GMT

PingBack from http://www.secure-software-engineering.com/2008/03/02/structuring-infosec-organizationally/