To keep your applications safe, it’s critical to detect and block attacks on your APIs as quickly as possible. In the past few months, we’ve made some changes to Advanced API Security’s Abuse Detection feature to make it easier and faster to identify legitimate attacks and take action. Read on for more details.
1. Abuse detection ML model improvements
To detect potential attacks, Advanced API Security uses a combination of heuristics-based rules and Google-engineered machine learning models. We recently released a new version of the Advanced Anomaly Detection ML model that works by taking into account all of your historical API traffic data at the environment level, creating a blueprint for what “normal” traffic patterns look like in that environment. Because this is trained specifically on your data, it can take into account seasonality and unique API usage patterns that might be specific to your business.
The Advanced Anomaly Detection ML model, engineered by Google and also used internally for Google services, flags anomalies based on what’s abnormal for your specific environment—for example, increases in request or response size; increases in traffic at times when traffic normally isn’t high; or increases in traffic from specific countries.
Because attackers can frequently change IP addresses, Advanced API Security groups traffic from multiple IPs that look similar—e.g., occurring in the same time frame, with similar usage patterns—into incidents. We’ve also recently improved the way we group and name these incidents to make it easier to understand at a glance what’s happening and start investigating.
2. False positive mitigation with IP allowlisting
By default, both Advanced API Security and API Analytics take the first public IP address and use this as the source IP. For some Apigee users, this can lead to false positives; for example, if you have significant internal traffic, you might see load balancer IP addresses falsely flagged as abusive. If you’re seeing this, you can change this configuration to make sure that Advanced API Security is referencing the correct source IP; our documentation explains how to do this.
If you’ve properly configured your IP client resolution and you’re still seeing IPs for internal batch jobs or known employee devices being flagged as false positives, you can now create a detection exclusion list. You can specify individual IP addresses or CIDR ranges to exclude from detection—either temporarily, like if you’re running penetration tests or other security tests—or for as long as you want. You have the ability to edit the exclusion list at any time and add or remove additional IP addresses.
After you exclude an IP address, it will no longer appear in any security incidents. However, it will continue to appear in the Detected Traffic tab, with the “Excluded” flag. We did this to make sure that you still have a way to observe any potential attacks on known-good IP addresses.Learn more about detection exclusion lists here. (Note: This feature is not yet supported for Apigee organizations with VPC-SC.)
Above: Detection exclusion lists in Advanced API Security’s Abuse Detection feature allow you to exclude IP addresses and CIDR ranges from being flagged as abusive.
Above: Displaying the Exclusions column in the list of detected traffic allows you to flag known-good IPs but still retain visibility.
3. Faster triage with anomaly explanations and Cloud Logging integration
Because Advanced Anomaly Detection analyzes API traffic for 20+ different conditions that could represent attacks, we’ve heard feedback that it can sometimes feel like a black box in terms of understanding why an IP address was flagged as potentially abusive.
That’s why, in the Details tab for a detected IP address, we’ve added a field for “Advanced Anomaly Detection reasons” to explain exactly why an IP address was flagged by the model.
Above: The new Anomaly Summary tab explains why the Advanced Anomaly Detection ML model flagged an IP address and links to ingress access logs.
We’ve also added links to ingress access logs in the Details tab for a detected IP address. When you click on the link, you’ll be taken to Cloud Logging, with a pre-set filter for the selected traffic log. In this tab, we’ve integrated Cloud Logging to point you directly to the traffic logs that were flagged so that you can more quickly triage and identify whether this is an attack that requires action.
As a reminder, if you’ve validated that the attack is legitimate, you can use Security Actions to either flag that IP address, passing a custom header in the downstream logs to identify and monitor it as potentially malicious. You can also block that IP address, so that the attacker can’t access your backend services. (As a best practice, you should practice a layered security approach and block this in your WAF as well.)
As you try out these features, we’d love to hear your feedback! Please drop us a note in the comments if you want to let us know what you think.
Ready to try it yourself? Get in touch with a Google Cloud Sales Specialist.