The Evolution of Application and API Security (AAS)
AAS Today
Application and API security (AAS) has been around as a unified security toolset for several years now, and it is near revolutionary in the breadth of coverage that it offers. Products in the space perform application-layer distributed denial of service (DDoS) protection, account takeover protection, API security, web app security, and more. As the products and their various functionality have been merged, advanced security has become possible too—things like data leak prevention that can watch for super slow data exfiltration attacks and application security that is informed by API security.
AAS Tomorrow
Even with all that these tools do, customers are demanding more. We’re seeing a convergence of all production-side security in one place and the possibility of even development security ending up folded into offerings. Indeed, some products already offer static application security testing (SAST), aka source code security scanning.
One-Stop Security Shop
On the surface, consolidating every security issue under the sun into a single product or platform may seem to limit best-of-breed choices and create a single location for attackers to target; however, there are benefits to this expanding approach. We will dispense with the obvious case of customers wanting a single responsible vendor. This is true of broad offerings of any kind: that subset of customers is both the driving force and the target market. But for AAS there is far more.
Inclusion of Development Security Capabilities
For example, the deep integration of SAST drives AAS quality up. And offering API security tools–often merely a check of the interface with little or no evaluation of the underlying code–in combination with SAST provides information about that very underlying code. If an API call passes security testing based on results, it may not be obvious that there is an underlying security flaw in the source just waiting to be exploited.
SAST specializes in looking for known vulnerabilities in source code and helping developers to fix them. It also knows about risky, but not inherently insecure, coding practices in a given file. That information, passed on to the web application firewall (WAF), can be used to create protections for the web app or, when passed on to the API security feature, can be used to forcibly limit response ranges for given variables.
Development security offers SAST, dynamic application software testing (DAST), interactive application software testing (IAST), and often runtime application self-protection. It’s focused more on the development side of DevOps, and SAST/DAST are sometimes even integrated directly into the integrated development environment (IDE). This is the other half of application security, and now that we’re seeing spotty inclusion of SAST and DAST in AAS products, we hope the trend continues until customers that would like it can have a one-stop security shop. Of course, the key has to be “customers that would like it.”
Inclusion of SBOMs
If we were to compile our dream list of features, the first thing we’d want to see added would be software bills of materials (SBoMs). While every security vendor under the sun creates SBoMs these days, we’d like to see AAS vendors import the two primary SBoM formats—software package data exchange (SPDX) and CycloneDX (CDX)—and use them as part of the overall security and protection environment.
The critical part of SBoMs is their ability to identify all of the libraries and open source components in an application’s build tree. This information can then be used to check against known vulnerabilities and inform the entire application security architecture as implemented in the AAS.
Plenty of security products have this functionality, but it has not taken off yet in the AAS market. Even with vendors that can generate a SBoM, it’s not well-integrated into the process. Yet with its great potential, we hope this soon becomes table stake functionality for AAS solutions: generation and/or import along with using the SBoM information across the spectrum of security services the platform offers.
In Security, More Information is Always Better
Essentially, in security, more information is always better. Traditionally, AAS tools (like the WAF and API security tools the market grew out of) look at security from the active attack/defense perspective. That is a good way to look at it, and considering that many of the vendors’ products were and are application delivery tools also, they have a wealth of runtime attack and protection information. However, security starts with the first line of code, and adding in that perspective simply increases the opportunities not only to actively defend the application but to proactively make the application more secure in the process.
There are many quality security tools out there, and we would hope any market-leading vendor would allow an enterprise to pick and choose which products do each part of the job. That will take time because integrating a dozen or so products across a single platform is not something that happens overnight, and certainly not with the depth that the current single-vendor solutions have.
That is, however, our hope for the long-term future, and we do seem to be headed that way.
Next Steps
To learn more, take a look at GigaOm’s AAS Key Criteria and Radar reports. These reports provide a comprehensive overview of the market, outline the criteria you’ll want to consider in a purchase decision, and evaluate how a number of vendors perform against those decision criteria.
If you’re not yet a GigaOm subscriber, you can access the research using a free trial.
The post The Evolution of Application and API Security (AAS) appeared first on Gigaom.