Ever since I took Systems Engineering I in my masters program at GW, I've viewed information security and risk management a little differently. In fact, as I've matured over the years, I've come to view the field(s) through multiple lenses, and continue to seek out new perspectives. From Systems Engineering, I learned to view risk as a systematic problem that required fault tolerance and that needed to balance the cost of solutions against the effective reduction of loss potential. This approach is also very compatible with the "risk resiliency" approach that my current employer is favoring in their marketing pitch, and something that I've naturally latched onto as being similar to my style of communication around risk management.
To that end, I had an opportunity to meet with Dr. Vernon Grose of the Omega Systems Group this week. His organization has been providing systematic risk management services for a few decades. In particular, his methodology has a couple key components that I found to be particularly interesting. First, Omega advocates a top-down workshop approach to initiating risk assessment as a lead-in to making risk management decisions. This workshop has some similarities to the NSA IAM/IEM approach, but differs by focusing on the executive/strategic level, making use of scenarios for planning. Second, Dr. Grose brings to bear a systems engineering approach to risk management wherein all scenarios are evaluated against a minimum of 3 countermeasures, looking uniquely at the costs of reducing or eliminating the losses associated with a given risk scenario based on a refined ranking approach.
From the Omega web site: "RISK is too often viewed as synonymous with LOSS. But that is a false view. While losses do occur when there in unmanaged risk, there is also a direct link between managed risk and PROFIT. It doesn't cost to manage risk - you increase profits by doing so." Their approach, then, is to look at loss elimination as an opportunity to increase profit, rather than as another overhead expense.
This approach to risk management is very congruent with how I prefer to approach risk management discussions. They have achieved that which I've always found challenging: getting a handful of key executives to sit down and evaluate how to best manage risks. Though my scope is generally limited to IT security, this methodology has a much broader applicability. In fact, Omega has leveraged this methodology in areas such as the NASA Space Program and in support of security for the 1984 Olympic Games in LA.
So, some of you might be wondering "Why are you telling us this? Are you just being a paid blogger to promote this company?" The answer is this: No, I'm not being paid to blog this, and, more importantly, I think this is a very good approach to risk management. As you might expect, I think that it combines very well with a bunch of other approaches, resulting in a hybrid style to overall assurance management that could be quite favorable to businesses, IFF they would buy into it. Specifically, I think that this methodology works very well within my own TEAM model and with my philosophy of security to help an organization implement a comprehensive, positive assurance management program that promotes business enablement and profitability.
What I mean by all of this is the following prescriptive approach to overall assurance management:
1) Start with a high-level assessment. In the past, I've pointed to the OCTAVE methodology from CMU SEI CERT, but now I see the SMART(tm) approach from Omega Systems Group as just as viable. The ISO 27000 series similarly calls for starting with an assessment like this.
2) Build your strategic plan. In the context of Omega's SMART(tm), we're talking about going through the hundreds of scenarios generated through the planning session, creating the TOTEM(tm), which is simply a ranking of risks vs the cost to mitigate or eliminate and the overall probability of occurrence. In addition to ranking your risks for mitigation, it is also important to ensure that you integrate business and regulatory requirements into this strategic plan. Most of the time, these requirements will be synonymous with specific risk scenarios, but all the same, it needs to be explicitly called out. Oh, and from a systems engineering perspective, make sure that you consider at least 3 possible countermeasures (alternatives) for addressing each risk scenario so that you are making a well-informed decision. These possibilities should include the cost to outright eliminate the risk (if possible), the cost of doing little or nothing, and the cost of a best-fit solution to address the concern.
3) Translate that plan into action. Just having a plan is meaningless unless it is communicated to the field and translated into action. The ISO 27000 series provides a very strong framework to implement such a plan, but it's not the only approach (I'm sure ISACA and the IT Governance Institute would suggest CObIT as an alternative, though I may not agree). The bottom line is that you may not need to use a formal framework at all, but rather parcel out the work as part of an existing operational approach. It's up to your organization to find that best fit, just so long as work gets done. And, remember, as you communicate this plan, highlight for people how this work directly increases profitability, so that folks know and feel and understand that they are contributing to the business in a meaningful way.
4) Continually reassess your environment. In the TEAM model I point out the importance of having an audit function. The bottom line is this: If you never test your environment, then you simply won't know the shape its in or risk resilient it may be. It is thus imperative to implement a regular testing program (beyond just internal audit) that goes out and evaluates your organization on a regular basis. There are many, many tools in the shed to support this initiative, ranging from RMI's FAIR for quantified risk assessment, to a myriad of pentesting approaches (see OWASP for appsec info), to use of the NSA IAM/IEM methodologies, and so on. These regular assessments represent a key metric in measuring the effectiveness of your overall program.
5) Lather, rinse, repeat. Revise the strategic plan on a regular basis. It's just that simple. Take your routine assessments and integrate new scenarios as they're identified into your strategic plan. Translate that plan into action. And so on and so forth. The entire process, from beginning to end, should be fluid and dynamic.
What do you think? Feasible? Achievable? I think the hardest part is the first step - getting the executives engaged and understanding the concept of risk. If you can get them to sit down and realize that this entire subject goes toward business enablement and increasing profitability, then you've already won 80% of the battle, and the rest is just the tedium of getting the program stood up.
The biggest concern I have today is the lack of any sort of formalized security program within organizations. It is still very often the case that security functions are buried within IT organizations, with physical security separate as part of facilities and maintenance, with very little, if any, time spent on understanding and addressing risk. This situation is, of course, greatly ironic given that businesses should be all about managing risk. However, as Dr. Grose pointed out in our meeting this week, business leaders are not generally trained in business school on how to measure and address risk, but are rather focused almost exclusively on opportunity and how to maximize it.
And, really, it's not so much that operational security functions are buried, but that there are rarely any strategic security teams (or risk management teams) that are performing the duties described above. These operationally-focused teams end up being in a constantly reactive firefighting mode, and nobody is standing up to provide strategic direction. It's no wonder that the US economy keeps hitting these speed bumps, such as the .COM/.BOMB bubble blow-out around 2000 and the current credit/mortgage/financing crisis. What will it take for business leaders to understand that a little forethought and planning can save a lot of pain in the long run? It's an interesting question to which I do not have an answer, unfortunately. My only hope is that over time new leaders will come on scene with a little better experience in true risk management. Hopefully posts like this one will help out.
