When I start at a new company, I make a point of meeting with key personnel from the departments that have the greatest potential for security risk, including operations, engineering, customer service, IT, finance, facilities and human resources. It’s a good way to unearth risks that might not be obvious to me and to get all of those people thinking in terms of security.
Unfortunately, the impetus for these discussions dissipates after a time as the participants get caught up in their own day-to-day priorities. Eventually, our meetings cease entirely. But such meetings can still be valuable, even though I have now been at this company for two and a half years. That’s why I have decided to implement a formal risk management program.
The idea is to get those department folks into a room on a regular basis so that we can identify and prioritize the company’s most serious risks, and then agree on plans for mitigating them. I am calling this my risk council. We will meet on a monthly basis until we are grounded in our mission and direction, and then we’ll meet quarterly.
Several risk management frameworks are available to assist us in identifying risks and priorities. Two that are highly regarded by security and compliance professionals are the National Institute of Standards and Technology’s Cybersecurity Framework (NIST CSF), which provides a framework with associated guidance on how organizations can protect themselves, and OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation), which was developed by the CERT Division of the Software Engineering Institute to help organizations identify and assess security needs.
It’s wise to use such recognizable standards. For example, when large customers or prospects send you security questionnaires, they are reassured when you can state that you use either CSF or OCTAVE as your guidance for risk management.
I have focused mostly on the NIST CSF but am also referencing OCTAVE and have taken what I consider the best features from each. For example, the NIST CSF contains a very comprehensive spreadsheet (there’s also an application containing the same information) that I have found useful in identifying less obvious security risks and controls. OCTAVE provides guidance on risk measurement criteria, asset profiling and analyzing the risks associated with various assets.
So I have come up with a hybrid framework by cherry-picking some of the more important elements from the NIST CSF document and combining those with guidance specified in the OCTAVE framework. I then tell my customers and auditors that my risk management framework is a blend of both NIST CSF and OCTAVE.
My risk council is using this hybrid framework to settle on the high-priority risks, with the assistance of a heat map that takes into account the likelihood of occurrence, the severity of any exploitation and the cost or resources needed to fix or remediate the identified risk. I map all this information on a four-quadrant grid that places risks on the basis of the likelihood of occurrence and the risk to the organization if exploited. Items in the high-likelihood, high-risk quadrant are then assessed on a cost basis. Those with low cost to mitigate can be acted on immediately, while those with a high cost or a high resource requirement must be planned for (though also resolved as quickly as possible).
One low-cost but high-priority item that is getting immediate attention is creating an inventory of all assets and applications. After all, you can’t fix what you don’t know about. Another high priority is the modification of our API to use Oath2, but that one will require a huge change management effort for both our product and our existing customers. But through the work of the risk council, we recognize how important it is to accomplish this task, and now we can plan accordingly.
Here’s hoping that involving so many stakeholders in the risk council will make it easier for me to get resources we need to mitigate risks.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Click here for more security articles.