LinkedIn
Twitter
Apigee’s API management platform includes a number of native security-related policies, like oAuth 2.0; JSON and XML threat protection policies; and SpikeArrest, among others. You can (and should!) configure and attach these policies to pre- and post-flow checks to protect your services.
But if you need to go beyond policy enforcement to comprehensive threat detection and blocking, Apigee Advanced API Security can help. It’s an add-on to Apigee X and Apigee Hybrid that continuously monitors and protects your APIs from security threats, including malicious clients and abuse. For example, with its risk assessment feature, you can automate configuration checks on all of your proxies, and detect when proxies are misconfigured and don’t include the policies that you’ve set up in Apigee, like authorization, authentication, quota, rate limiting, and threat protection.
One of the most powerful features of Apigee Advanced API Security is Security Actions. It goes beyond just threat detection, allowing you to automatically block traffic that has been detected as suspicious and shut down attacks.
A key benefit of security actions is that you have a lot of flexibility to configure these for your specific use case. But because of that flexibility, we often hear from customers who are new to this feature that they’d like some best practices for getting started. In this article, we’ll talk through some common customer use cases and our tips for how to get the most value out of security actions.
What are Advanced API Security’s Security Actions?
To understand security actions and their value, you first need to understand how abuse detection works in Advanced API Security.
Advanced API Security includes a set of detection rules. Some of these rules (specifically, anomaly detection and API scraping) are powered by machine learning, meaning they are dynamic and will become more and more accurate over time. Our anomaly detection model, for example, can be trained on your API traffic and can learn from your historical traffic patterns to reduce false positives.
Incoming requests to your Apigee API proxies are evaluated against these detection rules. By default, Advanced API Security won’t take action to deny or redirect traffic that looks suspicious based on these detection rules. We don’t want to take any action without your review or consent. This is where the power of security actions comes in.
Security actions can be configured on the environment level to flag, deny, or allow traffic based on findings from these detection rules, or alternatively, based on region codes or authentication dimensions like developer app, API key, or OAuth token. It is a powerful way to automatically block malicious attacks and protect your APIs—especially since these attacks can happen at any time, like at 3:00 in the morning when you’re not actively monitoring traffic.
Within an environment, you can apply security actions to specific proxies, or all proxies in that environment. You can also specify if you want those actions to end after a certain time period—for example, if you want to temporarily disable an API key or block an attacker.
Getting started with Security Actions
If you’re new to Advanced API Security, we recommend you start just by deploying Advanced API Security with no security actions configured. You can take a look at the analytics it provides and understand what types of threats are being detected.
Then, when you’re ready to start implementing actions, we recommend starting with the flagging configuration, to gain more insight and understanding of detected threats, including their impact and whether they are false positives. After you’ve gained confidence that the threats are real and deserve mitigation, you can start deploying security actions to block those threats.
We’ll walk through some common initial use cases below.
Flag detected traffic for inspection
Advanced API Security’s Abuse Detection feature monitors traffic for potential threats based on different detection rules (both static rules and dynamic ML models). You can use security actions to flag traffic detected as suspicious over a certain time period. This is essentially a “dry run” of Advanced API Security’s abuse detection that will allow you to understand what traffic would have been blocked if you had automatically denied instead of flagged this traffic.
When you’re flagging traffic, you can use headers to forward additional information to your target endpoints, like the name of the security action you’re creating, so that you know why the traffic was flagged. In the below step, we’re giving this action a name/ID of “flag-malicious-traffic-test,” and enabling it for all proxies in our prod environment for a dry-run period. You can choose to enable security actions for just one proxy, or a group of proxies in an environment.
Next, we can add a custom header to forward information that traffic to the target endpoint was flagged because of this security action:
And finally, we can configure this action to flag any traffic detected as suspicious by Advanced API Security’s detection rules:
Logging detected traffic in your preferred SIEM
You can use security actions together with Apigee’s native MessageLogging policy to send verbose logs to your SIEM tool (whether that’s Chronicle, or a third-party SIEM solution like Splunk or Microsoft Sentinel). This can help your security team triage and correlate suspicious traffic in their SIEM, stitching together this logging data with other related events.
To do this, you can follow the steps above to flag detected traffic with a custom header. Then you can configure Apigee’s MessageLogging policy to trigger when it sees the header:
<PostFlow name="PostFlow">
<Request>
<Step>
<Condition>request.header.apisec="flag-malicious-traffic-test"</Condition>
<Name>LogMessagePolicy</Name>
</Step>
</Request>
</PostFlow>
To configure the MessageLogging policy to send your log data to your SIEM, you can specify in the policy which Apigee flow variables you want to send to the SIEM. This enables you to send a richer set of log details to the SIEM for triage and correlation. Read more about configuring this policy in our documentation. .
Explicitly allow traffic from known-good IP addresses, to reduce false positives
To make sure that internal IP addresses or other known-good IP addresses aren’t detected as malicious traffic, leading to a false positive, you can create a security action to always allow traffic from known IPs. You can do this by creating a new condition to allow traffic from specific IP addresses, as shown below:
Because IP addresses can change frequently, you can also use other authentication attributes to allow (or deny) traffic, including API keys, API products, access tokens, developers, and developer apps. For example, if you wanted to simulate an attack but not block traffic from other internal developers, you could choose to block traffic from a specific API key.
After you’ve observed flagged traffic for a while and you’ve gained confidence that the threats are real and deserve mitigation, you can start deploying security actions to block those threats.
Below are some suggested ways to do this:
Deny all traffic or specific IP addresses detected in an attack and display an HTTP 403 response:
Advanced API Security’s Security Incidents view displays information about detected suspicious traffic, including a list of IP addresses. You can then create a “Deny” security action to deny all traffic from those IP addresses, and show an HTTP 403 response code.
Deny traffic from specific countries:
If you want to restrict traffic to only certain countries, you can use security actions to do this. You can create a “Deny” security action with the condition of “Region codes” and select all countries other than the countries you want to allow traffic from.
Tips and best practices for using Security Actions
- Avoid creating actions that include large CIDR addresses. For example, 200.0.0.0/16 could end up affecting traffic from over 65,000 IP addresses.
- Default to creating actions at the environment level. Only create proxy-level actions when environment-level actions do not meet your use case. Proxy-level actions have stricter limitations when compared to environment-level actions; for example, you can allow, flag, or deny a smaller number of API keys, access tokens, and developers at the proxy level vs. the environment level.
- Pause security actions if needed. If enabling security actions causes any unintended consequences, you can use the “Pause Enabled Actions” feature. Once paused, the state of all actions are retained, and you can resume those actions when you’re ready.
- Use our public API to more easily create, enable, or disable security actions. This article shows screenshots from our UI, but you can use our API to manage your security actions as well. View API documentation here.
- View data from enabled security actions on the Security Action Details page: You can view top denied rules, denied countries, and action details, as shown below:
Next Steps
To use security actions, you first need to have Apigee Advanced API Security enabled. Advanced API Security is available as an add-on for Apigee X and Apigee Hybrid pay-as-you-go and subscription customers. You can view more information about Advanced API Security and Security Actions in our documentation.