Jiri’s Notepad

We had a vigorous discussion on this topic at work and I thought it would be useful to some of my thoughts for re-use.

Despite us having much better methods and much improved information on vulnerabilities and threats, how is it that the decisions always feel to security practitioners only half right, leading to less than desirable outcomes? I found that quite often it is the irrational and subjective aspects are the driving for security decisions. And it is my opinion that what most researchers and practitioners have underestimated social dimension of decision making. It is my attempt here to tease your interest and draw your attention to the little discussed, yet important topic.

There are two types of decision making processes available for security projects: first for projects whose objectives are primarily risk prevention, second for those providing some tangible value. Most security projects (be their infrastructure, applications or policy/procedure) will fall into first category. Obviously, in real world a project will have traits of both, but a one will be prevalent influencing the decision making style, so for our purpose, I will keep talking about two types of projects.

Risk prevention projects
Security decision making has been traditionally firmly linked to risk analysis. Recently, security folks have had a keen interest in security economics, the economic downturn post dot-com lead to general preoccupation with return on investment.

There is a problem (or shall we say feature) with all methods used in IT and that is their neglect social aspects of their execution. So even though ‘decision making process’ creates an impression of solitary activity, in reality it is a social process with series of steps involving various stakeholders. As security is about rules for what is allowed and what not, it is also a political process. Because of this, the process involves rationality as well as guesswork; it involves analysis as well as communication.

Many organisations do use some kind of qualitative risk analysis methodology to justify decisions managers make on security; some industry sectors have taken this further and develop very detailed and specific methodologies. Yet, my observation has been that for the purpose of for business decision making, risk calculations are mostly irrelevant. Instead, business managers make security decisions based on few rules of thumb:

One: What is a common level of protection?
Two: How scared am I?
Three: Do I really have to?

Although there are going to be individual differences, I found these two factors are typically similar in an industry sector. They can change over time, mostly as a result of major security incidents and security features or products. Even when a third factor comes into play (regulatory compliance). But even then they are eying other companies to see if the regulations have actually any teeth (compare with most companies ignoring Data Protection Act).

“What?!” I hear you you saying. “That is unacceptably cynical and pessimistic view of the world. Risk analysis is key to rational decision making!”

As a way of explanation, let’s look at a simple decision making process at WidgetCo, a fictional manufacturing company which is working on deployment of the new ERP system. The architecture stages of the system is half way through, and so the system’s scope, objective, functionality and underlying technical architecture have been sketched out. As a first step of the security decision making, Frank, the security architect reviews the system architecture and carries out risk analysis (using whatever tools are available). Then he identifies proposed measures and develops cost & benefits case. He then presents the case to Carol, the project lead architect, who looks at it from a broader solution perspective. Once Carol is happy with the proposal, Frank will have the unenviable task to have the 5 minute presentation to Bernard, the project sponsor. Looking at ‘what do I get for my money’ perspective, Bernard will grill Frank and Carol on the proposal, challenging anything that he/she sees out of norm, requesting amendments to be made according to his wishes.

Who is the business decision maker in this scenario? Ultimate accountability is Bernard’s. Frank is responsible for providing security recommendations, Carol is responsible for ensuring they fit with the broader solution, but it is Bernard, who is the budget holder, who has the authority to actually make (or confirm) the decision.

In some cases the security architect may be lucky that the budget holder understands security concepts, more often the budget holder will be a person without security background without any great depth in the subject matter. How people make decisions about subjects they are not experts in? They revert to common sense. The two factors I outlined earlier, (’What is common’, ‘How scared am I’) are examples of such common-sense decision making approaches applied to security.

Assuming Frank has reasonably good analytical tools to make recommendation, the rest of depends on his and Carol’s influencing and communication skills convincing Bernard that the investment is good for the business and the project. Method as important as it is is only one part of the success here.

Tangible benefit projects
Then there is the second type of decision making, which applies to projects (or aspects) that bring some tangible benefit. This can be either measurable (cost reduction, improved SLAs on time to provision account or set of privileges) or non-measurable but still tangible (e.g. single sign-on). There is fewer of them in security arena and in my opinion, their justification is in my experience much more straightforward. Both Carol and Bernard will be much more used to judge the value of investment which does brings something tangible. As far as methods for developing a business case for projects which have tangible benefits, these are well developed, be they return on investment, total cost of ownership or others, whichever are more appropriate to the organisation at hand. Again social skills will matter as much as the justification itself. If going against an entrenched interests (e.g. switching from Tivoli to CA as the provisioning product), you can expect the decision will become political rather than rational discussion on merits of the proposal.

Conclusion
To conclude, methods do matter, but as the decision making is a social process, so do people’s skills. Thinking about that, whereas skills of people providing recommendations can actually compensate for the deficiencies of the method, better method cannot compensate for the lack of skills of people. So, the skills probably matter slightly more than the method.