How we're changing the way we protect our digital services from security risks.
If you’re involved in delivering digital services, you should be thinking about managing security risks, like online attacks or criminals getting hold of personal data.
At the same time, you’ll need to ensure that the service is performing well and is good value for money.
Managing these risks should be an integral part of creating and running a service. This will be the case if you’re a product manager, technical architect, security analyst or designer.
Traditional security risk management
A lot of the traditional tools used in risk management, such as Information Assurance Standards 1 and 2 (IS1 & 2), aren't designed for agile methods.
Traditional tools take a static view of a system. They analyse risk at a major delivery milestone, try to specify every risk beforehand, and can make the process overly complex through reams of documentation. Perhaps worst of all, they suggest that risk can be managed by simply following a step-by-step process.
We need to keep the knowledge behind these tools and techniques, but adapt them to more agile ways of working.
We’ve explored some solutions with CESG Digital, and come up with some principles for managing security risks on agile software projects.
5 principles of agile security risk management
We believe that agile risk management should be simple, inclusive, varied, creative and continuous.
1. Simple
While some risk management techniques can be complex, and require expert knowledge, the process for managing risk must be simple.
One of the most important steps in managing risk is getting the senior information risk officer or information asset owner to decide on what risks they are willing to accept.
People in these roles are usually senior leaders who are responsible for a large and complex services and organisations. They can only make effective decisions about risk if the general process is clear and simple.
A summary of the risk information for a typical digital service should be:
- short – eg fitting onto a single sheet of paper
- easy to understand
- available at all times
The summary should make sense even if you don't know all about the domain or system beforehand.
This summary can include links to details on related risks (eg on software components, hosting providers and networks), risk management techniques, mitigated risks and the system or service.
2. Inclusive
The overall process should be owned by a non-specialist in risk management, with specialists helping where their expertise is needed.
It should be easy for a delivery or product manager to go through the overall process.
Everyone involved in delivery should feel able to contribute by introducing new techniques based on their skills and knowledge.
3. Varied
We should use a combination of techniques rather than a monolithic approach.
Different risks are best identified by a variety of methods, including:
| Technique | How it works |
|---|---|
| Anti-personas | Fictional individuals who wish to attack or undermine a service can be used alongside more conventional personas, combining design thinking with risk management. |
| Mis-use cases | User stories where mis-use of the service is being considered rather than normal use. |
| Five-whys | A problem-solving technique which can be used following an incident to learn better ways to mitigate risk. |
| Ethical hacking | Breaking into systems to find any weaknesses that could be exploited by unethical hackers. |
| Static code analysis | Used to spot common weaknesses in web applications. |
| Automated vulnerability scanning | Ensures that basic configuration mistakes do not result in opportunities for attackers. |
| Attack trees | A methodical approach to identify possible attack scenarios on a system. |
| Quick checklists | Designed for their effectiveness, not their completeness, and used at the most appropriate times (eg delivery milestones), after each user story. |
4. Creative
Risk management should be seen as a creative activity because it's about trying to predict the future, and anticipate what could go wrong.
We should still use formal and rigorous techniques, but must also adapt creative approaches such as anti-personas or misuse cases.
5. Continuous
Risk management can no longer be considered a periodic or, worse still, one-off activity.
Agile delivery means that services change frequently, and new risks can be both introduced and mitigated as a service evolves.
As a result, we will need to constantly update the information on risks gathered using the techniques above.
This should be managed like source code: it should be version-controlled and editable by a group of people.
What’s next...
We will be working with our delivery teams, information assurance partners and other security experts to ensure we manage security risks in all these ways.
We’d love to know what you think. Have you adapted security risk management so that it works better with an agile approach? Or would you like to work with us to improve the process?
Like this blog? Keep posted: sign up for email alerts.
2 comments
Comment by Tom Wynne-Morgan posted on
Great work Dave
Comment by Mike Boyd, Lead Accreditor, MoJ posted on
This is a helpful summary which is also a good opportunity to note the differences between assurance /accreditation for traditional (‘legacy’) systems and Digital systems. Digital systems generally deliver a single defined function or range of functions to support a business aim, and so the technology, threats and risks can be clearly defined. Development through sprints allows vulnerabilities and mitigations to be readily identified, tried, and tested (and repeated) with focus and frequency. It also allows greater flexibility and choice in the assurance approach. This provides much greater assurance to the business owner. Our experience in MoJ has been that assurance of any resulting changes to existing systems with complex designs which may interface with new digital systems can still require protracted change, IA analysis, and assurance which is, of necessity, on a slower track. That work is often described as being attributable to the Digital project which, of course, it’s not.