Timothy Chiu discusses how data and digital architectures require improved application security and how the new security framework from the US National Institute of Standards and Technology (NIST) endorses this view. As more and more organizations move rapidly to the cloud, he argues, applications and their associated data are increasingly at risk. With supporting data from multiple sources, Chiu frames the risks through examples of data breaches across multiple industries and geographies. Fortunately, he says, NIST is on the case. In its recently revised “Security and Privacy Controls for Information Systems and Organizations,” or SP 800-53, NIST adds two application security technologies to its framework, runtime application self-protection (RASP) and interactive application security testing (IAST). Chiu outlines the new NIST requirements and their implementation timeline, as well as explaining what RASP and IAST are and how they can improve and advance application security for organizations.
With organizations rapidly moving to the cloud, applications and their associated data are at greater risk than ever. Each day brings a new security report showing increasing numbers of attacks on Web applications and zero-day exploits on application vulnerabilities that are still making it to production. With each successful attack, we also hear of a new data breach, each one as appalling as the next. According to Verizon’s “2020 Data Breach Investigations Report,”1 attacks on Web applications accounted for 43% of all breaches in 2019 — more than double the previous year’s total.
It is clear that the security solutions in use today are not working. Even the US National Institute of Standards and Technology (NIST) has recognized the need to do more to secure applications running in the cloud. Recently, NIST updated its security and privacy framework, “Security and Privacy Controls for Information Systems and Organizations,” or SP 800-53.2 The final version released on 23 September 2020 includes new requirements for runtime application self-protection (RASP) and interactive application security testing (IAST). This article covers the new NIST mandates and when federal government agencies and enterprises working with the government will need to comply with these new requirements. It also explains what RASP and IAST are and how these technologies can improve and advance application security for organizations.
Tackling Today’s Security Concerns
2020 brought with it the COVID-19 pandemic and the newly widespread phenomenon of working from home, which has stepped up the data and digital architecture transformation in many organizations. One of the key features of this digital transformation has been cloud adoption and an accelerated move of data and applications to the cloud. Having more data and applications in the cloud translates to a larger attack surface for cybercriminals, who are increasingly targeting Web applications and their associated data repositories. With nearly 80% of organizations claiming to have had a cloud data breach in the last 18 months,3 there is no such thing as a safe organization. Everyone is a target.
This year’s “Mandiant Security Effectiveness Report”4 found that only 26% of attacks are detected, meaning that 74% of cyberattacks were successful in bypassing organizations’ security measures. In other words, today’s existing security solutions are failing to protect Web applications and data in the cloud. It was partly in recognition of this failure of widely used security technologies to secure existing data and applications that NIST updated and released Revision 5 of the SP 800-53 security and privacy framework.
Until this most recent release, SP 800-53 had not had an update since NIST finalized Revision 4 in April 2013. Revision 5 focuses on updating and revising privacy and security controls. While much of the news regarding the revision has focused on the updates to the privacy framework, there are two important new requirements in the area of application security, which are the focus of this article. Specifically, these updates are found in the following sections:
RASP — “SI-7 Software, Firmware, and Information Integrity – Section 17: Runtime Application Self-Protection”
IAST — “SA-11 Developer Testing and Evaluation – Section 9: Interactive Application Security Testing”
The addition of these two application security technologies, RASP and IAST, to the framework highlights the importance of application security as part of enterprise security. The inclusion of IAST adds advanced security testing that is used during the software development phase, helping developers catch security flaws and vulnerabilities before an application is launched to production. Similarly, the addition of RASP will provide further protection and advanced security for applications and data during runtime.
These are important steps forward. While the NIST framework is primarily used by agencies within the federal government as a plan and structure for their technology deployments, an estimated 30%-50% of enterprises5 also use this framework for their security architecture.
When Do Government Agencies Need to Comply with SP 800-53 Revision 5?
Now that NIST has released the final version of SP 800-53 Revision 5, agencies in the federal government and those working with the federal government may be wondering when they must comply with the new security framework requirements.
The answer is found in a publication from the US Office of Management and Budget (OMB), “Circular No. A-130”:
For legacy information systems, agencies are expected to meet the requirements of, and be in compliance with, NIST standards and guidelines within one year of their respective publication dates unless otherwise directed by OMB. The one-year compliance date for revisions to NIST publications applies only to new or updated material in the publications. For information systems under development or for legacy systems undergoing significant changes, agencies are expected to meet the requirements of, and be in compliance with, NIST standards and guidelines immediately upon deployment of the systems.6
This means that any systems currently in development will need to be in compliance when they are released for deployment. All remaining legacy systems must be in compliance by 23 September 2021. The only other option for federal agencies is to request a waiver from the standard.
What Is RASP?
Runtime application self-protection was first introduced in 2012 as a security category, but it did not gain significant attention until 2014. As a product category, RASP describes security products that run directly on an application server and provide security and protection for the applications running on that server. RASP is a subcategory of the broader category known as application security (see Figure 1).
By running directly on the same server as the application it is protecting, a RASP solution has visibility into, and an understanding of, the operation and functioning of the protected application that other types of security solutions lack. RASP provides continuous security for the application during runtime, and RASP solutions often have the ability to protect any existing vulnerabilities in the application from being exploited by attacks.
On the application server, a RASP solution can analyze the application while it is executing in real time, validate that it is functioning correctly, and understand the context of the application’s interactions. RASP solutions benefit from being able to monitor and evaluate the application, often with code-level visibility. Typical edge network security solutions don’t provide this level of visibility. System/host- and operating system–level security solutions likewise lack this level of interaction and visibility into applications that are running on a server.
Some of the latest RASP solutions implement security technologies that are extremely efficient, have minimal impact on running applications, and are effective at zero-day attack detection and protection. Modern RASP solutions typically include several protection features, including:
Protection for the OWASP “Top 10 Web Application Security Risks”7
Memory-based attack protection
Zero-day attack protection
Real-time attack blocking/virtual patching
Broad support for application infrastructure
Introduced in 2003 and updated every few years, the OWASP Top 10 Web Application Security Risks list enumerates the risks that should be of primary concern to application security professionals. Many of the risks on the current list, released in 2017, have been featured through all of the list’s revisions. For example, two vulnerabilities — cross-site scripting (XSS) and SQL injection (SQLi) — have been featured on the OWASP Top 10 since its inception and remain the top two most widely targeted vulnerabilities in Web application attacks today.8
In addition to protecting applications from the risks on the OWASP Top 10 list, RASP solutions can provide memory-based attack protection. Memory-based attacks, also known as malware-free attacks, have been growing over time to become a significant concern. The number of malware-free attacks has increased to the point that, as of the beginning of 2020, they now exceed the number of malware-based attacks.9
Zero-day attacks have similarly been increasing over time and remain one of the more difficult attacks to detect, resulting in the many breaches we continue to see in the news. Some security solutions have a tough time with zero-day attacks because they are truly novel and different from prior known attacks. Traditional security technologies are based on matching and detecting variations on known prior attacks. Technologies like machine learning, artificial intelligence, heuristics, and fuzzy logic all start with prior attack knowledge and train or learn from these prior attacks to detect new ones. Instead of relying on past attacks to protect against a zero-day attack, a RASP solution has the ability to look at security from the point of view of the application. Some RASP solutions can actually validate the execution of the code in memory to protect the application from these truly new zero-day attacks.
By residing on the server, RASPs serve as a last line of defense after network and system security solutions. Network and system security solutions remain important, however, providing other types of necessary security. Implementing RASP does not eliminate the need for network and system security.
Because RASP solutions protect Web applications running in production that are typically hosted in the cloud, they must support many different cloud infrastructures and platforms, including Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. RASP solutions also have to work with bare metal deployments, virtual machine deployments, containers (like Docker), and frameworks like Kubernetes that have become popular in recent years.
Adding RASP to the Existing Application Security Layer
For many organizations, application security began with the use of Web application firewalls (WAFs), which started gaining traction in the late 1990s. After the introduction of the OWASP Top 10 list in 2003, WAFs were primarily marketed as the way to protect applications against those itemized risks.
While WAFs predate the introduction of the OWASP Top 10, they have not changed much in their coverage and capabilities since then. WAFs continue to function as a network perimeter security solution. Over the same period, Web threats have continued to evolve. While WAFs can help with certain types of attacks, including network-based attacks, they lack the visibility to protect applications against the new, more sophisticated attacks that target and trigger vulnerabilities found in Web applications.
Many organizations also consider typical system security measures like anti-malware/antivirus solutions and newer methods like endpoint detection and response (EDR) as providing security for their applications. These solutions safeguard the underlying system and operating system that the applications depend on, but they do not provide application-level protection for the Web applications or the vulnerabilities that can be targeted within those applications, such as SQLi, XSS, and the other OWASP Top 10 risks. System-level security also fails to address the security needs of applications running in containers and container frameworks. Without application-level protections, data and applications are left open to sophisticated attacks and data breaches.
The only way to successfully secure today’s applications is through the use of a multilayered security model, which includes a network security layer, operating system–level security layer, and an application security layer (see Figure 2). The new requirements for RASP and IAST in the NIST security and privacy framework recognize the necessity for this further level of application security.
RASP solutions can detect attacks where WAFs and system security lack visibility and control. Unlike WAFs, which only have visibility into the traffic coming to and from the server, a RASP can see what is happening inside the application to determine whether there is inappropriate use of the application itself.
As the last line of defense in the security framework, it is also important for RASP solutions to be able to block an attack as it happens in real time. By blocking the attack, the RASP offers virtual patching, enabling it to protect existing vulnerabilities from being exploited. RASP is the first security category to offer self-protection for the application.
What Is IAST?
While IAST is one of the latest buzzwords in security testing for applications during development, the technology category also arose around 2013 and just began gaining traction over the last three years. Interactive application security testing differs from traditional testing methodologies, including static application security testing (SAST) and dynamic application security testing (DAST), in that IAST uses a software agent running directly on the application server to observe the application as it is being tested. This is similar to the way RASP functions to protect applications during production. IAST solutions have the visibility to report further details on the vulnerabilities that are discovered during testing and detect additional vulnerabilities not seen by black-box testing tools.
SAST and DAST, as traditional application-testing technologies, have limitations in terms of visibility and the ability to detect vulnerabilities in the application being tested. SAST is used earlier in the development process. It examines the code as it is being developed, looking for problems. DAST is a black-box testing methodology that sends attacks to the application and bases its results on the responses the application returns. Besides the lack of visibility these technologies have compared with IAST, another common complaint about both SAST and DAST is the prevalence of false positives. IAST solutions tend to have fewer false positives, as they are able to validate the vulnerability directly in the application itself.
Today, there are two categories of IAST solutions: active and passive. The NIST requirement does not specify which should be implemented, so it is up to practitioners to decide which makes sense for their development environment. Active IAST is similar to DAST running with a RASP solution in that it also uses an active attack component along with the IAST agent running on the application server. In many cases, running a RASP solution with existing DAST testing can provide IAST-level results. Passive IAST, on the other hand, uses an agent to scan and detect vulnerabilities during normal QA testing without the need to employ an active attack.
RASP and IAST Are Necessary Additions to Security in the Age of Digital Transformation
With their inclusion in the recently finalized SP 800-53 Revision 5, RASP and IAST are attracting newfound attention. In SP 800-53, NIST has recognized the need for better application security, and organizations would do well to follow its lead. By implementing IAST, organizations will get better results from their security testing thanks to the increased visibility IAST solutions offer. Adding RASP will provide an additional layer of security for applications in production, enable much-needed visibility, and offer self-protection for applications that have vulnerabilities in production.
1“2020 Data Breach Investigations Report.” Verizon, 2020.
2“Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5.” US National Institute for Standards and Technology (NIST), September 2020.
3“Most Companies Suffered a Cloud Data Breach in the Past 18 Months.” Help Net Security, 3 June 2020.
4“Mandiant Security Effectiveness Report.” FireEye, May 2020.
5“What Is NIST? The Complete Guide to the NIST Cybersecurity Framework.” FTP Today, accessed December 2020.
6“Circular No. A-130.” US Office of Management and Budget, accessed December 2020.
7“OWASP Top Ten.” Open Web Application Security Project (OWASP), 2017.
8“2020 Vulnerability Statistics Report.” Edgescan, February 2020.
9Higgins, Kelly Jackson. “Most Cyberattacks in 2019 Were Waged Without Malware.” DarkReading, 4 March 2020.