IAST within the Production environment (Use Case)

As teams release code to production faster than ever before, mainstream AST tools are struggling to adapt to these changing conditions. Static ASTs help mostly during development stages, and are not well adapted to production environments. Dynamic ASTs are frequently used in production environments, but lack the agility to support continuous deployment practices. The reason behind this lack of agility is that DASTs produce snapshot analyses. This snapshot must be repeated every time the application changes: this is not efficient and does not conform well with DevOps practices. To make things worse, DASTs only identify 18% of the existing security issues of the OWASP Benchmark AST evaluation tool, and do not provide the location of the issue.

Table of contents

Production apps: AppSec pain points
Interactive AST for production apps

If you are new to this technology, start whith this post that describes the IAST vulnerability detection benefits.

The use case of using an IASTs  during development is obvious and clear. QA teams can also benefit from an IAST, as we detail in this previous blog post. Lastly, we firmly believe that IASTs can deliver tons of value to apps in production stage.

Production apps: AppSec pain points

Let’s review some Application Security pain points that we observe in our clients when they push their applications to production:

What’s the security stance of the application? how many issues, and what severity?

Teams lack insight into the security position of their applications. There is no easy way to review the number, severity, and exploitability of the security issues in the applications. A Red Team analysis and/or pen testing —this is how most teams cope with this pain point— takes weeks to complete, and must be repeated with each app update. Dynamic AST scanners are inaccurate and miss many security issues, plus do not provide information on the codebase location of the security issue.

How can I prioritize security patches?

Team managers wish they had a way to effectively prioritize security patches, based on tangible metrics such as the severity, the exploitability, and whether or not the app it is being attacked.

How can I direct the developers, and provide actionable details?

Once a team decides to patch a security issue, it would be great to provide actionable details on the vulnerability, such as location in the code base (file and line), type of the vulnerability, and codebase version.

How can I monitor third-party code?

The amount of third-party code included in apps keeps increasing. It is almost impossible to keep track of the different libraries included in modern applications. This includes keeping track of library version numbers to monitor CVEs and bug reports. As a result, teams fear that third-party code is introducing hidden security risks.

Interactive AST for production apps

As we mention above, we see IASTs as a formidable tool to assist in the maintenance and upkeep of applications that are in production stage.

Here are a few benefits that mitigate the pain points we just listed:

Plug-and-Play security

The security community is highly skeptical of tools that claim that require no customization and tuning. IASTs are, however, truly plug-and-play. Teams can be up and running with Interactive AST tools in a matter of hours, not weeks.

Real-time automatic picture of your security position

Management, Architects, and Operations teams value real-time analysis on the security position of the app. No need to interrupt developers or QA teams to run a manual security analysis. No need to attack the app, or hire expensive pen testers. The IAST data is always fresh, even if you push code daily. Everything is automatic.

Agile incident response

Don’t wait till it’s too late: receive automatic alerts when a vulnerability in your app is being exploited. The reports can also be ingested by a SIEM and/or connected to your task management system, such as Jira or Asana.

Smooth operation

Interactive ASTs impose a very small performance hit in the monitored applications. Also, since IAST do not block requests, there is no risk of damaging the user experience with false positives.

Automatically monitor external libraries

Modern IASTs will monitor your production application and alert teams when a risk is discovered in third-party libraries (OWASP Top 10 2017 #9)

Room for growth: upgrade to RASP when ready

Once the maturity level of the appsec operation increases, and teams become comfortable with an IAST running in a production environment, the next step would be taking a more proactive approach. RASPs and IASTs share the same core technology. So upgrading the IAST defenses to a blocking protection approach (RASP), would be a very efficient upgrade path.

Use case example:

1. Install the IAST agent in production environment: Just modify the launch command of your appserver and include the agent JAR in the deployment. This approach works both for cloud and on-premise deployments.
2. Monitor the IAST results: Developers normally use a developer toolbar to see the security issues in real-time while browsing the application. However, in production environments a web console and/or a connection to a SIEM system is the correct way of consuming the results.
3. Solve issues: Armed with tangible data on the number, severity, and exploitability of the vulnerabilities, request code patches. Since the IAST is integrated with task management system, and the tasks will have all the information attached, developers receive highly actionable input.
4. Improve over time: For each version and deployment, report metrics about the security metrics of the application. Celebrate improvements.