Back to blog results

July 27, 2016 By Mark Bloom

CIS AWS Foundations Benchmark Monitoring with Sumo Logic

The Center for Internet Security (CIS) released version one of the CIS AWS Foundations Benchmark in February this year. It’s a fantastic first draft, and represents the minimum security controls that should be implemented in AWS.

4 Sections of the CIS AWS Foundations Benchmark

  1. Identity and Access Management
  2. Logging
  3. Monitoring
  4. Networking

This post focuses on Monitoring. IMO, it should actually be called Monitoring and Alerting. CIS implemented the Monitoring controls based on CloudWatch Logs (CWL) integration with CloudTrail and CWL Alarms via the Simple Notification Service (SNS). This is fantastic if you already use these services liberally or cannot get funding for third-party solutions, but they aren’t needed if you already use appropriate third-party solutions. And of course, although I really dig AWS, there’s something to be said for avoiding cloud lock-in, too.

While we do use the required services, and have the pre-requisites configured already, we are shipping AWS logs to Sumo Logic (Sumo). Thus, I thought,“can’t we just use Sumo to satisfy the Monitoring requirements”? The answer is yes and no.

There are sixteen (16) Monitoring controls total. Fourteen (14) of them can be monitored using Sumo’s CloudTrail integration. Let’s have a look at the controls:

3.1 Ensure a log metric filter and alarm exist for unauthorized API calls
3.2 Ensure a log metric filter and alarm exist for Management Console sign-in without MFA
3.3 Ensure a log metric filter and alarm exist for usage of “root” account
3.4 Ensure a log metric filter and alarm exist for IAM policy changes
3.5 Ensure a log metric filter and alarm exist for CloudTrail configuration changes
3.6 Ensure a log metric filter and alarm exist for AWS Management Console authorization failures
3.7 Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs
3.8 Ensure a log metric filter and alarm exist for S3 bucket policy changes
3.9 Ensure a log metric filter and alarm exist for AWS Config configuration changes
3.1 Ensure a log metric filter and alarm exist for security group changes
3.11 Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)
3.12 Ensure a log metric filter and alarm exist for changes to network gateways
3.13 Ensure a log metric filter and alarm exist for route table changes
3.14 Ensure a log metric filter and alarm exist for VPC changes
3.15 Ensure security contact information is registered
3.16 Ensure appropriate subscribers to each SNS topic

Security contact information (3.15) has to be audited via the management console, and SNS subscribers (3.16) are not applicable for our configuration. Once we have the monitoring configured in Sumo Logic, we’ll use its Slack and PagerDuty integrations for alerting. Thus, the Monitoring section of the benchmark is really monitoring and alerting. We will cover Alerting as Phase Two of our Benchmark project. But first, monitoring 3.1-3.14.

CIS AWS: The finished product.

CIS AWS Foundations Benchmark Dashboards

CIS AWS Benchmarks in Sumo Logic Dashboards

Although I’m a Sumo Logic novice, this was very simple to accomplish, albeit by standing on the shoulders of giants. The majority of the searches that power the dashboards are derivatives of those used in Sumo’s out-of-the-box dashboards (dashboards are not available in Sumo Free). Next are the searches you’ll need to configure.

3.1 Detect unauthorized API calls

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"errorCode\":\"*\"" as error
| where error="AccessDenied" or error="UnauthorizedOperation"
| count by error

3.2 Detect console login without MFA

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"sourceIPAddress\":\"*\"" as src_ip nodrop
| parse "\"eventName\":\"*\"" as eventName nodrop
| parse "\"userName\":\"*\"" as userName nodrop
| parse "\"responseElements\":{\"ConsoleLogin\":\"*\"}" as loginResult nodrop
| parse "\"MFAUsed\":\"*\"" as mfaUsed nodrop
| where eventName="ConsoleLogin"
| where mfaUsed<>"Yes"
| count by username, src_ip

