Information security standards have at least two characteristics: 1) they can cure most sleep problems and 2) some describe a relatively perfect world where those responsible for information security have plenty of time and where there are enough resources to analyse needs and document decisions. Even though I may have started this post a little sarcastic, I'm actually a big supporter of standards and "best practice"; I see no reason to reinvent good stuff. I cannot do anything about the standards being boring, but I write this post to suggest some responsible shortcuts to a good start on risk assessments and as a pragmatic approach to ISO 27001 compliance (should you want that).
The first shortcut is called not all assets. An asset in the ISO 27001 is rather broadly defined as anything that has value to the organization and the standard says you are to "identify assets within the scope". I know of no company that has charted all assets. I suggest you start by "just" assessing your main business processes. Not any other type of asset and certainly not everything with an ip-number. You may later expand the scope to also include the services or systems that support your business processes (called sub-systems in NIST SP800-37). You and your colleagues probably already have a good sense of what business processes matter most to your business. This shortcut is basically a materiality criterion that allows you to perform fewer risk assessments and to spend our time on the more important ones.
The second shortcut is not all threats. If you look, you'll likely find that many information security standards contain fairly comprehensive threat catalogs. Further, if you make your own threat brainstorm to list everything that could possibly go wrong, you quickly discover your threat catalogs are becoming much too long to be operational. This shortcut is to split the assets into types, and then identify which threats are relevant to different asset types. For example, not all types of assets can burn. Business processes, IT services, logical servers, etc. does not burn. It is only the more physical types, such as hardware and buildings. And even within the different physical assets one can make responsible shortcuts by only assessing the threat from the fire at a datacenter, not individually on all the equipment that also stands in the data center. The shortcut here gives fewer threat assessments.
Inheritance is the name of the third shortcut. Good practice and some standards prescribe to make both the Business Impact Assessments (BIA) and probability assessments. The latter is performed by estimating how vulnerabile your assets are to the relevant threats.
Here is the problem: It's difficult to make both kinds of assessments on an asset. Example #1: It is difficult to make vulnerability assessment on a business process. Example #2: It's more than difficult to make a business impact assessment on a server; few people,if any, know which business processes a server supports and how important those are to the business.
The solution to this challenge is to identify dependencies between your assets. In a business process, you can identify which other assets it depends on. Business Impact Assessment are then done "only" on a business process level. Business Impact values are then inherited downwards to the supporting assets.
Vulnerability assessments are made "only" on the supporting assets, e.g. applications, virtual servers, data centers. The vulnerability scores are inherited upwards to the business process.
This method gives us a dependency hierarchy in which we have BIA scores and vulnerability or probability scores on each asset, and hence it's no problem to calculate a risk score on each asset.
This shortcut results in fewer impact assessments and fewer vulnerabilities assessments, and you'll benefit from assessments that actually is possible to perform.
Fourth and last shortcut is high level assessments first. When you conduct a BIA, you will be asking about how much a security incident is expected to impact revenues, costs, image or contractual and statutory compliance. The fourth shortcut is to assess these factors collectively, not individually. The same goes for vulnerability assessments where protection for multiple threats can be assessed together. Granted, it is a shortcut, and you can probably find experts who say that this is not good enough. I still think it makes sense to begin at a high level. You'll subsequently get plenty of opportunities to refine and evaluate your assets in more details, where that makes sense. Therefore, this is also a responsible shortcut, especially if your organization has not yet made risk assessments a recurrent, regular routine.
Here is a brief summary of the shortcuts:
- Not all assets
- Not all threats
- Up and downwards inheritance
- High-level assessments first - refine later
Remember that risk assessments and risk management - as all other security efforts - is a process, not a project. Apply this knowledge to use the shortcuts to a great extent and run your risk assessments gently at the first runs. You can refine later, for example by including more assets, more threats, involving more people (more reviews), or going into more details in your assessments.
I'm suggesting these shortcuts will make you save time (your own time, the time of your colleagues, or even your consulting costs if you have such). The shortcuts will also get you closer to ISO 27001 compliance with less effort (I know; we're ISO 27001 certified).
PS! For the purpose of full disclosure: I am the founder and CEO of Neupart which sells IT GRC tools and consulting services in GRC. You can use the four shortcuts with or without our risk management tool.
Do you find these shortcuts responsible and perhaps even useful? Or do you have tips for practical risk assessment that you want to share?
