Towards a light-touch risk management process
Introduction
The traditional approach to assessing and managing risk and documenting the assessment has tended
to produce large, unwieldy documents that do not particularly help business owners to understand
the risks to which their systems are exposed. Although there was no requirement for the RMADS (Risk
Management & Accreditation Document Sets) that were developed using IS1&2 to be so voluminous,
there was a tendency to over-document systems. It was also easy for the authors to just paste in the
list of risks outputted by the IS1&2 assessment tool without any attempt to combine, categorize, or
rewrite the language, which in part drove the document size.
The risk management processes described here are designed to place the business at the centre of the
Information Assurance (IA) process, and starts by understanding why the system being assessed exists
and what its functions are. By describing the risks in the business context they can be integrated more
easily into corporate risk functions.
Process overview
Can be mapped
to
Assess risk
Attack tree
Accreditor
(Technical)
Prioritized list of risks
Accreditor
Application
of
Guides
creation of
Suggests
development of
Stories / abuse cases
Project Team + IT Sec + TDA
Industry controls
(e.g., ISO27002)
Corporate Risk Register
Board-level
Application of
controls to risks
Reuse existing
controls (where
possible)
Calculation of
residual risks
P3T
Controls
Technical: IT Security
Personnel: HR
Physical: Facilities
Process: Business
Risk Mitigation Plan
Accreditor
Guides
creation of
Cross-Government
best practice
Industry best
practice
Security principles
Architectural patterns
IT Security + TDA
This process covers several different disciplines, which for many organizations will be undertaken by
different departments or teams in combination. The owners for these processes are shown in red in
the diagram above.
1
© 2T Security Ltd 2015
Attack tree and risk prioritization
The flow diagram below shows the tasks performed in order to assemble the attack tree(s) and then
calculate the risks for prioritization.
Understand
system
Understand
data
Define risk
objectives
Build attack
trees
Consider
risks
Prioritize
risks
Determine
controls
Map
controls to
risks
Create risk
register
2
• The risks inherent in a system cannot be defined without an understanding
of that system: What is its purpose, and who will use it?
• The data being processed and held by the system need to be considered.
What is their value?
• What are the high level objectives of the risk assessment exercise? What
are the business concerns? Who are the threat actors?
• In a workshop environment, build the attack trees to define the possible
attacks.
• Once each tree is drafted, work through the end nodes to assess the risk
factors. Iterate for consistency.
• Combine the factors according to the process in the attack tree guide to
create a prioritized list of risks.
• Identify potential controls that can reduce the risks, and assess their risk
reduction values.
• Identify which controls map to each risk, and determine the optimum
combination.
• Document the risks in a risk register, with their residual risk levels after the
application of the chosen controls.
© 2T Security Ltd 2015
The first three steps are important for setting the scope of the risk assessment exercise. The attacks to
which the system can be subjected will depend on:




