What is a Denial of Service Attack?

A Denial-of-Service (DoS) attack is an attack meant to shut down a machine or network, making it inaccessible to its intended users. DoS attacks accomplish this by flooding the target with traffic, or sending it information that causes it to behave unreliably or crash. In both instances, the DoS attack deprives legitimate users (i.e. employees, members, or account holders) of the service or resource they expected.

Overview

ZX Security has prepared this maturity model to help organisations evaluate their Denial of Service attack preparations. The preparations presented here are part of an ongoing process, not just something you review once. As each level is reached, the items on the lower levels should be revisited, as things are continuously changing (both your organisation’s IT systems, and the wider ecosystem of the Internet).

The items listed here are not exhaustive, nor is the list canonical. Rather, this document will help provide a starting point for discussions inside your organisation.

If you want to quickly assess your companies maturity, take a look at the following model and give yourself a score between 1 and 5. For more information read on below:

The content of the above image is also available as a PDF.

Level 1 - Lack of Awareness

• Lack of understanding of the organisation’s internet presence.
• Shadow IT present.
• No DoS risk/plan documentation.

Level 2 - Understand your Ecosystem

• An inventory of IT assets exists.
  • Know whether these are on premise, with an external service provider, hosted on the cloud, etc
• Understand the regulatory and contractual requirements of your systems.
• You have documented the expected impact of a DoS attack.
• A patching process for all systems exists and has been implemented.
• Inventory of all registered domains exists.
• You have engaged with suppliers, vendors, service providers, etc to understand their DoS mitigations.

Level 3 - Planning

• A documented communications plan if an attack were to happen.
• A plan for how the organisation is going to respond to a DoS attack.
• A plan for how the organisation is going to defend its assets.

Level 4 - Defending the Assets

• Implemented DoS mitigations for exposed systems and the systems on which they are dependent.
• All origin servers are restricted to just allow access from the CDN or DoS mitigation tier.
• Ensure the CDNs have points of presence in New Zealand and/or your major markets.
• Move origin servers to new IP blocks.
  • Ensure that origin servers do not have attributable domain names (such as through certificate transparency logs) and do not resolve in public DNS.
• Configure DoS protection for non-web services, e.g. VPN, Email
• Systems have been performance tested
• All domains are managed through a single registrar
  • Use a shared mailbox or distribution list instead of one person’s email address for registration.
  • Account details are stored in a password manager, or multiple users have been configured and passwords managed

Level 5 - Proactive Monitoring and Simulation

• Perform OSINT to stay abreast of potential attacks against your organisation.
• Systems are monitored for attackers performing reconnaissance.
  • Know what normal usage of the systems looks like.
• Architected to best use caching technologies offered by your CDN or similar.
  • Consider the use of third party APIs and how their availability affects your business.
• Define a method to identify new systems and shadow IT promptly after it is switched on.
• Perform a simulated DDoS attacks to quantify the impacts.

Description

Level 1 - Lack of Awareness

Level 1 is the base starting level for an organisation.

Organisations at level one are likely to not have a full picture of their IT asset base. Shadow IT will make this a task difficult, as the IT department and security team will not have visibility or oversight of these systems.

A plan for what happens during a DoS attack will likely not be in place.

Level 2 - Understand your ecosystem

Level 2 is about understanding the organisation’s systems and what the impact there would be to the organisation if a DoS attack were to occur.

The key tenant of being able to defend an organisation is to know what IT assets the organisation has and uses. Without this knowledge it will be difficult to understand what the threats are and how a DoS attack will affect the business. This inventory should include on-premise assets, cloud hosted assets, and SaaS assets.

Getting a view of Shadow IT assets is important, the assets should be documented and where possible brought under the control of the IT team.

While documenting the organisations IT assets, understand what systems interact with other systems. The interactions between systems will help you understand what the business impacts are if one system were to go down. As an example, it is important to think about what might happen if your DNS servers were to go down; what systems are accessed via their domainname for instance? This will help you determine where to invest further protections and mitigations.

