![](\"http:\/\/zapt2.staticworld.net\/images\/article\/2017\/02\/risk-100708607-large.3x2.jpg\"\/)
<\/p>\n
Credit to Author: Mathias Thurman| Date: Mon, 13 Feb 2017 03:45:00 -0800<\/strong><\/p>\n 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\u2019s 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.<\/p>\n At issue:<\/strong> It isn\u2019t always easy for a security manager to recognize all the risks a company faces.<\/p>\n Action plan:<\/strong> Start a risk council to bring in more information, and hope that its members will partner with you in obtaining the resources you need to respond to the biggest risks.<\/p>\n 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\u2019s why I have decided to implement a formal risk management program.<\/p>\n The idea is to get those department folks into a room on a regular basis so that we can identify and prioritize the company\u2019s 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\u2019ll meet quarterly.<\/p>\n 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\u2019s Cybersecurity Framework<\/a> (NIST CSF), which provides a framework with associated guidance on how organizations can protect themselves, and OCTAVE<\/a> (Operationally Critical Threat, Asset, and Vulnerability Evaluation), which was developed by the CERT Division\u00a0of the\u00a0Software Engineering Institute<\/a> to help organizations identify and assess security needs.<\/p>\n It\u2019s 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.<\/p>\n 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\u2019s 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.<\/p>\n 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.<\/p>\n 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).<\/p>\n 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\u2019t fix what you don\u2019t 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.<\/p>\n Here\u2019s hoping that involving so many stakeholders in the risk council will make it easier for me to get resources we need to mitigate risks.<\/p>\n This week’s journal is written by a real security manager,\u00a0“Mathias Thurman,”<\/strong>\u00a0whose name and employer have been disguised for obvious reasons. Contact him at\u00a0mathias_thurman@yahoo.com<\/a>.<\/em><\/p>\n Click\u00a0here<\/a>\u00a0for more security articles.<\/strong><\/p>\n