[CUSTOMER-FULL] DDoS Readiness
Guide & Run Book
[VERSION]
Prepared by:
Akamai Technologies, Inc.
[DATE]
Summary ............................................................................................................................................................... 3
DDoS Readiness – Goals .............................................................................................................................................3
DDoS Readiness – Initial Efforts .................................................................................................................................3
DDoS Readiness – Ongoing Efforts.............................................................................................................................3
DDoS Event Life Cycle ............................................................................................................................................ 4
Suspecting and Declaring an Incident ........................................................................................................................4
DDoS Event Underway – Triage, Mitigate, and Monitor ............................................................................................5
DDoS Event Declared Complete .................................................................................................................................5
Sharing Event Data .....................................................................................................................................................5
Stakeholder Contacts ............................................................................................................................................. 5
Akamai 24x7 Contacts ................................................................................................................................................5
Akamai Escalation Contacts .......................................................................................................................................6
[CUSTOMER-SHORT]’s 24x7 Incident Response Contacts ..........................................................................................6
[CUSTOMER-SHORT]’s Escalation Contacts ...............................................................................................................6
Monitoring and Alerting ........................................................................................................................................ 8
Recommended Preparation – Traffic Identification...................................................................................................8
Alerts ..........................................................................................................................................................................8
Monitoring Traffic ......................................................................................................................................................9
[CUSTOMER-SHORT] Attack Profiles Seen and Anticipated .................................................................................... 9
Akamai Recommended Preventative & Pre-Positioned Measures ....................................................................... 10
Logging and CPCode Pre-Positioning .......................................................................................................................10
Traffic Shaping via DNS Black Holing & DNS Geographic White Listing ...................................................................10
Fast IP Blocking ........................................................................................................................................................10
HTTP Application Layer Inspection ..........................................................................................................................10
Summary of Preparedness .......................................................................................................................................12
DDoS Readiness Playbook Manuevers ................................................................................................................. 13
Absorb the Attack ....................................................................................................................................................13
Deflect or Deny The Attack Request ........................................................................................................................13
Validate / Authenticate Transaction ........................................................................................................................15
Document Audit Trail ........................................................................................................................................... 16
2 DDoS Readiness Guide & Run Book
[DATE]
SUMMARY
This document outlines the process, contacts, and potential mitigation options for [CUSTOMER-FULL] with regard
to Akamai in the event of a suspected or actual distributed denial of service (DDoS) attack. The information in this
document will evolve over time as our respective teams change, new solutions and mitigations options become
available, and Akamai’s DDoS good practices are updated.
DDOS READINESS – GOALS
The goals of DDoS Readiness are to:

Ensure clear lines of communication when a DDoS is suspected or underway

Outline mitigation techniques that may be used in the event of DDoS

Establish shared expectations on mitigation technique’s including risks, benefits, and time to deploy.

Foster an on-going dialogue between Akamai’s [SUPPORT-TYPE] support team and [CUSTOMER-SHORT]’s
team to maintain DDoS Readiness over time
DDOS READINESS – INITIAL EFFORTS
The start of this engagement is used to:

Review and update [CUSTOMER-SHORT]’s Akamai usage, support procedures, and alerts to provide a baseline
on which future DDoS Readiness efforts will be built

Collect and share 24x7 and escalation contacts from both Akamai and [CUSTOMER-SHORT]

Establish an incident response process that can be initiated by either [CUSTOMER-SHORT] or Akamai’s
[SUPPORT-TYPE] support team

Update and enable contracted Akamai solutions for DDoS Readiness

Author initial playbook of DDoS mitigation steps and review with [CUSTOMER-SHORT] such that all parties
have a reasonable understanding of our joint capabilities prior to an incident occurring
DDOS READINESS – ONGOING EFFORTS
DDoS Readiness can be a challenge for many reasons, but perhaps the most challenging is sustaining a posture of
readiness over time as technical and business environments evolve. This DDoS readiness run book will be updated
as team members change and new mitigation options become available as Akamai good practices: this will allow
[CUSTOMER-SHORT] to take advantage of the latest mitigation techniques Akamai has effectively deployed to
protect customers around the globe.
3 DDoS Readiness Guide & Run Book
[DATE]
DDOS EVENT LIFE CYCL E
A DDoS event can be broken down into the following component parts:



