Preparing to withstand a DDoS Attack

A Distributed Denial of Service (DDoS) Attack, unlike most other cyber threats, is a lethal form of threat that is almost impossible to eliminate, and its “planned” execution can have a deadly effect on the target. This form of cyberattack is still as dreaded as it was a decade ago. This attack, unlike other forms of cyber-attack, targets the limitations of IT systems which all organizations have, and hence all are vulnerable to a DDoS attack by default. Additionally, tools to generate such attacks are freely available and easy to use. On the other hand, enterprises are generally ill prepared to handle these attacks.

Given below is quick checklist that an enterprise can use as a good starting point to assess their readiness to handle a DDoS attack.

More information regarding ways  an organization can prepare it self to withstand a DDoS attack can be found at my SANS article with name Preparing to withstand a DDoS Attack 

Question							Yes	No	Don’t Know
Preparation Phase
Does any of current ISP(s) provide Anti-DDoS service									X
Have important point of contacts for ISP(s) been identified and documented for quick coordination call?									X
Do we know level of support to expect from ISP(s) during attack?									X
Have critical assets been identified for prioritizing traffic for it?									X
Is process to deal with extortion demand in place?									X
Has DDoS impact analysis done?									X
Can the mission critical services be enabled from other site?									X
Does DNS record for critical hosts have short TTL for quick IP Address change?									X
Identification Phase
Is baseline network usage pattern identified? May be using MRTG or Flow for easy identification of attack									X
Are logs/events from critical servers and devices been fed to SIEM system for timely alerting?									X
Is service uptime for critical services been monitored and alerted using NMS?									X
Is resource monitoring and alerting enabled on servers and network devices using NMS?									X
Are mission critical public services (e.g., corporate website, mail server, DNS servers) being monitored from Internet?									X
Are critical mail boxes (tech-contact, abuse., etc) been monitored?									X
Does NIDS have DoS/DDoS specific signatures enabled and tuned?									X
Containment Phase
Can ISP(s) be asked to black hole/null route traffic for a host or subnet?									X
Can we initiate black hole/null route on ISP(s) network using BGP community modification?									X
Can ISP(s) be asked to perform mitigation of DDoS attack?									X
Is there any Anti-DDoS service provider engaged to help during attack?									X
Are anti-spoofing rules enabled in border devices to prevent spoofing attacks from being originated from inside network?									X
Are anti-bogon rules enabled in border devices?									X
Are out-of-band access available for critical network devices?									X
Is process in place to quickly enable access lists/other filtering in border network devices?									X
Are border device limits and capability information documented and readily available?									X
Does border network devices have control plane policing enabled?									X
Is dedicated anti-DDoS equipment installed and operational?									X
Is someone identified to perform negotiations with extortionist if need be?									X
Eradication Phase
Is a comprehensive DDoS incident response method available?									X
Has the DDoS incident response tested?									X
Is the DDoS incident response document getting regular updates?									X
Recovery Phase
Is process in place to test if the mission critical services are working as they should?									X
Is asset-to-business owner information available to verify functionality of server/service post an attack?									X

Incident management parameters

Setting up “security program targets” starts bringing things into perspective, without which most of the things are left to individual perceptions and are highly subjective. It is no more news in cyber security industry is that an organization will get hacked, regardless if its already hacked or not. Hence having a comprehensive incident management program is of prime importance.

The two most important factors that the incident management program needs to consider are Mean Time to Detect (MTTD) and Mean Time to Recover (MTTR). Before starting an incident response program, these two goals should be clearly defined as per realistic expectations of management.

Looking at some of the big security incidents, in my opinion, the CISO should first ask CEO, on when would he consider firing CISO, which would make a upper limit for CISO to start working on defining key parameters for their security incident management program. This also includes setting up realistic values for MTTD and MTTR. Once these values are set and met for most of the incidents, it is to further tighten them.

These parameters, once defined, should be engraved into hearts and minds of everyone in security team, by enforcing it repeatedly by means of speeches, documents and posters. Any changes that are done in the organization should be measured against these values to determine how this change will affect organizations MTTD and MTTR targets, and hence deciding whether to allow those changes to be implemented or not.

In order to meet MTTD and MTTR values for the first time, the necessary assessment of the organizational security posture should be done, which would help them identify gaps, which may result in missing these security parameters.

Some of the remediation measures to increase MTTD values can be:

1. Identifying key resources to monitor
2. Setting up a 24×7 SOC
3. Installing necessary probes with in network to generate alerts
4. Upskilling security staffs
5. Setting up escalation paths, along with setting up in-band and out of band communications channels

Some of the remediation measures to increase MTTR values can be:

1. Setting up EDR solution across organization
2. Automating some of the key SOC tasks
3. Re-architecting infrastructure to minimize impact of security incident
4. Setting up and testing backups and DR plans
5. Setting up and testing working relationship with other stakeholders such as ISP, Security vendor and business leaders to help initiate necessary action during security incident

