This article is more than 1 year old
DevOps: Bloody hell, we've got to think about security too! Sigh. Who wants coffee?
How to bake in security to DevSecOps, er SecDevOps ...
Imagine you're an organisation that is looking to implement a DevOps approach to applications and services, or perhaps you’ve already started, but you’re worried about security.
DevOps is all about rapid iteration and continuous delivery, but your security folks still want to be able to do checks to ensure systems are as bulletproof as possible. They likely to make sure your organisation is meeting regulatory requirements like GDPR, which comes into force very soon. How do you fit in security while staying agile?
OK, but we're deploying all the time...
Security can no longer be ignored or sidelined – just look at the damage caused by the WannaCry ransomware outbreak last year, for example - yet according to a June 2017 Global Security Report by Trustwave, 99.7 per cent of web applications* tested by the firm had one or more vulnerabilities.
If you’re looking for shortcuts and easy answers, then prepare to be disappointed. Security is difficult, and making it an integral part of DevOps – whether you call it DevSecOps, SecDevOps, or something else – is about having the right tools, having the right processes, and about cultural transformation. The good news is that if you have already had a measure of success in implementing DevOps, you should already be well prepared to make security part of the mix.
Who is assessing the 95 per cent of third-party code you’re using?
There has been a growing level of interest in DevOps over the past several years, as businesses started to realise they have to become more agile in order to maintain a competitive advantage. The result has been a drive for closer collaboration between developers and IT operators, in order to quicken the cycle of development and deployment.
Security needs to be treated the same way. The traditional way put security assessments towards the end of the development process, before an application went into production. If this held up deployment for weeks or months, it may have been acceptable when development might take a year, but with DevOps and continuous integration/continuous delivery (CI/CD), you may be deploying a new release on a daily basis.
This means that security needs to be involved right from the start of development. Secondly, security checks need to be automated and embedded into the development process itself, and thirdly, there needs to be auditing and monitoring to ensure that the correct processes have been followed.
You can't just dump a long list of requirements and run...
One person that has actually overseen a move to DevOps in the past is Dominik Richter, engineering manager at Chef, developers of the eponymous configuration management tool. He also helped to create Inspec, an open-source tool for automating compliance checks.
“To get security into the mix, first of all you bring them to the table. It is very important that you start with conversations, bring people together and actually get them together and talk. It isn’t enough to just come in once a year and drop a bunch of requirements on the folks in operations and devs. You have to trust to collaboration first,” he said.
Getting security involved right from the start means that many flaws will be picked up at an early stage in the development process, rather than later when all the work has been done and would cause delays to go back and fix things, Richter adds.
One tip that Richter offers is to put security requirements into the project documents and then turn these into code, in a similar manner to the way infrastructure and application requirements can be described using Chef recipes or Puppet files.
“Like you describe the end result [in Chef], so someone else can take that and run it and get the same result, the same thing happens here; you describe the security policy in code, which is what we did with Inspec,” he said.
A similar idea is championed by Mike Bursell, chief security architect at Red Hat, based on ideas presented by his colleagues at the OpenStack Summit in Sydney last year.
“One of the things they looked at is taking requirement documents, such as those you get from the government, for example, and deriving those security requirements and making Bugzilla (or whatever bug-tracking system you are using) entries for each of them.
“Then, as you go through your development process, each cycle you can say ’You know what, I’ve met this particular security requirement, but I’m missing these 99 other ones.’ That’s fine, because it’s your first go at it, but next time you go around, you are fixing it,” Bursell said.
Automation is also key. To ensure that checks do not hold up the development cycle, these need to be automated and performed whenever a developer makes a commit to the code, before it goes through into the production environment. These could be custom checks or a SCAP check or invoking off-the-shelf security tools, but the important point is that it is an automatic process that is embedded into the development cycle.
“In order to get the speed, agility and flexibility from DevOps, you need to automate everything. You need to automate build; you need to automate test; you need to automate regression testing; and I believe that test automation benefits security coming in to the DevOps process more than anything else,” said Chris Carlson, vice president of product management at Qualys, which develops vulnerability scanning tools.
However, Carlson cautions, organisations need to make sure that the process is performing the right functions, and not just serving as a tick on a compliance checklist.
“Automation is just a mechanism to execute a process without human involvement. But the process needs to be correct, and it needs to be monitored and continuously evaluated and improved over time, because if you automate an incorrect process, you’re going to create more problems,” he said.