Identify if there are any regulatory or contractual requirements which pertain to IT systems which must be available to your customers? If important information is not available on your site or part of an application, do other parts of your business need to shut down?

The risks of a DoS attack against each system should be documented, you should include the business impact of an outage for each discrete system. It should also be recorded if this system is fully independent or if it has dependencies on other systems and vice versa. These dependencies could cross boundaries, for example, your web application hosted in the cloud may perform authentication using federation to your on-premise Active Directory.

All these risks will need to be well understood, as it is important to know what the knock-on effects of a system being attacked are.

Patching in a timely manner (extreme risks should be patched within 48 hours (refer to ACSC Essential Eight: Patch applications and Patch operating systems)) is also important. Patching is a good way to eliminate “layer 7/protocol” DoS risks. As part of the inventory activity all systems should have a patching plan which outlines:

• How new updates are going to be identified by the IT staff (automatic install, email lists, web pages, twitter, etc).
• What testing needs to take place (if any) before the patches can be applied.
• Guidelines on when they will be installed.

Most companies will have a range of domains names. Along with the systems, the domain names should be documented. This should include details such as:

• The registrar.
• Where DNS is hosted.
• Where the credentials for the registrar and DNS hosting are stored (hopefully in a password safe)
• When they are next up for renewal.
• Where expiry/renewal notices and other correspondence are sent.

While evaluating new suppliers, vendors, service providers, cloud services, etc, understand what DoS protections and plans they have in place. Make this and other security items part of your organisation’s evaluation and selection process.

These providers may not necessarily be people who you are paying or have contracts with. For example, if you need to create a new environment in a new cloud region, you may hit rate limiting issues when deploying new containers. Container providers, as one example, often limit the number of requests which can be performed, this may hamper your ability to spin up all the containers required to deploy a new instance of your application.

Level 3 - Planning

Level 3 is about planning what the organisation will do if there was a DoS attack.

Create a communications plan so you know what to do if an attack was to happen. Know what is going to be said to the organisation’s staff, customers, users, public, etc and who will be performing that communication. Be clear about who is going to talk to the media. Media coverage may prolong an attack, as your adversaries may see the coverage as a sign the attacks are working. They may also use the media coverage to form part of their CV.

Have a plan for how the organisation is going to respond to a DoS attack:

• Know who the decision makers are and who need to be involved.
• Which systems are the most critical to restore service to?
• What are the inter-dependencies between systems, so if one system is not available you know what other systems will also be degraded.

There is an example DDoS Incident Response Plan template created by bananamster, which can be used as a starting point for your own response plan.

In preparation for level four, the organisation should be defining a plan for how they are going to defend the assets. The inventory created in level 2 will provide the scope and relative priorities for each system.

Given this is an effort which requires ongoing mitigation, the organisation’s development lifecycle should include items for:

• Ensuring new systems, and updates to them include DoS protections.
• Ensuring that the IT asset inventory is updated.
• Ensuring that the DoS response plans include the new or changed systems.
• That DoS mitigates are part of:
  • The requirements
  • Architecture
  • Design
  • Implementation
  • Testing

Level 4 - Defending the Assets

Level 4 is about ensuring all the organisation’s systems (web, remote access, APIs, email, IRC, etc) have DoS protections in place.

All exposed systems should have a CDN or similar DoS protections in place. Consideration for the internal systems which the exposed systems depend on should also be taken into account.

The domain names for these services should be hosted using a DNS provider that has the infrastructure in place that provides DoS protections. This is important if the organisation is suffering a DoS attack there may be a need to update DNS, having this separate from the infrastructure under attacks allows for this.

Origin servers which are being fronted by a CDN should ensure that they only accept requests from the CDN. This can be done through firewall rules or app proxies, so all traffic is filtered through the CDN.

When the origin servers are moved behind a CDN, they should be moved to a different IP block. This is so historical information regarding IP addresses cannot be used as a CDN bypass mechanism. Remember, even if the server has a firewall to block requests, some DoS attacks are bandwidth intensive and may be able to overwhelm your network regardless.

