Denial of Service (DoS) guidance

The network links between your service and your users, or between components in your service, could be saturated by illegitimate traffic. Consider:

• External connectivity to your service - Network bandwidth is a finite resource. If users access your service over the internet, your internet service provider will have provisioned you with a given capacity. Increasing this capacity may only give you a small gain, as the attacker may be able to saturate the network regardless of how much you increase bandwidth.
• Whether co-located services can affect you - If your service is exposed over a network link that is also used by other services, there is a chance that an attack on one of those other services could also affect yours.
• Network connectivity within your service - Internal network capacity in your service is also a finite resource that can be exhausted. Identify parts of your internal networking (connections and devices) that could present a bottleneck, such as network components with low throughput, or where multiple networks coincide.
• Management interfaces - An attacker may purposefully or coincidentally prevent administrators or operators from accessing servers during an attack. If your administrators or operators access the service over a network interface that an attacker can overload, you may be unable to administer or operate your service during the attack.
  
   

The amount of computing resource available to service legitimate requests can be overwhelmed by a surge in malicious sessions, or through a surge in compute-intensive operations performed by an attacker. Consider:

• Application capacity - An attacker may try to create more user sessions than you are able to cope with, or call application functionality which will be compute-intensive for your service. Both reduce your ability to serve legitimate users.
• Database query capacity - Depending on your service architecture, database queries could be computationally expensive to execute. An attacker can take advantage of this by calling functionality that puts a strain on your database servers, overloading your ability to respond to legitimate queries.
• Cascading failures - Putting strain on some components of your service can result in cascading failures on other components. For example, in a traditional n-tier web architecture, slowing down the response time of application servers or database servers can put stress on front-end web servers.
  
   

An attacker may attempt to consume your available storage capacity, leading to a service outage or causing a cascading effect on other aspects of your system. Consider:

• Application logs - An attacker may attempt to fill your available storage by repeatedly performing an action which writes a lot of data to a log.
• Local server storage - If your system relies on receiving files, for example user uploaded files to a website, or files received from third-parties, an attacker may attempt to flood your upload and/or transfer mechanism and exhaust storage capacity.
• Database capacity - Similar to the above, an attacker may attempt to fill database storage.