Once these new defences are included, or planned, then re-assess the situation.
Here is that approach in a diagram:
stateDiagram Assets&Uses --> SecurityPicture Networks&Access --> SecurityPicture Threats --> SecurityPicture SecurityPicture --> CoursesOfAction CoursesOfAction --> AssessingTheRisks AssessingTheRisks --> CurrentRisks DefendOptions --> ActionPlan RiskAppetite --> ActionPlan CurrentRisks --> ActionPlan ActionPlan --> ImplementControls ImplementControls --> SecurityPicture
We will go through each of these in more detail below, but essentially that’s the playbook to follow.
We strongly recommend going through it once quickly and scrappily to learn, and then again more carefully to be more thorough, and then again until it becomes routine and mostly automatic.
You will need:
We look at the assets first because these shape everything else in the assessment
Identify your assets and what they are used for. Estimate their security value:
Asset | Uses | Nicked | Bricked | Tricked |
---|---|---|---|---|
What Thing… | ..is used by who to do what? | If it is stolen then what can someone find out from it? | If you can’t use it, what are you also unable to do? | What false information on it might lead to problems? |
By doing this we not only remind ourselves what is actually important to us, but we can start to score these to compare them, and so prioritise which ones to focus on.
Where possible we should use the same units - eg money - to compare them, but if we include people then we might also include time, physical harm, emotional pain, etc.
See Assets Assessments for more detail, a starter [Asset Register][assets/AssetsRegisterGuide.md], and this explanation video
In a home network we will typically have sensitive personal information about our families on home laptops or phones, some valuable gaming devices, and probably access to our financial assets at a bank. For each of these consider what the impact would be if you didn’t have it any more, or if someone got a copy of it, or somebody fiddled with it. Read more
Map out the space - the computer networks - where your assets are located and moved through. Include:
This can be a very high level diagram to start with; don’t worry about all the various detailed technical links.
See Network Assessments for more detail and this explanation video
We draw out each device in our house, and then draw a line between it and the router that it connects to, depending on whether it is wifi (orange) or cable (blue). Read more
For this playbook we focus on active adversaries (sometimes called threat actors): people and groups that deliberately or accidentally compromise our assets.
[!NOTE]
Some risk assessment frameworks (such as NIST 800 3..) include natural threats such as earthquakes, but these can and should be managed in different ways; leave them out of this assessment.
Adversaries have a range of capabilities and motivations, both generally and when applied to our specific space and assets.
To start with, use a coarse score for each of these rather than listing technical skills, tools and goals:
Adversary | Capability | General Motivation | Specific Motivation |
---|---|---|---|
Script Kiddies | Low | High | Low |
Competitors | Medium | Medium | High |
… |
See Threat Assessments for more details, a starter Threat Registry , and an explanation video.
Let’s now look at how these threats would navigate this network to have an effect on these assets.
These are the courses of action that an adversary can take to cause you harm.
Pick out:
In most situations this will give you a very large combination of possibilities:
Number of Threats x Number of Routes x Range of Impacts
This will only get more as we start adding possible security plans.
To start with, pick the top threats, the main routes, and the most valuable assets and prioritise those.
As you develop the detail of your security risk assessment you will need to manage this information, probably in a database rather than a spreadsheet as these can get unwieldy.
Bear in mind that this database itself is an asset, and it can be used to discover the vulnerabilities in your systems - this is, after all, what you are using it for. It too must be included in your asset register and your risk assessment.
We can use our assessments of adversaries, networks and asset impacts to prioritise which of these we need to work on first. The highest risks are those with the most capable and motivated adversaries able to reach the most vital spaces using routes through the network that are the least defended.
These are our high priority vulnerabilities; the easiest courses of action for these adversaries that would cause us the most harmful impacts.
We can also eliminate particular combinations and possibly even adversaries. For example if you are building a standalone system that will not be connected to anything else, you can eliminate script kiddies for the built system; they may still be a threat to your development team.
We are left with all the other vulnerabilities, ie which courses of action do not have sufficiently good protection to deal with them. This is likely to be large. Look also for bottlenecks in the routes available to the adversaries and see what defences can be put in place. Otherwise, for the first passes, concentrate on the high priority vulnerabilities.
It can be tempting to just slam defences in everywhere you can see a vulnerability.
But defences have costs; you need to weight these costs against the impacts of assets being affected. If the cost of defending an asset is greater than the impact of that asset being affected then the defence is self-defeating. You will need to talk to your technical people to understand what defences will be appropriate for each vulnerability, what single defences might cover many vulnerabilities, and how much they will cost.
This might be operational rather than money; if you shut down your own people’s ability to work, you essentially “self-brick” your own operations.
You might even find examples of existing defences in place that cost more than the assets they now protect.
This is not clear cut. You might know the costs of defences reasonably well, but these need to be weighed against the likelihood of adversaries successfully affecting your assets combined with the likely impacts of those effects on those assets. That uncertainty can make this tricky. In the first passes, you can use the indexes in the sheets we provided to calculate the trade-offs, but be wary of ‘crap rigour’; use the indexes to guide you, do not treat them as rigorous.
These trade-offs will give a list of ‘residual risks’; these are the risks still left over once we have considered the existing defences and which assets are not worth spending significant defences on.
Convert these residual technical security risks into business security risks (usually in the form of business costs) and add them to the general project or company risk register. The risk owners look over all of these to decide if these are acceptable or not according to the business risk appetite, and to make a call on whether to continue operating even if some risks still require treating or transferring.
For the first assessments you can focus on direct, simple attacks where the adversary attempts to ‘break in’ and affect an asset using one technique.
In practice adversaries are likely to work more slowly and more piecemeal; they might attack the office network to steal some information about your developer network, then use that to persuade developers to reveal some information about the software used, then use that to insert some malware into an open-source software library being used.
This complicates the “assets impacts and residual risks”, because adversaries might attack low-impact assets to get information to reach high-impact assets.
While you can largely ignore this on the first pass, you should have a placeholder in your risk assessment to work out attack chains as courses of action that are complex attacks
(Why do we suggest assessing the risks like this? See our explanation )
With our prioritised list of vulnerabilities we can consider options for defending them.
Defences coarsely, consist of ‘protect’, ‘detect’ and ‘respond’ that correspond to the NIST CSF’s sections:
We can then use the asset layout over the network to show us where these protections should be applied.
The protection measures are called ‘controls’. These might be physical, technical or adminstration
Your action plan needs to go to your business team who will be approving the financial spend. You now have both the costs and the risks, so all the information is here that they need.
It will then need to go to your technical team to implement the right controls. You should have the attack vectors from your Security Picture, so the technical team will understand where to place the right controls to defeat the expected attacks. Ideally the team who will do this are the same people you have asked about the costs of the defences, so they are already aware and informed.
Plan out your next run through the playbook, this time focussing perhaps more on the areas that look vulnerable to attack that can cause you harm.