The National Institute of Standards and Technology (NIST) is a non-regulatory agency of the U.S. Department of Commerce that, among other things, maintains physical science laboratories and produces guidance for assessing compliance with a wide range of standards. NIST has a long history of providing documents that help organizations and agencies assess compliance with cybersecurity standards and implement changes to strengthen compliance and security.
The NIST Special Publication (SP) series provides “guidelines, technical specifications, recommendations and reference materials, comprising multiple sub-series.” One sub-series, SP 800, focuses on cybersecurity, specifically containing guidelines for complying with the Federal Information Security Modernization Act (FISMA). (If you are interested in digging further into NIST cybersecurity offerings, check out the relatively new SP 1800 cybersecurity practice guides as well.)
NIST SP 800-53, “Security and Privacy Controls for Information Systems and Organizations,” provides guidance for selecting the most effective security and privacy controls as part of a risk management framework. The latest revision of NIST SP 800-53, revision 5, was released on September 23, 2020.
Revision 5 includes requirements for RASP (runtime application self-protection) and IAST (interactive application security testing). While these approaches to application security are not new, making them a required element of a security framework is a first. Let’s examine how NIST SP 800-53 revision 5 affects the secure application development process.
What NIST SP 800-53 contains
The initial version of SP 800-53 was released in 2005, titled “Recommended Security Controls for Federal Information Systems.” SP 800-53 always focused on federal information systems, at least up through revision 4. Then, revision 5 dropped the word “federal” from its title. That means SP 800-53 is now a more general guidance document that applies to commercial information systems as well as federal systems.
This may seem to be a minor change, but it really means that NIST just expanded the scope of their recommendations. SP 800-53 isn’t a mandate at all, but it does signal a strengthening of guidance from the federal government for non-federal environments.
SP 800-53 contains a catalog of security and privacy controls, organized into 20 control families. Chapter two of SP 800-53 “describes the fundamental concepts associated with security and privacy controls, including the structure of the controls, how the controls are organized in the consolidated catalog, control implementation approaches, the relationship between security and privacy controls, and trustworthiness and assurance.” The other major chapter of SP 800-53, chapter three, includes a catalog of security and privacy controls, each of which includes a discussion of that control’s purpose and how it fits into a layered security approach.
The goal of SP 800-53 is to provide a consolidated guidance document that describes security and privacy controls, how they are related to one another, and how to best select, deploy and assess the controls required for specific use cases.
What revision 5 means to application security
Although SP 800-53 revision 5 provides general guidance for selecting security and privacy controls, a noticeable portion of changes since revision 4 focus on software. As mentioned in the introduction, one of the most important application-centric changes to SP 800-53 is the inclusion of RASP and IAST in its requirements.
If your organization develops, integrates or even customizes software that is used by an organization that is subject to SP 800-53, you will need to consider implementing RASP and IAST controls.
RASP
Common application software protection strategies often include web application firewalls (WAFs) or other perimeter-based mechanisms. While these approaches can be effective by inspecting network traffic at the higher layers (i.e., deeper into the messages), they are still outside the context of the running application.
Perimeter defense is similar to placing security guards and other controls outside and around a bank building. While the security guards may be very effective in stopping recognized attacks, they cannot do very much once a robber gets inside the bank. Having a security guard inside the bank provides protection based on what is happening inside in real time.
RASP is like the security guard inside the bank. RASP consists of instrumentation built into or added within the context of the running application software that detects and blocks malicious activity. RASP operates within the context of the application and has access to more behavioral information than external controls. Likewise, RASP can take quicker and more decisive action, such as terminating a malicious connection and releasing resources when it detects suspicious activity.
IAST
IAST is a close cousin to RASP, and a logical evolution of static application security testing (SAST) and dynamic application security testing (DAST). SAST and DAST are valuable controls, but they are essentially snapshots of an application’s vulnerabilities as a point in time. IAST implements SAST and DAST on a continual basis.
IAST may run in a development environment, as part of the quality assurance process, or even in a production environment. Like RASP, IAST consists of instrumentation that operates as a component of application software and has access to its context and runtime code. But where RASP focuses on detecting and blocking malicious activity in real time, IAST continually assesses application software to find vulnerabilities before they can allow an attack to succeed.
Going back to the bank security guard example, think of IAST as being the security guard doing the rounds. One of the security guard’s responsibilities is to periodically inspect the bank to ensure everything looks safe. IAST does the same thing by continually doing the rounds of its assigned application software to ensure everything looks safe and secure.
Steps you should take
Depending on your organization, SP 800-53 is either a helpful guideline or a blueprint for compliance. Either way, revision 5 recommends each organization deploy RASP and IAST to secure application software.
If your organization is in the business of writing software, you need to begin exploring adding RASP and IAST to your existing and future software. In most cases, retrofitting RASP and IAST will be more difficult than designing it in from the beginning, so start adding RASP and IAST to all new projects now. Even though it may take longer to see the decision pay off, spending time implementing RASP and IAST for new projects first, and then retrofitting existing software, will likely be the most effective approach. Of course, if your organization has the resources to do both at once, that is even better.
Carry out an internet search for RASP and IAST. You will find a growing number of vendors that are already providing solutions. Many RASP and IAST instrumentation products are designed to integrate nicely with existing software, so you do not have to reinvent the wheel and implement these measures from scratch.
Find the libraries or services that fit best with your existing software and build a proof of concept. Do not be timid about trying a few different options and walking away from ones that do not work well for your organization. There is no single right answer for every environment, so find what works for you.
Finally, recognize that RASP and IAST are getting a lot of attention because they are the new kids on the block, but they are only two of over 1,000 controls in SP 800-53. If your company is serious about application security, there is a lot more work to do.
