Why DevOps is Becoming More Like DevSecOps

(**Editor’s Note:**Sam Bocetta, a guest author on the Carbon Black blog, is a freelance journalist specializing in U.S. diplomacy and national security, with emphases on technology trends in cyber warfare, cyber defense, and cryptography.)

In the year 2000, a Time magazine essay authored by Steward Brand questioned whether certain technologies were moving too fast. He explained the chemical concept of autocatalysis as it may apply to technology in terms of endless self-acceleration, and he proposed that scientific disciplines such as genetic engineering should actually slow down. He even wondered whether the dynamics of Moore’s Law should come with brake-like functionality.

Brand is certainly qualified to make the statements above. As one of the founders of the Whole Earth 'Lectronic Link, more commonly known as The WELL, an online community that has been operational since 1985, he is an Stanford University biology graduate who served in an airborne unit of the United States Army, and he has been a respected member of the Media Lab at the Massachusetts Institute of Technology since the mid-1980s.

The seemingly unstoppable sense of excitement that has been a trademark characteristic of IT development in recent decades clearly applies to DevOps. For many enterprise leaders, widespread DevOps adoption has been like Henry Ford’s introduction of the automotive assembly line, and if we take this comparison to heart, the emergence of DevSecOps has been like the publication of Ralph Nader’s eye-opening book Unsafe at Any Speed in 1965.

Following the publication of Nader’s book, automakers had no choice but to pay much closer attention to safety. A similar situation is unfolding in the DevOps world.

Nightmare Security Incidents for DevOps

Let’s say a DevOps team, careless about security, has been sharing access credentials to containers and other cloud computing services of a project. From text messaging to yellow Post-It notes, coders, builders and testers have been sharing these superuser credentials without thinking about what could happen if a malicious outsider gets a hold of usernames and passwords used to access a master server.

If this was a DevSecOps team, SMS and paper sharing of credentials would never take place, or, at the very minimum, strong two-factor authentication would have been enabled for cloud services. While it is true that 2FA has the potential of slowing things down, at least it would discourage a good number of hackers who do not feel like getting into social engineering.

If the aforementioned security scenario sounds familiar, it actually happened in 2014 to a cloud computing services provider that catered to DevOps teams. Code Spaces was forced to completely shut down operations after a distributed denial of service attack on the company’s website forced all members to respond.

The DDoS was but a smokescreen; hackers took advantage of the diversion to access the Amazon Web Services assets controlled by Code Spaces, and they proceeded to destroy DevOps projects, backups and everything else they could get their hands on.

This was similar to a ransomware attack without ransomware because at some point the hackers demanded ransom payments in lieu of data destruction, which they ended up doing anyway.

Security and DevOps Should Not Collide

The automation aspect of DevOps is not a problem per se, it is the lack of security practices around it. These automation tools are normally accessed by means of high-level credentials, and this means that they could be rather damaging should they fall in the wrong hands.

According to the Office of the Australian Information Commissioner, the final quarter of 2018 was the worst for domestic enterprises in terms of data breaches, which are taking place at an average of 87 notifiable incidents per month. Three quarters of these incidents were determined to have been caused by lost, stolen or cracked username and password combinations.

DevOps teams that work detached from information security experts are the ones that have potentially more to lose. Business managers cannot reasonably expect coders and developers to be experts in security matters. Unless the managers are security experts themselves who can craft and implement effective plans, the risks faced by DevOps teams are too numerous and dangerous to ignore.

While many DevOps teams often interact with security and compliance departments, the relationship can break down if developers feel like agility is being compromised. It’s the time-honored tradition of resisting change until forced to comply.

For example, team members can be told that that they can only work on a project through the encrypted connection of a virtual private network, (VPN) but will they actually do it? Maybe and maybe not. In most workplaces, and DevOps is no different, they may not “remember” to fire up the VPN connection unless there is a security expert hovering in the background to audit connections.

With DevSecOps, there is no friction related to security because it is integrated throughout the toolchain. Every enterprise standard of security can be implemented into DevSecOps without slowing things down too much.

It would actually be slower, for example, to have a compliance department determine that the European Union General Data Protection Rule was ignored during the releasing stage. If someone can inform team members about this business requirement prior to the coding stage, this does not become a problem.

The Bottom Line: Speed Kills

Getting back to Steward Brand’s 2000 thoughts about technology developing too rapidly, it could be argued that DevSecOps is like a speed bump installed on a road that passes by the entrance of a school. The agility of the DevOps toolchain has already been proven; it is unreasonable to think that incorporating security and compliance processes will slow things down too much.

In the end, DevOps teams transitioning to DevSecOps can always build tools and automated processes that speed up the necessary security and compliance. To this end, secure password managers come to mind. Training existing team members or bringing in security experts is more of a mandatory safeguard because the cyber threat environment is always expanding and heating up, but there is no other way around it.

The consensus about information security is that things are bound to get more dangerous in the near future, and there is no reason to think that organized cyber crime groups will forget about targeting DevOps.

The post Why DevOps is Becoming More Like DevSecOps appeared first on Carbon Black.