The Adoption of Emerging AppSec Technology

This session was originally for the Fall 2020 Cyber Security Digital Summit.

Overview 

Has your organization considered Interactive Application Security Testing (IAST), Runtime Application Self Protection (RASP), and related solutions as part of your security program,? What has your experience been so far? 

Understanding the value provided by different types of vulnerability detection and exploit prevention technologies that are available today is critical to every security organization. This discussion featuring Nabil Hannan, Field CISO at NetSPI and Travis Hoyt, Head of Cybersecurity Technology at TIAA, will focus on IAST and RASP. 

• What is IAST, and how does it complement Pentesting, Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST)? 
• What is RASP, and why is it challenging to deploy at scale? 

Tune into the discussion to learn:  

• The capabilities of new emerging technologies that detect security vulnerabilities in software 
• The strengths and weaknesses of some of the new techniques 
• How organizations are using these techniques at scale 
• Challenges around adding yet another piece of technology to the ecosystem 

Key highlights:

• 1:40 – IAST
  • 1:56 – What makes IAST so appealing?
  • 6:30 – Security testing as part of the QA testing process
• 16:35 – RASP
  • 18:44 – How does RASP compare to application firewalls?
  • 24:01 – Why is it challenging to deploy RASP at scale?  
  • 27:01 – How is RASP different from IAST?
  • 27:42 – What are the challenges in adopting new technologies (adding yet another tool into the ecosystem)?

Interactive Application Security Testing (IAST)  

To get started, it’s important to first understand IAST and why it’s important.  

What makes IAST so appealing? 

IAST has powerful technological capabilities to emulate a pentester in a way that isn’t possible with dynamic security testing. This is particularly appealing for organizations that may not necessarily have the resources, from a human capital perspective, to have senior pentesting talent or other individuals with the right skills on staff.

While some individuals in the security space may say that organizations are overly reliant on tools, when capabilities aren’t available internally, then the right tools and automation are necessary to get to where an organization needs to be from a security standpoint. It’s a powerful capability, especially for smaller teams. 

Another way to look at the appeal of IAST is by taking a step back and thinking of IAST as an instrumented solution that has an agent that sits in your application and is providing what can be referred to as security telemetry. One important consideration to remember is, this isn’t necessarily different from technologies that engineering teams are already using for performance telemetry. Rather, it’s a similar concept that involves embedding an agent into your running application to understand and determine the inner workings of your system. This provides security telemetry, instead of performance telemetry that other solutions are providing.

Once engineering teams look at IAST this way, they embrace it, because it doesn’t necessarily take them out of their normal workflow. Additional overhead or requirements aren’t required from a security perspective because security gets ingrained into the engineering teams’ normal processes in a seamless fashion. As a result, this makes IAST appealing and helps with adoption.  

Security Testing as Part of the QA Testing Process 

Security testing is important to QA testing both for organizations that don’t have robust teams and resources, as well as an augmentation for companies with larger teams and pentesting capabilities. Oftentimes companies with bigger teams also have much larger scopes of applications. While a smaller organization may have 10 or 15 apps, larger firms may have thousands of them.

Leveraging IAST, just like any other type of automation, can free up pentesters and other team members to focus on other more complex issues. For example, at larger companies or those with complex application ecosystems, a lot of times when testing an application, it leads to a siloed view. This approach is taken across all applications. By integrating an interactive application security testing tool as well as other DevOps tooling, then team members can focus on the points in-between to break down silos. For example, understanding the handoffs of how an integration works and identifying weaknesses. As a result, you start to look at your threat model, and you can spend more time focusing on how it works.

In the pentesting space, incorporating IAST early on is a powerful component of the development lifecycle. A lot of effort has been put into embedding security into normal QA processes in the past, such as leveraging dynamic scanning technologies and static analysis technologies. However, a lot of these out-of-the-box tools tend to be noisy and can produce false positives. Asking a QA team to manage and interpret results from these tools becomes challenging because it requires additional education and experience that most QA teams don’t have.

A QA team can work well when they’re assigned misuse or abuse cases, or if the organization is building specific security requirements and gives the QA team a specific security test case to execute. But on their own, trying to interpret results from different security tooling and scaling this approach across a QA team is challenging.  

This is why IAST is beneficial to QA teams.  

The false positive rate is significantly lower compared to traditional static and dynamic analysis tools—and because of this—QA teams don’t necessarily need to be security experts. With IAST, the tool can run in the QA process seamlessly. The QA team does their work and the IAST tool reports on security issues.

