These are responses to a white paper recently published by a major vendor on how to respond to ddos attacks. Views and Opinions are my own.

1. Responses to
10 Steps in Mitigating DDoS Attacks
in Real Time
B V S Narayana
CISSP, CISA
@bvsnarayana03
layer4to7.wordpress.com

2. • Very recently a white paper was released by one of the
IT vendor, on how to deal with a DDoS attack when
they are struck with it. The document highlights 10 key
factors, which they claim are the measures to be taken
during the attack. But the document mostly deals with
certain hypothesis and mostly approaches which are
reactive in nature.
• Next few slides highlight why these steps might not be
helpful during DDoS crisis.

3. • Verify that there is an attack.
Rule out common causes of an outage, such as DNS
mis-configurations, upstream routing issues, and
human error.
• Response:
This indicates that one should wait till they are
attacked and not take any proactive measures to
handle the attacks or mitigate them. This also hints at
human intervention and decision to decide whether
they are under attack or not. In such a scenario, one
could most probably take a guess on the nature of
traffic only if there is a spike. Otherwise, for any attacks
which are taking place at normal traffic pattern are
sure will be ignored. This puts any network at high risk.

4. • Contact your Team Leads.
Here the vendor mentions that the network and application
leads must be immediately contacted to verify the areas
being attacked and to confirm the attack and areas
affected.
• Response:
This is a tedious task and absolutely not sure if there would
be a common affirmation for such case. On any normal day
of business operation if the user complaints of slowness in
application, both teams safeguard themselves and passes
the blame on to the other team. Application team puts the
cause of slowness on network and vice versa. How then
under an attack scenario, one can expect the two teams to
be cohesive and confirm whether or not its an attack and if
it is, then confirm the magnitude.

5. • Triage your applications.
The vendor mentions that during DDoS attack, focus should be on
protecting the critical apps / revenue generators.
Response:
Now such decisions are a part of BCP/DR plan and the strategy is
clearly defined on which apps are critical, when should the DR be
invoked, what should be the RTO and RPO for such applications.
One doesn’t decide about a critical application and the strategy to
keep it live when struck by an attack. When under attack, you may
affected at internet/mpls pipes, network devices like firewals, IPS,
load balancer might be impacted, server infra might be hampered
or the applications might be siffering. So irrespective of the
strategy you have, even if you have good BCP in place, how do you
ensure that the attack doesn’t reach your 2nd or 3rd DC or DR
from where you host the business critical apps.

6. • Protect remote Users.
Vendor asks to maintain White-List IP addresses and asks to
propagate it across the network devices even up to the ISP.
• Response:
While internet is shrinking the world and businesses are striving
to be available globally today, how easy it is for any organisation
to know whether the genuine user should be hitting the
application from US, UK, India etc. It is completely un-realistic
and also not expected of the business to know the IP pool from
where the users would access the application. Business in
present era is all about being available to everyone from
everywhere at all times. White-listing approach is not a fit and
completely out of question to handle ddos.

7. • Classify the Attack.
Whether the attack is Volumetric, Slow, Low? Service Provider must have
already taken remediation steps.
• Response:
Here the hypothesis is that the customer is already subscribed to a
mitigation service from ISP. Even bigger hypothesis is that the ISP is
equipped to handle all types of DDoS attacks and is capable of identifying
and mitigating them in real-time. If the hypothesis is correct and for
assumption the ISP has really handled the attack, then what is the white
paper published for?
Customer if at all they are relying on the ISP, must understand what
capabilities are built in his cloud to identify and mitigate various DDoS
flavours. Whether the ISP is offering any SLA’s for availability, is there a level
of transparency with customer on when the attack started, when it ended,
actions taken, is there a portal for access to customer in real-time, whether
the ISP is willing to sign a penalty clause in case attacks get leaked and reach
to customer network.

8. • Evaluate Source address mitigation options.
Vendor asks to identify the source of attacks and block the at
firewall.
Response:
Gone are the days of DDoS attacks which emerged from a single
source. Now with sophisticated tools and the reach of internet,
attacks can be launched from anywhere from any no. of source
IP’s, spoofed addresses, attacks might be coming from proxies
or CDNs (which also carry legitimate traffic). How do you keep
a track of the IPs in such scenario. Even if the IPs are tracked
and ACL are applied at firewall or at perimeter routers, the
attack has still reached those devices and might result in
exhausting their resources or choking the entire service
provider pipe.

9. • Mitigate Application Layer Attacks.
Vendor asks to indentify whether the malicious traffic
is generated by a tool. Specific application attacks
might be mitigated by existing solutions.
• Response:
Here vendor has another hypothesis that the
customer has intelligent solutions to handle L7
attacks. Application layer attacks are quite complex in
nature and require specialised solution. They cant be
identified and treated by generic security solutions like
firewalls and IPS. Especially when the traffic is HTTPS,
perimeter security solutions are incapable of handling
such attacks.

10. • Leverage your security perimeter
If attacks still persist, it could be asymmetric layer 7
ddos floods.
• Response:
Nothing of the above counter measures or suggestion
were successful so it is obvious that the attacks would
still persist in your network. But its too early to
conclude on a specific attack type without having
treated them at various levels.

11. • Constrain Resources.
Vendor asks to rate-Limit all traffic.
• Response:
This is a severe concern and might be risk to revenue.
If couple of genuine transactions get dropped in an
attempt to block the attack traffic, there is high
possibility of the consumer landing on to competitor
business and thus you loosing the revenue. Rate-limit
is good technique to manage QoS for out going traffic,
but its very risky if using this for incoming traffic.

12. • Thus overall, the steps suggested in form of a white paper are
completely helpless to a customer under attack.
• There are various assumptions and hypothesis as indicated at
relevant points, there seems lack of experience in handling
such live scenarios under attack.
• For any customer/business, the right time to be prepared to
handle DDOS attacks is “NOW”.
• Businesses has to be proactive in nature and should
acknowledge that DDOS is a crucial factor if they are existing
on internet.
• Risk management documents should indentify DDoS as a
crucial risk element.
• There must be proactive measures and a competent response
team to handle such attack patterns.

13. References
http://docs.media.bitpipe.com/io_11x/io_113276/item_826799/ddos-infographic.pdf