A DDoS is Suspected
A DDoS is Declared Underway
A DDoS is Determined to be Complete
SUSPECTING AND DECLARING AN INCIDENT
If [CUSTOMER-SHORT] or Akamai personnel suspect that a DDoS event
has started, then they should immediately open an Akamai CCare
ticket. Depending on agreed upon procedures, stakeholders could
decide to setup and join a bridge.
Questions [CUSTOMER-SHORT] and/or Akamai should be able to
answer in order to rule out the potential that the suspected DDoS is
actually valid traffic:
1.
2.
3.
4.
5.
6.
7.
Did you just publish any new content to your site (especially
large content)?
Do you have an event underway, or recent press release that
could be driving traffic to your site?
Do you have any type of email campaign that may have just
gone out?
Do you have any type of 3rd party banner ad campaign that
may have just activated?
Did you just ask any 3rd party crawler (Google, Yahoo, Bing) to
refresh their index?
Do you know if your content has been recently referenced on
a site like http://www.slashdot.com or Oprah?
Was a recent CP Code level content purge requested (check on
https://control.akamai.com )?
After initial analysis is complete, [CUSTOMER-SHORT] and Akamai will determine if the suspected event should be
declared an ongoing DDoS event. This can be done verbally, on a call, or via email between stakeholders. When
an event is declared an ongoing DDoS, it should be documented in the already opened Akamai CCare ticket when,
and who, declared the event to be an ongoing DDoS.
At this time, Akamai will determine, depending on the impact of the event on the customer’s site availability,
whether the event should be declared an Akamai Service Incident, at which point normal Akamai Service Incident
procedures would take effect for the CCare ticket.
4 DDoS Readiness Guide & Run Book
[DATE]
DDOS EVENT UNDERWAY – TRIAGE, MITIGATE, AND MONITOR
While an event is underway, Akamai and [CUSTOMER-SHORT] stakeholders will jointly agree on the frequency of
updates between involved parties in order to appropriately monitor, manage, and mitigate the effects of the
event. These updates will generally be more frequent, especially if the DDoS is having negative impacts on the
availability and/or performance of the targeted site. Likewise, once an event has been mitigated to the point
where it has no impact on the target availability and performance, updates will be less frequent until the event is
declared complete.
DDOS EVENT DECLARED COMPLETE
Akamai and [CUSTOMER-SHORT] stakeholders will jointly agree when they declare a specific malicious event
complete. This declaration should be updated in the Akamai CCare ticket with a time the event was declared
complete, and the stakeholders who declared the event complete. At some point after the event is declared
complete, Akamai will provide a post event report to [CUSTOMER-SHORT].
SHARING EVENT DATA
It has been Akamai’s experience that appropriate authorities are often very interested in obtaining forensic
information related to attack traffic suspected of targeting customer web properties. By default, outside of a court
order, it is Akamai’s standard practice not to share any customer specific information with these authorities
without the consent of the customer.
STAKEHOLDER CONTACTS
This section outlines the primary 24x7 and escalation contacts for both parties. In the event of a DDoS it is
expected that the party detecting the potential attack will leverage the 24x7 contacts below.
AKAMAI 24X7 CONTACTS
For Akamai’s contacts, please do not rely on e-mail messages or voicemails alone, actual verbal contact is
preferred for the fastest response in all instances.
[UPDATE-THIS] The table below needs to be filled out.
Title / Role
[SUPPORT-TYPE] Customer
Care
Name
[SUPPORTTYPE] CCare
5 DDoS Readiness Guide & Run Book
Phone
Email or Web
[UPDATE-THIS] Use Priority or
Premium Number if they have
Pri/Pre Support, otherwise use
the Standard CCare phone # (e.g.
1-800-4-AKATEC in the US)
N/A for Emergency
[DATE]
AKAMAI ESCALATION CONTACTS
In the highly unlikely event CCare is not meeting your needs or expectations please feel free to reach out to the
extended account contacts and escalation contacts below.
[UPDATE-THIS] The table below needs to be filled out.
Title / Role
[SUPPORT-TYPE] CCare Lead
[UPDATE-THIS] Engagement
Manager if one is assigned to
this customer, otherwise delete
this row
Akamai Project Owner
Service Line Manager
Service Line Director
Name
Phone
Email or Web
Add Name
Add Name
[XXX.XXX.XXXX]
[XXX.XXX.XXXX]
https://control.akamai.com
NAME@akamai.com
Add Name
Add Name
Add Name
[XXX.XXX.XXXX]
[XXX.XXX.XXXX]
[XXX.XXX.XXXX]
NAME@akamai.com
NAME@akamai.com
NAME@akamai.com
[CUSTOMER-SHORT]’S 24X7 INCIDENT RESPONSE CONTACTS
The [CUSTOMER-SHORT] Information Assurance (IA) Security Operations Center (SOC) is intended to be the onestop shop for external contacts reaching into [CUSTOMER-SHORT] regarding suspected security incidents outside
of normal duty hours. The [CUSTOMER-SHORT] IA SOC should have the business contact “on-call” for any given
period of time for [CUSTOMER-SHORT]. The SOC will be responsible for escalating within [CUSTOMER-SHORT]
based on their assessment of ongoing threats, or based on the recommendation of external stakeholders calling
into the SOC.
IMPORTANT: If contacts in the table below are generic (like a customer’s general SOC distribution list), named individuals
with authority to direct Akamai to make business rule changes (i.e. implement, activate, or update DDoS Mitigations) on
behalf of the customer must have an ECMC Portal account setup on https://control.akamai.com with an Admin or Technical
role assigned. This is the primary means by which CCare has to validate that a customer representative has authority to
request changes be made to a [CUSTOMER-SHORT]’s site(s).
[UPDATE-THIS] The table below needs to be filled out.
Title / Role
24x7 [CUSTOMER-SHORT] IA
Name
Phone
Email or Web
SOC
[XXX.XXX.XXXX]
soc@customer.com
SOC
[CUSTOMER-SHORT]’S ESCALATION CONTACTS
Below is a list of some of the escalation contacts associated with [CUSTOMER-SHORT]. These contacts may or may
not be available outside of normal business hours.
IMPORTANT: If contacts in the table have authority to direct Akamai to make business rule changes (i.e. implement,
activate, or update DDoS Mitigations) on behalf of the customer, they must have an ECMC Portal account setup on
6 DDoS Readiness Guide & Run Book
[DATE]
https://control.akamai.com with an Admin or Technical role assigned. This is the primary means by which CCare has to
validate that a customer representative has authority to request changes be made to a [CUSTOMER-SHORT]’s site(s).
[UPDATE-THIS] The table below needs to be filled out.
Title / Role
Name
Phone
Email or Web
Business Contact / Web
Manager
Technical Contact
Add Name
Add Name
[XXX.XXX.XXXX]
NAME@akamai.com
Add Name
Add Name
[XXX.XXX.XXXX]
[XXX.XXX.XXXX]
NAME@akamai.com
NAME@akamai.com
7 DDoS Readiness Guide & Run Book
[DATE]
MONITORING AND ALERTING
Akamai provides traffic monitoring, alerting, and historical reporting, via the EdgeControl Management Center
(ECMC) Portal at https://control.akamai.com/. Akamai also provides a programmatic API to interface with the
ECMC portal. Customers can interface with this API and integrate Akamai ECMC data with their existing
monitoring systems. The ECMC portal provides [CUSTOMER-SHORT] with insight, visibility, and control for all of
the Akamai services currently provided to [CUSTOMER-SHORT].
RECOMMENDED PREPARATION – TRAFFIC IDENTIFICATION
Akamai recommends that [CUSTOMER-SHORT] work with Akamai technical representatives to determine if it is
appropriate to segregate traffic reporting based on geographic location. For instance, for a United States based
customer, potentially creating a CP Code for all US originating traffic and another CP Code for traffic originating
outside of the US. If deemed appropriate, this custom configuration may enable Akamai and [CUSTOMER-SHORT]
to more quickly identify traffic spikes originating from within or outside a specific geographic region, in near realtime. The intent of this change is simply to segregate reporting and alerting in order to allow [CUSTOMER-SHORT]
to identify potential sources of abnormal traffic as quickly as possible. This information could prove valuable, in
the early stages of a suspected DDoS event when making decisions on how to respond. It is not generally
recommended to create more than two geographic reporting segregations. Please consult with your Akamai
technical team in order to determine the best configuration for your situation.
ALERTS
[CUSTOMER-SHORT] already has access to set up alerts via the ECMC portal. Some alerts may have already been
configured. Akamai recommends that [CUSTOMER-SHORT], at a minimum setup the following alerts, since they
may be an indication of a potential DDoS:
Alert Type
High Traffic1
Threshold
xxx Mbps2
High Traffic
Edge Errors4
xxxx Mbps3
50%
Recommended Alert Title
Info: High [CUSTOMER-SHORT]
Traffic
Warning: Very High Traffic
Warning: 50% Errors
1
Status
TBD
Action
No action, just informational.
TBD
TBD
Triggers stakeholder call
Triggers stakeholder call
High Traffic Alert - Notifies you when the total Mbits/sec exceeds the Mbits/sec threshold you specified, helping you monitor your
bandwidth usage and traffic volume.
2
Recommend setting this at 2 – 3 times normal expected traffic.
3
Recommend setting this at 5 – 10 times normal expected traffic.
8 DDoS Readiness Guide & Run Book
[DATE]
Alert Type
Origin DNS
Failure5
Threshold
50%
Recommended Alert Title
50% [CUSTOMER-SHORT]
Origin DNS Failures
Status
TBD
Action
Triggers Origin Owner review. 30
minutes w/o resolution triggers
stakeholder call.
MONITORING TRAFFIC
Akamai recommends that the [CUSTOMER-SHORT] IA SOC monitor key traffic graphs available from the ECMC
portal. At a minimum, Akamai recommends setting up a traffic viewing screen in their SOC that is logged onto the
ECMC portal, using the Mozilla Firefox browser, with the refresh option set to every 1-2 minutes. This will provide
the SOC with a near real-time monitoring view of [CUSTOMER-SHORT] traffic. Recommended ECMC reports are.
Site Navigation
ECMC - Site Accelerator
ECMC - Site Accelerator
ECMC – Live Streams
Report Type
Traffic, Page Views
Traffic, Volume
Traffic
Description
Provides a real-time view of page views in views per second
Provides volume being pushed in Mbits per second
Provides a real-time view of current active live streams and
can help to give insight to current events on the site
[CUSTOMER-SHORT] ATTACK PROFILES SEEN AND ANTICIPATED
[UPDATE-THIS] [Capture previous DDoS attack details here and any explicit threat profiles the customer is
concerned about – for example:


Our shopping cart is highly CPU intensive and we are worried about bots just adding thousands of items to
the cart, this is a very high risk for our business and something we have seen bad searchbots and
performance monitoring solutions do, a large scale coordinated attack would be debilitating in our
current form.
[CUSTOMER-SHORT] has been threatened with attack by Anonymous or the Russian Business Network
(RBN), etc.]
4
Edge Errors - Notifies you when a certain percentage of requests for a particular CP code on Akamai edge servers returns a 4xx or 5xx HTTP
status code.
5
Origin DNS Failure - Indicates errors when Akamai edge servers are unable to reach the origin server because they're unable to resolve the
DNS name.
9 DDoS Readiness Guide & Run Book
[DATE]
AKAMAI RECOMMENDED PREVENTATIVE & PRE-POSITIONED MEASURES
Akamai’s professional services and [SUPPORT_TYPE] support team have made the following Akamai DDoS
Readiness good practices available to protect your site. These measures outline key mitigation capabilities
designed to bolster the DDoS Readiness of your site. Some of these capabilities are pre-positioned with up front
configurations and implementation activities, and some are activated during a DDoS event.
LOGGING AND CPCODE PRE-POSITIONING
Akamai will provision a new CPCode ([DDOS_CPCODE]) that can be used in the event of a DDoS attack to quickly
separate reporting for malicious versus non-malicious traffic. During an attack, traffic being identified as part of
the attack can be reported under this CPCode if desired. The key is to have this CPCode setup before it is needed
with log delivery proactively enabled, preferably to NetStorage to prevent additional origin capacity concerns.
TRAFFIC SHAPING VIA DNS BLACK HOLING & DNS GEOGRAPHIC WHITE LISTING
Due to the fact that many malware vectors target speakers of specific languages, DDoS attacks can often be
localized to a specific set of geographies, and sometimes specific countries. A Global Traffic Management (GTM)
property will be setup on behalf of [CUSTOMER-SHORT] to enable you to quickly black hole traffic from a specific
geography should it be deemed valuable to do so during an attack. Conversely, this same property can be used to
White List a specific geography (like a country) and prevent traffic from other countries from reaching your site.
For instance, if a site is only intended to serve customers from a specific country, then it may be acceptable to
temporarily shut off traffic originating from other countries.
This type of DNS mitigation has the distinct advantage of being fast to implement, and is often only constrained by
the DNS time to live settings for the GTM property being used: a change to block or white list a geography based
on DNS can be configured to take effect in as little as 20 minutes. The disadvantage of this type of implementation
is that it cuts off entire geographies (both good and bad traffic), and limits the forensic information available to be
gathered about the attacker.
FAST IP BLOCKING
If an attack is determined to be sourced from a distinct set of IP addresses, Akamai will be able to leverage our Fast
IP Blocking capability to deploy expedited IP blocking policies for impacted sites. These types of changes are
usually deployed to Akamai’s product network in about an hour.
HTTP APPLICATION LAYER INSPECTION
As a trusted partner of [CUSTOMER-SHORT], Akamai has the ability to inspect HTTP application layer traffic
headers and implement DDoS mitigation policies based on the content of those headers. For example, based on
these headers, Akamai can:
10 DDoS Readiness Guide & Run Book
[DATE]
1) Allow the request, via passive or active authentication, and serve content
2) Redirect the request to a new location (one that potentially applies additional business rules)
3) Deny the request
Akamai can take these actions based on information such as:








