Changing the AppSec Game with Security Instrumentation

Existing approaches to application security (AppSec) testing are not getting the job done: 2009 called, and they want their technology back.

Traditional AppSec Testing Is Behind the Times

This is evident in the fact that the number of vulnerabilities per application is the same today as it was in 2000—26.7 serious vulnerabilities. In spite of improvements everywhere else in development, it’s not very comforting to see this same old-style data point that comes with vintage, handcrafted, manual security testing procedures. And the urgency should be obvious: More than half (52%) of all breaches involve hacking, and web applications are by far the most common vector for hacking-based breaches.

Static application security testing, like a broken clock

The problem is that while every other application development process has simplified and decomposed its feature set to support automation, older application security tools remain as complex and ineffective as before. Static application analyzers still haven’t evolved to reliably trace data in and out of structures like Map, Set, and List.

In addition, false positives are still overwhelming, as static application security testing (SAST) analyzers take guesses as to what the code means. Shifts in frameworks and languages explode the complexity as well: microservices, dynamic languages like Groovy or Scala, inversion of control, and so on. Like a broken clock, they are still sometimes right, but also wrong much of the time.

Dynamic application security testing, accuracy is fleeting

Automated dynamic analysis tools that watch webpages have an even worse time with modern applications. As front-end specialists shifted from multi-page layout systems to single-page web applications that communicate over application programming interfaces (APIs) like REST, gRPC, and GraphQL, dynamic application security testing (DAST) scanners very quickly lose track of what they are looking at—and accuracy goes out the window.

Boarding Up the Vulnerability “Doors”

Admittedly, with a complicated topic like security, it’s important to persevere and try, try again. However, after 21 years of the same AppSec tools, it’s time to try something else. 

There’s a famous quote attributed to famous robber Jessie James, “I rob banks because that’s where the money is.” When servers and back-end applications have the data, the modern Jessie James cyber criminals rob them “because that’s where the data is.” Hackers don’t just appear on networks out of nowhere, they must gain access through an “open door.” In many cases, the door they enter is the same web application that everyone else uses; the hackers just enter it a different way.

When DevOps teams strive to ship software, their aim is to deliver value and get customer feedback as quickly as possible. Time spent waiting for security teams takes time out of their valuable feedback loop, so many of these teams will take unique steps to avoid or pass through the security gates without detection. A recent study finds that 55% of security professionals admit that it is difficult to get development teams to prioritize remediation of vulnerabilities—even if it’s a performance metric for them. Rather than the manual engagement technique of yore, security teams should find a better way to work with development: automation.

Security Instrumentation Offers a Path Forward

Uniting development and security is key to a strong AppSec strategy. An instrumentation-based approach to application testing helps realign development and security objectives while eliminating counterproductive workflows that slow down development and operations. It’s similar to the parallel approach taken to solve application performance testing (accomplished by the likes of New Relic and AppDynamics, among others).

Here, dynamic byte code instrumentation helps identify vulnerabilities inside running applications. It can protect applications in the same ways that smoke detectors and fire suppression systems protect buildings. As an application starts up, an agent automatically places instrument sensors at specific locations within the application code (including libraries, frameworks, and application servers) to observe operating conditions and ensure safe operation. If an outside threat seeks to exploit a vulnerability, sensors can detect the activity in real time and respond accordingly. These instrumented sensors can see far beyond the single-decision point available to network-level controls.

Instrumentation + Runtime exploit prevention. Sensors infused into a running application

Core Capabilities in an AppSec Platform     

Following are some of the core capabilities needed in an AppSec platform:

Automation of AppSec

Instead of a synchronous development and testing loop that impedes time to market, security instrumentation becomes a parallel process that automatically launches with applications under real-world operating conditions. This provides direct, real-time vulnerability analysis and threat telemetry to improve application security without slowing down DevOps. This also reduces the demand on overburdened security teams to ensure validation under the pressure of delivery—at a time when the majority (65%) of organizations report a shortage of cybersecurity staff. And at the same time, these capabilities dynamically scale across any number of deployed applications.

This automation also improves the lives of AppSec professionals. There is no reward to security testers for finding their “5,000^th” injection attack. No bonus, no plaque, no promotion, and so on. By using automation to find the “findable” issues, security testing professionals can free themselves up to do the exciting work that probably got them into security in the first place: working on unique attack techniques that other people haven’t thought of yet.

Discovery, visibility, and verification of vulnerabilities

The old adage, “You can’t secure what you can’t see,” applies here. Organizations need to know where all the software in use is running. Instrumentation supports automatic software inventory to track all applications, APIs, libraries, and frameworks across all environments (e.g., production, test servers, development servers) with 24x7 monitoring and risk management. Visibility also solves the accuracy problems, because systems that observe (interactive application security testing [IAST]/runtime application self-protection [RASP]) are more accurate than systems that guess (SAST/web application firewall [WAF]).

Policy-based security controls

Like physical sensors in a factory, instrumentation measures the operating conditions within an application—allowing organizations to then set policies in the event that a potential event is detected. Policy-based control responses range from alerts with detailed contextual analysis or real-time remediation actions to prevent an attack from spreading.

Integrations and reporting

Organizations should treat security vulnerabilities the same way as they do other bugs. The era of PDF-based security reporting is over. Modern application security works through instant notifications and alerts, sending details immediately into the tools that development and operations teams are already using. This enables quick remediation at the lowest cost possible.

Security Instrumentation Is the Future

Instrumentation-based application testing improves security without skilled security staff or the need to change code. It can help developers push code into production much faster than manual processes for testing and approval. Finally, organizations can transcend adversarial relationships and put developers and security on the same operational cycle—all while improving the security of the applications they produce.

For more details on security instrumentation, download a free copy of our eBook, “Using Security Instrumentation to Analyze and Protect Software.”