Interactive application security testing

An Introduction to Application Security Testing
Security flaws are one of the highest concerns to organizations. Traditionally, two approaches have been followed to test application for these vulnerabilities or security holes:
* Dynamic application security testing (DAST): This category includes most vulnerability scanners designed to test Web-based server applications in a running state, from the “outside in”, by testing their exposed interfaces. They are often referred to as black box testing tools and are independent of the language or platform used to develop the application under test.
* Static application security testing (SAST): This category includes most static code analysers which test applications from the "inside out" by analysing an application's source code, byte code or the native binary code. They are often referred to as white box testing tools and are highly dependent on the language or platform being used. They are better suited for use during the software development process.
The Need for Change
Application Security is of utmost importance to all organizations in today’s date. At the same time, the traditional processes have started to fall apart due to multiple reasons:
* Rapid Software Development - Introduction of agile methodologies have reduced the software development cycle timelines drastically. Traditional tools cannot be useful in these timeframes, as we shall not be able to quickly identify vulnerabilities present in the design or code.
* Complex Web content - Most AST tools assume that the protocol and data structures are easy to intercept, parse, and modify. HTTP indeed is all plaintext and so are the typical data formats sent by browsers. However, this has started to change over the past years and hence, the need for new AST tools is evident. With the development of Ajax, tools like soapUI, application frameworks using serialized objects, mobile applications like iOS, etc., testing of applications have become more difficult and require custom tools with custom data parsing.
* Shortening Testing Window - Many organizations are expanding their application architectures into mobile, HTML5 and WebSockets, and are interested in expanding their security programs. However, there is no scope to increase the time allocated to testing.
Even automation tools are incapable of testing the specialized and large amount of code developed today, round the year around the globe.
Interactive Application Security Testing (IAST) - Definition
IAST, a term coined by Gartner, combines the SAST and DAST techniques and aims to provide increased accuracy of application security testing through the interaction of both. The approach is to incorporate the best of SAST and DAST into a single solution, in order to confirm or disprove the exploitability of the detected vulnerability and determine its point of origin in the application code.
IAST is not a hybrid analysis of the two techniques. Setting up and running both dynamic and static tools on an application and then interpreting the results is time-consuming and requires expertise. The concept is to install an agent inside the application that can monitor control flow, data flow, software architecture, and anything else. Such contextual information from within the running application can help find vulnerabilities easily. IAST can see how the source code gets exercised in practice, how the data flows, and how the control flow operations actually work. Unlike dynamic tools, IAST can see into all of the code. And unlike static tools, IAST has access to the entire runtime context, including the full HTTP request, values from files, database results, etc.
Runtime Code Analysis Technology
IAST tools use the Runtime Code Analysis Technology wherein the code is analysed in memory. They are plugged into the application and then step-by step execution of the code is monitored. It gives us a clear picture on what the code is actually running on - memory allocations, query generations, and file accesses - real-time, as it happens. As mentioned above, this also provides us a visibility to the data that goes through the system. With this analysis of what’s happening in the runtime, we can create the next test/request, and that is how we create an interactive process of testing. The runtime analysis does not analyse the source code, but the binary.
Basic Interactive Application Security Testing Architecture
The below illustration is that of a single-tier application consisting of a Web server and a Database.
The IAST solution consists of two parts: the IAST agent, which is installed on the Web Application Server, and the IAST Console, which is used to generate HTTP traffic.
To start the testing procedure, the console informs the Agent that it is going to start sending HTTP requests, and that the Agent needs to start monitoring. Then, it sends an HTTP request to the Application server. These are potentially malicious requests or a sequence of QA test scenarios.
The Application sever starts processing the request, while the Agent is looking into everything that is going on. For example, if the application is sending some ODBC code through the Database connection, the Agent will be able to track that.
After it finishes running, the application sends the HTTP response to the Console. At this point of time, the Agent collates all the information collected during execution, and sends them back to the Console. The Console then processes the same and co-relates it with the HTTP response received.
In some IAST implementations, dynamic capabilities of IAST execute DAST scenarios as input for vulnerability testing.
IAST Agent Monitoring
What can be monitored?
# End-to-end HTTP requests
# Parameters propagation
# HTTP response writing
# Database/Directory calls and responses
# File System calls
# String manipulations
# Memory manipulations
# Usage of Third-party libraries
# Calls to external applications, APIs, and so on.
Overall, anything can be monitored, but it is easier with platforms like JAVA, .Net, PHP, Stored Procedures, etc. where there is a definite source code.
How does it monitor?
The most common ways of IAST monitoring are:
# Instrumentation : Instrumentation is an API provided by many runtime environments like JAVA, .Net, etc. which can be used to inject code into the application in runtime. Using this, we can inject code into the process memory that monitors the things we want to secure. We do not need to have any source code, or modify the binary.
# Debugging : We can use debuggers to put break-points wherever we require and then look into the memory, collect time-stamps, etc.
# By modifying the Runtime Environment.
# Aspect-oriented programming
# Recode/Recompile techniques
Benefits of Interactive Application Security Testing
The advantages of IAST over older techniques like DAST, SAST or DAST/SAST combinations can be listed as under:
# Visibility of Application Internals : Whatever is going during runtime is clearly visible to the Security tester. In additions, simulated attacks can be performed for finer analysis.
# False Positive Elimination : With higher visibility, false positives can be easily identified and eliminated. For instance, in case of a SQL injection, we can see the query being changed in the memory.
# Pointing source code for vulnerabilities : We can directly point to the source code which is responsible for the identified vulnerability. That makes it easier for the developers to fix the same.
# Demonstrate attack in memory : IAST solutions have high validation levels with which attacks can be illustrated to the developers.
# Identify more Vulnerabilities : Second generation IAST tools with data-tracking can identify more vulnerabilities than any other automated tool.
# Higher Accuracy and Speed : They are faster than scanners which, being unaware of the internals, test for all vulnerabilities on all parameters. We do not need to do that with IAST, as we know what is happening in the code.
# Fits Great in Testing Environments : Because of the above, IAST tools get fitted into the testing environment used by Quality Analysts for internal testing, very easily.
Development of Interactive Application Security Testing
Generation 1
First generation IAST tools are more common and focus on the basic stuff.
# They are used to track tainted inputs
:* SQL Injections
:* File/OS injections
:* Cross-site scripting (XSS), etc.
A request is sent and tracked for its response. The input validations are then validated.
# They can be used to identify the vulnerable source code.
# They can also be used to see the relevant query or response.
# Coverage monitoring/enhancement : IAST tools can accurately determine the part of code which is being tested and the part remaining.
For example, a request is generated and then the corresponding binary response is monitored. The exact lines of code which were executed during this process can be identified during the runtime monitoring. So, the next request/test can be designed to test a different code-flow. In the end, metrics can be generated to classify the part of code which is tested from the part which is not.
# Interactive Iterative testing : Based on the response of one attack, we can try for another attack or evasion, which can be similar or entirely different from the previous ones.
# IAST first generation tools are basically improvements upon the previous SAST/DAST correlation.
Generation 2
Second generation IAST tools are used to perform more advance tasks.
# End-to-end Data tracking: Data being transferred from one level to another in real-life multi-level applications is tracked and then used for deeper analysis.
# Testing the complete Application : They are used to test the security of an entire application, not just a part of code. The correlation of separate code segments in an n-tier environment, which might be secured independently but produce a vulnerability when executed together during a multi-step procedure, can be tested. With the use of second-gen IAST tools, we can identify persistent XSS by testing the correlations between multiple pages of the application.
# Data Sensitivity/Accessibility Classification : While sending the test request, we have the privilege to enter different types of data for different types of users. These can then be used to check for permission issues, authorizations, authentications, etc.
# Identification of logical vulnerabilities : Threats like data manipulation, parameter tampering, insecure handling of data, etc. can be easily identified with the use of data tracking. By tracking the whole data cycle, we can ensure that proper validations are in place to prohibit unexpected change of data.
# Tracking of sensitive data : Sometimes, sensitive data like Credit Card information, passwords, PII, etc. can get misplaced during the complete data flow. These can the source of future threats. With advanced IAST tools, these data can be easily tracked to see where they are running through the application.
Cons of Interactive Application Security testing
# Most IAST solutions require that an agent be deployed on the application platform, which renders the testing activity to be more effective when carried out by QA, and not so much for developers.
# The IAST agents run well on platforms or languages such as PHP, Java or .NET/ASP.
# Even though these agents are carefully designed to be passive, companies are generally reluctant to the idea of installing tools into a production environment.
# IAST agents affect the speed of applications. There is an approximate reduction of 20 to 30% in the application running-speed. Platforms using Debugging method of monitoring instead of Instrumentation, run slower.
Market
Some companies which are offering IAST solutions are Quotium Technologies, Armorize Technologies, Aspect Security and IBM. Market penetration at present is less than 1% of target audience.

Main Menu

See Also

Main Menu