Our website uses cookies

Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing Infosecurity Magazine, you agree to our use of cookies.

Okay, I understand Learn more

What’s Driving the Need for Automated Security?

In 2011, Marc Andreessen said “Software is Eating the World.”  In 2017, Forbes declared the start of the “API Economy”.  In 2020, we will see “Data Dominance” where the companies with the broadest and most unique data insights will dominate their respective industries. Data advantages will not only create new opportunities but deepen protective moats against competitors.

With this hunger for data dominance, how do companies handle security breaches caused by hackers, data loss via partners, and compliance requirements such as GDPR? With all this new software and an economy of APIs, traditional approaches just won’t scale to protect business data.

Security of APIs and the data that flows through them are in desperate need of automation. Teams are understaffed and over utilized, so how can they manually review and monitor results from each and every security product, even with outside consultants helping? One major solution is to automate API security without bringing on additional staff.

In today’s agile development era, developers must “move fast and break things.” So how do they keep up the pace? Baking security into their automated work flows is the best, most manageable route, and tools must scale as fast as developers, otherwise they are not going to work.

From the developer point of view, automated testing is mission critical. Speed is the number one priority. If you want to “move fast and break things” developers must write a lot of code; where automation allows security to go fast – or even faster than developers – without breaking security things.

Many people think the acceleration pedal allows one to go fast in car, which is not the entire case. It is actually the brakes that enable a vehicle to move fast, and in DevOps the brake is an analogy for security automation. Knowing that security is baked into the process, like brakes on a car, allows developers to speed through their work without giving a second thought to security.

This has allowed for security tools to be purchased directly by developers and not security teams, which is a very new trend in the past five years. Developers are now at the front lines of security in many cases.

We need to remember that developers have been writing code for 50+ years, but security for DevOps – aka DevSecOps – is brand new. AppSec teams have power and authority and often use it accidently to force developers to adhere to their own processes and procedures.

Because of this, developers need to ensure their AppSec testing assimilates to existing processes, and avoid creating new or slower ones. If AppSec creates a new process that developers must adhere too, chances are they will comply initially, because security mandates require due attention.

However, over time, developers will avoid it and find a work around if pace of delivery is slowed. The more AppSec that can fit into an existing developer process, the more success it will have long term, even if it is not the “perfect” program. 

Before being enamored with features of a particular AppSec solution, teams need to ensure the tool is solving a problem that exists. This sounds obvious, but many features are not linked to actual problems. It is critically important to ensure each product or feature ties to a specific security problem, (i.e., authentication, authorization, encryption, auditing, availability) before jumping in with two feet.

Often times the pre-requisites are overlooked, but if the tool is integrated into existing developer processes, there will be a long term “baked-in” solution that scales. For example, we still hear of email being used as a bug tracking system (PDF with security bugs emailed to developers), which has a very low success rate for fixes.

Be sure to ensure that the DevSecOps product of choice does not require full time employees to be successful. Many security products need two-to-three operators to use it daily to make it effective. There are not enough security people in the world, and the ones you have don’t want to spend their day stuck on a vendor tool. Ensuring the product can be used without full time employees can avoid doubling or tripling the cost of the product overnight.

Automating security testing will enable developers to go fast, focusing on software delivery without worrying about security or being slowed by security processes. With data emerging as a clear enabler for successful companies, only those organizations which can secure all their APIs and data sets will be able to leverage this competitive advantage.

All the data in the world will not help a company if the data is not secure and slows innovation and delivery. With automated API testing solutions, organizations have the tools available today to best leverage the data advantages of tomorrow.

What’s Hot on Infosecurity Magazine?