Info-Sec Risk Management - Establishing Context
Posted on: 22-Jul-2012Author: cmk
Talking about information security without mentioning risk management is like talking about literature without mentioning Shakespeare or philosophy without mentioning Socrates. While every info-sec professional worth his salt will know his threats from vulnerabilities, the actual designing of a risk management program in an organization is often neglected. Most organizations hire consultants to define a methodology for them and dive into identifying threats, vulnerabilities and risks in reams of excel. ISO 27005:2008 tries to correct this process. It says boldly: “The context is established first. Then a risk assessment is conducted.” OCTAVE mentions a step “Establish Impact Evaluation Criteria” before getting into details of assets, threats, et al. Most standards mention the need for establishing some sort of context before conducting a risk assessment. So what exactly does an organization have to do to establish the context for a risk assessment? The basic objective of establishing the context of risk management is to know the risk appetite, or the level of risk that an organization is willing to accept for itself. How does one find that out? Here, I think ISO 27005 has on of the best ideas on how to establish context and hence will elaborate more on that, in a way that I think is the most implementable. To be able to calculate the risk appetite, the organization needs to know what exactly does it mean by ‘risk’ to business. Here, the lines between ‘risks’ and ‘impacts’ start to blur. For example, “not being able to maintain transaction logs” would lead to the risk of ‘regulatory or legal penalties’. “Server crash during peak usage” could lead to the risk of ‘loss of goodwill’. Effectively, what the organization is trying to capture is its impact criteria. What will be the impact of a risk materializing on the organization’s finances, reputation, legal, regulatory and contractual obligations, etc? As you can see, things are starting to get murky. Let us take a step back and rethink. As an organization, I need to know my ‘risk appetite’. To know my risk appetite, I need to know what ‘impacts’ me the most. So, I make a list of the types of impacts that would be the most damaging. How do I do that? I get all the senior management team into a room (I can visualize those who have tried to set such a meeting before it before roll their eyes and say ‘there goes one month in the project plan’) and ask them what will cause the most damage to the organization. A simple list of the basic impacts can be prepared as a starting point.
- Reputation and Goodwill
- Legal and Regulatory Obligations
- Contractual Obligations
- Evaluate risks for all business processes
- Focus only on the critical assets defined by the process owner
- All risks that affect the customer have to be addressed in detail
- Any risk to our reputation should be treated with the highest priority.