“When you discover that you are riding a dead horse, the best strategy is to dismount.” That, legend has it, is tribal wisdom of the Dakota Indians that has been passed on from generation to generation.
To all chief security officers out there: Although the horse isn’t quite dead yet, it’s time to start thinking about alternative transportation methods.
New methods of securing networks, systems and data are going to be best sought within the context of operational risk management, which is less about compliance than performance.
Compliance vs. Performance
It’s human nature — people want to know what their obligations are. Give me the rules, and I will meet them. This is referred to as the “compliance culture.”
There is another way to fulfill the business mission, though. Your first concern is the good of the business — so for the sake of the business, you try to improve your activities in every way. In a performance culture, standards represent the starting point — not the objective itself.
Compliance Culture
- I comply with the standard.
- I am told the standard. If I am not told, I don’t act.
- When I am given the standard, the standard is my objective.
- When I meet the standard, that’s it, I am done.
Performance Culture
- My job is to optimize risk — to perform.
- A standard is merely the baseline. I use Operational Risk Management (ORM) to exceed it.
- Standards are a starting point. Meeting a standard means little. I continuously improve.
What Is Operational Risk?
Operational risk, the new buzzword, is an emerging field driven by regulations such as the Basel II Accord and Sarbanes-Oxley, and by the desire to implement risk measurement and risk management practices in order to protect or enhance shareholder value. In layperson’s terms, operational risk represents the losses that follow from acts undertaken — or neglected — in carrying out business activities. Further clarified, operational risk can be associated with the following:
- People: losses associated with intentional violation of internal policies by current or past employees.
- Processes: losses incurred due to a deficiency in an existing procedure or the absence of a procedure. Losses can result from human error or unintentional failure to follow an existing procedure.
- Systems: losses that are caused by unintentional breakdowns in existing systems or technology.
- External Factors: losses occurring as a result of natural or man-made forces, or as the direct result of a third party’s action.
The concept of operational risk is not new. What is new is the idea that ORM is a discipline with its own management structure, tools and processes, much like credit or market risk. While there has been a significant focus on development of risk management for market and credit risks over the past 10 to 20 years, the recognition of operational risk management as a separate discipline has occurred primarily during the past five years.
For some time now, we in the information security sphere have thought about risk management from a technology perspective — asset risk management, if you will. The asset risk management model is simplistic and intuitive, and focuses primarily, but not exclusively, on the protection of the organization technology assets against external threats like hackers, crackers, worms and Trojans.
ORM is about optimizing the performance of the business — unlike security management, which is all about compliance with minimum standards. In sum, ORM is a tool by which a leader can better perform mission-oriented business functions while also minimizing risk.
Following are seven phases that companies can use to identify and create an effective ORM process.
Phase 1: Document process by cataloging actors, acts and assets.
Within the context of the company’s strategic objectives, start identifying key operational processes — the processes that make the company tick — by cataloging the actors, acts and assets, or systems, that in aggregate constitute the process. For example, in our company, Acme, a manufacturer of large construction equipment, a critical process is the sales booking process:
- Operational Process – Sales Booking Process
- Actors:
- Sales Operations
- Accounting
Acts:
- Sales operations books a sale within the sales registration database. Upon completion of the registration, notification is automatically sent to accounting where the sale is reviewed and an invoice is generated.
Assets:
- Local Workstations
- Sales Registration Database
- Finance and Accounting System
Phase 2: Identify hazards.
This step starts with brainstorming. Staff should identify key operational processes and list every hazard practically imaginable for these activities. A hazard can be defined as any real or potential condition that can cause operational degradation, injury, illness or death to personnel; or damage to or loss of equipment, property or other assets.
- Acme Example:
- Sales operations deliberately/inadvertently miskeys critical information.
- Notification from sales registration database to accounting fails, thus the invoice is not generated.
- Information is captured/sniffed and relayed to a competitor regarding the terms of the sale.
Phase 3: Assess risks.
Go through every item on the “brainstorming list” of potential hazards associated with key processes and ask two questions:
- 1. How likely is it for this hazard to occur? Give the answer using one of the following probabilities:
- A. FrequentB. LikelyC. OccasionalD. SeldomE. Unlikely
2. Given that this event does occur, how severe would it be? Give the answer using one of the following severities:
- 1. Catastrophic2. Critical3. Moderate4. Negligible
Once hazards have been identified and an event likelihood and severity value associated with each, it is time to “rack and stack” the risks within a “Risk Assessment Matrix.”
Through use of this matrix, one can define — within the context of the organizational risk appetite, as defined by senior management — how much attention needs to be devoted to a particular risk. Ranking risks allows a worst-to-first approach. This is vital, because risk control resources are limited and should be directed at the big problems first to assure maximum bang for the buck.
In this case, red = very high risk; orange = high risk; yellow equals = medium risk; white = low risk; green = no to lowest risk.
Example:
Hazard: Sales department deliberately/inadvertently miskeys critical information (e.g., wrong invoice address, wrong price).
- Likelihood = FrequentSeverity = CriticalCode A2Risk = Very High
Hazard: Notification from sales registration database to accounting fails, thus the invoice is not generated.
- Likelihood = OccasionalSeverity = CriticalCode = C2Risk = Medium
Hazard: Information is captured/sniffed and relayed to a competitor regarding the term of the sale.
- Likelihood = UnlikelySeverity = NegligibleCode = E4Risk = No to lowest Risk
Phase 4: Analyze Control Measures
When addressing risk, we have a number of options at our disposal:
- Reject
- Accept
- Delay
- Transfer
- Mitigate by applying controls
- Administrative
- Policy & Procedure
- Train & Educate
- Improve Task Design
- Technical
- Protect
- Detect
- Respond
- Monitor
- Physical
Arguably, the most tangible cost is associated with the last option, mitigate. Therefore, it is critical to ensure that organizations spend money in addressing only risk that matters to the business by performing a cost-benefit analysis.
The example shows risk “mitigation” costs in a highly simplistic model to illustrate output. Obviously, a similar assessment can be performed on any of the control options in a much more detailed and complex manner.
Phase 5: Make Control Decisions
In this phase, the objective is to identify where it is possible to get the most “bang for the buck.” Ultimately, the decision to address a risk should be left to the business owner, with the ORM team acting as the teacher, prognosticator and implementer.
Hazard: Sales operations deliberately/inadvertently miskeys critical information (e.g., wrong invoice address, wrong price).
- Risk = Very high riskControl Type = MitigateCost = US$5,000Effectiveness = HighControl Decision = Mitigate
Hazard: Notification from sales registration database to accounting fails, thus the invoice is not generated.
- Risk = Medium riskControl Type = MitigateCost = $25,000Effectiveness = HighControl Decision = Mitigate
Hazard: Information is captured/sniffed and relayed to a competitor regarding the term of the sale.
- Risk = No to lowest riskControl Type = MitigateCost = $10,000Effectiveness = HighControl Decision = Accept
Phase 6: Implement integrated controls.
Obviously, controls should be integrated fully within the plans, processes and operations with which they are associated. Within the area in which they are integrated, risk controls should always compete for resources and time based on their relative significance to the mission of the corporation. Where possible, these controls should be reused to maximize overall value to the corporation.
One practical recommendation is to flesh out the conceptual control options matrix (Phase 5) with an inventory of controls available to the organization and the cost of the control. This will allow the ORM team to prevent duplicative or overlapping technology investments.
Phase 7: Supervise and Review.
The final phase of this process is designed to close the ORM loop. How? By implementing a method and model for evaluating whether the control infrastructure developed by the team continues to address new, existing or evolving hazards.
A highly effective approach is to implement a monitoring infrastructure that allows for the measurement and reporting of the overall health of the integrated control infrastructure. While technology in this arena is new, it does exist.
In addition to the technology base, it is critical to systematically assess the results of the ORM process in terms of lessons learned sessions, for example. Was the benefit worth the cost?
Finally, adapt and reapply ORM as necessary.
Kristin Gallina Lovejoy is CTO, vice president of technology & services at Consul risk management.
Loading ...
This article is right on the money.
The idea of ORM isn’t new but time and time again we see examples of companies making the same mistakes over and over.
http://www.techknowbizzle.com/2006/06/20788366461-brief-history-of-data.html
You’d think that after the VA laptop , AOL, Visa incidents, people would start to get the idea that although there are risks involved with business, there are plenty of measures that can be taken to avoid certain ones. For example, if AOL had chosen to encrypt the data they wanted to provide researchers, and only giving them access to decrypt the data, we wouldn’t have fun into this problem.
Although not all business choose to be compliant, there are a good many reasons why it’s good for businesses to consider it. It provides the right framework for a less-faulty foundation upon which to build upon, decreasing ORM. There are software available that help with compliance and businesses should definitely look into such solutions.