I was reviewing the changes to NIST SP 800-30 today, and have been discussing with several colleagues how one chooses the right risk framework given that there are so many known flaws or limitations with the ones commonly used today. That got me thinking about what an organization who is just starting out needs to do day 1 to get their program off the ground and showing value. Otherwise they are never going to get the opportunity to implement a mature or elaborate program.
The following are some initial thoughts on that initial selection process as part of building a program from scratch, but making the best use of what is out there knowing it isn’t even close to perfect:
- Matching the company culture / industry
- What exists already?
- Map to business’ strategic objectives
- Articulate the organization’s risk tolerance
When looking at the ‘frameworks’ that are commonly used in information security circles, you will find that they all came about to address slightly different problems, and therefore may be more suited to one environment or another. For example, the OCTAVE framework’s emphasis on workshops, interviews, collaboration, and detailed worksheets might not be a good fit for a federal government agency, but it might be well suited for a software development company.
Beyond the frameworks themselves, it is essential to consider what risk processes and practices already exist within your organization. You might look to the operations, legal, insurance, finance, business continuity, compliance, business strategy, or human resources teams to identify if they have a framework for risk assessment or management already. If something does already exist, be sure to first determine if it can be expanded to meet your needs or how the information security risk frameworks would interoperate with models in other business units.
The next step before you select a framework is to look at the core objectives of your organization. Make a list of your company’s annual strategic objectives, read the mission statement or vision statement, and look where the company is investing resources most heavily. This is an important activity, because it can inform the style of framework that works best for you. For example, if your organization is expanding into international markets you may want to consider the ISO framework because it will be more accepted than NIST outside the U.S. Similarly, if your organization may have new regulation on the horizon, you would want to look at the frameworks that are recommended by that regulator to avoid unnecessary audit challenges later.
Finally, before you select any framework or even a risk model, you need to guide the executive team through the exercise of articulating the organization’s risk threshold. Have them describe in words only, what level of risk they want escalated to them. For example, if the organization’s mission includes a focus on being highly available to clients, then this might be their risk tolerance statement:
“At a minimum, any risk that is likely to result in service outage for all clients longer than the published recovery time objective should be escalated to the executive management team.”
Then you would want to select a framework that could articulate risks in a way that would allow you to compare each risk to this tolerance statement easily. The framework would need to include the same risk factors that your organization is focused on.
If this topic interests you, you may want to check out my upcoming session at RSA Conference 2012 later this month: Taking Information Security Risk Management Beyond Smoke & Mirrors (GRC-107). You can get a feeling for the content of the session by listening to this podcast I did last month: GRC-107 Sneak Peak.