In Shakespeare’s iconic tragedy Romeo & Juliet, the play’s heroine speaks of Romeo from her balcony:
What’s in a name? That which we call a rose
By any other word would smell as sweet.
This famous quote is set to the backdrop of the tension between the two sets of families, Juliet’s Capulets and Romeo’s Montagues, and Juliet is lamenting that to be identified with a name has no bearing on her love and affection for Romeo. She wants to be with Romeo in spite of his name, and not because of it.
This made me consider the role of names within information technology and, more specifically, cybersecurity. Security folk enjoy nothing more than a pithy handle for the latest security bug; I refer you to Heartbleed, Poodle, WannaCry, NotPetya, Beast, and many others. From a high level, this characterisation can be a positive thing to break down technical barriers and highlight vulnerabilities and security requirements to a wider audience.
However, before I unearthed my childhood Illustrated Works of Shakespeare book, the talk over the past few years has been around DevOps. DevOps is attempting to tear down the siloes between application developers and IT operations to deliver a cultural and procedural change in how applications are built and deployed, using automation tools, and feedback loops, all done with speed and agility, with repeatable processes. Once again, the industry coined a new term (at the time), DevOps, to help capture the new culture.
A side-effect of this new world of speed of deployment was the impact it had on security. Traditional security is viewed as slow, manual and cumbersome, relative to DevOps, and was struggling to keep pace. Security was also seen as something which impacted time to market and cost, reducing application deployment to a series of security gates to work through. Now that DevOps is well established, and as a consequence of some high level breaches such as Equifax, the application community has begun to engage with their security colleagues to see how security can be embedded into the software development lifecycle (SDLC). It’s something we at NTT Security have been looking to help customers with through our Secure Application Services.
Why do we need this and what are the benefits of a secure SDLC anyway? As stated earlier, traditional security doesn’t work in the new world of DevOps so it has to adapt. The iterative and agile nature of application development with legacy “bolted-on” security, results in applications with more vulnerabilities and at greater risk, as reactive controls struggle to be effective due to an ever changing application landscape. Securing the lifecycle of application delivery and embedding security throughout the development process, for instance with continuous security testing, serves to deliver applications that are more secure, still in a timely manner, with a reduced time to fix for any vulnerabilities found and at a reduced cost. This narrows both the attack surface and the attack window, resulting in fewer incidents and all the associated negative effects of these.
Of course, it seems like nothing is achieved in the digital world unless it has a name and the three main choices for embedding security into DevOps have been SecDevOps, DevSecOps and DevOpsSec. Whilst researching the different choice of terms, the most interesting feedback was not the one that was more popular, rather, the suggestion that the name shouldn’t matter at all, which does go against the usual tide of everything needing a label.
Should the infosec Juliet care whether she was performing SecDevOps, DevSecOps or DevOpsSec methodologies and practices? Should it not be more important that security was adapting to the challenges of DevOps and being embraced by the developer community? In fact, if DevOps is here to stay and high profile breaches continue to make the headlines, shouldn’t DevSecOps just be called DevOps?
Security should be everyone’s responsibility so, I ask, what’s in a name?