“Software is Eating the World”. This attention-grabbing phrase was the central theme of an article by Marc Andreessen in the Wall Street Journal back in 2011. And its argument still rings true today: most of the world’s most powerful firms bear some relationship to software. Not only that, but many traditional firms are rethinking their business to bring it more into line with a software firm (the banking sector, to go no further). The process that has been dubbed the digital transformation is driven by many factors such as the ubiquity of internet, but another fundamental factor is that many procedures that traditionally involved physical components can now be done virtually at a fraction of the cost.
One of the obstacles to this transformation is that real-world operations use standardized and tried-and-tested parts (whether a nut and bolt, an engine or an aircraft’s rudder). In the software world, on the contrary, these parts are intangible and the process of bringing them on stream has always been closely bound up with the developers (Can anyone imagine having to call the hardware store every time we wanted to introduce a bolt? To some extent this is the situation experienced by many system administrators when installing a new software version).
This separation between developers and operators is what the DevOps philosophy is meant to solve: to narrow the gap between these two worlds by means of a series of tools and practices that make it easier for developers to deploy their own products and operators to run them and maintain them in the least disruptive way possible. The goal is always to cut times and bring in new functions more adroitly; “Agile” is precisely another of the methodologies pivoting around DevOps.
Just like development and operations, security has always worked its own patch, separated off from the former two: connecting a new system to the network behind a corporate firewall involves for many firms a nightmare more bureaucratic than technical. It is no longer viable to maintain this way of working if we want to have a continuous flow of deliveries as proposed by DevOps; but the aspect most overlooked by this approach is cybersecurity. The classic slogan of the developers of Facebook “move fast and break things” is an invitation to tag on new functions with the assurance that any faults will soon be corrected. The trouble is that cybercrime also moves fast and can ferret its way into these gaps as soon as they are detected. Just as there are firms trying to automate their software processes, there are whole armies of bots looking for vulnerabilities in internet-exposed web servers.
It therefore becomes necessary to bring the same DevOps philosophy to security and move towards SecDevOps; a working philosophy that aims not for a production chain with start, end and strict borders between teams but rather an iterative process in which each team complements the functions of the other. The inclusion of cybersecurity, which thereby turns DevOps into SecDevOps, can hence be used as a gauge of these processes’ maturity. Indeed, to make sure our DevOps scheme does not leave out of account risk- and vulnerability-management we need to:
– Phase the best security practices into the DevOps cycle from the design phase (Secure by Design).
– Incorporate security-automating tools into operations.
– Bear in mind, in short, that security is a process whose lifecycle can (and must) be managed in an integrated way with development and operations.
Author: José Pedro Mayo
Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de GMV
The author’s views are entirely his own and may not reflect the views of GMV