By Sujay Maheshwari —

AWS Events and Changes You Should Track For Your AWS Account Security and Operational Excellence

AWS Events and Changes To Track For Your AWS Account Security

AWS CloudTrail service captures and publishes every action taken or change performed across any other AWS services.

These changes could come as a result of

  • Console use by a user
  • An application running its code
  • A SaaS partner using assume role running/ accessing some API in your account
  • An event trigger another component (e.g File got uploaded on S3 which trigger a Lambda function)

As you can see everything gets pushed into CloudTrail.

The example below shows that the IAM user Alice used the AWS CLI to call the CreateUser action to create a new user named Bob.

				
					{"Records": [{
    "eventVersion": "1.0",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "EX_PRINCIPAL_ID",
        "arn": "arn:aws:iam::123456789012:user/Alice",
        "accountId": "123456789012",
        "accessKeyId": "EXAMPLE_KEY_ID",
        "userName": "Alice"
    },
    "eventTime": "2014-03-24T21:11:59Z",
    "eventSource": "iam.amazonaws.com",
    "eventName": "CreateUser",
    "awsRegion": "us-east-2",
    "sourceIPAddress": "127.0.0.1",
    "userAgent": "aws-cli/1.3.2 Python/2.7.5 Windows/7",
    "requestParameters": {"userName": "Bob"},
    "responseElements": {"user": {
        "createDate": "Mar 24, 2014 9:11:59 PM",
        "userName": "Bob",
        "arn": "arn:aws:iam::123456789012:user/Bob",
        "path": "/",
        "userId": "EXAMPLEUSERID"
    }}
}]}
				
			
 

So much data?

Data -> information -> insights becomes challenging and overwhelming if the amount is large and needs to be consumed in real-time. So, below is the list of metrics that we recommend you keep an eye on. This doesn’t mean that other events are not important but the objective of this blog is to ensure that the signal-to-noise ratio for your team is minimum and you do not lose sight of critical updates.

  • ConsoleLogin

      • What? : This event is raised when anyone logs into the account using the AWS console.
      • Why? : Generally, if you have CI/ CD setup and your team uses command-line tools to interact with cloud API, then console login is a rare act. It makes it important to stay alert if there is a console login.
      • Risk: Medium
      • What to do next? If you have a console login, especially for someone with a root or administrator role, then checking with them offline (over Slack or other messenger-based tools) is recommended.

  • StopLogging

      • What? When AuditTrail logs are disabled. Yes, it raises this event and logs this action too 🙂
      • Why? There will be little to no reason that anyone without a planned notice and communication has disabled AuditTrail logs themselves. So, this event itself is a good enough reason to jump on it.
      • Risk: High
      • What to do next? Jump on a call with team members (if required), login into your console, and assess who did it? If it was a mistake, then reenable the logging again. Also, put controls and education in a place where this mistake doesn’t happen again in the future.

  • CreateRoute, CreateNetworkAclEntry, CreateSecurityGroup

      • What? These deal with VPC security – one of the building blocks in which your compute and other resources and data resides.
      • Why? This activity should be planned, documented, and approved activity.
      • Risk: High
      • What to do next? Alert your team about this and fix the issue/ process which has caused this.

  • AuthorizeDBSecurityGroupIngress, CreateDBSecurityGroup, DeleteDBSecurityGroup, RevokeDBSecurityGroupIngress

      • Why? Your database should be one of the most protected resources. Not only shouldn’t have a public assigned IP but it also should be in the Private subnet. Now listening for these events ensures that any changes with DB Security groups don’t go unnoticed.
      • Risk: High

References

Know more about