By Max Pritchard, pre-sales consultant, activereach
INTRODUCTION
Welcome to the activereach 2016/2017 guide to DDoS, DDoS mitigation, and DDoS mitigation testing. This guide is aimed at technically aware business people who do not necessarily have a background in data networking or security.
The guide is split into the following sections:
Section 1 – An introduction to Distributed Denial of Service attacks and mitigating them
Section 2 – Assessing the business risk posed by Distributed Denial of Service attacks
Section 3 – Testing Distributed Denial of Service mitigation
ASPECTS OF DDOS TESTING
This is the third part of the activereach 2016/2017 guide to DDoS, DDoS mitigation and DDoS mitigation testing. In the first two papers, I discussed the DDoS threat landscape, DDoS mitigation techniques and conducting risk assessments specifically for the threat of DDoS attacks against business. In this article, I will discuss various aspects of DDoS testing – starting at the decision whether to test your company’s ability to withstand DDoS attacks, the business case for testing, how to scale a test, what a DDoS should include and more.
DDoS testing is relatively unknown compared to more ubiquitous testing services, such as penetration testing and server vulnerability assessments, and this guide tries to collate information specific to DDoS testing to inform businesses of all sizes about this kind of security testing and how it can help protect your business from attackers making use of DDoS attack tools.
WHY TEST YOUR DDOS MITIGATION?
Testing your security makes sense when we think about our homes. Some of the time it seems automatic, almost second nature; many of us test our house door handle after we have just locked the door, for example.
However, a lot of the time, the process of testing the security of IT systems that support a business is not second nature. Regardless of the possible severity of the consequences, testing systems are nowhere near ubiquitous – there always seems to be something higher on the IT agenda and in greater need of spend from the limited IT budget. In the spectrum of threats to simulate – DDoS has traditionally been lower on the agenda than vulnerability assessments or penetration tests.
DDoS creates a risk for businesses that conduct any transactions using public Internet services. The severity of the risk will, of course, depend on how much that business relies on its online systems for revenue, a matter discussed previously in the earlier risk assessment white paper. If the risk is sufficiently large, then the budget is usually set aside for mitigation. But until recently – many companies see DDoS as a nuisance, and not a threat to data.
However, things are changing. DDoS attacks are no longer simply a risk to the availability of an IT system or service. DDoS attacks are being used in concert with attempts to penetrate networks and/or steal data, and this is changing the way that businesses have to calculate the risk of loss on DDoS attacks – as well as the way that counter-measures need to be deployed.
As examples – in May 2011, Sony sent a letter to the US Congress, explaining that they did not immediately detect the theft of up to 101 million customer records because it was distracted by DDoS attacks. More recently in October 2015, UK Telecoms company TalkTalk suffered an attack that simultaneously degraded the performance of their services (DDoS), as well as involving the theft of account information for hundreds of thousands of customers. TalkTalk’s share price dropped from 289.4 (October 20th, 2015) to 225.3 (October 26th, 2015) in the aftermath of the attack.
In both cases, the companies involved had invested time, money and effort in IT security, but when it came to the actual attack, that security failed, the investment was wasted, and they suffered financial and reputational losses anyway.
Routine testing of company security systems might have highlighted vulnerabilities and weaknesses in systems and processes. It could also help them familiarise staff, tune detection, and improve response times and efficiency. Testing may have mitigated some of the damage these companies suffered as a result of a successful attack on their infrastructure.
THE BUSINESS CASE FOR SECURITY TESTING
Minimising the risk to the business of security threats of all types is one of the responsibilities of the company’s board. For business, which is increasingly underpinned by IT systems and processes, IT security is employed to reduce the risk, and thus the cost of a security incident of some nature.
Deciding on the appropriate investment in security is a calculation of the expected loss (likelihood of damaging event multiplied by the impact of damaging event) and then deciding what proportion of that expected loss to invest in systems and processes to eliminate, or at least reduce, the likelihood of a damaging event. The ideal situation is that any spend on security should reduce the likelihood and/or impact of a security incident such that the following is true:
Where Expected loss (£) = Chance of loss (%) * Impact of loss (£)
Spend on Security + Expected Loss from security incident with security in place
<
Expected Loss from security incident with no security in place
Testing IT security is based on the premise that security systems, processes and people have a non-zero risk of not being effective when they come under attack (i.e., They are fallible). The likelihood of security system failure tends to increase over time as things change inside and outside the business environment. The scale of the loss is not only that of the breach itself, but also the investment in the security system – which is wasted money unless the protection is effective.
Spend on IT Security testing =
f (Likelihood of security system failure * (Impact of loss + cost of security system))
So – the business case for IT security testing is the same as the business case for IT security more generally IF you consider security as a process, as opposed to a static system. All spend on IT security is based on the premise that there is a risk of financial and reputational loss and that a proportion of the expected loss can be spent reducing the likelihood of loss – and that this is more efficient than doing nothing and accepting the loss when it happens.
SECURITY AS A PROCESS
Security is not a static product or service one can buy. All successful businesses change over time, and their IT changes with it. Simultaneously the tools and techniques attackers and criminals use to try and exploit businesses change as well. If a company’s attack surface and the criminal’s methods of attack are in constant motion – a company’s security posture and the systems and processes it employs to enforce that posture have to be in constant motion as well.
Security is a process – a practice. This simple message is visualised in a security wheel – popularised by Cisco.
Security testing generates important data that can be used as feedback to improve security systems and processes. DDoS testing is crucial to the efficacy of DDoS mitigation systems employed in defence of a company’s data assets.
A lot of companies engage penetration testers to look for holes in servers and network systems. Sometimes this is a matter of compliance with regulations, sometimes this is a response to feeling the pain of a breach, and sometimes simply following the good business practice.
Although the business case for DDoS testing is similar to that of penetration testing, the test mechanism itself is completely different to penetration testing or vulnerability assessment requires different tools and capabilities and is often overlooked. With the emergence of attacks which combine DDoS and penetration/data theft, it can no longer be considered a separate business decision.
There is plenty of literature to support understanding of how to implement security as a process into a business, but that is beyond the scope of this document. Suffice to say that testing security systems is a critical part of being secure and being seen to be secure.
IS DDOS TESTING IMPORTANT?
Some types of counter-measures benefit more than others from routine testing and DDoS mitigation systems are a case in point. Some DDoS mitigation techniques rely on deviation of traffic from normal levels and characteristics and so need good baseline information to be effective. Some DDoS attacks mimic typical user behaviour to a point, to try to evade detection and slip past defences – testing helps to tune mitigation detection, minimising false positives and optimising response times to attack.
Staff also need to be familiar with detection and response, and testing can help streamline response plans, reducing the distraction effect of DDoS attacks and keeping resources available to prevent data theft.
activereach has encountered several businesses who are under such regular DDoS attack that they feel they can suspend their DDoS testing. But for most companies, the frequency of DDoS attacks is low enough that confidence in staff and system preparedness will be commensurately low.
There are some features of DDoS attacks and DDoS mitigation systems that make testing particularly important.
#1 DDoS mitigation systems are expensive
Building a cloud service that is proof against the largest possible attacks is an expensive business that requires investment in many data centres, massive peering capacity and hundreds of scrubbing systems. In the flood prevention market – the solution price often reflects the investment made in the mitigation capability. When it comes to defeating 100Gbps+ attacks, size is important.
Providing this kind of flood defence for a single data centre might cost a company more than £100,000 a year. For many mid-market companies, this represents a significant investment in security to mitigate an unknown or poorly quantified risk.
A DDoS test costs a fraction of the annual cost of mitigation. A test can demonstrate to the board what impact a DDoS attack may have on the business and thus quantify the need for mitigation. A DDoS test might be able to quantify the capabilities of existing mitigation and help inform future investment in additional mitigation. A DDoS test might reveal that existing mitigation is not performing as expected, allowing the company to go back to mitigation vendor, so they meet contractual obligations.
#2 DDoS mitigation systems vary widely in performance and capability
DDoS mitigation covers a broad range of techniques and technologies. Even the lowliest router claims some level of DDoS protection as a feature. Businesses need to be certain what scale of protection existing devices and services provide as opposed to what they promise.
#3 DDoS mitigation systems “leak” to avoid false positives
With a lot of DDoS attack traffic masking itself as user traffic, the task of mitigation is not always to block, like traditional defences, but to improve the ratio of good traffic to bad traffic sufficiently for the system under attack to cope with it – and continue to deliver normal service to the legitimate user.
#4 DDoS mitigation vendors cannot/do not reveal performance parameters
Many mitigation companies, in our experience, don’t like their infrastructure being tested. This is understandable – it is a cost to them and they would be most happy to accept payment for a service that is then never employed in anger. However, a customer has every right to ensure that contractual obligations can be met – in terms of detection, response, and mitigation capability. Moreover, if the mitigation company truly wants their solution to be operating at peak efficiency (system and people/process), then they should not only accept but actively encourage regular test programmes alongside the deployment of their mitigation solution.
#5 DDoS mitigation requires processes to be followed by staff
DDoS mitigation involves people communicating – either electronically or by phone. This is especially true of some ‘on demand’ mitigation solutions which sometimes require human intervention, and changes to traffic routing to ‘swing’ mitigation capabilities into place. Until it is employed, a company may not be aware that the process of mitigation is broken. Staff may not be aware of who to call, or even what an attack looks like. A company experiencing a system with degraded performance may expect IT failure or service provider issues as opposed to an attack and may not follow appropriate response protocol. With DDoS being used to blind companies to other attack methods, staff needs to be aware that a DDoS attack may be an indication of a concurrent penetration or data theft.
#6 DDoS detection requires monitoring systems to be tuned
Not all DDoS attacks are easy to spot. The public perception of DDoS attacks is the high profile ‘flood’ attacks, which are easy to detect. However, a significant proportion of DDoS attack methods involve techniques which do not necessarily involve large amounts of data. These ‘low and slow’ attacks can slip past simple flood defences because they are designed, to a degree, to mimic normal user or application behaviour. Some powerful DDoS mitigation techniques rely on detecting deviation from normal traffic patterns. This means the system needs tuning – and a DDoS test can help immeasurably with this establishment of a baseline and subsequent tuning process to detect anomalies.
#7 Modern networks and dependencies on public cloud are increasingly complex
With the rise in server virtualisation, virtual machines running on non-server devices (like routers), and virtual network technologies like VLANs and Q-in-Q – alongside rapid adoption of SaaS and hybrid cloud architectures, a company’s logical network architecture and data landscape is complicated like never before. It is not always clear what business applications rely on which network devices or circuits. We have experienced customers who have learnt a great deal about network dependencies during a DDoS test – outages in systems that were considered previously isolated and invulnerable to attack.
#8 DDoS attacks are increasing in frequency, impact and sophistication
Previously DDoS might threaten an outage but were considered more of a nuisance rather than a bonafide threat to business data. However, modern cyber criminals have found the benefit of blending DDoS with penetration and data theft in a multi-vector assault. DDoS attacks have also become more sophisticated in and of themselves and untested mitigation systems may no longer offer the protection they once did.
#9 ISPs, SaaS companies, and hosting providers do not always test their
DDOS MITIGATION CAPABILITIES
Many customers make assumptions about their service provider’s attitude to DDoS and their capability to assist when a customer is under attack. The economics of the situation often present the service provider with the choice between upsetting one customer by turning them off or upsetting all of their other customers who are suffering from collateral damage. Any DDoS mitigation capabilities the ISP does have is often of limited scale and capability compared to a dedicated DDoS mitigation company. The lack of specialisation may mean the ISP or hosting company cannot provide the level of protection required. A test would confirm this.
#10 DDoS attacks are infrequent
Although this does not hold true for some customers in modern times, some of whom experience daily DDoS attacks, a large proportion of businesses have very little experience of DDoS attacks. Testing in this business environment will have a proportionately higher impact than for those companies who are very familiar with DDoS attacks.
DDOS TESTING, LEGALITY AND ETHICS
To properly represent the nature of any future DDoS event, a DDoS test needs to be an actual DDoS attack in all possible technical regards. So when conducting a DDoS test, one needs to bear in mind the legal status of DDoS attacks under UK law.
The Computer Misuse Act (CMA) 1990 was amended by the Police and Justice Act in 2006. The CMA specifically outlaws DDoS attacks under section 3 “Unauthorised acts with intent to impair”. This makes the matter of authorisation for any DDoS test paramount since the intent is, indeed, to impair the target even if it is for good reasons.
The person contracting for the DDoS attack service needs to have authority from the company. A purchase order, having multiple customer stakeholders on a conference call during the attack and having a finite (and short) window for the attack goes a long way to minimise the risk of a disgruntled employee using the DDoS test as a means to strike out at the company or owner of the target.
The company needs to have authority over the target of the attack. In these days of shared physical infrastructure (VPNs, virtual servers, VLANs and the like) this might be difficult to determine with total confidence. This raises the problem of a DDoS test impairing service for others using infrastructure common to the target server or network – collateral damage.
Errors and misconfigurations during the attack might lead to a DDoS attack hitting a target other than that which was intended. Again, stakeholders monitoring the elements of the actual target infrastructure would quickly note attack traffic was not seen when expected and the test can quickly be stopped and any errors corrected.
Jurisdiction requires there to be at least one significant link with the UK. This would mean that the target of the DDoS was physically located in the UK, the command and control operator was based in the UK or some other similar connection.
With respect to ethics; unlike penetration testing, there is no chance of an engineer conducting a DDoS test coming into contact with confidential data. This limits the ethical dimensions of conducting the test somewhat. However, the approach to obtaining and ensuring proper authorisation, checking the target, and minimising the risk of collateral damage are all ethical concerns.
In any case, almost all testing of any security systems should be protected under NDA to help manage any negative output from the test itself – particularly vulnerability to certain types of attack, or general intelligence about the nature and configuration of customer security systems.
TESTING DDOS MITIGATION SYSTEMS
According to the Worldwide Infrastructure Security Report (vol. X), only 34% of companies that managed data centres and Internet backbones test their anti- DDoS systems. Perhaps we should not be surprised. DDoS medicine can be worse than the cure and can impact a lot of customers and the implication of testing a DDoS mitigation system is that you are launching a DDoS attack against your infrastructure to see what happens. The proportion of UK businesses that are testing their DDoS defences is undoubtedly lower than 34%.
With so many companies relying on devices that were not designed to defeat DDoS attacks (routers, firewalls and IDS/IPS) and the broad spectrum of DDoS mitigation techniques employed by devices and marketed as “DDoS protection”, the only way to know how a system will behave under attack is to try it.
DDOS ATTACK TESTING IS NOT THE SAME AS A LOAD TEST
It is relatively easy to find traffic generator software and send lots of traffic from one source to a target server or device. It is also easy to overwhelm most connections with traffic. Many servers in the UK are connected with 100Mbps or 1Gbps Ethernet bearers, the average DDoS attack in 2014 was 7-10Gbps and modern load generators can create traffic significantly larger than most company’s primary connectivity capacity.
So what can you learn from a simple overwhelming load test against a target server?
The only legitimate use for a test of that type and scale is to see if you are obtaining the degree of cloud-based mitigation that you have contracted for and what proportion of attack traffic ‘leaks’ through. Care needs to be taken that the target does not suffer from unexpected ‘overage’ charges from the cloud-based mitigator for test traffic.
Otherwise, the only lesson learned is that you need cloud-based mitigation to defeat volumetric attacks – and that we already know.
The associated risk is that by creating large flows of traffic and aiming it at a target, you run the risk of, not only saturating your connection but also causing collateral damage upstream of your server, impacting your immediate service provider and other connected customers.
So simple large-scale load tests reveal little and can have serious negative consequences. So DDoS testing is ideally about something other than that.
HOW BIG SHOULD THE TEST BE?
Most network systems have a saturation point at around 85% of load, above which the system becomes unstable and prone to shockwaves which lead to sudden exponential increase in latency (lag spikes).
activereach normally recommends that most typical corporate customers test their services to, but not past, 70% of the contracted capacity delivered to the service. Anything above 70% and the test results can be obscured by saturation effects – lag spikes caused by simple overloading, rather than the nature of the DDoS attack itself. It is also activereach’s traditional approach to increasing attack intensity in stages, to see which devices in the chain of communication fail first under certain attack conditions.
Keeping the attack below the contractual bandwidth level means that collateral damage to other customers using shared network elements upstream will be minimised.
Even so, activereach has a rigorous policy of notification of upstream ISPs and Internet exchanges for DDoS attack tests above a certain size. It is best practice to notify the ISP of any network testing of this type in any event.
It is up to the customer whether to inform any DDoS mitigation provider. Customers are well-advised to check whether additional charges may be incurred from the mitigator for tests. There may be a conflict of interest if the Internet service provider/hosting provider is also the company providing DDoS mitigation. activereach is very comfortable in these situations meeting the requirements of the customer and fulfilling the objectives of the test while observing good business etiquette and good ‘netizenship’.
OTHER CONSIDERATIONS PRIOR TO LAUNCHING A DDOS ATTACK TEST
Like any security testing, there are a lot of things to think about above and beyond the target of the attack and how big you want the test to be. Here are some of the other issues that might be worth considering.
Who’s behind the attack? Business would be well-advised to choose their DDoS attack test partner carefully and make sure they are using appropriate tools and business processes.
Where is the attack being launched from and what jurisdiction applies? Launching a DDoS attack is illegal in many parts of the world (including the UK). In others the legal status is less clear. DDoS testing is less regulated than Penetration Testing, and an effective DDoS attack must come from many geographical areas otherwise it won’t be appropriately representative of an actual attack. Attacks from some parts of the world are more expensive to launch because of the cost of connectivity and bandwidth in those locations (e.g., Africa and South America).
DDoS Testing Platform in Operation.
Regardless, any DDoS testing organisation must take care about the contractual authority to test, the ownership and responsibility for the target of the test and the limits of the testing. Verification of order documentation and ownership of the assets being tested are also required as is indemnity for impacts on customers – if live/production servers and systems are being tested. Confirmation of target IP addresses is crucial to avoid errors and inadvertent attacks on the wrong target. Constant communication during the attack is advised as is the ability to stop the attack on demand at any time during the test.
Collateral damage may involve not only direct disruption of the targeted services, but also consumption of resources on networks upstream of the target, or using shared physical network elements. There is also the risk of indirect damage caused by attempts to mitigate or solve the issues caused by the attack by someone who has not been informed that the attack is taking place.
While the potential damage caused by a short fixed duration DDoS attack at 70% of contracted bandwidth timed to coincide with low-traffic window is unlikely to be high, the nature of an effective DDoS test is to find the limits of the systems, people and processes in place to improve overall defence posture against future unscheduled and unlimited attacks.
The selected servers and systems, ideally, should not have live transactions at the time of the test, but should be as similar to the live system being tested as possible with common network devices and configurations in place. activereach’s testing protocols can provide a ‘sacrificial lamb’ of a target virtual server that can be installed behind the mitigation and act as a target for the DDoS test if required.
The scope of the test should include the frequency, duration and, critically, timing of the test patterns. This has to sit alongside the list of people to be notified before the test, and those involved in the test directly with responsibility for the systems or devices being tested. Notifications to upstream network providers are standard best practice, and the testing provider should have a policy of notifying upstream ISPs, mitigation providers and peering points for DDoS attacks above a certain size.
AN EXAMPLE TEST PROCESS
The following is an example test process that might be employed. In any engagement, activereach will discuss test attack patterns with the customer and can advise on variations to the kind of test process described below. This might mean mixing attacks up, for example, or launching different attacks at different intensities at the same time.
DURATION
The overall duration of a typical DDoS test is 90 minutes. This window of testing is suitable for many businesses. It is long enough to conduct meaningful tests, yet short enough to fit into a normal business routine (e.g., maintenance windows), and to maintain high levels of participant concentration throughout.
FORMAT
All stakeholders identified during the pre-test consultation are invited onto a conference call. Simultaneously those stakeholders with administration responsibilities for equipment that is either in-line for the attack, or form part of the customer’s monitoring capabilities log into those devices, or enable monitors. The testing engineer also makes available a web portal that shows the attack monitored from the testing company’s systems.
A 90-minute test is divided into three test patterns; each pattern comprises of a five-minute test at each of three intensities – low, moderate and high. Intensity might be measured in packet rate (packets per second or pps) or traffic volume (bits per second or bps) or simply the number of agents being employed to conduct the test (sessions). Some customers may find five minutes insufficient for their monitoring systems to detect and respond. Longer attack durations might mean breaking the test into multiple events, or reducing the number of types of attacks being conducted.
Low-intensity attacks are useful in identifying whether monitoring systems can identify abnormal traffic patterns. Attackers use low-intensity attacks to gather intelligence on target detection and mitigation capabilities, often weeks in advance of an extortion demand or an actual attack. They can use the results to determine the most likely form of DDoS attack to cause the most damage to the target.
Medium intensity attacks are useful in demonstrating how system resources are consumed as attack intensity increases. Tuning of defences and monitoring systems is easier as the medium intensity attack is easier to spot compared to low intensity, but less likely to disable intervening systems that high-intensity attacks. Customer technical teams often find it interesting how a DDoS attack manifests itself to their users, which can aid in swifter diagnostics in future.
High-intensity attacks are useful in identifying vulnerable devices or connections in customer systems and enumerating the size of attack (and thus the attacker resources) required to bring the target system down. It can help demonstrate the experience of legitimate users during a DDoS attack and thus help inform customer communications and risk assessments. High-intensity attacks can also reveal previous unknown dependencies in networks where shared physical network resources are not obvious.
ATTACK GEOGRAPHY
The DDoS test platform is comprised of any number of agents in multiple data centres across the globe running traffic generation scripts coordinated by a central command and control system. The data centres are located in North America, EMEA and Asia Pacific region to mimic the broad geographical spread of many botnets.
There are some DDoS attacks, such as the so-called ‘Great Cannon of China’, which are unusual in the specific geographical nature of the bots used in the attack. In that attack, a percentage of browsers that received Chinese language adverts served from servers behind the Great Firewall of China received malware-laced content instead. This converted their browsers into an ad-hoc botnet of great size. A few customers may wish to simulate an attack by changing the ratio of agents from each region – but in general, an even spread of agents geographically is preferred.
DDoS tests can also co-opt agents in Africa and South America, but bandwidth charges in those regions can be high and the chance of collateral damage is increased as backbone and peering connections in certain regions can be significantly smaller.
TYPE OF ATTACK
The nature of attack is determined by the programme being followed by the agents. At its simplest, the script can simply generate traffic load, but there are any number of low-cost online tools that can be used to do that. Although such traffic could be used as a DDoS attack in sufficient volume, it is easily detected and defeated, even by traditional security and network devices. The power of the DDoS test platform is not only in the elastic network of agents, but the sophistication of the scripts available to the testing company.
DDoS testing companies maintain a library of DDoS attacks that can be drawn on to recreate DDoS attacks seen in the wild and identified as being potential weaknesses in the technical systems deployed at customer sites. Custom scripts can also be developed to mimic user behaviour on custom applications (not just web servers – perhaps game or gambling servers, trading systems or online banking).
Test attack types can vary from the kind of traffic seen during a reflected attacks (DrDoS), which use intermediary servers to amplify attack traffic volume – recently domain name services, network time services and service discovery protocols have been used in this way. This is a classic volumetric attack. There is seldom need to recreate the actual scale of these attacks because they can easily exceed 100Gbps and the risk of collateral damage is too high. Also, it would require the use of third party reflection servers. Instead, it is usual practice to simply directly simulate the attack traffic seen during a DrDoS – replaying what is seen during an attack, rather than using the exact mechanism for generating a DrDoS. Testing at lower levels of intensity can ensure the attack can be detected quickly, and the customer is aware of how much traffic can be mitigated by their current defences.
Testing Services.
Application attacks can also be recreated. These mimic user behaviour and often take advantage of web-based encryption (i.e., SSL), which can hide the attack from mitigation systems and services. The difficulty here is ensuring that mitigation can detect illegitimate traffic from legitimate traffic and minimise or eliminate false-positives. Aggressive mitigation can impact legitimate users and a test can help enumerate the risks or poor customer experience.
It is usual to select at least one volumetric and one application attack – and one other, with the type determined in consultation with the client. The more the testing company knows about the mitigation systems in place, the better the choice of attack might be to demonstrate something interesting, or previously unknown about the customer’s security posture.
EMERGENCY STOP
DDoS, unlike some other rarer forms of DoS, does not tend to cause permanent damage to systems. DDoS relies on constant traffic flow to deny the service to legitimate users. If the flow of traffic is cut off, any system that was under attack should return to normal operation within seconds.
Sometimes certain devices may need to be rebooted to restore service.
The test platform command and control system has an emergency stop that instructs all co-opted agents to cease sending attack traffic. This command takes about ten seconds to execute and for the agents to cease. Although not used that often, customers like the comfort of knowing that the attack traffic can be stopped at any time during the test.
MID-ATTACK ANALYSIS
After each five-minute attack instance, the testing engineer will halt the attack traffic and there will be an opportunity for the stakeholders to reveal what they observed, and discuss the test – perhaps ask questions to clarify understanding or check what the next step of the test will be. This can change the nature or intensity of future tests within certain bounds (an increase of intensity may not be possible without going back to planning phase to ensure that collateral damage is minimised).
POST-ATTACK ANALYSIS
Feedback on the entire test process is captured prior, during, and after the test itself. All stakeholders contribute their findings. The test engineer collates the findings and also provides expert insight and analysis of the results to meet the test’s overall objectives.
USING DDoS TESTS AS PART OF A SECURITY PROCESS
Although DDoS tests could be one-off events and can still be helpful in shaping a customer’s approach to DDoS mitigation, it is most powerful when incorporated as a regular event in a company’s security diary.
DDoS attack techniques are changing rapidly, and the customer’s increasing dependency on public cloud or 3rd party networks outside the corporate perimeter may be increasing the overall risks associated with DDoS attacks. Regular DDoS tests can also allow a company to identify where detection and mitigation systems need tuning to protect legitimate traffic, or need reinforcement or increased capacity to deal with current threat levels.
Even if compliance does not dictate regular DDoS testing, it can be a strong indicator to auditors, investors and customers that a company takes its responsibility to service availability very seriously.
DDoS TEST PRICING
The price of a DDoS test depends on several factors that are discussed with clients during a consultation process. This includes, but is not limited to; time of day the attack is conducted, number of agents co-opted into the test, maximum intensity of the required attack.
However, a test is a small fraction of the annual cost of effective mitigation systems and can be a useful tool to ensure that value for money is being obtained from the mitigation company.
OVERAGE
Mitigation companies often ensure they more than cover their costs by charging a customer for the size of attack they are mitigating. This is called an overage charge. It makes sense from the supplier’s point of view because the cost of the infrastructure to defeat flood attacks is proportional to its absolute mitigation capacity. However, for a customer, it is unsatisfying that an attacker can determine the scale of charges the customer incurs. Attackers may select simple volumetric attacks simply to cause the customer grief, rather than a more subtle low and slow attack. It almost doesn’t matter whether the mitigation works or not.
Overage is also a problem for DDoS testing companies because of the chance that a test may incur overage charges from the mitigator. Customers are well-advised to check their contract with the mitigation company, or have a conversation with them about appropriate levels of testing – and ensure that any new contract with the mitigator includes clauses to allow the customer to conduct reasonable tests without incurring additional charges.
CONCLUSIONS
DDoS tools now regularly being used by cyber criminals to distract companies from data theft or other security attacks. DDoS testing should be used by businesses alongside penetration tests, vulnerability assessments and phishing simulations. This will reduce the expected loss from security systems and processes that fail to cover all forms of modern threats, which are increasingly being blended together.
DDoS testing requires a new set of tools, processes and understanding to implement properly. Companies that are contracted to provide penetration tests and/ or vulnerability assessments are not necessarily focused enough to provide a simulation that stretches mitigation enough. Legal and technical pitfalls exist that make it important to engage with a professional organisation that is familiar with the necessary scoping and ethical concerns of launching volumetric attacks of this nature. ■
ABOUT ACTIVEREACH
activereach is a leading provider of Internet, networking, voice and security solutions delivered through the cloud, managed services, software and appliances. For organisations faced with today’s complex IT challenges, activereach provides a unique consultative approach with solutions based on best of breed products and services.
activereach has helped hundreds of businesses across the UK, Europe & Middle East – ranging from FTSE 500 enterprises and financial institutions to retailers and SMEs – manage and secure their network infrastructures, voice & data communications and critical information assets. Operating across activeNETWORKS and activeDEFENCE technology divisions, activereach is headquartered near London, UK.
activereach is the UK’s leading company in DDoS testing and provides a wide range of security solutions, including DDoS mitigation services for customers in the private and public sector.
For more information, please visit www.activereach.net
ABOUT THE AUTHOR
Max Pritchard is a network pre-sales consultant who has been designing secure business networks for 20 years with network integrators, ISPs and Telcos. He now works as a pre-sales consultant for activereach – helping UK businesses make sense of DDoS threats, designing, implementing and testing DDoS mitigation solutions.
Publication date: March 2017