AWS security practitioners must be able to demonstrate their knowledge of security tools and methodologies to protect critical infrastructure and avoid the often costly penalties of noncompliance. Security engineers and managers who pursue additional IT training and certification, such as AWS’ Certified Security – Specialty program, can provide value to not only their professional careers, but also their organization’s security.
Another benefit of certifications, said Stuart Scott, author of AWS Certified Security – Specialty Exam Guide, is their ability to boost a company’s reputation. “To be able to say that our team has passed the AWS Certified Security – Specialty tells customers, ‘Your data is in safe hands with us,'” he said.
AWS managed services, such as Amazon’s cloud auditing tool, AWS Config, play a significant role in securing infrastructure appropriately at every level. AWS Certified Security – Specialty exam questions will likely touch on the various features available from these services, including evidence collection and enforcement rules for compliance.
In the following excerpt from Chapter 13 of AWS Certified Security – Specialty Exam Guide, published by Packt Publishing, Scott, AWS content and security lead at Cloud Academy, outlines how to use the AWS Config service to better understand and protect AWS environments.
After reading the excerpt, take the AWS Certified Security – Specialty practice test questions to see what you have learned.
Be sure to also check out a Q&A with Scott, who provides additional insights on the certification, and download a PDF of Chapter 13 to read the entire chapter — including more AWS Certified Security -Specialty exam questions.
Understanding your AWS environment through AWS Config
With the number of services rising each year in AWS (currently at 168 services at the time of writing), it’s easy to comprehend how difficult it can be to have an understanding of what resources you might be running within your environment. How can you keep up with what instances you have running and where, what are they running, and the resources still needed? You might be running infrastructure that’s no longer required that got overlooked in among the thousands of virtual devices that are in production.
With the huge network of resources running within your account, do you have a clear understanding of which resource is connected to which? What ENI is connected to which instance? Which subnet is that instance running in? Which subnets are connected to which VPCs? Do you have a logical mapping of infrastructure that quickly and easily allows you to identify a blast radius should an incident occur, or visibility into resource dependencies should you change your configuration?
On top of that, do you know their current state of configuration? Are you certain they are running the latest patches, or is there a chance that some of your infrastructure is exposed and has been left vulnerable to potential security threats?
If someone makes a change to your infrastructure and environment, do you have an accurate record of that change, what changed, and when it changed?
Going back to compliance, how can you be assured that the resources that you are deploying and keeping meet compliance needs as dictated by both your internal and external controls and processes?
Answers to all of the above questions are generally required when performing audits, but gaining this information can be very cumbersome in traditional IT deployments, let alone cloud environments, which by their very nature are far more dynamic and are subject to afar higher rate of change. However, AWS is aware of these audit and compliance requirements and has an AWS service called AWS Config to help you address many of these questions in an automated, auditable, and compliant way.
For a comprehensive walk through of how to configure AWS Config, please see: https://docs.aws.amazon.com/config/latest/developerguide/gs-console.html. In this book, I want to focus more on the different components of AWS Config, and how they operate to help you understand how the service works and provides a level of auditing and governance checks. So, once you are set up, come back here to explore the various components of AWS Config.
To understand how AWS Config can help you achieve these results, let me explain some of the components of the service, which include the following:
- Configuration items
- Configuration streams
- Configuration history
- Configuration snapshots
- Configuration recorder
- Config rules
- Resource relationships
- Config role
Let’s begin with our first component — configuration items (CIs).
This is a fundamental element of AWS Config and is essentially a JSON file containing point-in-time snapshot information on the configuration data of attributes of a specific AWS resource within your environment that is supported by AWS Config (a full list of supported resources can be found at: https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html).
These attributes include its current configuration, any direct relationships the resource has with other resources, metadata, and events. A new CI is updated every time a change is made on that resource, for example, when a create, update, or delete API call is made against the resource.
To understand more about the construct of a CI, a table containing a list of components of a configuration item can be found within the AWS documentation at: https://docs.aws.amazon.com/config/latest/developerguide/config-item-table.html. Let’s go over the components one by one:
- The Metadata section contains information and data about the configuration item itself.
- The Attributes section focuses on the data of the actual resource that the CI relates to.
- The Relationship section holds data related to any connected resource, for example, if the CI related to a subnet, the relationship could contain data related to the associated VPC the subnet was a part of.
- The Current Configuration, as the table explains, shows the same information that would be generated if you were to perform a describe or list API call made by the AWS CLI.
These CIs are effectively building blocks of AWS Config and are used by many other components of the service. Let’s continue to see how these work together.
When a change against a resource occurs in your environment, and as a result a new CI is created, then the CI is automatically added to a configuration stream, which is essentially an SNS topic. During the configuration of AWS Config, you can specify the SNS topic to be used for your stream:
This enables you to monitor the stream and customize notifications for changes occurring to resources, helping you to identify potential issues or security incidents that are unexpected.
This is especially useful when it comes to audits and provides a complete history of all the changes made to a resource. By collating the CIs for a resource, AWS Config is able to assemble a history of modifications to that resource. The history of your resource can be accessed via the AWS CLI or via the AWS Management Console as a timeline of events. Also, as a part of the process, AWS Config will store a configuration history file of each resource type in an S3 bucket that is selected during the configuration of AWS Config.
Here, you can see the configuration history of an EC2 security group. It shows the date and time of any changes to the resource:
Using the AWS Management Console, you can select these changes and dive deeper to understand what element changed. Also, following a security incident or an outage, this history can be very useful to determine the timeline of events that led to the incident and can help you resolve it quickly and effectively.
Again, using the building blocks of AWS Config, new CIs will be created allowing for a configuration snapshot to be constructed to get a point-in-time image of your AWS environment of all supported AWS resources with AWS Config in a particular region. This snapshot can be initiated by running the AWS CLI deliver-config-snapshot command and the results will be sent to your predefined Amazon S3 bucket.
You can think of the configuration recorder as the on and off switch for the AWS Config service. You must first enable the configuration recorder before the service can start creating your configuration items (CIs). When you first configure AWS Config, the configuration recorder is automatically started, but once started, you can stop and re-enable it at a later date:
This shows the initial configuration screen and allows you to select the resource types that you want AWS Config to record. If you uncheck the Record all resources supported in the region, then you will be able to select from a drop-down list of Specific types, an example of which can be seen here:
With your chosen resources selected and the destination S3 bucket selected to store your configuration history and snapshot files, the configuration recorder can begin resource changes.
AWS Config rules
From a compliance perspective, AWS Config rules are a great feature and should be implemented whenever you use AWS Config. Backed by AWS Lambda functions performing simple logic, Config rules automatically monitor your resources to ensure they are meeting specific compliance controls that you might need to introduce within your AWS environment. If a resource is found not to be compliant, you will be notified via SNS and the configuration stream, allowing you to take corrective action.
Practice AWS Certified Security – Specialty exam questions
These questions were curated by SearchSecurity to test your knowledge of the above excerpt.