Evolution of Application Security Testing tools 

Tools enabling traditional web application vulnerability detection methodologies such as static analysis, and dynamic analysis have been available for more than 15 years and reached the limits of their technological potential to support the speed of modern Agile software development.

Traditional vulnerability scanning tools require significant configuration and tuning, and the time required for these efforts means that the tools cannot usefully keep up with the release cycles made possible by DevOps and automated integration and delivery environments. Additionally, legacy application security testing tools do not provide contextual analysis for their test results, leading to false positives that undermine the accuracy, reliability and effectiveness of security testing overall.

The rapidity of software development, integration and delivery demand a new approach, one where security instrumentation is integrated into an application’s code base. Integrated instrumentation can take advantage of internally generated contextual information providing for more accurate examination and assessment.

Instrumentation is possible with new technologies such as Interactive Application Security Testing (IAST) and Runtime Application Self-Protection (RASP) that enable a continuous, real-time approach to application security. Both IAST and RASP can be delivered as either integrable modules or on a subscription basis following a Software-as-a-Service (SaaS) model. Vendors offering IAST and RASP tools include IBM, HPE, Acunetix, and Contrast Security.

In an IAST deployment, a software agent is used to add instrumentation to applications. A second component then generates malicious traffic as per predefined test cases, attempting to force failures and catch coding flaws that lead to exploitable vulnerabilities. IAST allows teams to scan more code with significantly fewer false positives, thus increasing the speed at which high quality and secure software is delivered. There is a cost, however. Current IAST implementations are complex and their use requires specialized training to parse test results and determine the root causes of identified issues.

IAST identifies security vulnerabilities at a testing stage while RASP addresses security attacks in deployed products.

RASP is implemented as instrumentation to the application runtime engine, either the application VM (e.g. Java Virtual Machine (JVM) and .NET Common Language Runtime (CLR) or the application servers (e.g. Tomcat, JBoss and Microsoft Internet Information Services (IIS), adding a protection layer against application- level attacks.

RASP products are integrated with an application's underlying source code libraries, and provide full insight into the application’s logic, data flows, and configuration during execution of application ensuring continual contextual security analysis. RASP intercepts all calls at runtime from the client application to a system and validates requests directly inside the application checking it against the application's runtime context.

The way RASP works is conceptually comparable to Attribute Based Access Control (ABAC), a next generation identity and access management technology where RASP, like ABAC, embeds data request validation into the application and determines at runtime if execution is permitted.

RASP enables the application to continuously monitor its own behavior, and block only those activities that are incongruous with expected application behavior, and that can be addressed immediately without human intervention. For example, RASP will block the execution of queries to a database server that appear to be a SQL injection attack.

Since RASP is embedded into the application and is highly adapted to it, there is no need to reconfigure the RASP as the application undergoes changes - e.g. migrating to the cloud, implementing microservices architecture with containers, adding REST or SOAP web services, or scaling up or down.

As RASP resides in the application server, it uses CPUs and memory (RAM), staying inside the application throughout its all lifecycle. This means that even if a security incident occurred, attackers will not be able to penetrate an application to get to the data in or behind the application.

Having the latest security testing tools will not make an application as secure as building security into the application across the SDLC. Establishing a secure development lifecycle is critical. Web application security is continually evolving, and an organization’s security policies and guidelines must keep pace.

Article originally prepared for www.uscybersecurity.net