Recent Posts


Recent Comments


Archives


Categories


Meta



In my previous articles, we looked at security governance in both small-scale and large-scale Amazon Web Services (AWS) environments.

In this article we will look at several security tools that we can quickly deploy to our AWS accounts.  These tools are easy to implement, especially when you are working with a smaller number of accounts.  In particular, we will explore:

  • AWS’ CIS Benchmark Quick Start
  • AWS Guard Duty

CIS Benchmark on AWS Quick Start

The Center for Internet Security (CIS) maintains what many consider as industry standard security hardening guides for different technologies. The CIS Amazon Web Services Foundations Benchmark provides a set of security configuration best practices for hardening AWS accounts.

AWS maintains a security-related Quick Start that implements a set of security best practices and continuous monitoring capabilities based on the CIS AWS security recommendations.

The AWS Quick Start can be found at  https://aws-quickstart.s3.amazonaws.com/quickstart-compliance-cis-benchmark/templates/main.template. Here you will find a deployment guide, a security controls matrix that shows how the Quick Start maps to the CIS controls, and a set of AWS CloudFormation scripts to install the Quick Start. The CloudFormation scripts can also be pulled and modified to add other capabilities or update the checks to meet your needs.

Let’s take a quick look at some the checks and the AWS capabilities used to implement the checks:

 

AWS CloudWatch Events Implements checks to detect changes in:

  • CloudTrail and Config configurations
  • IAM and S3 Bucket Policies
  • Network ACLs and Security Groups

 

CloudWatch Metrics and Alarms Implements continuous monitoring on CloudTrail events sent to CloudWatch Logs for:

  • KMS key that has been disabled or scheduled for deletion
  • Console login failures
  • Console logins without multi-factor authentication (MFA)
  • Root user logins
  • Unauthorized/Access Denied IAM actions

 

Config Rules Implements custom Config rules and supporting AWS Lambda scripts for evaluating:

  • CloudTrail and associated S3 bucket settings
  • VPC Flow Logs are enabled
  • IAM settings like password policies, user access keys and passwords that need to be rotated, MFA enabled on the root account, etc.
  • Security Groups to look for default VPC security groups that allow traffic and network ports used for administration that are open to the entire Internet

 

There are couple of things to be aware of with the default Quick Start:

  1. The CloudFormation scripts have the option to configure AWS Config and AWS CloudTrail for you, or they can use existing settings. If you use an existing CloudTrail, that trail must deliver logs to both S3 and AWS CloudWatch Logs.
  2. The AWS Quick Start must be installed in each AWS Region that you need to monitor. Many of the checks are AWS Region dependent.
  3. Depending on the usage pattern of the AWS Account, the alerting can become noisy at times. For example, if a CI/CD process updates IAM policies or Network settings on a regular basis, each changed resource will trigger an alert.
  4. Entire checks can be disabled, but you can’t filter out specific resources in a check.

When problems are detected by this AWS Quick Start, alert messages driven CloudWatch Events and Alarms are sent using AWS Simple Notification Services (SNS) to an email address passed to the CloudFormation scripts. Issues flagged as non-compliant by Config Rules are viewable in the AWS Config Console.

Threat Intelligence with AWS GuardDuty

One of AWS’ newer security services is AWS GuardDuty. GuardDuty provides a managed threat detection service to monitor for malicious or unauthorized activity within your AWS Accounts and workloads. GuardDuty applies analytics against your VPC flow logs, API calls via CloudTrail, internal DNS resolvers, and other data samples to look for potentially malicious activity.

AWS GuardDuty can be enabled via the AWS Console by:

  1. Login to the Console.
  2. Switch to the desired AWS Region.
  3. Select the GuardDuty service from the list of services.
  4. Enable GuardDuty.

GuardDuty is AWS Region dependent and must be enabled in all Regions that are to be monitored. AWS does recommend enabling to all AWS Regions provides the best coverage.

You can view and manage your GuardDuty findings on the Findings page in the AWS GuardDuty Console, using the GuardDuty CLI, or via API calls.  Filters can be created to help review results or to auto-archive events to stop specific events from alerting.   More details on GuardDuty Filters can be found here.

GaurdDuty Alerting Tool

GuardDuty does not create an alerting mechanism when it is enabled, but it is easy to create a simple email alert system using AWS CloudWatch Events and AWS SNS. This will send all GuardDuty findings to the SNS topic’s subscribers.

  1. Create a new SNS topic or identify an existing SNS topic to use.
  2. Configure and/or verify the SNS Topic subscribers to ensure they are correct.
  3. Open the CloudWatch Service page in the AWS Console.
  4. Create new CloudWatch Events Rule:

  1. Add a Target using the SNS Topic created from Step 1.

  1. Select “Configure details” when done with Targets
  2. Give the rule a name, set the state to “Enabled,” and create the rule.

We have now implemented a basic Threat Detection service on our AWS account and workload. There are other GuardDuty features, Trusted IP Lists, and Threat Lists that can be used to identify known good and bad IP addresses. The alerting mechanism can be enhanced by implementing additional alerting criteria, such as finding severity levels, and more complex processing of findings using AWS Lambda.

Wrap Up Time

The AWS Quick Start for the CIS AWS Benchmark and GuardDuty can be easily added to an AWS account to provide a more secure AWS configuration, threat intelligence, and continuous monitoring of the account. They provide a good start on reducing risk in how the account itself is accessed and managed, but they do not address all potential security issues one may encounter in the Cloud. The workload itself, the services used to build that workload, and the threat profile of the workload will drive the other security tools and process that need to be implemented.

Bob is a member of the CTO Architect Team at Sungard Availability Services. In his over 25 years of IT experience, he has touched just about every aspect of technology from desktops to large enterprise systems and everything that connects them together. His last 10 years has been focused on Information Security, including Red Team, Blue Team, technical controls, and managing security operations. Prior to Sungard Availability Services, Bob held several positions AT&T (formally USi) and TASC. Bob holds a B.S. in Electrical Engineering from Virginia Tech.


Comments

0
There are no comments.