# Cloud APIs Called More Often Than Usual Per User

## Description

Builds a per-user baseline for how many API calls is normal, and then alerts for deviations.

## How to Implement |
---|

Assuming you use the ubiquitous AWS, GCP, or Azure Add-ons for Splunk to pull these logs in, this search should work automatically for you without issue. While implementing, make sure you follow the best practice of specifying the index for your data. |

## Known False Positives |
---|

This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately a spike in the number we're monitoring... it's nearly impossible for the math to lie. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise. How you handle these alerts depends on where you set the standard deviation. If you set a low standard deviation (2 or 3), you are likely to get a lot of events that are useful only for contextual information. If you set a high standard deviation (6 or 10), the amount of noise can be reduced enough to send an alert directly to analysts. |

## How To Respond |
---|

When this alert fires, you should look at what APIs were called. We've excluded some of the basic inaction ones (such as DescribeInstances), but the severity of the event will vary based on the severity of the API calls. The natural next step is to call a user and see if they expected this behavior. If the user cannot attribute this activity, it is best to reset the keys and continue your investigation to see what occurred. |

## Help |
---|

## Cloud APIs Called More Often Than Usual Per User HelpThis example leverages the Detect Spikes search assistant. Our example dataset is a collection of anonymized AWS CloudTrail logs, during which someone does something bad. Our live search looks for the same behavior using the very standardized index and sourcetypes for AWS CloudTrail, GCP and Azure Audit, as detailed in How to Implement. |

## SPL for Cloud APIs Called More Often Than Usual Per User

### Demo Data

| First we bring in our basic demo dataset. In this case, anonymized AWS CloudTrail logs. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data. |

| Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same day. |

| Next we use stats to summarize the number of events per user per day. |

| calculate the mean, standard deviation and most recent value |

| calculate the bounds as a multiple of the standard deviation |

### AWS Data

| First we bring in our basic dataset, AWS CloudTrail logs that are filtered for interesting APIs. |

| Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same day. |

| Next we use stats to summarize the number of events per user per day. |

| calculate the mean, standard deviation and most recent value |

| calculate the bounds as a multiple of the standard deviation |

### GCP Data

| First we bring in our basic GCP Audit logs, filtering out list activity. |

| Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same day. |

| Next we use stats to summarize the number of events per user per day. |

| calculate the mean, standard deviation and most recent value |

| calculate the bounds as a multiple of the standard deviation |

### Azure Data

| First we bring in our basic dataset, Azure Audit logs. |

| |

| Next we use stats to summarize the number of events per user per day. |

| calculate the mean, standard deviation and most recent value |

| calculate the bounds as a multiple of the standard deviation |