The integration of development and operations (DevOps) is not a new approach to most enterprises, but as pressure builds to complete code development and move it into live production ever faster, DevOps security is becoming ever more an issue: as code breaks, bad actors use automated vulnerability-finding tools and regulators watch closely for data breaches, software security is vital. But has DevOps left security behind?
Paul Farrington, EMEA CTO at application security firm Veracode told Computer Business Review: “The DevOps movement centres around an alignment of culture, while also breaking down silos in relation to how software gets created, how it gets nurtured and how it is maintained.”
He added: “Traditionally security has tended to be more of an afterthought and so many security practitioners have promoted the notion of DevSecOps’, to encourage the idea that ‘Security’ is not the team left out of the conversation. To be candid, the term DevSecOps or even SecDevOps can be a little like Marmite to some.
“The consensus point however, should be that DevOps can’t deliver secure software at faster rates unless security is 100 percent built-in. Some 64 percent of C-suite respondents believe security teams are involved in technology design and deployment versus 39 percent at the team level – so there is a disconnect.
“The best way to get everyone on the same page is through the mutually reinforcing DevSecOps pillars of automation and measurement. Businesses which adopt DevSecOps fix flaws 11.5 times faster than teams that use agile or waterfall methods.
DevOps Security: Automation is Crucial
Brook Schoenfield, master security architect at pentesting specialist IOActive, told Computer Business Review: “The essence of DevOps is automation. Failure to grasp a powerful shift towards automating most software builds and deploy mechanisms will cause development teams who have embraced DevOps to ignore security.”
When it comes to DevOps security, he suggests it is vital that “required security features get identified early in the development process when they can be built into software, rather than added on expensively and perhaps in a tortured or hacked manner too late in the process to be designed properly. Just as important, where security can be automated, this is far more efficient,” Schoenfield notes.
Collaboration Rules
For DevOps security to become central to product builds, communication and collaboration has to be paramount.
Marco Rottigni, EMEA CTO at cybersecurity firm Qualys told Computer Business Review that: “It’s important that each team feels they are collaborating with each other, rather than being held back or frustrated by the others. When you have a common goal – clean and secure code pushed to production – it becomes easier to work on this together.”
In not considering your approach to DevOps security, developers will be able to quickly create code and deploy it at pace, but the quality and security of that code may be in question. Boeing knows how that ended…
See also: Bad Code, Crashes Send Boeing to Record $2.9 Billion Loss: Software Fixes Ongoing
Next thing you know, your security team, helpful white hats, or less helpful individuals in the security ecosystem are sending emails warning about security, management gets worried about a vulnerability or a potential breach as that can taint a whole brand, and suddenly everything is stopped dead in its tracks due to security concerns.
Rottigni points out that: “Security doesn’t want to be the ‘Department of No’, but they will play this role if there is too much risk. Secondly, this will slow everyone down and run the risk of costing more to fix over time.”
Collaborating at a High Professional
Look, most people at some stage have been involved in or witnessed a project that was nearly completely sunk because of a lack of communication between teams.
In the UK the government is in the process of modernising its emergency service network: the project is late and majorly over budget. Many of the delays and cost overruns have been attributed to a failure by government officials to identify that EE and Motorola, two of the main contractors, were working to different – and conflicting – technical standards, meaning the systems they were developing were not interoperable.
Clearly this is a mess that could have been avoided with clear lines of communication between all parties involved. Having workers collaborating at a high professional level brings in a bounty of secondary benefits (or core benefits, depending on your outlook).
One key gain is a cultural change within the company: suddenly security are not viewed as the IT people from the hidden room who come in after an incident to tell you why and how your service crashed, exhaustingly explaing the hotfixes they have done to keep it ticking over because whoever deployed it made glaring security mistakes; instead they are now part of the fold, integral to each step of the development process.
Jonathan Stewart senior product manager at systems configuration and automation firm Puppet notes that: “This holistic approach enables security teams to stop being seen as ‘gatekeepers’ who are ’slowing down’ delivery of business features, or ‘not being team players’.”
“Instead, a DevSecOps approach enables automation of the desired state – with security policy fulfilment being part of that desired state – resulting in a stronger security stance and a more agile and competitive enterprise, with more motivated employees who now have time to work on high value work such as threat hunting or dealing with exceptional remediations, rather than repetitive work.”