what the system is;
who will be using it;
what data it will hold; and
who the threat sources and actors are.
2T Security has developed detailed processes for the creation of attack trees for systems, and provides
workshop facilitation and training in their use.
Agile stories
This approach works especially well for projects being delivered using agile methods. Each end node of
an attack tree can be written as a story, and can therefore feed into the agile process. The stories
should be considered to be abuse cases (also known as anti-use cases); i.e., stories that the system
owner wants to fail, as they are abusing or breaking the system. For example, a denial of service attack
on an internet-facing system could be expressed in the following way:
As a member of Anonymous,
I want to perform a denial of service attack on the
system
So that maximum embarrassment is caused
to the system owner when it is reported in the press.
This has a greater impact with system owners than a story about providing a technical feature to
mitigate the risk of an attack. These stories should then be fed into the project backlog.
Stories can be created from each end node of the attack tree; this will ensure that each attack type is
represented for incorporation into the project. The risk prioritization should be used to guide the
order for the stories
Controls
Risks can be mitigated through the application of controls (sometimes called countermeasures).
Wherever possible, existing controls should be reused, rather than inventing new controls. There will
inevitably be many controls which are project-specific though, and hence need to be developed by the
project in accordance with existing standards and principles, and in co-operation with other teams.
Examples of these include:
Project-specific controls
User interface changes
Process flow changes
3
© 2T Security Ltd 2015
Multi-system controls
DDoS protection
Auditing and logging
VPN
Verify
There are a number of groups involved in the delivery of controls, as shown in the diagram below (in
blue):
Controls
Approves
Manages
Delivers
Advises
Project
Accreditor
Advise on
Assists
Used by
Security
principles
IT Security
Used by
Architectural
patterns
Creates
Creates
Technical
Design
Authority
Creates
Project Team
Many controls will be integral and specific to the project, and will be developed by the project team
using principles, patterns, and guidance from other groups. This might be driven from stories being
added to the backlog, as described in the previous section.
IT Security
The IT Security Team should be the custodian of existing controls, and hence have to be involved in
determining their applicability. They will often deliver multi-system controls, but if a new control is
being designed and delivered by a project, IT Security will assist to ensure that the control can be
supported once the project is live.
Accreditor
The role of the Accreditor in assessing risk and advising on acceptable levels of risk remains the same.
Having been involved in creating the list of intrinsic risks, they will advise the project on appropriate
controls for mitigation, and will approve (or not) the controls that are chosen and developed. By
remaining closely involved with the project, this process can be managed through ongoing
collaboration, which will be more effective than the project developing the controls on their own and
then presenting them back to the Accreditor.
4
© 2T Security Ltd 2015
Technical Design Authority
The TDA sets the strategic direction for technology, including the creation of architectural patterns
and setting out security principles (in conjunction with the accreditation team). Patterns for security
functions might include those created by CESG and published as part of the IA Policy Portfolio, as well
as those deriving from commercial and industry best practice.
Risk Mitigation Plan
The Risk Mitigation Plan sets out the prioritized list of risks and assigns owners and actions to them.
Each risk, even those that are within risk tolerance, must be assigned an owner. Risks with mitigation
actions should have dates for completion of the actions; risks without actions should have a review
date set, by which point they will be reviewed to determine whether they still need no mitigation.
Many of the mitigations will occur through the application of the controls. In many cases, assessment
factors for the likelihood can be assigned to controls. An example set of controls is shown in the
diagram below.
Goal of
System Owner
Increase
‘Cost’ of
attack
Effect on attacker
Greater
investment
to stage
attack
Controls
DDoS
protection
Drive
encryption
Encryption
Increase
‘Complexity’
of attack
VPN
Harder to
perform attack
Verify
Increase
‘Detection’
of attack
More likely
to be caught
Audit and
logging
Assignment of values to controls is fraught with difficulty, and will be a subjective process that will
require agreement from a number of different teams. The values will depend on the context of the
controls and the system and risks to which they will apply. The intention is that the risks can be
recalculated in light of the chosen controls to ensure that the control set is appropriate and
proportionate.
5
© 2T Security Ltd 2015
Applying multiple controls to a single risk must be done with care. Simply adding the values together
for all of the controls is rarely likely to lead to a sensible outcome. This is logical: after applying one
control, the risk is reduced, so there is less risk remaining for subsequent controls to affect.
For example, the addition of an audit solution to a system – as the only control – might be deemed to
increase the detection of an attacker by 2. The risks that are mitigated by the audit solution must be
recalculated with their detection values increased by 2.
For another attack, a combination of adding a VPN and modifying the user interface might be
assessed, collectively, to increase the cost by 1 and the complexity by 2. The particular attack would
be recalculated in one step with these changes to both of the values, rather than in two steps that
separately assess the impact of adding the VPN and modifying the interface.
Once this process is complete for all proposed controls, a new prioritized list of risks is created, which
represents the residual risk.
Mapping to Corporate Risk Register
The organization’s corporate risk register will contain high-level risks that need Board-level attention.
Individual risks on a system attack tree are very unlikely to be present on the corporate register.
However, it should be possible to map groups of risks from the system-level registers into the risks on
the corporate register. This process should therefore give a view as to the severity of the corporate
risks, and thus provide a ‘bottom up’ confirmation of the corporate risks.
Blending attack trees
It should be relatively straightforward to blend together multiple attack trees from related systems, so
long as they have been prepared consistently. The more subjective assessment factors (complexity
and jeopardy, in the most part) need to have been addressed in a similar manner, otherwise the
likelihood components of the risks will not be compatible between the different trees. This
demonstrates the importance of having either a consistent approach, or preferably the same people
involved in the preparation of the trees.
If an organization will be creating a number of attack trees across multiple systems, it might be
advisable to create specific guidelines for each of the factors to help provide consistency. This should
not be an onerous task, but it will support any workshop facilitator when they are guiding the creation
of trees.
It is important to note that the risks must not be scaled before being blended. The risk scaling is so
that a complete set of risks can be placed on a standard scale. Anomalous results will occur if scaling
occurs before blending – for example, if two systems have very different levels of risk, but are both
scaled from 0 – 100, then the highest risks in each might have the same scaled value but equate to
different levels of attack (loss of £10,000 and loss of £1 million). If both of these trees are scaled so
that these risks have a value of ‘80’, and then they are combined there will be an obvious discrepancy
between the impacts, which will undermine the process. In effect, blending trees is a process that
creates a larger tree, and scaling must be seen as an activity carried out on a complete tree.
6
© 2T Security Ltd 2015
Conclusions
There is a growing need for information risk management to be understood by the business in its own
language. Over the past few years, the failure to translate the technical outputs from risk assessment
tools such as IS1&2 into a succinct list of business risks has damaged the credibility of IA in the eyes of
the business. The processes described in this paper have been used with Government, and proven to
deliver faster, cheaper, and more intelligible IA risk management. They provide a good fit with agile
delivery methods, and encourage security and IA to be brought into the team and engage with
everyone, rather than existing in a silo.
2T Security has developed this approach in real-world scenarios with some of our Government clients,
and they have proven their value in providing a more agile approach to risk management. This lighttouch approach fits with current pressure on budgets and the expectation on information assurance
managers and accreditors to achieve more with less resource.
To find out more about how 2T Security could help your organization manage its risk assessment in a
better way, please contact Tony Badsey-Ellis ([email protected]).
7
© 2T Security Ltd 2015