Runtime Application Self Protection (RASP)  

Runtime Application Self-Protection (RASP) can be challenging to deploy at scale and has distinct differences from IAST.  

Overall, opinions are divided on RASP and the level of adoption varies greatly by organization. One factor that plays into adoption is the size of a company. RASP is typically embedded and needs to be instrumented appropriately, with the right rules in place, during production.

Some RASP models can learn and mature over time, but many organizations are hesitant to adopt RASP because they don’t want technology in place that can make a decision about whether or not something is accurate. For example, if a team makes a code change and the RASP model isn’t updated effectively, it may block functionality and can hinder applications. In general, vendors have addressed this over the years, but the risk of blocked functionality isn’t zero. 

How Does RASP Compare to Web Application Firewalls?  

The primary difference between RASP and a web application firewall is that a web application firewall is sitting outside of an application, not inside the application trying to analyze traffic to determine and block possible attacks.

When it comes to web application firewalls, understanding the two distinct types is important. One type is signature-based, which requires building signatures and patterns that you’re looking for in traffic and trying to block them. The other type is behavioral-based, which involves teaching the web application firewall what good behavior looks like in an application in order for the firewall to know how to block malicious behavior. 

While a web application firewall is an effective defense in depth and almost a necessity today, with different types of DDoS and related attacks, it can end up blocking a lot of context with the inner workings of the application.  

When this is the case, RASP is the more beneficial solution, because it can look at fields and values and understand how values are used. For example, if you get a value that has a payload for cross-site scripting, but it’s going to be used only for a database query, chances are that’s not going to be exploitable.  

On the other hand, it can determine, if you have a payload for SQL injection, and it is going to be used in the database query and immediately block the behavior and also notify you of that behavior. In these instances, RASP is the more effective solution, as it allows defense in depth—and no organization can trust only one layer of defense today. 

Challenges to Deploying RASP at Scale 

Early on, when RASP products weren’t as mature, overall user experiences weren’t positive, and RASP impacted application performance. In addition, while RASP has improved and will continue to evolve over time, the efforts it takes to train RASP models are complicated, especially on mission-critical platforms. As a result, justifying RASP tools and encouraging adoption can be difficult for some teams.  

 
RASP technology is improving and making the barrier to entry or barrier to usage much less significant. RASP vendors are getting better at making it easy for the technology to feel more like plug-and-play, rather than needing significant customization. As RASP technology improves, what needs to change now is the mindset of teams who are worried about an unknown entity as part of their application that could potentially modify the behavior of the application, especially for mission-critical applications.

Many large organizations, such as financial services businesses are concerned because every moment of downtime leads to lost money. If the RASP technology blocks app functionality or other regular behavior that it shouldn’t be, this can have a drastic impact on the business. While RASP technologies may not see rapid deployment at scale because of valid concerns, more companies will start using RASP tools in small areas of the business. 

IAST versus RASP 

At a high level, IAST focuses on early lifecycle instrumentation and testing of the application during the development cycle for the most part. On the other hand, RASP offers runtime, in-production defense.  

Challenges of Adopting New Technologies 

One of the challenges with adopting new technologies is history. When organizations have had a negative experience with security tools in the past, they are hesitant to adopt new tools because of the assumed negative experiences. Developers, engineering managers, and organizations are frustrated with having to manage many security tools for different purposes. 

Initially, there was a push over the past decade to shift security efforts to earlier in the software development lifecycle (SDLC). The only way to shift earlier in the SDLC with technology was using static analysis tools because static tools can be run from the moment you’re writing your first piece of code. However, static tools end up being more noisy, disruptive, and prone to false positives, versus newer technologies. Static tools and other early technologies that teams tried to implement left a negative impression for a long time, which continues to make them skeptical of new technologies. 

Another challenge is that as organizations invest in more security testing tools, they think they’re improving from a security perspective, but don’t focus on remediation. What many organizations are missing is an effective threat and vulnerability management solution and a strategy to take results from testing tools and consolidate and resolve them.  

Improve Your Security Program with NetSPI 

Whether your organization uses IAST, RASP, or a combination of any other technology tools to identify vulnerabilities in your applications, having a strategy in place to remediate vulnerabilities is critical.  

NetSPI’s proactive security platform, can help your team improve vulnerability management, achieve penetration testing efficiencies, leverage security automation, understand your risk, scale your security program, and manage your ever-expanding attack surface.  

Schedule a demo to learn more about how NetSPI can help you effectively improve and scale your security program.