6 years ago
Multiple Mitigations Per Threshold
Those readers who’ve used our alerting system know that it’s based on alert policies that are each made up of one or more thresholds that enter alarm state when triggered by user-defined conditions. Alarms generate notifications (email, Slack, PagerDuty, etc.) but they can also automatically initiate mitigation. With our latest iteration, you can now assign more than one mitigation per threshold.
What’s the advantage of multiple mitigations per threshold? Below are a few simple examples of why this feature is so useful:
- You can now use a single policy to configure all of the desired mitigation methods/platforms with which you’d like to respond to a given set of conditions, which is much more scalable than cloning a given policy for each of your appliances so that they can all trigger at the same time for a given condition.
- Users with mitigation appliances at multiple sites now have the ability to trigger them all at the same time.
- The response for a given alarm can now include a mix of mitigation types, e.g. RTBH, A10, and Radware. A multi-location DDoS response involving multiple mitigations types is outlined in the following example:
1. De-preference or stop announcing a BGP route on Location #1 by injecting a route whose community has been predefined as a flag for these actions.
2. Announce a broader routing table entry, less-specific than /24 (thus forcing acceptance by Internet peers), for Location #2.
3. Trigger a 3rd-party mitigation method — e.g. A10 or Radware — on Location #2 to announce more specific prefixes for internal re-direction to a scrubbing center.
For more information about using mitigation, check out our KB article on Alert Mitigation.