Separation of Duties: InfoSec, IT and Audit
A colleague who had the opportunity to restructure the role of his InfoSec department asked for advice about defining the roles and duties and how to make his department more effective.
Being very conservative in some ways I recommended a traditional Separation of Duties. It begins with what might be described, for lack of a better term as "the separation of InfoSec and IT".
In the limiting case:
- IT "makes it so"
- Audit makes sure that they did.
in other words InfoSec addresses the areas you've expressed concerns about responsibility for by setting policy, standards and requirements (?compliance?). IT is responsible for the implementation, the hardware, the software, its installation and maintenance.
It can be an easy sell if you approach it properly.
| You: | See that firewall? |
| IT: | Yea, what about it? |
| You: | Its on the network, right? |
| IT: | Yea, where the f*** do you think it should be? You bu**ers are always interfering. |
| You: | And you guys take care of the network and stuff on the network? |
| IT: | When you bu**ers don't interfere. |
| You: | Well we're not going to. Its yours. We won't touch it. We won't go off and buy stuff and put it on your network. |
| IT: | Are you serious? |
| You: | Yes. |
| IT: | Can I have that in writing? |
| You: | Yes. I'll copy you on the roles & responsibilities and separation of duties documents. As well as the policies, compliance and audit requirements. |
Smile when you say that, but don't make it a predatory smile.
Yes, that makes it sound easy, but reality never is, is it?
That's why people buy books that offer the same kind of advice.
If you really want to work it through, try the books by The Harvard Negotiation Project:
* Getting to Yes: Negotiating Agreement Without Giving In
* Difficult Conversations: How to Discuss what Matters Most
* Getting Past No: Negotiating Your Way from Confrontation to Cooperation
* Getting Ready to Negotiate
Consultants, that is people with no formal authority in the hierarchy, may also appreciate
(Another time I'll discuss the stupid idea that some people in the recruiting profession have that because 'consultants' don't occupy a line-management role that they have no management skills or experience.)
The technical staff in the IT department may be perturbed in a number of ways. They might feel that their 'freedoms' are being removed and they are being 'policed'. Make it clear to them that YOU are not policing them. AUDIT is policing them. That is the correct corporate role for audit.
InfoSec is writing the specs - the policy, the requirements, and they are doing it in cooperation with not only IT but also with other stakeholders in the business and to make sure that the IT department is serving the needs of the business and not just collecting expensive "Toys For Boys".
This is no different from a software or hardware development situation, or, for that mater, the original set-up and procurement that went onto IT.
Someone did a needs analysis (even if it was only guesswork and estimations on a paper napkin), wrote up a requirement and handed it over to the people with a Picard-like order to "made it so".
I appreciate that this 'formal' approach is being depreciated by 'agile' methodologies where the techies work without any of the formal management structure, without specifications or formal requirement, writing and running their own tests, all in the name of "Web 2.0".
However the original idea as to set up a formal system of division of responsibility and duties and to deal with strengths and specializations.
Many people think that by fitting in with the power of a formal system they are giving up 'freedom'. They don't see the power of having all that organization (and buying power) behind them, of having defined roles that offload from them the detailed housekeeping that slows them down. They only think in terms of the Marxist cant about oppressive 'production lines' that dumb down the worker into an automation.
This is short-sighted and they know it if they'd stop and think about it.
Lets look at an example out of IT: The compiler - a tool that takes a high level requirement and specification and converts it to the fiddly assembly code - is one they accept. But some of us are old enough to remember the arguments against compilers, that they couldn't produce the same quality code as good assembly programmer.
Perhaps: that may have been true back 30 years but its not now. Now compilers are 'expert systems' in code generation for very complex CPUs and instruction streams and branches. Programmers recognise this and accept it, often without thinking very deeply about it - they just code in the HLL and the compiler "makes it so" that it runs on the machine. But even 30 years ago compilers could produce assembly code to match a 'good' assembly programmer - but at 10 to 100 times the speed and when used by a middling programmer who understood the subject matter of the application better than he did the hardware of the computer did a very good job of delivering the application program.
This is a classic example of abstracting and encapsulating specialized knowledge and division of labour.
I have no doubt that today's programmers would be upset if you took away their compilers.
What I am suggesting in this separation of duties between InfoSec, IT and Audit is no different from a doctor writing a prescription and the patient taking it to an apothecary to be filled. The apothecary isn't doing the diagnosis or needs analysis, but he still plays an essential role.
The "You" in InfoSec, have to understand business needs, regulations, compliance issues. The "Them" in IT have to understand the details of the technology they are working with. Each have their roles to play.
Its when people start interfering with these responsibilities, these 'separation of duties', that things get upset.
Related articles
"Paid to be paranoid"(infosecblog.antonaylward.com)
