As we have discussed through this series, many types of attacks can impact the availability of your applications. To reiterate a number of points we made in Defending Against Denial of Service Attacks, your defenses need to be coordinated at multiple levels: at the network layer, in front of your application, within the application stack, and finally within the application.

We understand this is a significant undertaking, and security folks have been trying to get developers on board for years to build security into applications – with little effect to date. That said, it doesn’t mean you shouldn’t keep pushing, especially given the relative ease of knocking down an application without proper defenses within the application. We have found the best way to get everyone on board is by implementing a structured web application security program that looks at each application in its entirety, and can be extended to add protections against denial of service attacks.

Web Application Security Process

Revisiting the process described in Building a Web Application Security Program, web applications need to be protected across the entire lifecycle:

1. Secure Development: You start the process by building security into the software development lifecycle (SDLC). This includes training for people who deliver web applications, and improved processes to guide their activity. Security awareness training for developers is managed through education and supportive process modifications, as a precursor to making security a functional application requirement. This phase of the process leverages tools to automate portions of the effort: static analysis to help engineering identify vulnerable code, and dynamic analysis to detect anomalous application behavior.
2. Secure Deployment: At the point where an application is code complete, and ready for more rigorous testing and validation, it is time to confirm that it doesn’t suffer from serious known security flaws (vulnerabilities) and is configured so it is not subject to any known compromises. This is where you use vulnerability assessments and penetration testing – along with solid operational approaches to configuration analysis, threat discovery, patch levels, and operational consistency checking.
3. Secure Operations: The last phase of the process moves from preventative tools and processes to detecting and reacting to events from production applications. Here you deploy technologies and/or services to front-end the application, including web application firewalls and web protection services. Some technologies can protect applications from unwanted uses; others only monitor requests for inappropriate activity.

To look at the specific aspects of what’s required to deal with AppDoS attacks, let’s look at each step in the process.

Secure Development

In this phase we are looking to build the protections we have been discussing into the application(s). This involves making sure the application stack in use is insulated against HashDoS attacks and no database calls present an opportunity for misuse and excessive queries. The most impactful protections are input validation on form fields to mitigate against buffer overflow, code injection, and other attacks that can break application logic.

Understand that heavy input validation impacts application performance at scale, especially when under attack with a GET/POST flood or a similar attack. You should prioritize validating fields that require the least computational resources, and check them as early as possible. Extensive validation may exacerbate the flood attack and take down the application sooner, so you need to balance protection against performance when stress-testing the application prior to deployment.

Also ensure your application security testing (static and dynamic) checks the application’s robustness against denial of service attacks, including shopping cart and pagination attacks.

Secure Deployment

When deploying the application make sure the stack has protections against the common web server DoS attacks including SlowLoris, Slow HTTP, and Apache Killer. You can check for these vulnerabilities using an application scanner or during a penetration test. Keep in mind that you will likely need some tuning to find the optimal timeout for session termination.

Secure Operations

Once the application goes into production the fun begins – you will be working with live ammunition. You can deploy an anti-DoS appliance or service, or a WAF (either product or service) to rate limit slow HTTP type attacks. This is also where a CDN or web protection service comes into play to absorb high-bandwidth attacks and intelligently cache static content to blunt the impact of random query string attacks.

Finally, during the operational phase, you will want to monitor the performance and responsiveness of the application, as well as track inbound traffic to detect emerging DoS attacks as early as possible. You developed profiles for normal application behavior earlier – now you can use them to identify attack traffic before you have an outage.

Finding the Right Mix

As we have described, you have a bunch of options to defend your applications against denial of service attacks, so how can you determine the right mix of cloud-based, server-based, and application-based protections? You need to think about each in terms of effort and agility required to deploy at each level.

Building protections into applications doesn’t happen overnight – it is likely to require development process changes and a development cycle or three to implement proper security controls to protect against this threat. The application may also require significant re-architecture – especially if the database-driven aspects of the applications haven’t been optimized. Keep in mind that new attacks and newly discovered vulnerabilities require you to revisit application security on an ongoing basis. Like other security disciplines, you never really finish securing your application.

Somewhat less disruptive is hardening the application stack, including the web server, APIs, and database. This tends to be an operational responsibility, so you will need to collaborate with the ops team to ensure the right protections, patches, and configurations are deployed on the servers.

Finally, the quickest path to protection is to front-end your application with an anti-DoS device and/or a cloud-based CDN/website protection service to deal with flood attacks and simple application attacks. As we have mentioned, these defenses are not a panacea – you still need to harden the stack and protect the application as well. But deploying an inline device (or service) as a first line of defense, does not depend on any other part of the organization, so it is usually the quickest and easiest protection to get operational.

With that we wrap up our Defending Against Application Denial of Service series. As you have seen, there are many ways attackers can adversely impact the availability of your applications. Protecting yourself requires a multi-faceted program, including both server and application defenses. As always, we will assemble the final paper over the next week, integrating feedback on the posts, as well as some additional research we have been doing.