I’m Dan Spilsbury, Head of Data Security. I’m working on the security strategy for HMRC’s Data Engineering Delivery Group (DEDG). The aim is to build a real security culture, one where security is part and parcel of how we design and build services and then continuously monitor them.
Back in the day
When I first began my career in information security, it was in the defence sector and 'accreditation' was the way that we did security. We worked on long-term projects, using Waterfall delivery techniques (a sequential, non-iterative design process in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of development) and the security team got involved by providing security requirements, doing risk management and writing a rather large document called an RMADS (Risk Management and Accreditation Document Set).
The techniques for doing this work were very specialised and a whole community of consultants appeared who could write an RMADS and accredit a system. That's how accreditation got a bad name - an RMADS became something of a totem of quantity over quality. Security professionals will all have heard bad stories about consultants – ones who knew very little about the system they were accrediting and were paid hefty fees for the privilege of writing as many pages as possible. But, to be fair, there were also some very good ones, who tried to add value by getting to understand the detail of a system and working with the design teams and the business to implement a pragmatic set of security controls. The term 'accreditation' still, however, became a word that could no longer be mentioned.
Back in March I went to CyberUK in Liverpool, an annual conference held by the National Cyber Security Centre (NCSC), the UK Government's information security authority. NCSC had stated a couple of years earlier that accreditation was no more. However, they were still very much in a transition from 'old-school accreditation' into the brave new world of security.
Brave new world
This brave new world is one where the people developing systems and solutions are the ones who do security! This is instead of corporate security teams with little technical knowledge. It seems obvious but why not equip the technical teams with sufficient security knowledge to allow them to design and develop their solutions securely?
To build our security strategy I’m creating a network of Security Champions who, first and foremost are developers, but have an interest in security. They know the technology inside out, they know their solutions inside out, so all we need to do is to equip them with enough security knowledge to ensure that we develop secure systems.
The Security Champions will be the voice of security for their product area or scrum team. We’ll enable them to dedicate the right amount of time to be able to focus on security related activities and participate in monthly security champion forums.
We’re building security related user stories (OWASP have some evil user stories and SAFECode have some not so evil examples that are worth a look) and guidance on threat modelling into our sprints.
Threat modelling breaks down into three steps
- decompose the system
- determine the threats
- identify countermeasures or gaps
At the 'code-face'
It’s a great way to have those at the ‘code-face’ understand the risks their system presents and allows them to design security iteratively as opposed to doing a single risk assessment at the end of a project on a completed system. Once we have all of those risks identified, we consolidate, translate and aggregate them using a JIRA workflow (other tools are available). That's where the Security team comes in, we translate technical risk into business risk and expose those accountable to a consolidated view that is both meaningful and up to date.
We are at the start of a journey but I hope this has given you some real insight into how we build security into our work from day one.