DEVOPSdigest

A few years ago, I worked as a developer for a software provider, delivering applications to customers using their own servers. I don't want to say how long ago that was, but "DevOps" wasn't a thing back then and cloud was in its infancy. We were playing around at trying to be an agile team, using continuous integration and releasing updates with new features (but mostly hotfixes!) every week. We sneered at some of the other teams dropping six monthly releases and they accused us of being reckless with our continuous releases. Either way, our security team would poke at the apps from time to time and struggled to get a handle on what we were releasing.

Fast forward to 2019 and things have changed. A lot. Not only has the pace of development increased exponentially, but organizations have increasingly relied on their software to act as a differentiator against the competition. Yet, in this race to provide value to the customer, security teams are being stretched to the limit.

Back in the day, security teams needed only make sure that the servers were patched and that the firewall was set up effectively, they would probe applications for vulnerabilities every six months at best. They'd build a wall around the app, maybe even throw in a VPN to stop it being accessed from the bad guys.

So, what's changed? Today, we've split that one monolith app into a dozen microservices, each with their own tech stack (it is best practice to let developers choose). We're now pushing changes hourly to these microservices hopeful this will trigger a pipeline which will push this app into production. We're now running the app in a container — which the developers probably chose — within an orchestration platform in the cloud. On top of that lets sprinkle on some cloud solutions such as file storage, messaging and expose a bunch of APIs to a mobile app of our partners (bye bye VPN). You get where I'm going with this, there is a lot more security work to do.

At this point we should consider the alternative. Slow things down, put the breaks on. It is time to accelerate or die. It is like what we are seeing in the retail industry. There, some of our oldest and most respected brands on the high street are struggling to keep up with their digital counterparts. They're falling behind in the race and without becoming more agile there is one inevitable conclusion. Today a brand will only get you so far, you need to accelerate your development to compete, or your company will join the dozens already in the corporate graveyard.

What does this mean for application security?

We know that applications are the most common cause of data breaches, so we need to make sure we're making the effort to secure them. However, web applications are prickly. They're built on a mix of complex technologies, have a heap of vulnerability types (regardless of language) and they're having to morph daily, or hourly.

In the past we've taken the approach of penetration testing our applications and throwing a Web Application Firewall (WAF) in front of them, but these approaches require a lot of time and expertise. These are expensive and much sort after commodities. You might try to circumvent this by training your developers on security. Whilst this is something I would always advocate to a certain extent, it is a strategy that is based on hope and it's still all too easy to slip up.

When faced with complexity there has always been a consistent approach adopted by engineers to understand what's happening on the inside: instrumentation. Think about an airplane, factory or even the family car, sensors are deployed throughout to provide insight as to how the system is running from the inside. It's the same with software. It is far better to deploy sensors inside software to conduct ongoing security analysis of the application. This provides continuous, fast and accurate feedback to developers in a language they understand. On top of this, it lets developers know whether they are using vulnerable libraries and can block attacks on applications which WAFs would otherwise miss.