You get a bonus - 1 coin for daily activity. Now you have 1 coin

Security testing: SAST, WAF, DAST, IAST, and RASP

Lecture



According to statistics, 90% of security incidents result from attackers exploiting known software flaws. Naturally, eliminating vulnerabilities during the software development stage significantly reduces information security risks.

The application security testing (AST) technology market consists of the following categories:

1st generation

  • SAST (Static Application Security Testing)
  • DAST (Dynamic Application Security Testing)
  • WAF (Web Application Firewall)

2nd generation

  • IAST (Interactive Application Security Testing)
  • RASP (Runtime Application Self-Protection)

To eliminate vulnerabilities during the software development stage, a whole range of technologies have been created to help developers identify security flaws early, removing them before the product is released. These technologies include:

  • SAST
  • DAST
  • IAST
  • RASP

Security testing: SAST, WAF, DAST, IAST, and RASP

Security testing: SAST, WAF, DAST, IAST, and RASP

SAST and DAST — Dynamic and Static Application Security Testing

SAST (Static Application Security Testing) — «white-box» testing, has existed for more than ten years. It allows developers to find security vulnerabilities in an application's source code at early stages of the software development lifecycle. SAST also helps ensure compliance with coding guidelines and standards without actually executing the underlying code.

Why is it called static? Because the test is performed before the program is run and executed. SAST can help identify weak spots in your program before the world finds them.

SAST uses a testing methodology to analyze source code in order to detect any traces of vulnerabilities that could provide a backdoor for an attacker. SAST tools typically analyze and scan the code in addition to how it will be compiled.

The SAST process is also known as white-box testing. Once a vulnerability is found, the next course of action is to review the code and fix it before the code is compiled and deployed to production.

DAST (Dynamic Application Security Testing) — «black-box» testing, can detect vulnerabilities and weaknesses in a running application, usually a web application. This is achieved by using fault-injection techniques within the application, such as feeding malicious data into the software, to reveal common security vulnerabilities such as SQL injection and cross-site scripting.

DAST can also shed light on runtime issues such as:

  • authentication and server configuration issues
  • flaws that are visible only when a known user is logged in

These cannot be detected through static analysis.

This tool is very different from SAST, since DAST uses a black-box testing methodology: it performs its vulnerability assessment from the outside, since it has no access to the program's source code.

DAST is used during testing and quality control in the SDLC.

SAST and DAST are often used together, because:

  • SAST will not detect runtime errors
  • DAST will not flag coding errors, at least not down to the specific line of code

SAST works well when it comes to detecting an error in a line of code, such as weak random number generation, but is generally not very effective at detecting data-flow flaws. In addition, SAST solutions are known for producing a large number of false positives or false negatives.

Abstract interpretation

Some success in reducing or completely eliminating false positives has been achieved using so-called abstract interpretation. However, to achieve the best results, abstract interpretation algorithms must be tailored to:

  • code that uses the application domain, which includes its architecture
  • the ways certain numerical algorithms are used
  • the types of data structures it manipulates

Security testing: SAST, WAF, DAST, IAST, and RASP

Despite all of SAST's shortcomings, it remains a favorite among development teams to this day.

The main selection criterion is the ability to scan the project at the code level.

This makes it possible to find flaws at early stages of product development, which helps reduce the cost of fixing them.

Moreover, SAST can be automated and transparently integrated into a project's workflow. This eliminates some of the problems typically associated with application security testing. This feature stands in sharp contrast to DAST, where large projects require building a separate infrastructure, running special tests, and launching multiple instances of the application in parallel with different input data.

However, DAST understands function arguments and calls, which cannot be said of SAST.

Features of SAST

  • Simple to deploy and use
  • Scalability
  • Comprehensive support for your programming languages and frameworks
  • Low rate of false positives
  • Easy integration into the SDLC and with other development and CI/CD tools

Example solutions for PHP

PHP Malware Finder (PMF) is a standalone solution that helps you find possible malicious code in files. It is known to detect tricks, encoders, obfuscators, and web shell code.

