unix and linux commands - unix shell scripting

Risk paralysis


 
Thread Tools Search this Thread
# 1  
Old 05-23-2008
Risk paralysis

One of the zombie threads on CISSPforum (i.e. one of those discussions that seems to die off ... but then a few weeks later comes back from the dead to haunt us all over again) is about quantitative versus qualitative risk analysis. Members of CISSPforum typically fall into one or other camp and the discussions, while interesting and passionate, always seem to generate more heat than light in a security geek's version of religious war. While fans of quantitative methods point out the need for data to support assertions about information security risks with "facts", the qualitatives point out the lack of data and various other reasons to rely on "experience" or "gut feel".
... Meanwhile, Rome is burning ...
A fascinating post on the Israeli Software blog draws a parallel with risk analysis methods used by fighter pilots. In a dogfight, pilots are inundated with an avalanche of real-time safety- and mission-critical information coming at them from all manner of systems and senses. Time is very obviously 'of the essence' so successful fighter pilots need lightning-quick reactions, but more than that they need to react appropriately. Blogger Danny Lieberman outlines the OODA loop, a risk analysis process originally described by military strategist John Boyd. It's a cycle with four steps:
Observe --> Orient --> Decide --> Act --> rinse and repeat
Harry Hillaker (chief designer of the F-16) said of the OODA theory, "Time is the dominant parameter. The pilot who goes through the OODA cycle in the shortest time prevails because his opponent responds to actions that have already changed."
Anyone familiar with ISO/IEC 27001 will probably see similarities with Deming's PDCA (Plan, Do, Check, Act) cycle. Whatever the precise nature of the steps, cycle time is important in any fast-moving situation. It's no use 'fighting the last war'. In many situations, it's better to make assumptions and move ahead quickly than to procrastinate, provided that the cycle repeats, in other words we need to review our actions in the light of experience and make adjustments where necessary.
ISO/IEC 27005 is a draft information security risk management standard revising the Management of Information and Communications Technology Security (MICTS) standards ISO/IEC TR 13335-3:1998 and ISO/IEC TR 13335-4:2000. The scope of ISO/IEC 27005 is to: “provide guidelines for information security risk management. This International Standard supports the general concepts specified in ISO/IEC 27001 and is designed to assist the satisfactory implementation of information security based on a risk management approach.” Like ISO/IEC 27001 and '27002, '27005 avoids the issue of whether to recommend quantitative or qualitative risk analysis methods, instead advising organizations to use whichever methods suit them best for the particular situation at hand - note "methods" with the implication that, for example, high level broad scope risk assessment might be supplemented by detailed risk analysis using different methods. If the organization already has well-developed methods for assessing and reacting to risks in other spheres (such as financial risks, legal/compliance risks, health and safety risks etc.), it may even make sense for management to adapt those methods to information security risks rather than be forced into using a specific but unfamiliar method.
Danny sums up his blog entry with a call-to-arms:
"It is clear that the root cause of the increasing spiral of security breaches is that the attacker community moves much faster than business today."
Does your organization cycle rapidly, assessing current information security risks, implementing control improvements where necessary and re-assessing risks, or is management locked in the analysis phase, paralyzed like a bunny caught in the headlights? Even worse, is the fruitless discussion about which risk management method is best sapping your strength to analyze anything?
Gary Hinson CISSP
Passionate about security awareness
www.NoticeBored.com Creative awareness materials
www.ISO27001security.com ISO/IEC 27000 standards


More...
Login or Register to Ask a Question

Previous Thread | Next Thread

1 More Discussions You Might Find Interesting

1. Solaris

question about shell risk??

Hello, I want to know are there any risk if I do not allow user to have any shell access. (actually, I do not know about Solaris much) Well, what I understand is if I do not assign any shell access to a user, then those user cannot access command line. So, they should not have any risk to... (1 Reply)
Discussion started by: Smith
1 Replies
Login or Register to Ask a Question