In honor of Cybersecurity Awareness Month, we are delving into the top security topics that enterprises should pay extra attention to as we head in to 2019. In my previous post, I briefly discussed the need to focus on data security, especially in our era of cloud adoption, and the security implications of the Internet of Things (IoT). I also touched on DevOps as an area of growing concern. In this post, I take a deeper dive into that topic because the DevOps trend is growing fast, and so are the security risks it is leaving in its wake.
The Case for DevOpsSec
On many levels, digital transformation and cloud adoption are all about speed. Getting to market in weeks, not months and years. With the software development method known as DevOps, those cycles are now occurring even faster. The practice unites software development (Dev) with IT operations (Ops) with the goal of releasing new product updates and enhancements quickly and frequently to meet immediate business needs. Rather than focus on one big release that may happen once or twice a year, DevOps teams perform multiple releases, working in short sprints, often two weeks or less.
DevOps is catching on fast as companies seek every advantage in hyper-competitive markets. But in the headlong rush to get new functionality into the hands of customers, important aspects of traditional software development are falling through the cracks. Among the most serious of these is security. I say that not just because I’m a CISO. In a cloud-connected world, apps and devices are the main avenues for cyberthreats of all types.
To get an idea of how security activities are getting lost, let’s compare the way security testing is done in a traditional waterfall-based software development lifecycle (SDLC) versus DevOPs. In traditional scenarios, the dev team would build a new version of a product, call it 2.0. When completed, the ball moves on to QA. Typically, no new features or code are added while QA goes about its work of conducting their testing processes.
The development cascade moves next to security teams who perform threat modeling, security reviews, static and dynamic code analysis, and pen testing in order to validate the security level. Again, working with software whose development is largely static while testing is taking place, and with a number of weeks allotted in the schedule to complete their work. QA and security are provided blocks of time to log the bugs and escalate them during the build process.
With DevOps, the traditional development cycle, with its cascade of sequential phases is replaced with one in which each phase is ongoing and overlapping. For example, there are no code freezes with DevOps. Their work is continuous. A team might release a tiny bit of new functionality in a web app on a Tuesday. By Friday, they’ll release something else. Something early the following week, and on and on.
From a security perspective, it is very difficult to adequately test software builds that are essentially always in motion and where the time set aside for testing is often only a few days at best. As a consequence, this risk is that often enhancements to software enter the market with inadequate security testing. (It’s worth noting that QA testing is also less than ideal with the compressed cycles of DevOps, often impacting software quality).
Why the Security Risks from DevOps Are Escalating
Many of the enhancements created through DevOps are quite small and incremental. It’s tempting to think that the security risks they pose are similarly small. Keep in mind, though, that hackers, organized crime syndicates and rogue nations have become quite adept at finding and exploiting the tiniest of security flaws to execute attacks.
By far, the biggest security concern when it comes to DevOps is that this accelerated development is happening primarily with apps and devices that are cloud-connected. For example, a security flaw in a connected smart bulb in your living room could potentially enable a hacker to gain access to the systems that control the smart locks to your house. In the fall of 2016, millions of cloud-connected small appliances, including security cameras and baby monitors, were used in a massive DDoS attack that took down hundreds of web sites around the world for hours, including the New York Times, Twitter, and Netflix. Those connected devices were used as bots to attack the DNS servers at Dyn, a cloud provider of DNS services.
When you consider potential hacking scenarios involving connected cars or energy grids, it brings the imperative for heightened security in DevOps practices into sobering perspective.
How to Make DevOps More Secure
In the compressed timelines of DevOps, traditional security testing is unworkable. One option is to crowdsource. Business is booming for “white hat” organizations like BugCrowd, Synack and HackerOne. The problem with hiring outside hackers for DevOps projects, however, is that they often lack the context that comes with being an embedded part of the development lifecycle. Their view into the product being enhanced is often limited.
The far more effective approach is to ensure that product security is an ongoing process as well, baked into the development process from the very outset. Train your developers to write secure code in the first place so you don’t have those issues at the end of the development process. Build security requirements in the initial product spec. Get ahead of the problem, that is the ideal situation. Whether companies racing to bring new enhancements to market in the blink of an eye will embrace this ideal remains to be seen. But it’s one I believe the tech industry as a whole should give serious consideration to. And soon.
