Automating processes for handling and remediating AWS Abuse alerts

Introduction

AWS Abuse addresses many different types of potentially abusive activity such as phishing, malware, spam, and denial of service (DoS)/ distributed denial of service (DDoS) incidents. When abuse is reported, we alert customers so they can take the remediation action that is necessary. Customers want to build automation for handling abuse events and the actions to remediate them.

Recent AWS Health updates

Two recent AWS Health service updates make it easier for customers to automate processes for handling abuse alerts, set up remediation steps, and control access to more sensitive abuse cases. The first update makes the transition from exclusively email-based abuse event notifications to making the alerts available in a number of different ways, including the AWS Personal Health Dashboard (PHD), Health APIs, and the AWS Health Amazon CloudWatch Events channel. The second update is the support for fine-grained access control within AWS Health via IAM Policy Conditions.

When customers received abuse notifications via email only, it was challenging to manage the alerts because emails could be lost due to email filters, or they could be sent to incorrect contacts on the account, or they might not be reviewed in a timely manner. AWS addressed those challenges by surfacing abuse alerts in the AWS Personal Health Dashboard (PHD) where customers are already monitoring the health of their environments. The following screenshot shows an abuse alert in a PHD:

The following abuse types are handled in AWS Health today:

• Sending email spam
• Spamming online forums or other websites
• Hosting a site advertised in spam
• Excessive web crawling
• Intrusion attempts (e.g., SSH or FTP)
• Exploit attacks (e.g., SQL injections)
• Hosting unlicensed copyright-protected material
• Phishing website
• Website hosting viruses/malware
• Credit card fraud
• Open proxy
• Port scanning
• IRC botnet activity

Customers can now programmatically create custom automation based on abuse events. For example, when DoS reports are published, customers can route these events to the correct team, person, or system. This improves time to resolution and helps customers gain efficiencies. A sample AWS CloudFormation template that can be launched with a single click to set up an Amazon Simple Notification Service (Amazon SNS) notifier for DoS events in AWS Health is available on GitHub.

One customer reported employing 20 people to process and respond to abuse reports from AWS. Using the abuse reports now available in the PHD, this customer could automate the intake of abuse cases, which reduced their response times dramatically. For some abuse types, they completely automated the vetting and response to the event. Ultimately, this customer reduced the number of employees working on abuse by 80 percent.

In addition to building automation, customers often need to manage access to more sensitive abuse alerts, such as those related to security. Previously, access to alerts in PHD was all or nothing. Now, with fine-grained access control, customers can limit access to sensitive alerts to only those users who need to see them.

Conclusion

With these updates to the AWS Personal Health Dashboard, customers can build automation that saves time and improves productivity while also reducing risk by limiting access to sensitive abuse events.

About the Author

Barry Murphy is a Senior Product Marketing Manager for AWS Support. He likes working with customers to understand the outcomes they are hoping to achieve with AWS. He also likes walking his dog, playing golf, and playing hockey, but not all at the same time.