Referrer
User-Agent (i.e. the type of browser software)
Language
Method (e.g. POST, GET, HEAD)
Cookies
Requested Object
Client IP
Etc.
11 DDoS Readiness Guide & Run Book
SUMMARY OF PREPAREDNESS
The table below is a quick reference for each of the digital properties considered in scope for this DDoS Readiness initiative. [UPDATE-THIS] Update table as
appropriate with YES, NO, CONFIGURED, ACTIVE, or other appropriate information. This section is optional and can be removed from the final document if desired.
Digital Property
Configuration
DNS Traffic
Black Holing
www.customer.com
Secure.customer.com
Content.customer.com
Static.customer.com
Metrics.customer.com
DSA-customer.xml
Secure.customer.com.xml
www (IP Intel)
Secure (IP Intel)
None
None
none
Content.customer.xml
none
DNS
Traffic
Auth
No
Yes
No
No
HTTP
Geo
Auth
No
Yes
No
No
Validate
Cookie
Exists
No
Yes
No
No
Header
Inspection
Blocking
No
Yes
No
No
Header
Inspection
Redirects
No
Yes
No
No
DDOS READINESS PLAYBOOK MANUEVERS
How you respond to a DDoS incident is an important, and often difficult, question to answer. At times, politics,
costs, and other circumstances dictate that a response to a particular attack is both warranted and desired. When
this situation arises, Akamai can implement a combination of the maneuvers below. The best maneuver in a given
situation may change based on time considerations, long term forensic requirements, the nature of an attack, the
geo-political environment, etc.
The critical first step is discovering how to identify attack traffic versus legitimate traffic. Once this is understood
the mitigation options below can be reviewed to select the appropriate response for the attack profile.
ABSORB THE ATTACK
In general, the best attack is the one that never happens. Unfortunately, we know attacks will occur. That is why
the second best attack is the one you know about, but can withstand. In some cases, Akamai may recommend a
stance of not responding to an attack that you can absorb, but each case must be judged separately.
From a US-CERT perspective, this concept becomes particularly potent: consider the impact of a US Government
site responding to deflect and thwart a large attack against www.whitehouse.gov, and thus thwarted,
unintentionally enabling that same attacker to focus their efforts on knocking out a weaker, less prepared,
government target. Attackers often do not have good feedback regarding the intensity of the DDoS attacks they
initiate.
It is possible that a well absorbed attack will successfully discourage a powerful BOT controller by making them
misunderstand the scope of the resources at their disposal, hence underestimating the damage they can actually
inflict.
Implementation
Options
Estimated Time
to Mitigate
Risks, Notes and Other Considerations
 Relying on offload and capacity to absorb the attack based on pre-
