Which Cloud Trail Calls are Important for Security Teams ?

The Basics

Log Integrity — Where to send the logs to ?

First, enable cloud trail, in All Regions

There are several places that you can send the cloud trail logs to

• S3 Bucket
• Cloudwatch
• Third party service

As a security person, I recommend picking a third party service because of the following reasons

Advantages of Having a third party service

1. Confidence that logs are not lost or tampered with. Once an attacker gets access to your account, the attacker might tamper with or delete the S3 buckets or cloud watch logs. Once the logs are shipped off your account, you can be more confident and move faster in the investigation in case of a breach working with logs that are stored “off pre”
2. Ability to search, slice and dice and alert. As this article will detail, there are API calls that you want to get woken up in the middle of the night, there are API calls that you want to ask more questions around the call, the user, the source IP . While you can write your own tools on top of S3 or cloud watch, a third party service will give you tools for searching and alerting
3. Right, up-to-date rules. AWS adds, changes API calls frequently and therefore it is important to keep the alert rules up to date. You might have better bang for the buck with a third party tool than fiddling around in house.

Lets dive into the calls makes sense for security purposes.

There are two types of

1. Alerts — Calls that need to be acted on right away
2. Monitor — Calls that need to be investigated in the “next day or two”

What are the Cloudtrail calls to get Alerted On ?

The following are the scenarios and corresponding calls you want to get alerted on -

Account got Compromised — Attacker Compromising Logs

When an account is compromised, one of the first things that the attackers would do is to stop logging the call and delete existing trails.

Calls to get alerted on :

DeleteTrail, StopLogging, UpdateTrail`

Root Account is being Used for Infrastructure Operations

The concept of AWS Root account should not be used for normal operations is well known. By this time, you probably have disabled access keys for your root account . So if a API call is being made with Root credentials, then you want to get alerted on it

Calls to get alerted on :

user="root" and (eventType !="AwsApiCall" or eventType !="AwsServiceEvent")

Critical IAM Changes

IAM service is where many of the security incidents will get reflected

1. New access keys getting created
2. New users/groups/role getting created
3. New policies being attached to users and roles
4. Changes to access methods and changes to account level policies

Calls to get alerted on :

eventSource = "iam.amazonaws.com" and (eventName = "AddUserToGroup" or eventName = "AttachGroupPolicy" or eventName = "AttachRolePolicy" or eventName = "AttachUserPolicy" or eventName = "CreateAccessKey" or eventName = "CreateLoginProfile" or eventName = "CreatePolicy" or eventName = "CreateRole" or eventName = "CreateUser" or eventName = "CreateVirtualMFADevice" or eventName = "DeactivateMFADevice" or eventName = "DeleteAccessKey" or eventName = "DeleteGroup" or eventName = "DeleteGroupPolicy" or eventName = "DeletePolicy" or eventName = "DeleteRole" or eventName = "DeleteRolePolicy" or eventName = "DeleteServerCertificate" or eventName = "DeleteUser" or eventName = "DeleteUserPolicy" or eventName = "DeleteVirtualMFADevice"    or eventName = "DetachGroupPolicy")

Users running instances in non standard hidden regions incurring costs

When your access key gets stolen an easier way for the attackers to hide their instances is to run them in regions that you do not operate in so normal DescribeInsances call wont see them.

Calls to get alerted on

eventName = "RunInstances" and (region != "xxx" or  region != "yyy")

What are the Cloudtrail calls to get Alerted On ?

The following are the scenarios and corresponding calls you want to get alerted on -

What are the Cloudtrail calls to Monitor for each AWS Service ?

The following are the calls for each AWS service that are relevant to monitor from a security perspective -

EC2 Service

Are Security Groups getting Created or Changed that would be out of your Security Policy ? (example — wide open security groups)

Calls to Monitor:

(eventName = "AuthorizeSecurityGroupEgress" or eventName = "AuthorizeSecurityGroupIngress") and cidrIp = "0.0.0.0/0"

Are Instances being Launched with non-standard images or key names ?

Calls to Monitor

eventName = "RunInstances" and imageId != "ami-xxx"

S3 Service

Changes to Bucket Policies

Calls to Monitor:

eventName="DeleteBucketLifeCycle" or eventName = "DeleteBucketTagging" or eventName = "PutBucketAcl" or eventName= "PutBucketLifecycle" or eventName = "PutBucketPolicy" or eventName = "PutBucketReplication" or eventName = "PutBucketLogging"

SQS

Your SQS queues has your data flowing through them, any changes to permissions on the queue or deleting/purge of queues has security implications

Calls to monitor :

eventName = "CreateQueue" or eventName = "DeleteQueue" or eventName = "AddPermission" or eventName = "RemovePermission" or eventName = "PurgeQueue"

VPC Changes

Any VPC changes such as new/edit/deletes of routes, subnets should is a common

eventName = "CreateRouteTable" or eventName = "CreateNetworkAcl" or eventName = "CreateRoute" or eventName = "DeleteNetworkAcl" or eventName = "DeleteRoute" or eventName = "DeleteRouteTable" or eventName = "DeleteSubnet" or eventName = "DeleteVpc" or eventName ="ReplaceNetworkAclAssociation" or eventName ="ReplaceNetworkAclEntry"

Route53

Any DNS record changes is important from a security perspective

Calls to monitor :

eventName = "ChangeResourceRecordSets"

RDS

Creating a new security group for a database, copying of snapshots , deleting snapshots

Calls to monitor:

eventName = "CreateDBSecurityGroup" or eventName = "CopyDBSnapshot" or eventName = "CreateDBSnapshot" or eventName = "DeleteDBSnapshot" or eventName = "ModifyDBInstance"

For awesome autonomous cloud operations product, get www.avarmia.com