Saying that you think about web application security is not the same as actually doing web application security. Application security is tough and will likely continue to be until we have artificial intelligence guarding us (unless another, better AI is attacking?). For now, we need to think about security frameworks and execute against those frameworks to minimize the area available to attackers.
First, we have to understand the types of attacks that can be launched against web applications. The Open Web Application Security Project (OWASP) is particularly valuable here. For example, the types of attacks are enlightening and can highlight how reporting may be structured.
Once we understand the attacks, we can measure our vulnerability. There are a variety of test methods some of which include:
- SAST – Static Analysis Tools – This relates to scanning the binaries or source code at rest (AKA “without running the application”). This is helpful for development teams who would naturally have access to the source code. This would be part of manual code reviews, requires expertise from your personnel and may be part of some compliance requirements (for example, PCI DSS, which is a proprietary information security standard related to credit cards). Some teams will use Bug Bounties and other team incentives to get issues fixed, so beware of false positives and motion without progress.
- DAST – Dynamic Analysis Tools – This relates to outside testing, basically scanning as a typical attacker would scan to identify vulnerabilities in the web application layer. When someone talks about “vulnerability testing” with web applications this is usually what they mean. This is also different than penetration testing which seeks to leverage the vulnerability to determine the type of information exposed.
- IAST – Interactive Application Security Testing – This is a hybrid approach utilizing SAST and DAST. Working together both the client side and backend are traceable and some advantages can be gained such as discovering attack surfaces that are not publicly available.
We generally recommend DAST vulnerability assessments because the ultimate goal is to reduce the attack area available to bad actors. This is also the lowest hanging fruit for organizations that may be running external websites without a staff of technologists focused on security. After all, the desired outcome is remediation of the vulnerability, and ensuring it stays remediated – which leads us to improvements and governance.
Improvements usually include a combination of items, including the aforementioned secure coding remediation. Virtual patching through Web Application Firewalls (WAF) for public sites helps dynamically patch against attacks. This should be a baseline requirement and some load balancers or other edge devices also have this capability. Further analysis by specialty tools to scan the environment and report known vulnerabilities can be helpful. For example, we use a management tool to keep track of when plugin patches are available. Tools like Black Duck can scan for known upgrades depending on the open source software running. Tools such as Runtime-Application Self Protection (RASP) embed security on the server side-by-side with the application at runtime to validate all requests into the system without changing the structure of the code.
Governance and control is the next consideration. Security is not a one time event. It is ongoing and must be operationalized. The main part of this is monitoring and reporting. How many attacks? What type? Any emergent severe vulnerabilities? These types of questions help you gather data and report up through your dashboards. Integration of coding best practices from organizations like Cigital and training through both them and SANS should help uplift coding capability for the team. Emergent concepts in cloud security which are based on detection and response will also go a long way toward improving security.