What you can’t see cannot be protected
There was a recent news that Australian banks are being targeted by DDoS extortionists. That hackers are sending emails to banks asking for large payments in Monero, and threatening DDoS attacks if their demands aren't met. In spite of technology innovation, financial institutions, especially banks, are unable to prevent DDoS attacks.
Therefore, unless security teams are aware that DDoS vulnerabilities exist and where they are located, they can’t take corrective measures to eliminate them. The primary issues security teams face today, in managing DDoS threats, is the lack of visibility on just how secure their DDoS defenses are.
DDoS Mitigation technologies don’t know how to auto tune
Today’s DDoS Mitigation works in the following way:
- First, DDoS mitigation policies are configured (in the 'Attack identification module') and deployed in accordance with how the mitigation vendor understands your network layout.
- If under attack, the 'Attack identification module' analyses incoming traffic according to its policy configuration. It then filters out attack traffic, which is blocked by the 'attack blocking module'. The remaining legitimate traffic is then passed onto the requested service e.g. MAIL, WEB.
- Traffic is only filtered out and blocked assuming that the underlying network layout has not changed since the initial deployment and mitigation policy setup, as shown in figure below:
Initial DDoS Mitigation configurations with underlying network
In reality, however, the underlying network changes continuously.
In some cases, new mail servers are added to the network. Third-party vendors may have been given access to other servers. Regardless of the change, networks and their services change constantly.
With each network or service change it is necessary that the DDoS mitigation policy is fine-tuned, or else DDoS vulnerabilities are left wide open.
As a matter of fact, this level of diligence, of making a change to the DDoS mitigation policy each time a network or service change happens, is not viable, nor is it a part of any enterprises’ change request process. Furthermore, there is no feedback loop or two-way communication that is sent to the DDoS Mitigation's 'Attack identification module' to update that any changes have taken place in the underlying network.
Can’t Fix what you can’t see or are not aware of
No feedback given to DDoS Mitigation when network is changed
As the network changes, it is important that 'Attack identification module' policy configurations are reviewed to ensure that the policies defined are in line with what needs protecting.
When the 'network' or 'service' changes, CURRENTLY' Attack identification module' policy updates are NOT automated. DDoS Vulnerabilities are opened up, and if the security teams are not able to see where the vulnerabilities lie, they can’t eliminate them. Proactive feedback is an essential requirement to close DDoS Vulnerability Gaps. Existing DDoS Vulnerabilities become the target of hackers and are exploited fast. This causes downtime.
As per The State of DDoS Protection, even with current best in class DDoS Mitigation in place, most enterprises, are at 48% risk of downtime if attacked.
See where the vulnerabilities lie and defend them before getting exploited
24/7 ongoing visibility into changing production and services network
The Proactive Feedback Module technology enables automatic and ongoing feedback of the underlying production network changes, also how those changes affect your current 'Attack identification module' policy. It allows you to keep the 'Attack identification module' policy fine-tuned and up to date.
This feedback, is the threat Intelligence required to configure a DDoS Mitigation 'Attack identification module' policy to close the exposed weaknesses of DDoS Vulnerabilities.
With the help of the Proactive Feedback Module, DDoS Mitigation identifies all DDoS vulnerabilities and allows you to fix them before being exploited.
Security teams can now proactively close DDoS vulnerabilities before they are exploited to cause downtime.
Read more about Proactive Feedback Module in this Solution Brief