Adam Moss is the Head of Engineering Strategy, Technical Leadership, DevOps, and SRE at the Department for Work and Pensions. At this year’s GitLab Commit in London, Adam spoke about how his organization transitioned from waterfall to Agile, and how they built security into both their organization's infrastructure and culture.
The Department for Work and Pensions (DWP) is the United Kingdom’s largest government department. It comprises 84,000 employees and serves 22 million citizens, with systems containing approximately 55 million lines of code and seeing about 10,000 changes per year.
In other words, it’s a big deal.
But their infrastructure and operations were less than stellar. Adam and his team wanted to offer 24/7 service availability, improve their user experience, and reduce operational costs. So, they went Agile.
Big change for big gains
Before the transformation, the DWP had outsourced services for 30 years. To get to continuous delivery, they brought everything in-house. In addition to massive operational change, this also required an enormous cultural shift within the organization. Insourcing meant taking responsibility for everything – they couldn't blame a third party should anything go wrong. Teams also had to take on an iterative mindset: Changing their standard maximum viable product into a minimum one.
Then there was the question of tools, which also brought the question of security: What tools would best enable developers, without leaving gaping holes in their systems?
Owning the risk
As a government organization, the DWP was used to managing risk – but they suddenly found themselves without an outsourced partner to blame. Now that Adam’s team was fully responsible for security efforts, they needed to become much more risk averse. Taking ownership of security is also a big change for developers, even for organizations not undergoing massive transformation.
The journey to DevOps security
Considerations
To keep both processes and systems secure, the DWP took a multi-layered approach with people, devices, and code among the top aspects considered.
Developers are often highly privileged users, which poses certain risks to your environment. While it’s necessary to protect both systems and people, organizations need to be clear about their security policies and intent in order to build and maintain employee trust. Adam puts it this way: Think about disciplinary policies – if a piece of vulnerable code is released and causes a problem, is it the individual’s fault? Or is it a fault of the processes you’ve put in place?
Adam also emphasized that restrictions might not be the best answer: Developers will find a way around, so it’s better to implement something that allows them to achieve their objectives without creating any backdoor processes.
There was also the consideration of open source – while it provides great benefits, there are challenges that must also be managed appropriately. Adam’s team chose to implement continuous vulnerability monitoring (with GitLab) to keep track of any risky dependencies that might spring a data leak. They also chose to use GitLab as a central point of control and single source of truth, increasing transparency for the organization.
Lessons learned
In his presentation, Adam shared some valuable tips for a successful transition to continuous delivery. Here are a few favorites:
Automate, automate!
Automation will make things immensely easier – not just because of the time saved, but also because of its repeatability and reduced risk for human error. Focus on the low-hanging fruit early on in the process. There will always be things you can’t automate, so pick the easy battles first.
Identify your pain point
Take a look across your operations and organization. What is the biggest challenge you can solve? Or, what change will bring a lot of value in the move to continuous delivery? Try to achieve ROI as soon as possible.
Anticipate risks from an external POV
Adam recommends threat modeling, and looking at security from the outside in. What might an adversary be thinking? Why and how might they attack? Some tools will even generate possible situations that you’ve never considered.
Continuous doesn’t always mean automatic
While you may want to automate functions as much as possible, the catalyst can still be human. Separation of duties can serve as a useful defense mechanism to ensure that big changes won’t cause undue risk.
The journey doesn’t end with DevOps
Adam concludes with some wisdom for the future: Always be thinking about how you’re going to evolve your organization, and make sure your roadmap continues to change as well. He suggests looking externally for options you might not have yet considered, like the capabilities planned for your favorite DevOps tools.
To build some new ideas into your own roadmap, watch Adam’s talk from GitLab Commit London.