configured business rules
No Action
n/a
 Closely watch critical indicators to determine if there is a level at which this
approach needs to be abandoned.
Maximize Offload
120-240
Minutes
 Start or Increase caching on targeted object(s) to offload traffic to the
Akamai Edge if the attacker targets an object with minimal, or no, caching
DEFLECT OR DENY THE ATTACK REQUEST
Block or Redirect traffic based on specific signatures of malicious traffic.
Implementation
Options
DNS CIDR Black
Holing
Estimated
Time to
Mitigate
Risks, Notes and Other Considerations
 Stop traffic via a DNS response to 127.0.0.1 based on the CIDR of the
15-30 Minutes
requesting Domain Name Server
 This is fast, but you significantly reduce your ability to gather intelligence &
[DATE]
Implementation
Options
Estimated
Time to
Mitigate
Risks, Notes and Other Considerations
attack forensics
 Risks denying good traffic with the malicious traffic and should be employed
when traffic from offending CIDRs is impacting site performance
 Stop traffic via a DNS response to 127.0.0.1 based on the Geography (typically
continent or country) of the requesting Domain Name Server
DNS Geo Black
Holing
15-30 Minutes
 This is fast, but you significantly reduce your ability to gather intelligence &
attack forensics
 Risks denying good traffic with the malicious traffic and should be employed