The Progpilot static analyzer lets you specify the type of analysis, such as GET, POST, COOKIE, SHELL_EXEC, etc. It currently supports the suiteCRM and CodeIgniter frameworks.

Arachni is a high-performance security scanner built on Ruby for modern web applications. It is available as a portable binary for Mac, Windows, and Linux.

Security testing: SAST, WAF, DAST, IAST, and RASP

Not just a basic static website or a CMS-based website — Arachni can also fingerprint the platform. It performs both active and passive checks.

  • Windows, Solaris, Linux, BSD, Unix
  • Nginx, Apache, Tomcat, IIS, Jetty
  • Java, Ruby, Python, ASP, PHP
  • Django, Rails, CherryPy, CakePHP, ASP.NET MVC, Symfony

Some of the vulnerabilities it detects:

  • NoSQL / Blind / SQL / Code / LDAP / Command / XPath injection
  • Cross-site request forgery
  • Path traversal
  • Local/remote file inclusion
  • Response splitting
  • Cross-site scripting
  • Unvalidated DOM redirects
  • Source code disclosure

You have the option to get an audit report in HTML, XML, plain text, JSON, YAML, etc.

Arachni lets you take scanning to a new level using plugins. Check out all of Arachni's features and download it to try them out.

Features of DAST

  • Flexibility that makes it easy to prioritize, schedule, and adjust tests as business needs change
  • Thorough analysis for any application
  • Ability to quickly scale your testing initiatives without resource constraints

Example solutions for PHP

RIPS is one of the popular PHP static code analysis tools that can be integrated into the development lifecycle to find security issues in real time. You can classify the findings by industry compliance and standard to prioritize fixes.

  • OWASP Top 10
  • SANS Top 25
  • PCI-DSS
  • HIPAA

IAST — Interactive Application Security Testing

IAST (Interactive Application Security Testing) — interactive application security testing. SAST and DAST are relatively old technologies, so there is a view that they are not the best choice for testing modern:

  • Web applications
  • Mobile applications

For example, SAST performs poorly with:

  • Libraries
  • Frameworks

And these are present in practically every modern application.

Static tools only see the application's source code that they are able to follow. Moreover, libraries and third-party components often cause static tools to get stuck, producing messages such as:

  • «lost sources»
  • «lost sinks»

The same applies to frameworks. A static tool will not find anything wrong in:

  • an API
  • a web service
  • a REST endpoint

All because it cannot understand their structure.

IAST was designed to address the shortcomings of SAST and DAST by combining elements of both approaches. IAST performs all analysis in real time:

  • anywhere in the IDE development process
  • in a continuous integration environment
  • in a production environment

Because IAST works inside the application, it can analyze:

  • application code
  • data flows
  • configurations
  • HTTP requests and responses
  • libraries, frameworks, and other components
  • internal connection information

Compared to SAST or DAST, access to all this information allows the IAST engine to:

  • cover more code
  • produce more accurate results
  • check a wider range of security rules

Features of IAST

  • Fast and easy deployment
  • Full integration into CI/CD workflows
  • Ability to both identify security vulnerabilities and determine whether they are exploitable
  • Ability to identify third-party and open-source components, known vulnerabilities, license types, and other potential-risk issues
  • Enterprise-level scalability to handle hundreds of thousands of HTTPS requests
  • Compatibility with existing automated tests, QA/dev tests, automated crawlers, unit testing, etc.

RASP — Runtime Application Security Protection

RASP (Run-time Application Security Protection) — runtime application security protection. Like IAST, it works inside the application, but it is more of a security tool than a testing tool. It attaches to the application or its runtime environment and can monitor the application's execution. This allows RASP to protect the application even if network perimeter defenses are breached and the application contains security vulnerabilities.

RASP allows the application to perform continuous security checks and respond to attacks in real time, terminating the attacker's session and alerting defenders to the attack.

Drawbacks of RASP

