?AST - The Who, What, Why and Where of Application Security Testing

Picking your application security testing technology is not a simple task. Intuitively, you will ask yourself, “What is the best technology?” When you find the answer, it is then a simple matter of picking the product you like the best.

I am a big fan of intuition, but in this case, intuition will mislead us if we do not understand the full scope of our considerations. The question above basically sets us in a “DAST vs. SAST vs. IAST” mindset, when it should be “DAST & SAST & IAST.” In the world of AppScan, we came to that conclusion more than a decade ago, as we expanded from DAST to SAST and then into IAST. This expansion came as a realization that it is not just a matter of offering our customers more options. It is a matter of improving scanning coverage and reducing risk, applying security testing in more places in the DevOps lifecycle, using the right technology for the right job and offering the right tool to the right person. Technologies do not replace each other but complement each other and exist side by side.

Why are you looking for a single technology?

Technologies have strengths and limitations, they have intended audiences, they yield different types of results and they thrive under different conditions. A development and release lifecycle has many stages and many participants with varying skills and areas of focus. You can, and should, introduce the technologies in different points of the lifecycle to get the most effective security testing possible.

The search for a single technology usually stems from three reasons:

• Budgetary Constraints: Expenditure is always an organizational concern and there may be constraints.
• Profiles and Politics: The types of people working in an organization, who they listen to, which blogs they read and so on. The willingness of parts of an organization to participate in a security program and resulting arm-twisting (a.k.a. politics) all affect the technology choice.
• Misinformation: Or perhaps over-information. Knowing too much or not enough can be equally confusing.

Let us ask ourselves some more questions to try and frame the context of usage of each technology. They will help design your program, but if selecting a single technology is still your goal, they should help you decide.

Who is performing the scan?

This question is not strictly about who will be configuring or setting up the scan. The question is also about who will be executing it. Not that there is a special restriction, but technologies often have certain user-types in mind that fit them much better than other technologies.

Developers: Developers would benefit most by running SAST scans, but they can leverage IAST as well, with DAST probably being a less natural fit.

QA Engineers: QA engineers are most likely the best executors of IAST scans, as there is no special interaction. The scan happens as they are performing normal QA work (manual or automated testing). They are unlikely to run DAST scans and normally have no access to development environments for SAST.

Security Experts and Pen-Testers: Security experts and Pen-Testers find SAST and DAST a good fit but will mostly likely not use IAST.

Who will be the catcher of the results?

This is important as we would like the output to be as actionable as possible. Ultimately, development will receive all of the scan results and need to act on them (i.e. fix them). However, there may be additional catchers (such as Ops or IT) and intermediate processors.

SAST and IAST results are most directly consumable by developers. They hold the most direct information for them (such as specific code locations). However, developers who prefer recreation scenarios over code locations might get more benefit from DAST (it is really a matter of what the user gets accustomed to).

DAST results have more meaning for experts, pen-testers or Ops/IT (for fixing infrastructural issues). The code, in most cases, is inaccessible or irrelevant to them.

When are you planning to perform the scans?

Scanning can be time-consuming. Introducing another task into your development lifecycle, whether it be code reviews, unit-testing, automated functional testing or anything else, must be done with care. Security testing is just one of those tasks, but it is normally ignored. You need to consider what is most important to you.

If finding issues as early as possible is paramount, introducing security testing to developers using SAST is a great choice. Developers can also find certain DAST testing approaches very useful.

If your primary objective is minimal disruption to existing workflows, and you need the impact to be unnoticeable, then IAST is probably your technology of choice. Setting IAST to deploy with the application is a one-time operation, and once that is done the application is always monitored. Every time there is an interaction with the application (automated functional testing, manual testing or integration testing) the application is monitored for security issues.

You might be looking to build a new team dedicated to testing, external to your existing team. In that case, DAST technology will be their tool of choice. DAST offers testers the greatest degree of separation from the underlying code and executing application.

What is the expected outcome of the scan? What are you trying to accomplish?

These sound like silly questions. The answer to both of them is, “I want my application to be more secure!.” However, looking to limit the type of technology that you use is meant to accomplish some type of savings. You are trying to be cost-effective in monetary terms, time terms or any other terms. For that, you need to honestly answer these questions.

For example, you may be more interested in, or give a higher priority to, securing your server-side code, and if you would like developers to address issues as early in the development lifecycle as possible, then SAST may be the correct decision.

Another example is giving priority to avoiding developer distraction and encouraging time-savings. IAST would be appropriate to meet those priorities. This technology identifies flaws while you are doing something else. Very little effort is required to identify issues. While limited to the code that is being executed during that “something else” activity, it is extremely cheap in the criteria set.

Overlay and extrapolate

As you read this, you might believe that there are clear lines between who should use what and when. Reality is, of course, much more complex and the important thing is to identify the advantages and fit of each technology and optimize along those lines.

There are four parameters representing the lines: scanning strength, limitations, risks and assumed target users (assumed by the vendor).

SAST: SAST works great to identify server-side vulnerabilities (in web-applications; it covers all aspects of mobile and desktop applications). Client-side vulnerabilities can also be detected, under certain circumstances, but are not considered its strong suit. SAST results may require a significant amount of triaging and cleaning up. This process may not be trivial and may require several cycles, but code-oriented results make them ideal for developers and can be very effective in getting a quick fix turnaround.

DAST: DAST does a very good job with server-side vulnerabilities as well, but of the three technologies, it does the best job with client-side vulnerabilities. Its active nature also allows for a far more accurate validation and reduction of false reports. While missing code locations, test payloads can help in debugging, which may serve as a viable alternative. DAST does have certain blind-spots: It cannot identify issues that do not generate externally visible side-effects, on which DAST relies. Coverage can also be a problem as DAST can miss parts of an application that are difficult to get to. Not requiring the user to interact with the code or the running application, DAST is a tool that typically best suits pen-testers or out-of-band testing cycles.

IAST: IAST’s strength also lies in server-side vulnerability detection. In many ways it shares a lot of characteristics with SAST, with a significant limitation in that the quality of results depends directly on the quality of coverage of the functionality of the application. One advantage over SAST is the presentation of request data along with internal code representation. This enables a reproduction and debugging capability that’s otherwise missing from SAST. A second advantage is the runtime verification of proposed sanitation and validation code. Trust of the sanitation and validation code is performed either heuristically (unless well-known library functions are used) or by configuration. This is not required in IAST. The intended users are anyone who’s engaged in functional testing in an organization. This greatly increases the possible investment in testing, enabling testing to be done during development phases in which it was previously impossible or didn’t make business sense.

So, what do you think about the gaps? Are they something you can live with?

At HCL AppScan, our foregone conclusion is that you should not give up on any technology. You cannot afford to.

To Learn More

To test-drive Application Security Testing technology for yourself, request a 30-day free trial of AppScan now.