when traffic from offending geography is impacting site performance
 Currently limited to 32 entries (IPs or CIDRs)
Fast IP Blocking
30-60 Minutes
 In a large attack use these 32 entries for the largest offenders
 Allows more IPs or CIDRs than Fast IP Blocking
HTTP Deny based on
Client IP
120-240
Minutes
 Is good when the attacker is sourced from a finite and slowly changing set of IP
addresses
 Is best employed when it is preferable to block some good traffic instead of
letting any malicious traffic through
 Allows more IPs or CIDRs than Fast IP Blocking
 Is good when the attacker is sourced from a finite and slowly changing set of IP
addresses
HTTP Redirect based
on Client IP
120-240
Minutes
 Is best employed when it is preferable to let some bad traffic through instead
of denying valid end user traffic
 This relies on less capable BOT networks that do not follow HTTP Redirects, as
many do not
 Is good when the attack traffic from specific geographies is impactful
HTTP Deny based on
Geography
120-240
Minutes
 Is best employed when it is preferable to block some good traffic instead of
letting any malicious traffic through
 Is good when the attack traffic from specific geographies is impactful
HTTP Redirect based
on Geography
120-240
Minutes
 Is best employed when it is preferable to let some bad traffic through instead
of denying valid end user traffic
 This relies on less capable BOT networks that do not follow HTTP Redirects, as
