In the world of web application security systems, there exists a myriad of systems to protect public-facing services in any number of ways. They come packed with all the elements necessary to play an action-packed round of buzzword bingo, but they often overlap in some ways that may make them sometimes seem similar. After the second or third pitch of how each product delivers whatever acronym, it sometimes becomes difficult to ask yourself which one you need the most.
Well, quite frankly, you probably need all of them.
The potential for overlap can often cause pause for question: Why is one solution not the best fit for all problems?
This sounds like an absurd question when phrased this way, but as is the case more often than not in IT, this very question is posed in one form or another from management to the security engineering team. In this article, we will provide a brief, high-level breakdown of what each type of web application security systems is, and why you likely need a mixture of all of them.
WAF – Web Application Firewall
In the Open Systems Interconnection, or OSI model, a network connection is abstracted into seven layers. A typical firewall may exist on layers 3 or 4, handling border routing or connection gatekeeping, but the most damaging attacks against web services are at the 7th layer, against the web application itself. This is where a Web Application Firewall (WAF) becomes a crucial asset.
Pros
- Especially in situations where a web application cannot be subjected to a source code audit or other security methods (such as in cases of proprietary, closed-source applications like JIRA or Outlook 365), a WAF can help prevent common attack methods from being executed (like typical cross-site scripting or SQL injection vulnerabilities).
- Typically adaptive, meaning that it is capable of reacting dynamically to an attack, rather than operating solely on strict thresholds (more usual of a typical firewall). This allows a WAF to apply heuristics to attacks that would otherwise normally escape detection.
Cons
- A WAF is highly complex due to the incredibly dynamic nature of web application security. Both configuring and maintaining a WAF requires a very deep understanding of the web application being protected, as well as requiring a thorough grasp on common web vulnerabilities to be most effective.
- A WAF is reactive rather than proactive, meaning it is acting only when triggered by an attack. If a web application is already vulnerable (such as having a 0-day in the code, something that should be discovered and fixed during a scan or source code audit), a WAF can do only so much to protect it – assuming it ‘knows’ how.
If you’re on Amazon they recently introduced their own WAF solution, there’s also NAXSI and the evergreen ModSecurity of course.
SCA – Source Code Audit
The oldest and most mature security methodology in this list, security source code audit remains a critical core component of a strong security posture to this day due to its invaluable benefits. Code audit is part of a process known as “defensive programming,” where a software is designed to be resilient and resistant to invalid data or misuse of the software. Commonly, this named practice is applied to lower level languages that have far more restrictive bounds (e.g. strcpy in C), but web applications also have critical bounds that a SCA can detect (such as XSS and SQL injection vulnerabilities).
Pros
- A source code audit, if executed effectively, will lead software developers and testing teams to discover bugs and, more importantly, vulnerabilities before they make it into production.
- To reduce impact and delays on deliverables, source code audits can be done real-time during an agile development cycle, especially when using unit and integration testing. These tests can be leveraged for threshold testing, ensuring that data is properly within bounds, sanitized, and that errors are handled appropriately and not leaking information.
Cons
- Source code audits can be done only against assets for which the code is available. Proprietary web applications where the code is closed-source cannot be subjected to the SCA process.
- A source code audit requires deep familiarity with the code being audited in order to be as thorough as possible. This makes it difficult to properly and effectively apply the SCA process to even open-source projects (such as WordPress) where the code is written by a third party and thus not as familiar to the personnel doing the source code audit.
- Source code audits are proactive rather than reactive, which while this sounds like a very desirable thing, it should not be relied upon as the only approach (as is usually the case). Code is infinitely complex, automation suites can only look for patterns (explicit or inferred), and human eyes are even more fallible. With each additional line of code, the complexity increases and, thus, so, too, does the probability of a vulnerability going undetected (a statement deserving of its own eponymous law or adage).
There are various static analysis tools that can help you run code audits such as:
– Brakeman – Static Analysis Rails Security Scanner
– Codesake::Dawn – Static Code Analysis Security Scanner For Ruby
– Graudit – Code Audit Tool Using Grep
– Yasca – Multi-Language Static Analysis Toolset
– RIPS – Static Source Code Analysis For PHP Vulnerabilities
And more..
Web Application Security Scanners/Web Vulnerability Scanners
A source code audit normally focuses only on the components of the whole application, applying methods of unit or integration testing that simulate certain conditions or data. However, much like how car manufacturers not only test the components but also the assembled car itself, web application security is no different. A thorough test must not only include the components, but the summation of the parts as a whole as well. A web security scanner does just this, emulating real-world traffic (specifically attacks) in order to find areas of weakness.
Pros
- A scanner may be able to detect vulnerabilities that escape detection during the development phase, including passing a source code audit. This can happen where individual unit tests may not see error in the way functions or methods are executed, but the summation of these parts run together may yield a vulnerability – something that may be detectable only during a security scan of the web application in full working action.
- Scanners are proactive and typically employed against code in development or staging environments (rather than in production, although it should be noted that scanning production is always a good idea regardless), which allows them to detect problems before they are discovered by users or, worse, by attackers.
- Scanners are automated tools that can do the work of hundreds of QA testers in a matter of minutes or hours. Since humans are prone to error and often begin to slip up the more repetitious an action is, a scanner can precisely execute and repeat a test over and over without making a mistake.
- Good web application security scanners apply heuristics to their scans and discoveries – such as digging deeper and attempting creative attacks upon finding a questionable but not exactly directly exploitable vulnerability – to find previously unknown attack vectors (sometimes called 0-day attacks) that could otherwise likely escape detection in all the other security methodologies mentioned in this article.
Cons
- Scanners can be invasive, therefore one must be very familiar with the tool prior to running a scan in a live environment.
- While scanners are proactive, they are also highly dependent upon pattern recognition of known attack vectors. As stated earlier, code is infinitely complex and, as such, vulnerabilities can escape the detection of a scanner (most notably uniquely exploited 0days).
IDP – Intrusion Detection and Prevention
Even with the most thorough and intensive source code audit, web vulnerability scan, and adaptive web application firewall, there still exists potential for a hacker to compromise a system. As stated previously, humans are fallible and problems can still slip through. If a web application or ancillary system (such as a database or key/value store) is connected to the Internet, directly or indirectly, one should assume it can be compromised, no matter what protections you put in place. Intrusion detection and prevention exists to find and limit when this happens.
Pros
- When tightly coupled with monitoring and off-machine logging in general, a well-configured IDP can provide immediate, deep insight into an intrusion that is being attempted or has successfully been committed. This allows a first-level response team to work far quicker in discovering and mitigating a threat before it becomes a more serious problem.
- An IDP provides a thorough mechanism of proving compliance with various regulations and standards, such as the Payment Card Industry Data Security Standard (PCI DSS). Not only are intrusion detection and prevention systems sometimes are a requirement in general (like with PCI DSS), but they act as an efficient tool during audits to demonstrate a strong security posture.
Cons
- Much like web application firewalls, IDPs are highly complex and require finely-tuned configuration and testing in order to be effective. Too restrictive and you will end up ignoring your IDP due to all the false-positives; too permissive and you may end up missing an intrusion when it happens.
- Also like web application firewalls, intrusion detection and prevention is mostly reactive rather than proactive, meaning it is acting only when triggered by an attack. If a web application is already vulnerable (such as having a 0-day in the code, something that should be discovered and fixed during a scan or source code audit), a properly configured IDP should notify the appropriate people immediately. But even in doing so, once an attacker has gained access, a lot of damage – especially reputation – has likely already been done.
There are various options here too like:
– Smooth-Sec – IDS/IPS (Intrusion Detection/Prevention System) In A Box
– pytbull – Intrusion Detection/Prevention System (IDS/IPS) Testing Framework
– Suricata – Open Source Next Generation Intrusion Detection and Prevention Engine
Summary of Web Application Security Systems
As demonstrated above, there is indeed some overlap between all these web application security solutions, so it is easy to see how one could think that not all are necessary. However, also as demonstrated above, there are many things that are highly unique to each solution. The overlap is also a good thing. A source code audit and web vulnerability scanner, for example, may both highlight similar potential problems, but they do so in largely different ways. What may be discoverable during an SCA may go undetected by a scanner, and vice versa.
The overlap, therefore, is actually a net gain in the end. Not only will each solution in combination provide many tangible benefits for the security posture of the web application, but they also act as a sort of check against each other to ensure that what goes missed in one solution may be detecting in another. Indeed, the most appropriate response is to, wherever possible, implement all of the aforementioned solutions, not just some.