The AWS Management Console, along with the AWS CLI can produce powerful results for auditors across multiple regulatory, standards, and industry authorities. I am going to cover some of the key sources that produce important and meaningful log information that you can use within your audit and compliance program.
You should consider auditing your security configuration in the following situations:
- On a periodic basis. You should perform the steps described in this document at regular intervals as a best practice for security.
- If there are changes in your organization, such as people leaving.
- If you have stopped using one or more individual AWS services. This is important for removing permissions that users in your account no longer need.
- If you’ve added or removed software in your accounts, such as applications on Amazon EC2 instances, AWS OpsWorks stacks, AWS CloudFormation templates, etc.
- If you ever suspect that an unauthorized person might have accessed your account.
The key services that produce meaningful audit event telemetry in most AWS environments include: Amazon S3, Elastic Load Balancer, Amazon CloudWatch, AWS CloudTrail, and Amazon VPC. This is not a definitive list, but should get you started in the right direction. Also, be sure to check out the resource links at the bottom of the article.
Get My Free Cloud Security Journal
In reality, you will most likely want to use the AWS Audit Manager Service because it helps you continuously audit your AWS usage to simplify how you assess risk and compliance with regulations and industry standards. Audit Manager automates evidence collection to reduce the “all hands on deck” manual effort that often happens for audits and enable you to scale your audit capability in the cloud as your business grows. With Audit Manager, it is easy to assess if your policies, procedures, and activities – also known as controls – are operating effectively. When it is time for an audit, AWS Audit Manager helps you manage stakeholder reviews of your controls and enables you to build audit-ready reports with much less manual effort.
Amazon S3 Server Access Logs
Logging can be audited on Amazon S3 (Simple Storage Service) buckets using access logs. Access logs contain important details about requests. For example, the request type, resources requested, data and time the request was made. These logs give security professionals and stakeholders insight into the nature of requests made by clients.
Elastic Load Balancer (ELB) Access Logs
The logs for ELB appliances can be audited using its own access logs directly. ELB access logs natively capture important event information about each request sent to the load balancer. For example, IP address, latency information, and ever server response information. In addition to the audit logs, you can use event data to analyze traffic patterns and also for troubleshooting and diagnostics.
Amazon CloudWatch Logs & Events
Amazon CloudWatch logs allow you to monitor and troubleshoot all the operating systems and applications that are running in your AWS environment. CloudWatch logs also allows you to monitor logs for very specific phrases, patterns, and values which can be tied with other services to provide unique and highly automated security monitoring and alert solutions.
Auditing your AWS CloudTrail logs allows you to obtain a comprehensive history of API calls to your AWS account whether it is made via the console, CLI, SDK, or other AWS Services.
Amazon VPC Flow Logs
Amazon VPCs can be audited for connectivity and security issues using VPC flow logs. These logs are an important part of your overall security plan because your network access rules can be verified via these logs. In short, the VPC flow logs capture detailed IP traffic events that are flowing in and out of your interfaces and subnets.
The main goal of this article was to help AWS users understand the core building blocks for auditing on the AWS platform.
I highly recommend the following resources for digging deeper:
- AWS Security Audit Guidelines
- AWS Audit Cloud Academy Training
- AWS Audit Manager
- Security at Scale: Logging in AWS Whitepaper (PDF)
- AWS Services: Amazon S3, Elastic Load Balancer, Amazon CloudWatch, AWS CloudTrail, and Amazon VPC
Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management for business stakeholders across the enterprise. Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier.
Stay Connected With Tim Layton
Get My Free Cloud Security Journal
COMMON CYBERSECURITY RISK TERMS DEFINED
Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. (NIST 800–30)
Threat: potential cause of an unwanted incident, which can result in harm to a system or organization. (ISO 27001)
Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. (NIST 800–30)
Vulnerability: weakness of an asset or control that can be exploited by one or more threats. (ISO 27001)
Likelihood: A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities. (NIST 800–30)
Likelihood: chance of something happening. (ISO 27001)
Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NIST 800–30)
Risk: effect of uncertainty on objectives. (ISO 27001)
Security Controls: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NIST 800–30)
Compensating Security Control: A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NIST 800–30)
Impact Level: The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. (NIST 800–30)
Residual Risk: Portion of risk remaining after security measures have been applied. (NIST 800–30)
Security Posture: The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST 800–30)
Get My Free Cloud Security Journal