IAST is the emerging technology which is rapidly transforming the way code security is done. Instead of security being a pain and a worry, IAST enables a fully automatic process that ensures no code vulnerabilities creep in during development.
IAST technology works by hooking into the application and analyzing it from within as it runs. Just as a debugger would do, IAST looks into code execution in memory and seeks out specific events such as database queries, file system access, web service calls, input validations, and more. These events are analyzed to see how they may lead to vulnerabilities.
Currently there are two approaches to IAST:
- One of them is Active IAST, meaning there is a component generating malicious traffic and a component that monitors the application in runtime. The two components work together to identify vulnerabilities, clear out false positives and verify risk by performing simulated attacks.
- The other is Passive IAST which is composed just out of a monitor that looks at the application in runtime. Passive IAST has an inherent accuracy problem similar to the traditional static analyzer because it has no way to see how the application would really behave under an attack.
For this reason we focus this explanation on Active IAST, ideally paired with data flow analysis.
A basic deployment of Active IAST requires two components: one is a component that monitors the application and the other is a console that drives simulated attacks. These components work together to see how the application will behave under a real attack to see where and how it is vulnerable.
Analyzing the application in runtime allows to accurately see how vulnerabilities happen (for example – track user input from the moment it enters the application, through the point it goes into a database query, and up to a point the database returns a dataset which is then returned to the end user). It also provides an accurate location of the problem in the code by analyzing the runtime and tracing it back to relevant code. Even if no code is available (3rd party components or on-the-fly code) it would still provide the location of vulnerability.
Using the runtime code analysis agent, it is possible to monitor everything taking place in the code execution and memory of the process, including (but not limited to):
- HTTP Requests received by the application and HTTP Response writing and creation by the application
- Parameter Propagation within code execution
- Database queries (such as ODBC), Directory queries (such as LDAP), file system access
- String manipulations live in runtime (String merging, splitting, etc.)
- Memory (Watch specific values in memory, identify tainted input, etc.)
- Usage of 3rd party libraries
- Calls to external applications or services
- Execution of specific lines of code
- Much more…
What are then the advantages of this technology?
- Accuracy without false positive : It automatically finds vulnerabilities, performs exploitation to clean false positives, shows vulnerable line of code and suggests relevant remediation. No human intervention needed. This means it can (and is by many of our customers) be interfaced directly with existing software testing automation to give fully automatic application security as part of the SDLC.
- Cleaning false positives means the combination of seeing what is happening in memory in runtime together with simulated attacks that verify all vulnerabilities ensures the identified problem is an actual security threat.
- Testing is fast. Real fast. A probe is sent to see what parameters go where (database, file system, etc) and then the console generates only relevant attack attempts. This means testing is between minutes and hours. Even for large apps.
- 3rd party applications, on-the-fly generated code or applications for which source code is not available also can be tested because IAST runs on the compiled application in runtime. Old code nobody remembers where it came from? 3rd party code? Standard platform with customization? IAST tests it all the same
- It’s indifferent to the underlying framework. It can be Spring, Struts, MVC, or anything else – as long as the core technology is supported in runtime they all look the same.
- It needs no customization. No manual work is needed. It does not matter what function is called as long as the input can be traced to it in runtime. It does need to be manually told which web services are invoked – it sees this information directly in runtime memory. It does not need custom rules. It’s simple to operate.
Do you want to see it in action ? REQUEST A DEMO
This post is also available in: French