Hence, if your security team does not currently have a comprehensive security incident management program, you are bound to fail during a security incident. Also, if there is an incident management program and it doesn’t speak about MTTD and MTTR parameters, the program will still not be effective enough.

How much Security are you using?

The concept of building a layered security solution, which is called defense in depth, is not alien to security world including cyber security.

The oldest implementation of Defense in Depth known to humanity, dates more than 5000 years back. When guru Dhronacharya implemented Chakraviewh during Mahabharat war to capture Yudhisthir. While that plan was not as successful as they wanted it to be, but the concept still provides much stronger security than any other solutions.

Despite of cyber security knowing this principal since decades, it is difficult to see it being implemented in real world. One of the reasons for this is increasing cost of security solutions. While it is wise not to spend thousands of dollars to protect asset worth hundreds, but what is wiser is to increase organizational security posture without increasing cost of security.

One of the ways to implement Defense in Depth without increasing security cost is to look and configure every Operating System, every application, and every appliance with security mindset. Given below are some of the examples of such security configurations at different level:

1. Operating System hardening
2. Configuring HIPS and Firewalls at Operating system level, other than traditional AV solutions.
3. Switches can be configured with VLANs and PVLANS, including post security and mac security features
4. Wifi devices can be configured access control and mac filtering
5. Routers can be configured with management plane and control plane security along with traditional packet and session filtering solutions.
6. File and FTP servers can have stronger file permissions with encryption
7. Printers and Print servers can hardened and configured with spool encryption
8. Configuring Group policies and local policies in windows environment
9. Eliminating Telnets and using SSH using password protected Keys for *nix hosts.
10. Configuring log auditing and multifactor authentication for accessing cloud applications.

These are just some examples of reconfiguring existing devices with security mindset, while the list can be very exhaustive this is just tip of the iceberg, and actual implementation is only limited to one’s technical abilities and imagination.

Thus, stating budget constraints for not implementing defense in depth is merely an excuse or a sign of lack of knowledge.

Here is link to my patent that elaborates on this concept: https://patents.justia.com/patent/10044755

BCP and Security Parameters for CMDB

While most of the organizaitons have asset inventory in some shape form but they are seldom built keeping security goals in mind. Hence they largely lack BCP and Security related parameters. Which is why they often are found useless incase of real security incidents.

Hence I have highlighted a sample set of fields that an organization can use as guidence to capture BCP and IT Security realted parameters, and should be captured as part of their CMDB build process. This is just a guidence and by no means is complete, but certainly it provides organizations a good starting point to start working on.

<Circuit Name> Circuit Information Circuit id   Location – Point A   Location – Point B   Provider   Circuit Type Internet/ MPLS/ Point-to-Point Install Date   Renewal Date   Limitations Bandwidth: Traffic Cap: Circuit Features With protection/ with redundancy etc. Cable provider/ Route Used   Physical Media   Provider Point of Contact (POC)   Provider Escalation POC   Provider POC contact hours   Provider Escalation POC contact hours   Provider SLA   Provider Capabilities <VAS that provider can provide currently but is not subscribed for> BCP/DR Information Is backup available Yes/No Backup Type Active/Active or Active/Standby Primary of   Backup of   Point A L1 Termination   Point B L1 Termination   Point A L2/3 Termination and Type – Primary Terminating Asset id:   Asset Type: Firewall/Router/Switch Point B L2/3 Termination and Type- Primary Terminating Asset id:   Asset Type: Firewall/Router/Switch Point A L2/3 Termination and Type – Backup Terminating Asset id:   Asset Type: Firewall/Router/Switch Point B L2/3 Termination and Type- Backup Terminating Asset id:   Asset Type: Firewall/Router/Switch RTO   RPO   Security Information Encryption Level   Security Zone   Usage information Expected Data % Expected Data <absolute> Expected Voice % Expected Voice <absolute> Expected Mission critical traffic % Expected Mission critical traffic <absolute> QOS Implemented Yes/No QOS Details    Network Diagram/Other important information

<Site to Site VPN/GRE Tunnel Name> Connection Information Local GW IP/Host Name Primary: Backup: Remote GW IP/Host Name Primary: Backup: Local Protected subnets   Remote Protected Subnets   Is traffic filtered Yes/No Filtering ACL Name/Number   This is depending on   Services that depends on this   Type GRE/IPSec Backup Remote GW Info   IPSec VPN Negotiation Information IKE Version ½ Phase 1 encryption   Phase 1 authentication   Phase 1 hashing algorithm   Phase 1 DH group   PF secrecy   Phase 1 Lifetime   Phase 2 encryption   Phase 2 hashing algorithm   Phase 2 lifetime   Phase 2 group