3.3 Detect Root Account Usage

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"userIdentity\":{\"type\":\"*\"}" as authData nodrop
| parse "\"type\":\"*\"" as loginType nodrop
| where loginType="Root"
| count by loginType

3.4 Detect IAM Policy Changes

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"eventName\":\"*\"" as event nodrop
| where event matches "Put*Policy" or event matches "Delete*Policy*" or event matches "Attach*Policy" or event matches "Detach*Policy" or event matches "CreatePolicy*"
| count by event

3.5 Detect CloudTrail config changes

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"eventName\":\"*\"" as event nodrop
| where event matches "*Trail" or event matches "StartLogging" or event matches "StopLogging"
| count by event

3.6 Detect AWS Mgmt Console authorization failures

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"responseElements\":{\"ConsoleLogin\":\"*\"}" as loginResult nodrop
| where eventName="ConsoleLogin"
| where errorMessage="Failed authentication"
| count by errorMessage

3.7 Detect disabling or scheduled deletion of CMK

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"eventName\":\"*\"" as event nodrop
| where event matches "DisableKey" or event matches "ScheduleKeyDeletion"
| count by event

3.8 Detect S3 bucket policy changes

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"eventName\":\"*\"" as event nodrop
| where event matches "*BucketAcl" or event matches "*BucketPolicy" or event matches "*BucketCors" or event matches "*BucketLifecycle"
| count by event

3.9 Detect AWS Config config changes

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"eventName\":\"*\"" as event nodrop
| where event matches "StopConfigurationRecorder" or event matches "DeleteDeliveryChannel" or event matches "PutDeliveryChannel" or event matches "PutConfigurationRecorder"
| count by event

3.10 Detect Security Group changes

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"eventName\":\"*\"" as event nodrop
| where event matches "CreateSecurityGroup" or event matches "DeleteSecurityGroup" or event matches "RevokeSecurityGroupEgress" or event matches "RevokeSecurityGroupIngress"
| count by event

3.11 Detect Network ACL changes

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"eventName\":\"*\"" as event nodrop
| where event matches "CreateNetworkAcl" or event matches "CreateNetworkAclEntry" or event matches "DeleteNetworkAcl" or event matches "DeleteNetworkAclEntry" or event matches "ReplaceNetworkAclEntry" or event matches "ReplaceNetworkAclAssociation"
| count by event

3.12 Detect Network Gateway changes

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"eventName\":\"*\"" as event nodrop
| where event matches "CreateCustomerGateway" or event matches "DeleteCustomerGateway" or event matches "AttachInternetGateway" or event matches "CreateInternetGateway" or event matches "DeleteInternetGateway" or event matches "DetachInternetGateway"
| count by event

3.13 Detect Route Table changes

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"eventName\":\"*\"" as event nodrop
| where event matches "CreateRoute" or event matches "CreateRouteTable" or event matches "ReplaceRoute" or event matches "ReplaceRouteTableAssociation" or event matches "DeleteRouteTable" or event matches "DeleteRoute" or event matches "DisassociateRouteTable"
| count by event

3.14 Detect VPC changes

_sourceCategory=[YOUR SOURCE CATEGORY] 
| parse "\"eventName\":\"*\"" as event nodrop
| where event matches "CreateVpc" or event matches "DeleteVpc" or event matches "ModifyVpcAttribute" or event matches "*VpcPeeringConnection" or event matches "*tachClassicLink" or event matches "*ableVpcClassic"
| count by event

As mentioned previously, I’m a Sumo Logic novice—there is no doubt these searches can be improved. The searches looking for more than a few events, like S3 bucket policy changes, can take a longer time to run depending on the date/time range chosen. The initial 7-day search we ran took over an hour to provide results, but we haven’t done any tuning or partitioning yet so YMMV.

This CIS AWS Foundations Benchmark Monitoring blog was written by expert Joey Peloquin who can be reached on Twitter @jdpeloquin.

Complete visibility for DevSecOps

Reduce downtime and move from reactive to proactive monitoring.

Mark Bloom

More posts by Mark Bloom.

People who read this also enjoyed