When selecting a CDN provider, look for one which has points of presence in New Zealand and/or your major markets. In addition to providing DoS mitigations these changes can also improve the user experience.

HTTPS or other transport encryption should be used between the origin server and the CDN tier. Care should be taken such that the host names which get published to the certificate transparency logs are not attributable to the organisation, or they should not resolve in public DNS.

In addition to web assets, other internet facing services should be configured for DoS protection. VPN concentrators can be proxied into a cloud solution using tools such as app proxies, where the cloud solution can enforce authentication before passing the traffic to the concentrator. The cloud authentication ensures only authorised people can send traffic to your infrastructure which is based on-premise, with the cloud provider able to mitigate an attack by denying unauthorised users/traffic from reaching your systems.

If you are not already doing so, the organisation should consider the use of a cloud email provider. There are four major advantages to this:

• The webmail portion will be well protected against DoS attacks.
• There is less of a risk that your organisation will lose the ability to receive email. This is because the cloud providers have many geographically diverse inbound email servers which are hardened against DoS attack.
• The ability to send mail will also be protected as the cloud providers are too large for other providers to cut off or add to a block list. We have seen organisations who send email themselves or through a service provider, where their outbound email server gets placed on an email block list and any email they send gets rejected by the recipients.
• The provider will patch their systems often well before a vulnerability is publicly disclosed.

Perform a performance test of web sites and APIs. When slow endpoints are identified they should be fixed. Try and avoid putting “yes that page is slow, but its only used rarely” on the risk register. The slowness might not affect your users, but to an attacker, it will become their point of attack. The slowest may indicate that the request is not be cached by the CDN and/or that the request is making the database consume a lot of CPU time which may affect other users of the site.

Move all domain registration to one registrar, using a single shared email inbox or list for correspondence. If there is a need to update the details, all the organisation’s domains are in one location. Having a shared email inbox, important emails, like renewal notices, will be received and not lost if someone is on leave or has left the organisation. The credentials for domain registration and the DNS provider should be stored in a password manager and all relevant people should have access.

Level 5 - Proactive Monitoring and Simulation

Level 5 is about putting the organisation in a position where they are on the front foot regarding DoS attacks by running through simulations and increasing their situational awareness.

Perform Open Source Intelligence (OSINT) gathering to stay abreast of potential attacks which may be targeting your organisation. This is particularly relevant if you are the target of an issue motivated group, they may discuss potential attacks before performing them (such as threatening an attack publicly).

You should be monitoring the performance and usage of your applications and network infrastructure. This should be started before an attack so that there is a benchmark for what normal usage looks like. Detailed monitoring of usage may allow you to observe potential attackers conducting reconnaissance before performing an actual attack. This reconnaissance can be used to tune the DoS defences and potentially stop an attack before it starts.

Some of this monitoring should be performed external to your infrastructure. This will ensure that it follows the path of your users and can make accurate observations if performance changes.

Require DoS protection and/or mitigations as a non-functional requirement for all IT projects. Systems should be architected to make the best use of caching technologies and DoS protections which CDNs and other DoS mitigations products offer.

If your systems uses APIs from third parties, consider the impact on your systems if these APIs were to be unavailable.

• Can your systems gracefully handle these systems being down?
• What will be the impact, e.g. credit card processing will fail, how will your application handle that to minimise lost business?
• What will the communication plan be and what will the error messages look like?

There needs to be processes and methods in place to ensure that when new systems, infrastructure and shadow IT (remember you need a process to detect this) are added to your organisation, they are recorded in an asset register. This will allow you to:

• Know what assets you need to protect.
• Ensure that new assets are not targets and have the required protections in place.
• Know if the new assets create a risk for existing systems.

Perform simulated DDoS attacks against your organisation to:

• Quantify the impacts and verify assumptions are correct.
• Ensure that if you are buying services you are getting what you pay for.
• That the mitigation/communication/notification plans work as expected.

The results from these simulations should feedback into the previous levels to help improve them.