The main problem with RASP is that it can give the development team a false sense of security. Some security measures may be neglected on the grounds that — «If we miss something, RASP will fix it».

Another drawback of RASP technology is degraded application performance. IAST has the same drawback. Although performance-boosting techniques can minimize the slowdown, an unpleasant aftertaste still remains.

All of the technologies listed above have their own strengths and weaknesses, so combining them with one another provides a higher level of security. However, using even a single technology at early development stages makes it possible to build more secure software, and, more importantly, to do so faster and at lower cost than tying all tests together after already running into a problem at later stages.

Features of RASP

  • Code-level application visibility beyond what a Web Application Firewall (WAF) provides
  • Passive and active incident-response capabilities (e.g., monitoring/alerting and blocking modes)
  • Configurable to log, alert on, and block what it identifies as attacks
  • Support for many languages and platforms
  • Can operate standalone with a local remote server or with no remote connection at all
  • Coverage of a wide range of vulnerabilities

Conclusion and choice

SAST, DAST, and IAST are excellent tools that can complement one another without any issues, as long as you have the financial backbone to support all of them. Security experts always advocate using two or more of these tools to ensure better coverage, which in turn reduces the risk of vulnerabilities in production.

SAST DAST
This is white-box testing, where you can see the framework, design, and implementation of the program's source code.

The entire application is examined from the inside. This type of testing is often called the developer's approach.
This is «black-box» testing, where you have no access to the internal environment, and cannot see the program, its source code, or design.

Application testing is done from the outside. This type of testing is often called the hacker's approach.
SAST does not need to be installed, but it needs the source code in order to operate.

It typically analyzes the source code directly, without executing the program at all.
DAST needs to be deployed on the application server and does not need access to the source code before operating.

It is simply a tool that is run to scan the program.
This is one of the tools used to detect vulnerabilities very early in the SDLC.

It is applied as soon as the code is written. It flags vulnerabilities right in the IDE.
This is used only after the code has been compiled, to scan the entire program for vulnerabilities.
This tool is not expensive, since vulnerabilities are typically found very early in the SDLC, which makes them quick to fix before the code is put into production. This tool is expensive because vulnerabilities are usually found toward the end of the SDLC.

Remediation is generally not performed in real time, except in emergency cases.
This tool scans only static code, which makes it difficult to identify any runtime vulnerabilities. This tool scans the program using dynamic analysis to identify vulnerabilities at runtime.
This supports any kind of program. This only scans applications such as web applications; it does not work with other kinds of software.

IAST vs. RASP

IAST RASP
This is used mainly as a security testing tool. It looks for security vulnerabilities. This is used not merely as a security testing tool, but to protect the entire application by running alongside it. It monitors the program against any attacks.
This maintains SAST's accuracy by using runtime analysis results from SAST. This is a tool that detects and blocks threats in real time. This activity requires no human intervention at all, since the tool lives inside the main application and protects it.
This is gradually being adopted and requires agent deployment. This is not yet widely adopted and requires agent deployment.
Language support is limited. This is language- and platform-independent.
This tool is very easy to integrate for source code analysis, runtime monitoring, and all the frameworks that make up the program. This tool integrates seamlessly with the application and does not depend on any network-level defenses such as a WAF.
This tool delivers the best of a combination of SAST and DAST features, helping it identify vulnerabilities on a broader scale. Covers a wide range of vulnerable spots

Despite some limitations you may notice in technologies such as SAST, DAST, IAST, and RASP, using these automated protection tools always ensures more secure software and will save you the high cost of fixing a vulnerability discovered later.

Which is the best approach or security tool among these four?

Answer: Usually, the best approach is to use all of these tools, if your budget allows it. By implementing all of these tools, you will make your software stable and free of vulnerabilities.

Comments

To leave a comment

If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Lectures and tutorial on "information security - Cryptography and Cryptanalysis. Steganography. Information protection"

Terms: information security - Cryptography and Cryptanalysis. Steganography. Information protection