Cloud environments and web applications are essentially under siege. Cyber attackers are constantly looking for weaknesses in an attempt to infiltrate and compromise your cloud-based servers, web apps and data. So far in this series, we’ve looked at secure coding practices and why it’s important to validate all input to defend against SQLi attacks, as well as the importance of vulnerability scanning and penetration testing once those apps are deployed. Now we will look at the third of the 5 tips for protecting apps in the cloud, employing a layered defense with tools like firewalls and IDS.
3. Layers of technology using Web Application Firewalls (WAF) and Intrusion Detection Systems (IDS)
A good second line of defense for protecting your web apps is the deployment and use of technologies designed to detect malicious traffic going to the application so an action can be taken to mitigate. Intrusion detection systems (IDS) and a web application firewalls (WAF) are two traditional technologies that are used to fulfill this role. Using both together can provide a strong layered defense against web applications attacks.
Because we’re specifically talking about web application attacks, let’s start this section with the web application firewall. WAFs are designed to work at layer 7 (application layer) of the OSI model, which means that they can inspect the actual HTTP request coming into the web application. This is an ideal place to detect anomalous or malformed HTTP requests, and a good WAF will have a default policy set that contains a signature set for detecting that malicious traffic.
Another advantage that web application firewalls have at layer 7 is their blocking ability. If the web application firewall is deployed inline, bad traffic can be stopped before ever reaching the web application, thus preventing the attack from having any effect. Another advantage of blocking is the ability to apply a “virtual patch” for flaws found in an application. Essentially, a temporary signature can be created on the WAF that is specific to the flaw, which allows time for developers to create a more permanent fix. This is often also used for legacy applications that are no longer being maintained.
One warning about blocking with a web application firewall is that it can also block legitimate traffic (false positive) if not tuned correctly. Tuning is the process of putting the web application firewall into a non-blocking state, which gives it time to learn the traffic patterns coming into the web app. A good WAF will allow the user to tweak and/or disable the signature that are causing false positive. Some web application firewalls, like Alert Logic’s WSM, will even offer the ability to drill down on every parameter, write your own signatures, and control every input, thus reducing the possibility of false positives.
In contrast to a web application firewall, an intrusion detection system does not operate at the application layer and cannot perform blocking of traffic. However, this doesn’t mean that an IDS isn’t an effective tool against web application attacks. It just means that it is used in a different manner.
Instead of working at layer 7 like the web application firewall, the intrusion detection system works at layers 3 and 4 (network and transport) of the OSI model. While the intrusion detection system can’t see the request in the same way as the web application firewall, it can still detect layer 7 attacks at those lower levels. The IDS signatures (using regular expressions and other methods) just have to be written specifically to find those attacks as they come across at those lower levels.
Because an intrusion detection system does not block attacks, the main purpose for an IDS is to detect the attack and alert (typically) an internal security team, which allows that team to take some remediation action. Detection allows decisions to be made based on policy, which can give the security team flexibility of action during their incident response phase. This kind of measured response can cut down on panic and the potential for blocking of legitimate traffic.
To wrap up this section, here are three quick points to think about with a dual WAF/IDS deployment:
- Deployment: How you deploy your WAF/IDS combo depends entirely on your infrastructure and business goals. However, we often see the pair deployed with the web application firewall closest to the ingress point of traffic into the web application. This allows it to weed out most cyber attacks because of its inherent ability to see layer 7 traffic. Anything that gets past the web application firewall can be then detected by the intrusion detection system, which can send an alert to the security team. This also serves the dual purpose of lowering the number of alerts that the IDS creates while also detecting other compromising actions by the cyber attacker at layers 3 and 4 (remote exploits, SSH login attempts, etc.).
- Layers: While a quality web application firewall and intrusion detection system combination that is well-tuned and maintained is very effective against web application attacks, a determined attacker who is very familiar with how to craft application layer attacks can often bypass these protections. Don’t fall prey to the notion that all you need to do is deploy a WAF and IDS. Make sure you emphasize a secure software development lifecycle.
- A huge benefit to cloud security technologies like a web application firewall and intrusion detection system is their ability to capture the network traffic in your environment, even if that traffic was not seen as malicious when it traversed your network. That traffic can be centrally stored as data and analyzed to find information on any successful attacks that were not detected, which can help you avoid future cyber attacks.
In the next post of this series, we will discuss how basic measures like effective identity and access management and staying on top of patching and updating can help prevent cyber attacks.
This post was a collaborative effort with Joe Hitchcock.