AST, SAST, DAST, IAST, MAST, and everything in between. But what do these acronyms actually mean? Let’s break it down into its core components.
What is AST (Application Security Testing)?
Application Security Testing is the umbrella for which the other acronyms fall under. In the simplest terms, AST means testing your application for data leaks, information leaks, privilege escalation, etc. There are plenty of ways to test an application and within AST, you can do it manually – penetration testing which produces results but there are disadvantages. Manual testing can be costly, and the attack surface is ever-changing which leads to errors. Ultimately, manual security testing is antithetical to the principles of CI/CD, so it’s out. Let’s move onto more practical AST’s.
Application Security Testing Caveats
Before we go any further, it’s important to spend time discussing the caveats with all automated application security testing. First, it’s mathematically proven that none of these approaches are sound. What does that mean? All these approaches can have either false negatives or false positives.
- False Negative – A false negative state is the most serious and dangerous state. This is when the system identifies an activity as acceptable when the activity is actually an attack. A false negative is when a system fails to catch an attack.
- False Positive – A false positive is when the system flags a security vulnerability that you do not have and the activity is actually acceptable behavior.
What is SAST (Static Application Security Testing)?
Also known as white box testing, static application security testing is a framework that analyzes source code for an application or sometimes the compiled application itself and analyzes the code to find security vulnerabilities. SAST takes place in the early software development life cycle, and helps developers identify vulnerabilities in the initial stages to quickly resolve them without breaking builds with real-time feedback.
SAST Disadvantages
There are a few downsides to SAST to be aware of. It is important to note that if the SAST being used is source code-based vs. binary-based, the tool will only scan the code which you have the source code for. To mitigate this, make sure that what you’re scanning is what you are putting into production. There’s no checking of any compiled libraries which you’re pulling in. Second, reflectively loaded code isn’t being checked, so if you are dynamically loading code, your SAST solution isn’t going to be able to check it for vulnerabilities. And the most common complaint you’ll see around SAST is false positives, since the tool is scanning hypothetical paths in the control flow which can lead to a lot of noise. To reduce the noise of false positives, rules need to be put in place and set correctly.
What is DAST (Dynamic Application Security Testing)?
Unlike SAST, Dynamic Application Security Testing tests the application while it’s running. This is done by using debug symbols or creating certain hooks into system calls within the application. This security forward approach allows the DAST to see how the applications behave while they are in production, hunting for a weakness that attackers could exploit. DAST’s most appealing feature is that it tends not to have many false positives, because you’re not dealing with hypothetical control paths.
DAST Disadvantages
A major disadvantage to DAST is that the tool only checks the control paths that are taken, meaning DAST only points out that a problem exists, but it can’t identify problems within the code itself. Also, DAST typically runs at a slow pace taking days or weeks to complete testing which extends timelines and increases costs.
What is IAST (Interactive Application Security Testing)?
Interactive Application Security Testing analyzes code for security vulnerabilities while the app is run by an automated test, human tester, or any activity “interacting” with the application functionality. Another big differentiator for IAST is that the tool works inside the application, which unlike SAST and DAST.
IAST Disadvantages
IAST is best used in conjunction with other testing technologies, and it is only as strong as the tests you’re using it with and the scope of your tests. Although it has 100% coverage, UAT or integration testing is a staggering investment in testing infrastructure. Although UAT tests tend to be fragile, the reason for failure is most likely due to the test being incorrect rather than the functionality. Because of this, most companies focus on testing limited functionality and rely on integration testing and/or unit testing to boost coverage.
There’s a more fundamental problem with this approach. QA tests are NOT security tests. QA tests essentially check that something is working normally through a UI. These types of tests focus on the most used part of the application and checks the well-trodden paths for unexpected breaks in features and functionality. Security testing focuses on breaking stuff, willfully breaking things, hidden things within APIs, parts of the attack surface which normally aren’t thought about, the exact opposite of QA tests which test the parts which you do think about (because you’re testing them).
What is MAST (Mobile Application Security Testing)?
Let’s dive into Mobile Application Security Testing and how it is different from something like SAST. MAST tests applications deployed within an Android or iOS ecosystem, where apps typically play in sandboxed environments, running signed code and with explicit permissions. It is important to ensure the tool you’re using understands what your APKs manifest means, how it impacts security, and what calls are being made to extract data from part of the infrastructure. MAST is crucial in the prevention of future attacks by guessing the behaviors of attackers and anticipating their moves.
Cybersecurity Cannot Be Achieved In a Silo – Quokka Does it All
There are very few companies out there who say they do SAST, DAST and even IAST. And if they do offer these tools, it is offered separately, treating them as separate entities. At Quokka we do things differently, which is one of the reasons why we’re so highly rated in the MAST world.
At Quokka, we do binary analysis of the generated APK or IPA, our technology scans all the code intended to be deployed in the form that it’s deployed. We don’t do siloed security, take a look at a few key points:
- We analyze the manifest, the results of which are sent to our SAST analysis engine.
- Our SAST engine runs our full static analysis to find potential issues but also to map ALL control flows. These results are then sent to our DAST analysis engine.
- Our DAST engine instruments and launches the IPA / APK and uses the SAST analysis with our Force Path Execution engine to run all the control paths within that app.
- We don’t leave it up to guess work, we make sure each path of the flow is being fully exercised.
- We execute with data we’ve seeded into the device, as well certificates baked into the device; ultimately being the ‘man in the middle’ of all the data hitting the network and finding the possible data leaks along the way.
Using this form of scanning for potential threats, we mitigate a lot of the false positives from SAST and look at the issues in reflectively loaded code. While from the DAST side, we monitor and scan the control paths via our Force Path Execution where we know where the paths are and forces them to be taken. Lastly, we take the positives from each engine and mitigate the negatives by leveraging an intelligent pipeline which uses the AST’s.
There is a paradigm shift. The future of consumer computing is Android and iOS. This change brings new challenges and new ways of thinking about security. Quokka is at the forefront of tackling these challenges. We help you to understand and mitigate these issues both as a developer and as an enterprise as a whole. Check out the Quokka website to understand how we do that.
