In part 2 of our dissection of the ISO27005 risk assessment we will have a look at some controls recommended by ISO27005.
Setting the Stage
As usual, in this article series, we’re going to try to do one of our bad anologies to pretend that this isn’t a boring but necessary subject. Imagine you’re a chef preparing a gourmet meal in Nobu Kuala Lumpur. You’ve got your recipe (the ISO27005 standard), your ingredients (your information assets), and your kitchen (your organization). Now, you need to follow the recipe (which is the standard) to turn those ingredients (assets) into a delicious meal (your eventual certification and promotion). That’s where controls come in. They’re the steps you take to protect your information assets and manage your risks. Essentially, why ISO27005 is so attractive to many IT operator is that it is an asset based risk assessment. Let’s run with this chef analogy for this whole article and let’s see if we get hungry by the end of it.
The ISO27005 Control Menu
Now, ISO27005 doesn’t just give you a single recipe to follow. Oh no, it gives you a whole buffet of controls to choose from. It’s like walking into a gourmet restaurant and being handed a menu the size of a phone book. But don’t worry, we’re here to help you navigate this control buffet and pick the right dishes for your organization.
Appetizers: Preventive Controls
Let’s start with the appetizers – preventive controls. These are the controls you put in place to prevent a risk from occurring in the first place. It’s like washing your hands before you start cooking to prevent foodborne illnesses. Wearing a mask so you won’t get infected and so on.
For example, ISO27005 recommends implementing access controls to prevent unauthorized access to your information assets. This could involve things like user authentication (passwords, biometrics, etc.), access restrictions (who can access what), and user account management (creating, updating, and deleting user accounts).
Main Course: Detective Controls
Next up, we have the main course – detective controls. These are the controls you put in place to detect when a risk has occurred. It’s like having a smoke detector in your kitchen to alert you when your gourmet meal has turned into a gourmet disaster.
For instance, ISO27005 recommends implementing monitoring and logging controls to detect security incidents. This could involve things like network monitoring (keeping an eye on your network traffic), log management (collecting and analyzing log data), and intrusion detection systems (detecting unauthorized access attempts). A healthy SOC for instance, goes a long way in detecting issues when or before they occur, which is crucial, especially when events and incidents can happen so quickly. One moment you are settling down for your cup of coffee and the next you are neck deep in phone calls and yelling executives.
Dessert: Corrective Controls
Finally, we have the dessert – corrective controls. These are the controls you put in place to correct a risk that has occurred. It’s like having a fire extinguisher in your kitchen to put out a fire.
For example, ISO27005 recommends implementing incident response controls to respond to security incidents. This could involve things like incident response planning (having a plan in place for responding to incidents), incident response training (training your staff to respond to incidents), and incident recovery (recovering from an incident).
The Anatomy of a Risk Report
That being said, after everything is done and identified and analysed, one still needs to get down to writing the risk report. It doesn’t actually have to be a traditional report, whereby a pdf document, with standard margins, signoffs and such. While this may be the case for many; some organisations are already migrating to system based risk reviews with live dashboards or risks and organisational wide data analytics. With technology growing, there are many tools out there designed to manage risk for you and calculate the ever growing number of vulnerabilities introduced daily. However, if you do find yourself not having these dashboards handy and you need to provide your auditor with something resembling a risk report, here are some guidelines:
The Anatomy of a Risk Report
A risk report isn’t just a list of risks and controls. We have been chucked some pretty cryptic excel sheets that makes as much sense to us as Sanskrit pointing out the Sankara stones locations. As auditors, most of these excel sheets or five page documents may not be enough to pass the litmus test of a risk report. Here’s what a typical risk report might include:
- Executive Summary: This is a high-level overview of your risk assessment. It’s like the blurb on the back of a mystery novel, giving the reader a taste of what’s to come. Some throw in graphs or charts here – you never go wrong with a little bit of pictures.
- Risk Assessment Methodology: This is a detailed description of how you conducted your risk assessment. This is critical because the auditor will review your risk report based on your risk methodology. If these two does not sync – for instance you have a complex risk calculations in the methodology but in the report, you assess risk by sticking two fingers in your mouth and then holding it up against the cool air … well, that’s a recipe of the famous NC – non compliant.
- Risk Analysis: This is where you present your findings. It might be in the form of table, taken from your risk worksheet or excel, or in an asset by asset review; or category by category review. Which ever way , it should be fairly readable, because the audience for this report includes non technical people. So go easy on the jargons.
- Risk Treatment Plan: This is your plan of action for dealing with the risks. You should include a list of recommended controls, their expected effectiveness, and their implementation details. This is important. The plan should not just be: OK, we have WAF, that’s cool. And many people get mixed up with the risk treatment plan and the current controls in place. It needs to be clear, whether in the plan, these controls will be implemented, what timeline and by who.
- Conclusion and Recommendations: This is where you wrap up your report and make your recommendations. It’s like the detective’s closing argument, convincing the chief that they’ve got the right culprit.
A Sample Risk Analysis, Risk Treatment Plan and Risk Register
Now, let’s take a look at a sample risk analysis and risk treatment plan. Let’s say you’re running an online store, and one of your identified risks is a data breach.
- Risk: Data breach
- Impact: High (loss of customer trust, potential legal penalties)
- Likelihood: High (due to lack of strong security measures)
- Risk Level: High
Risk Treatment Plan
- Control: Implement stronger security measures, such as encryption and two-factor authentication
- Expected Effectiveness: High (these measures are proven to reduce the risk of data breaches)
- Implementation Details: Purchase and install an encryption solution, implement two-factor authentication for all user accounts
- PIC: Homer Simpson from the Nuclear control room
- Time Frame: by end of Q4 2022
- Residual Risk after treatment: 2.4
A typical risk register might include:
- Risk ID: A unique identifier for each risk (optional for reference)
- Risk Description: A brief description of the risk.
- Threats: Threats are external, things that exist that may impact that asset
- Vulnerabilities: Vulnerabilities are internal, the yin to the Threats’ yang. These are issues that exist within the asset itself.
- Risk Likelihood: The likelihood of the risk occurring.
- Risk Impact: The potential impact of the risk.
- Risk Level/Rating: The overall risk level, based on the impact and likelihood.
- Control ID: A unique identifier for each control (optional for reference)
- Control Description: A brief description of the control currently existing
- Risk Treatment: Implementation of controls to mitigate the risk
- Risk Monitoring: The expected effectiveness of the control and risk being monitored, or the residual risk remaining
All the above can be monitored within a simple excel sheet, using basic columns and rows. Again, we are not expecting a report written by Leo Tolstoy with a smashing 500 pages to go through, with illustrations and exposition into the answer to the meaning of life, universe and everything. We need something concise, and something that we can go through and something that is implementable in the context of that organisation. That’s it.
If you have futher need for assistance in risk assessments based on ISO27005, drop us a note at firstname.lastname@example.org and we will get back to you. Happy assessing!
P/S – it’s 42. As in the meaning of life, universe and everything.