Unified Security
Date posted
3 December 2018
Reading time
17 Minutes
Unified Security
When you consider security within Digital Services, you could say that 3 main facets exist:
App Security
The above diagram above shows 3 separate software projects. If we apply OWASP ASVS as a means of verifying security against these apps, we can see that there are 20 areas to consider, ranging from Architecture, to Mobile to API. Some of these may not be applicable to your project, that's fine. In some cases, if the tech stack is the same across projects, you can reuse your approach to aligning with ASVS requirements. More on this later.
If you take this a step further and implement the OWASP ASVS for your software project in something like Confluence and JIRA, you can start to clearly visualise how you comply with it. Additionally, it moves you away from spreadsheets being sent around your organisation that no one looks at.
Say we implement the OWASP section on V4 Access control as a confluence page, you'll get something like the following:
This approach has a number of clear benefits to teams:
Closing Thoughts
We've used the Unified Security approach across a number of projects for our customers, and even within our own platforms as it provides the means to cover security for the app, the platform and the service.
Hopefully you'll find something of use here to help improve security for your own services please let us know!
- Security Testing, Pentesting or IT Health Checks (ITHC) involve using some tooling to try and find any vulnerabilities in a system, and then to see if those vulnerabilities can be further exploited. Usually you'll see one or more of these lined up towards the end of a project, often crammed in before go-live.
- Security Accreditation looks at assessing what security controls are in place, what risks exist within the service and what mitigations are planned to address those risks. You'll end up with an accreditation pack that gets taken to a Senior Information Risk Owner (SIRO) for sign off, i.e. the person that owns and accepts the risks.
- Security Engineering is often referred to as RuggedOps, SecOps or DevSecOps, and it involves building security thinking into the agile development process using tooling at development time or within the build pipeline. I very much like the term 'Continuous Security' (<- great deck) as it fits well with Continuous Integration, Continuous Deployment and Continuous Delivery. We should all use this term.
- ASVS Level 1 is for all software.
- ASVS Level 2 is for applications that contain sensitive data, which requires protection.
- ASVS Level 3 is for the most critical applications that perform high value transactions, contain sensitive medical data, or any application that requires the highest level of trust.


- Standard Guidance - Development teams have a guide to the areas that need to be considered when building secure software. You aren't reliant on having a security savvy person within the team anyone can read up on the standard and get an idea on what needs to be thought about. Knowledge is distributed.
- Visibility Anyone, including customer security teams can come along and see what security stories have been implemented, and how they have been implemented. You link from the confluence page straight out to the implementation story or design document.
- Granularity Security stories can be mixed into the sprint backlog. We all need to have a healthy balance between functional and non-functional stories per sprint. No excuses on this one as ASVS has been composed really well into overarching themes with sub-stories.
- Consistency and Reuse In the example, we can see how three projects apply OWASP ASVS. Anyone moving from project to project can understand what's been done. Verification approaches can be shared across projects (assuming a similar tech stack is used). Assets and scripts can be built up that can be reused for future projects. Pure Win.
- Security Documentation evolves When building out an accreditation pack, security stories in Jira (or whatever tool you use) can be tagged as such. You can then report on implementation coverage pretty quickly.
Verify that a threat model for the target application has been produced and covers off risks associated with Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of privilege (STRIDE).
This particular story is a Level 2 ASVS story, but I think it should be a standard consideration for any Digital Service, and therefore included in the Level 1 category. With the knowledge of a threat model, you can then start to identify what aspects of the platform security features you really need. For example, if you expect to be DDOS'd, maybe it's a better idea to move from the basic platform DDOS feature to a Standard Tier version? Maybe insider threats are a big concern from rogue administrators? This could indicate that you should consider something like Just In Time access for service administration. The point being made is that we can move towards an approach of clearly identifying why we need to spend extra ???? on additional platform security features the threat exists therefore we need to mitigate it. Service Security The 14 Cloud Security Principles from the NCSC should be used as the Service Security Standard. These standards encompass both the development and platform security controls, but also extend further to cover off important aspects such as supply chain security, secure service administration and operational security In the same way as we put ASVS compliance in a Confluence page, a matrix model can be used to show compliance, partial compliance and non-compliance against the 14 NCSC principles. Note, that Azure compliance has been previously mapped by Microsoft and a similar mapping has been created for AWS. Again, the goal here is visibility. People can see how the service is standing up against the cloud security principles, and what areas need worked on. You can revisit this page over time to see how the service security is improving, and perhaps even use the page itself as part of any SIRO accreditation set as well.