Tackling Risk Management, One Step at a Time

In part one of the series I explained why information security programs should include practical risk management as a key component. In this post I will explain “the what” of practical risk management with some guidelines. The final post in the series will be “the how” of implementing practical risk management in your environment.

All information security programs are unique. The interactions of business, industry, and technology are too complex to prescribe a definitive framework for practical risk management. Instead, I will outline various guidelines and themes that any practical risk framework should contain.

Business Compatible – Above all, practical risk management needs to acknowledge and be compatible with the business it will protect. Most often the people who will accept the risk or approve the mitigation will not be security experts per se – however, they will understand the business and its goals/objectives. Presenting the risk by acknowledging business needs as well as security dangers will defuse the perception that security hinders the business instead of protecting it.

Qualitative – Expressing risk with complex formulas and finely detailed scoring will likely create more confusion, focusing the discussion on the math rather than on the critical decision-making process surrounding risk. You don’t want to get into an argument on what a risk score of 6.3 versus 5.9 means to the business as a whole. Instead, risk should be measured in general terms of severity. I’ve found four severity levels — calculated by a matrix of threat and impact definitions — to be the most effective way of relaying risk in nearly every environment I’ve been familiar with:
1. Critical – An active threat to the environment with high impact requiring immediate action
2. High – Very likely threat with high impact requiring high priority action
3. Medium – Likely threat with moderate impact requiring normal priority action
4. Low – Unlikely threat or minimal impact requiring documentation and tracking

Process Focused – Practical risk management should not be limited to patching and compliance with configuration standards but should also include business processes, system design, change management, and data lifecycle management.

Actionable – The ultimate goal of practical risk management is to get the decision makers to agree upon a strategy where they accept risk, transfer risk, or approve mitigating controls. Documenting and educating on the strategic risks of an environment has value, but should be kept separate from the operational functions of practical risk management.

Documented – It is likely that you will uncover multiple risks in various stages of management. Documentation of each risk as it travels through the process, and archiving managed risks, will be critical to the effective implementation of the program. I recommend keeping it simple and easy to use in order to improve the security team’s ability to process and track high volumes of risks.

Repeatable – Consistency will build trust with the process of practical risk management. Build your program off of the many existing frameworks for information security risk. NIST SP 800-39 and ISO 27005 are two great resources to get you started.

In the next post I’ll wrap up with recommendations on how to get a practical risk management program up and running.