Branded Content by Cosmic Press

Web applications are a critical asset for many organizations, and specialized security tools have emerged that can help you protect these applications from cyber threats. In this article, I’ll review two specialized web application security tools, and one general-purpose tool that can be used to secure the web server: 

• Static Application Security Testing (SAST)—scans application source code to identify security vulnerabilities early in the development process. 
• Dynamic Application Security Testing (DAST)—scans applications at runtime using a black box approach, to find exploitable attacks from an attacker’s perspective. 
• Endpoint Detection and Response (EDR)—deployed on a web server, able to identify suspicious behavior on the server, alert security teams, and automatically block attacks on the endpoint. 

What Is Static Application Security Testing (SAST)? 

Static application security testing (SAST) is a white-box technique implemented during the early phases of the software development life cycle (SDLC). SAST tools analyze source code, byte code, and binaries, looking for security vulnerabilities and weaknesses. It works for mobile and web applications, as well as embedded systems. 

SAST facilitates early detection of issues in the source code, ensuring developers can fix coding and design flaws before deployment. By using SAST tools regularly, developers can catch vulnerabilities during the daily or monthly build and whenever the code is checked or released. 

What Is Dynamic Application Security Testing (DAST)? 

Dynamic application security testing (DAST) is a black-box technique that analyzes applications in runtime and production. It works externally to discover vulnerabilities and weaknesses by simulating cyberattacks, without access to source code. DAST provides information about the current security state of the application.  

DAST tools typically only test a web application’s exposed HTTP and HTML interfaces, but some tools can test non-web protocols and data malformation. A DAST simulation can employ various attack vectors to check the application’s resiliency. For example, it can try injecting malicious software (malware) into the application to test its resiliency to SQL injection (SQLi) attacks. 

You can run DAST tools continuously during and after development. A DAST scanner works by crawling through the application to find all exposed inputs on app pages and then testing each one. These tests are fully automated to facilitate rapid identification and remediation of risks. After detecting a vulnerability, a DAST tool automatically sends alerts to the relevant personnel for quick remediation. 

What Is Endpoint Detection and Response (EDR)? 

EDR solutions continuously aggregate and correlate telemetry data from multiple sources, including endpoints like workstations and third-party security solutions. Data collection typically involves deploying agents on endpoints and sending the information to a centralized location, such as a cloud-based platform, an on-premises system, or a hybrid solution. 

EDR solutions apply behavioral analysis on the collected data to identify potential threats, such as malicious software (malware), ransomware, advanced persistent threats (APTs), and emerging exploit chains. After detecting a potential threat, EDR solutions send out alerts to relevant parties, including internal stakeholders and external security teams.  

In addition to alerts, advanced EDR solutions can initiate automated actions in response to specific threats. The information collected by the EDR solution helps keep the platform informed, providing the context needed to distinguish between new threats and a long-term breach. Additionally, threat hunters can use this historical data for proactive investigations.  

EDR vs SAST vs DAST 

SAST 

Static application security testing provides the following capabilities: 

• White-box testing—testers can access the underlying framework, implementation, and design of the application, testing it from the inside out. It is a developer-based testing approach. 
• Source code analysis—SAST requires source code, not deployed applications. It can analyze the binary or source code without executing the app. 
• Early vulnerability detection—testers can execute SAST scans as soon as they deem the code feature-complete. It can identify vulnerabilities early in the SDLC. 
• Cheaper remediation—when teams discover vulnerabilities earlier in the SDLC, they can fix them quickly and easily, reducing the expense of remediation. By fixing vulnerabilities immediately upon detection, it is often possible to fix the code before it progresses to the deployment phase. 
• Supports most software types—SAST usually supports all web services, web applications, and clients.

However, SAST cannot detect environment- and runtime-related issues. SAST tools only scan static code, so they cannot discover runtime vulnerabilities. 

DAST 

Dynamic application security testing provides the following capabilities: 

• Black-box testing—testers don’t know what frameworks or technology the application comprises. They test the application from the outside. It is a hacker-based testing approach. 
• Application-based analysis—DAST requires a running app, not binaries or source code. It executes the application to perform an analysis.  
• Environment and runtime vulnerability detection—using dynamic analysis on applications allows DAST tools to identify runtime vulnerabilities. 

However, DAST has the following drawbacks:  

• Limited usability—DAST usually only works with certain applications, such as web apps and web services. It is not useful for other software types. 
• Late vulnerability detection—DAST can discover vulnerabilities later in the SDLC, so testers can only identify issues after the development cycle. 
• More expensive remediation—with vulnerability detection pushed to the end of the SDLC, Dev teams often have to fix issues in the next cycle. It is possible to address critical issues in emergency releases, but this is often more expensive.   

EDR 

• White box security testing—EDR is deployed on the web server, and can test the web server environment from the inside. However, it does not have internal knowledge of web applications and cannot perform white box testing on applications. 
• Requires a running application—EDR can only detect threats facing applications currently running on the web server. 
• Finds threats in production—EDR is only relevant for discovering threats in a production environment. However, EDR agents can also be deployed on development and staging environments to protect their endpoints. 
• More expensive to fix vulnerabilities—like DAST, EDR does not enable discovering vulnerabilities early in the development lifecycle, so remediation can be expensive and time consuming for developers. 
• Can discover complex threat patterns—unlike SAST and DAST, EDR can identify many types of suspicious behavior on the endpoint, such as failed login attempts, suspicious processes, data exfiltration, and more. 
• Can scan any type of application—web servers typically have software applications running which are not web applications—for example, databases, messaging systems, and other middleware or utilities. EDR can be useful in protecting these additional applications as well. 

Conclusion 

With web application protection growing in importance and complexity, there is a need to combine multiple tools to ensure protection. It is best to combine all three categories of tools I described above:  

• SAST – should be used early in the development lifecycle to uncover vulnerabilities and fix them before deploying to production. 
• DAST – should be used for preventive scanning in production environments, to discover exploitable vulnerabilities that must be urgently addressed. 
• EDR – should be used in production environments to identify breaches that have already happened, and enable security teams to detect, triage, contain, and mitigate the threat. 

I hope this will be useful as you improve the security posture of your web applications.