many do not
HTTP Deny based on
Headers
120-240
Minutes
 Is good when the attack traffic contains specific HTTP signatures, such as a
specific set of User-Agent values, Llack of valid Referrer, Improper use of HTTP
14 DDoS Readiness Guide & Run Book
[DATE]
Implementation
Options
Estimated
Time to
Mitigate
Risks, Notes and Other Considerations
Method, unsupported language
 Is best employed when it is preferable to block some good traffic instead of
letting any malicious traffic through
 Is good when the attack traffic contains specific HTTP signatures, such as a
specific set of User-Agent values, lack of valid Referrer, Improper use of HTTP
Method, unsupported language
HTTP Redirect based
on Headers
120-240
Minutes
 Is best employed when it is preferable to let some bad traffic through instead
of denying valid end user traffic
 This relies on less capable BOT networks that do not follow HTTP Redirects, as
many do not
 Is good when the attack limits the attack surface to a small set of targets
HTTP Deny based on
URI
120-240
Minutes
 Referrer, Improper use of HTTP Method, unsupported language
 Is best employed when it is preferable to block some good traffic instead of
letting any malicious traffic through
 Is good when the attack limits the attack surface to a small set of targets
HTTP Redirect based
on URI
120-240
Minutes
 Is best employed when it is preferable to let some bad traffic through instead
of denying valid end user traffic
 This relies on less capable BOT networks that do not follow HTTP Redirects, as
many do not
VALIDATE / AUTHENTICATE TRANSACTION
Allow traffic through based on required characteristics of the traffic request.
Implementation
Options
Estimated Time
to Mitigate
Cookie Existence
Check
120-240
Minutes
Geographic Whitelist
CIDR Whitelist
120-240
Minutes
120-240
Minutes
Risks, Notes and Other Considerations
 Check for the existence of specific cookies before the edge server allows a
transaction to continue
 Only allow traffic from a specific geography (like a country)
 Only allow traffic from a specific set of CIDR blocks
15 DDoS Readiness Guide & Run Book
[DATE]
DOCUMENT AUDIT TRAIL
Version
0.1
0.2
0.3
Updated By
rpowell
Change Notes
Initial draft
Updated with pre-positioned details
Updated with available mitigation maneuvers
16 DDoS Readiness Guide & Run Book