In the last article I have written about SAST and DAST, here I’m sharing some experiences with IAST and RASP technologies, which are still considered quite new to the application security market.
IAST (Interactive Application Security Testing)
If you ever used strace on Linux or equivalents on other operating systems, you know they are extremely useful for diagnosing application runtime or performance problems. They do it by hooking up to the operating system’s process tracing interface and running the application from there, looking at each system call’s inputs and outputs.
That’s precisely what IAST does, just on different level — in case of Java, using Java instrumentation API with an attached instrumentation agent, an accompanying JAR that will look at JRE API calls that your application is executing, along with all the data passed in arguments, and their outputs.
Conceptually it’s a revolutionary change in application security testing: rather than guessing from application response (DAST) or trying to imagine what would the code do if we supplied it with specific data (SAST), the scanner runs inside of your application at it sees precisely what is going on there. This has an enormous positive impact on the scanner’s precision: my personal experience on actuall business applications is that rather than producing hundreds of “this might be a problem” issues (SAST, DAST) out of which most are false positives or irrelevant (but you’ve had to spend time validating), IAST will show you a dozen. But you definitely want to know about each single of them.
IAST is great in terms of precision and lack of false positives, but this comes with a price: first, they are highly specialised. IAST scanner only works on a specific programming language (like Java, kind of obvious), then specific SDK (like JDK8 but not newer) but then it also needs to support specific version of the web application framework (like Spring, DropWizard etc) that you are using to be able to understand which API calls are data sources, which are sinks and which are dangerous. The good side is that once it knows that, it also know which API calls are used e.g. to sanitize or validate input data, and then it can actually confirm if the validation is effective — because it sees the data as it flows.
Another downside is that there are few IAST tools on the market — I know of Quotium (now Synopsis) Seeker, Contrast and CheckMarx IAST. All of them are commercial tools with varying support for programming languages, but mostly limited to Java and ASP.NET, primarily due to mature support of instrumentation interface in these languages. And they all are bloody expensive. And there’s no open-source equivalents.
Where to IAST?
Running application in an instrumentation interface comes at a performance penalty. If you do continuous integration, you’d want to run newly built application instance with IAST agent attached in a separate staging environment with all functional tests. Separate, because the performance penalty will mask your performance testing results. With all functional tests because IAST scanner doesn’t “scan” anything on its own — it fully relies on your application processing data supplied from outside, preferably by an extensive, automated functional test. And yes, it’s would be a great idea from coverage point of view to combine IAST-enabled app with a DAST scanner pointed on it. I know Synopsis Seeker comes with such a scanner by default, while Contrast will expect you to run your functional tests on your own.
If you use integrated testing framework (as in DropWizard or Django), there’s nothing preventing your from running IAST (well, at least I can say that about Contrast) even straight on your developer workstation. Some IAST scanners will also go a step further by scanning the JAR for compiled in libraries and checking them for know vulnerabilities (“dependency checking”) or even basic SAST by checking the bytecode for known vulnerable API calls (think MD5 or single DES for example).
We talked about these in detail above, so just a quick summary:
- As of 2020, availability on the market limited to few programming languages, limited support for their versions and web frameworks.
- Visibility limited to the very component you’re instrumenting: if it’s a single Java microservice, IAST will just see data flowing through this microservice, nothing else (unlike DAST, which looks at the application as a whole).
- Security testing coverage directly proportional to your functional test coverage. If you just run an app instrumented with IAST, you may see not a single issue until you actually execute some user journeys through the app.
- IAST has great signal-to-noise ratio, mostly by relying on the actual data flows observed in the running application, rather than guessing based on application output (DAST) or code syntax analysis (SAST).
From my personal experience, this single advantage in many cases may fully beat all the above disadvantages, assuming you know about them and realise limitations of IAST in your security assurance program. Especially in case of IAST your mileage may vary, and always be sure to evaluate candidate scanners on your actual application prior to purchase.
RASP (Runtime Application Self-Protection)
RASP is an evolution from WAF (web application firewall) and IAST, combined in one — it’s basically a web application firewall running inside your application, and combining real-time intrusion detection features using instrumentation, but with low performance overhead, suitable for production usage. OWASP AppSensor could be probably described as the first open-source RASP solution for Java, I also know commercial solutions offered by Waratek and Contrast. All of these are very different: RASP is a high-level behavioural concept rather than a well defined technology. OWASP AppSensor is a Java programming library, which you can use in your application to define additional security constraints and validation checks. Waratek and Contrast are both JRE plug-ins which offer specific intrusion detection and confinement capabilities, and as I tested them they significantly differed in the scope of offered functionality.
If IAST can be described by an analogy to
strace, RASP can be compared to
SELinux — runs as part of JRE, but controls your application behaviour
to ensure it won’t go for example reading files it’s not allowed to under normal circumstances. Once again, because RASP runs kind of inside your application, there’s no problem
with TLS or HTTP compression or encodings, because whatever it gets is already decrypted, decompressed and decoded. This makes intrusion detection much easier,
and attack evasion much harder.