Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why you need to automate security for continuous delivery

public://pictures/Tony-Bradley-Editor-in-Chief-TechSpective.net_.jpg
Tony Bradley Editor-in-Chief, TechSpective.net
The same tools that automate change can also be used to automate and accelerate security efforts. Here's how.
 

Many organizations are moving to embrace DevOps and microservices. These technology trends depend heavily on automation, and that results in IT infrastructures changing at an unprecedented speed. It was already a challenge to keep up with the pace of security with a traditional IT environment, and now security professionals are faced with an exponentially more dynamic landscape to protect. Thankfully, the same tools that automate change can also be used to automate and accelerate security efforts.

Slow and stable wins the race?

Change is often seen as the enemy of computer and network security. Security professionals work to understand the vulnerabilities that exist in the network and endpoints and take steps to remediate or mitigate them to reduce or eliminate the risk they pose. As soon as something changes on the network or a new application is introduced, that equilibrium is destroyed and the security professional has to start over to identify vulnerabilities and minimize risk.

"Today, security teams are constantly trying to keep up with security threats. Unfortunately, in most organizations, checking for vulnerabilities only happens when it's time to deploy the finished system," explains Colin Campbell, director of patterns and practices at Chef. "The tools, such as checklists, scans, and (often vague) documentation, result in point-in-time review that impacts the ability to deploy quickly and safely."

Andrew Storms, vice president of security services at New Context, says, "The thing that stirs fear for a lot of security people with continuous delivery is the idea of constant change and sped-up processes. For some reason, security feels that when things go slow, they have more control and will be more secure. Somehow only having a monthly change window on production makes things better, unless of course there is a nasty zero day and everyone has to wait a month to get a patch distributed."

Slow as the problem, not the solution

Nick Galbreath, founder and CTO of Signal Sciences, says that fixing vulnerable code doesn't necessarily take very long in and of itself. He pointed out, though, that many vendors take 100 or even 180 days or more to develop and issue a patch.

There are a number of factors that contribute to this lag, according to Galbreath. Long, painful build processes and release cycles are one. A lack of confidence that a patch can be undone if it ends up breaking more than it fixes also adds additional testing and QA time to replace some of that paranoia with peace of mind before an update is deployed.

Most or all of these issues are addressed with a DevOps culture and a more rapid pace of development and deployment. When you combine DevOps with microservices and automation, you also get a more modular approach that can be easily rolled back or changed at the push of a button if any hiccups occur.

Despite the general sense that change is bad for security, Storms describes why continuous delivery, in fact, makes an organization significantly more secure. "Imagine having the ability to ship a new patch or a new mitigation configuration change 10 times a day instead of only once a month. Smaller, incremental changes are always easier to handle than a large behemoth of a release that can include hundreds of changes."

In a nutshell, everything happens faster. When a vulnerability is discovered, it is fixed quickly. When a compromise is found, it is resolved quickly. There is no lag time or persistence that an attacker can depend on to gain an edge. In other words, the rapid pace of change becomes a strategic advantage more than a burden.

"If you look at John Boyd's OODA loop strategy, you can see how much of a role tempo plays in the game," says TK Keanini, CTO of Lancope. "Boyd said that if you can spin your loop faster than your adversary, you dominate and have superior advantage within the conflict. To this end, continuous delivery is just that: increasing tempo of IT to where adversaries cannot even make sense of the situation well enough to execute. They are disoriented."

According to Keanini, the value to the customer is that a constant stream of content and quality software is being delivered at a faster tempo. Even if bugs are introduced, they can be fixed quickly.

Where the rubber meets the road

"Completely integrating security requirements with the release pipeline won't happen overnight, but automation itself drastically reduces response times to unexpected threats," says Chef's Campbell.

At face value, the perception that change is bad for security seems to make sense. When you look more closely, though, the evidence proves that rapid change provides greater value for security than stability. Taking months to develop and deploy updates that make massive changes to the code all at once leaves the organization vulnerable too long and introduces too much change at one time, making the company less secure and more susceptible to chaos.

Campbell describes a real-world scenario that demonstrates the value of continuous delivery for security. "For example, a major financial organization immediately saw the benefits of using Chef's automation platform when Shellshock hit in 2014. The company had migrated 2,200 servers to Chef, and it took those 2,200 servers 10 minutes to self-report the vulnerability and to self-patch. The company's 66,000 servers that they hadn't migrated to Chef? It took eight hours to identify the vulnerability, five days to patch all the servers, and a team of 18 to solve the problem."

Storms sums it up well. "Security practitioners cannot continue to rely on manual, human-controlled processes to defend against attacks. Automation is a requirement for the next evolutionary phase of security protection."

Keep learning

Read more articles about: SecurityApplication Security