Why Isn’t Application Security Instrumentation in Your Software Stack?

Basketball is a precision sport that requires players to put in a lot of practice to become truly good. Until recently, players who wanted to improve their game needed an experienced coach who could watch their form and make recommendations for improving it. This “analog” approach has been practiced since the sport was invented by James Naismith 130 years ago.

Finally, another option for improving one’s game emerged seven years ago. The 94Fifty Smart Sensor Basketball is a regulation basketball with built-in sensors that measure dribble speed, shot rotation, the arc of a shot, and more. A smartphone application analyzes the data and gives real-time feedback. After I used the ball for an hour, the 94Fifty let me know that I was shooting too flat. I made the change and it improved my game.

An instrumented basketball does not replace talented coaches, but it can change their role and allow them to scale. They no longer need to be involved in every drill, and this can free up their time to be more strategic. All it takes is a few sensors placed inside the ball. This same principle holds true in the field of medicine and in many other areas. For large-scale challenges that have traditionally relied on experts, instrumentation can fundamentally change the economics.

SEE ALSO: The State of DevOps Report

Embedded Application Security Sensors

For DevOps professionals, the security of applications and application programming interfaces (APIs) is an increasing threat to their organizations. Recent research finds that 96% of applications have at least one vulnerability at any given time, the average software development project introduces one or two new vulnerabilities every month, and the average application was attacked more than 13,000 times per month. When it comes to open-source libraries and frameworks in an application, the average library in an application uses a version that is 2.5 years old, but 62% of those libraries are never invoked by the software.

The good news is that many of these problems can be addressed by instrumentation—similar to the sensors found in the 94Fifty. And it is very easy to do! Instrumentation embeds continuous security testing into applications in development (“shift left”), and runtime application observability and protection extends “right” into applications in production. It also can be used to monitor and secure the open-source libraries and frameworks that are so common in software these days.

How is software instrumentation accomplished? One just adds an agent to the application. As the code loads, the agent surgically adds passive sensors directly into the code of the application. These sensors directly measure the code during development and production and can detect issues automatically. Using the telemetry from these sensors, organizations can provide instant feedback to developers on the security of their code.

Agent Provides Immediate Feedback

The agent has access to the code, the HTTP traffic, the libraries, the configuration, the data flow, back-end connections—everything. And any time the code steps out of line, the agent sends out an alert with contextual guidance containing all the details that developers need to remediate the problem. There is no longer a gap of several weeks or more between the time a vulnerability is created and when the security team gets feedback to the developer. Developers no longer need to work their way back through layers of subsequent code to get back to the vulnerability.

For example, if the agent sees untrusted data flow through the application into a SQL query without being escaped or parameterized—a message alerts the developer of a SQL injection vulnerability. No experts are needed to make this diagnosis, and no one needs to attack the application or exploit anything as with a penetration test. For applications in production, instrumentation can be set up to detect attacks and prevent exploits. This allows AppSec “coaches” to focus their efforts on key challenges like threat modeling and security architecture.

Figure 1. In this example, instrumentation is used during development to expose an application’s access control matrix. This instrumentation-based analysis reveals that the accessD.jsp webpage is likely missing an important access control check.

Figure 2. In this example, instrumentation is used in production to prevent Expression Language Injection attacks from exploiting a vulnerability (like the ones in Struts and Spring) in the application.

A Move to Modern Application Security

Instrumentation represents a disruption—and modernization—to legacy application security tools and practices that are now 20 or more years old. While application security has changed little over two decades, software development has accelerated rapidly with streamlined processes like Agile and DevOps. Organizations are developing more applications, more rapidly than ever.

This acceleration has threatened to push the legacy “scan-and-firewall” model to its limits. It is disruptive to the development process, is based on a snapshot in time rather than continuous testing, and often involves siloed security tools that are not integrated. Even with an army of experts, organizations cannot keep up with a flood of vulnerabilities and attacks—and the attendant flood of false positives. Such an architecture is inadequate because it does not move at DevOps speed, but rather slows release cycles and incident response.

Adding Security Instrumentation to the Software Stack

In medicine, we are on the verge of eliminating many viruses using CRISPR-based techniques, including the mRNA vaccines created for COVID-19. Imagine if we could eliminate entire classes of application security vulnerabilities, or at least make them dramatically harder to exploit. Techniques like address space layout randomization (ASLR) and data execution prevention (DEP) changed the cybersecurity landscape by making kernel exploits very difficult to exploit. We can do the same thing for application vulnerabilities by adding security instrumentation to the stack.

So, the question is, should you add security instrumentation to your software stack—specifically interactive application security testing (IAST) and runtime application self-protection (RASP)?

• IAST uses instrumentation to discover vulnerabilities during your normal software development process. This works just like a performance tool, passively, with no scanning required. Because IAST works from inside the application itself, the results are instant and far more accurate than traditional scanners. IAST tools can also verify your open-source software, with an accurate understanding of how libraries are used by the application.
• RASP, on the other hand, uses instrumentation during production to identify attacks and prevent vulnerabilities from being exploited. Again, because it works from inside the application, not simply looking at network traffic, RASP has the full context of the application and is many times more accurate than traditional perimeter defenses. Of course, organizations should still focus on writing secure code, but RASP offers runtime defenses that will protect an application even if it is not perfect during development.

Clearly, it is time to modernize application security and empower teams to deliver and operate secure software in the face of aggressive deadlines. In basketball, the constant pressure of the game clock and the shot clock forces errors that the other team can exploit. We cannot afford to allow software velocity to create security vulnerabilities that hackers can exploit. By adding security instrumentation to the software stack, we can make security observable and even thwart attackers—all without requiring security experts to get involved. The time is now.

The post Why Isn’t Application Security Instrumentation in Your Software Stack? appeared first on JAXenter.