1. Determine if a Cloud Adoption Office (CAO) has been established.
2. A CAO is an essential mechanism for successful cloud adoption.

An auditor should review:

1. CAO has been established,
2. Cloud activities within the company are managed through the CAO,
3. Stakeholders include infrastructure, security, compliance, finance, and HR, and.
4. Frameworks, policies, standards, and procedures have been defined for the cloud.

 

1. Determine if the Cloud Adoption Framework (CAF) has been developed.
2. CAF includes best practices and approaches to cloud computing throughout the organization.
3. Proper sign-offs on CAF from senior management.

 

1. The multi-account strategy is well documented and leverages tools such as AWS Organizations and AWS Control Tower to manage the multi-accounts (if applicable).
2. Clearly define an AWS account-creation process. Understanding who in the company is creating AWS accounts and what each account will be used for is an essential part of an AWS account. Many companies have a centralized process for creating AWS accounts; however, centralization is not required as long as the process is well-defined and allows a business to maintain an account inventory.
3. Define a company-wide AWS usage policy. Implement well-defined AWS usage policies and vet them with company stakeholders to align business and security requirements. This empowers CSCs to leverage AWS without internal confusion about what is or is not within policy guidelines. An AWS usage policy should include a company’s minimal security baseline requirements for how they will use AWS, such as which services are approved for use or what security or encryption features must be enabled.
4. Create a security account structure for managing multiple accounts. Creating a security relationship between accounts makes it even easier for companies to assess the security of AWS-based deployments, centralize security monitoring and management, manage identity and access, and provide audit and compliance monitoring services.
5. Leverage AWS API operations and scripts. Many CSCs leverage the AWS API operations and custom-developed scripts to automatically and consistently apply baseline configurations across multiple AWS accounts. CSCs should consider leveraging compliance-monitoring scripts to provide insight into how well a company’s accounts comply with its defined policies and standards for AWS usage.

 

1. Determine if management or an internal function performs a periodic assessment of cloud control effectiveness at a frequency consistent with the policy (for example, annually).
2. Inspect the risk and control assessment results to determine if the assessment included design and operating effectiveness testing of controls.
3. Inspected that results were communicated to those charged with governance.
4. Inspect that, when applicable, remediation processes took place and were followed through to resolution.

Identity and Access Management

1. Inquire and understand user access life cycle policies and procedures followed by management.
2. Inspect access provisioning and de-provisioning procedures to determine appropriate individuals authorized to grant and approve access.
3. Obtain and inspect a list of new user provision access during the period. Use AWS services to obtain the user list as follows:
4. For AWS IAM users –
5. Obtain user profile details from AWS Console >> IAM Service >> Credential report >> download the report.

Further, apply a filter on column “User_creation_time” in the file downloaded to obtain a specific list of users provisioned in the audit period. (This is a point in time)

1. Obtain and inspect CloudTrail logs to assess events related to user provisioning activity during the audit period.
2. For Federated users, it is based on the implemented AWS architecture.
3. Determine if management uses AWS Directory Service, and then obtain AD event logs from CloudWatch logs.
4. Determine if management uses AWS single sign-on service, then obtain the targeted logs from CloudTrail using Amazon Athena or possibly CloudWatch logs if forwarded.

iii. Determine if management manages the on-premise AD, then obtain logs from on-premises AD.

 

1. If management uses on-premise AD, Amazon Kinesis Agent for Microsoft Windows or CloudWatch agent can feed data into CloudWatch.
2. Perform testing over the user list to determine the completeness and accuracy of the list generated (for example, review query language to determine that no users have been inappropriately excluded).
3. Select a sample of individuals Based on the number of access additions/changes over the period. For the sample selected:
4. Inspect evidence that approval was obtained before access was granted.
5. Inspect evidence that the appropriate personnel approved.

 

1. Obtain and inspect the list of terminated or departmental transfer users from the Human Resource management department. Determine if the termination or transfer date from one department to another is available and accurate in the listing. Use AWS services to obtain the list as follows:
2. AWS users – Analyze AWS CouldTrail logs for IAM user deletion event to determine the

     de-provisioned user.

1. Federated users – Based on implemented AWS architecture.
2. Determine if management uses AWS Directory Service, then obtain AD event logs from CloudWatch.
3. Determine if management uses AWS single sign-on service, then obtain logs from CloudWatch.

iii. Determine if management manages the AD without using AWS services, then obtain logs from on-premises AD. If management manages AD without an AWS service, Kinesis Agent for Windows (KAW) can feed data into CloudWatch.

2. Perform testing over the user list to determine the completeness and accuracy of the list generated (for example, review query language to determine that no users have been inappropriately excluded).
3. Select a sample of individuals based on the number of terminations/transfers over the period. Inspect CloudTrail logs to assess IAM user deletion events and related details such as time stamps, user IDs, etc. For the sample selected:
4. Determine system credentials are removed when user access is no longer authorized on a

     timely basis (refer to the user list mentioned in step #2.

 

1. Obtain evidence of the periodic user access review retained by management.
2. Obtain an understanding of how management gains assurance over the completeness and accuracy of the review.
3. For example, if a query generates a list of users for review, regular expression, etc.
4. Inspect the review artifacts to:
5. Determine that it was performed by the appropriate personnel (for example, someone with sufficient understanding of the system listing and associated access types) and at the right level of precision (for example, is there enough information in the review to determine what access each user has? Is there enough information to determine who has access to generic accounts?).
6. Determine if the reviewer(s) requested any modifications. If so, inspect evidence that appropriate action (removal, modification) was performed.
7. Inspect the review artifacts to determine that the review was performed promptly, including any access modifications requested by the reviewer. Inspect the review artifacts to determine that there were no cases of self-review (that is, the reviewer is not responsible for signing off on their access). Note: The reviewer is blocked from approving their access.
8. Inspect the review artifacts for evidence of approval.

 

1. Inspect AWS configurations and validate the system is configured to enforce multi-factor authentication for user and root accounts. Specifically:
2. Click on Services >> Click IAM >> Under the Access Reports, click the Credential report >> Click the Download Report button
3. For root and any other user, if “password enabled” = true, ensure “mfa_active” is also true
4. For federated Roles, include a check-in trust policy for MFA. Use eduPersonAssurance SAML Attribute. Determine rules set up in AWS Config service to monitor changes to MFA policies. If there is a change in AWS Config monitoring rules for MFA configuration, then:
5. Determine the applicability of the AWS SSO service. If applicable, then determine the MFA settings by accessing AWS console >> open SSO console >> choose Settings >> choose Configure. Further, verify that “Always On” or “Context Aware” fields are selected to enforce MFA.
6. For AWS-managed MFA, Config is set to alarm via CloudWatch if MFA is not configured.
7. For AWS-managed AD, CloudTrail and CloudWatch (for alarming) can be set to alarm to monitor MFA changes.

 

1. Obtain evidence of the periodic role permissions review.
2. Evidence could be of the review being performed in a spreadsheet, via email, and so on.
3. Ensure the review of policies regarding roles in the AWS console (or via API).
4. Obtain an understanding of how management gains assurance over the completeness and accuracy of the review (for example, does management review parameters used to generate the access listing?).

The auditor should compare change approvals with logs – Config or CloudTrail and CloudWatch (alarms) logging.

3. Use AWS Policy Simulator (API or console) to test the level of access granted by the policy or use IAM Access Analyzer or Advisor

Verify that role assignment follows the principle of least privilege. At least annually, definitions of role permissions are extracted and reviewed to ensure that each role is defined per this principle.

 

1. Obtain evidence of the periodic role permissions review.
2. Evidence could be of the review being performed in a spreadsheet, via email, and so on.
3. Ensure review of policies over roles in the AWS console (or via API).
4. Obtain an understanding of how management gains assurance over the completeness and accuracy of the review (for example, does management review parameters used to generate the access listing?).

The auditor should compare change approvals with logs – Config or CloudTrail and CloudWatch (alarms) logging.

3. Use AWS Policy Simulator (API or console) to test the level of access granted by the policy or use IAM Access Analyzer or Advisor.
4. Inspect the review artifacts to determine:
5. Review was performed by the appropriate personnel (for example, someone with sufficient understanding of the system listing and associated access types) and at the right level of precision (for example, is there enough information in the review to determine what access each role has?).
6. If the reviewer(s) requested any modifications, inspect evidence that appropriate action (removal, modification) was performed.
7. The review was performed promptly, including any access modifications requested by the reviewer.
8. Evidence of approval (for example, signature).

 

1. Inquire with management to understand preventative or detective guardrails implemented to restrict and monitor usage of root account activity.
2. Inspect whether guardrails are implemented per management’s expectation. If implemented, assess their status of compliance. Preventive guardrails can be either enabled or not enforced; detective guardrails can be either explicit, in violation, or not enabled.
3. AWS provides standard rules to enable and protect root user accounts, such as the “Guardrails rule preventing the creation of access keys for the root user.” The Auditor should look for custom guardrail rules that management has implemented.
4. Obtain evidence of the user access review.
5. Obtain an understanding of how management gains assurance over the completeness and accuracy of the review (for example, does management review parameters used to generate the access listing?).
6. Inspect the review artifacts to determine:
7. that it was performed by the appropriate personnel (for example, someone with sufficient understanding of the system listing and associated access types) and at the right level of precision (for example, is there enough information in the review to determine what access each user has? is there enough information to determine who has access to generic accounts? etc.).
8. If the reviewer(s) requested any modifications, inspect evidence that appropriate action (removal, modification) was performed.
9. that the review was performed promptly, including any access modifications requested by the reviewer.
10. that there were no cases of self-review (that is, the reviewer is not responsible for signing off on their access).
11. evidence of approval (for example, signature).
12. Review systems configurations to determine that the root user account is secured and has not been used over the period. Specifically, click on services >> IAM >> Credentials report >> download the report. Check if there is a last login date for the root account.

Data Security and Privacy

1. Understand management’s approach to data governance and how data classification is performed.
2. Ensure that there is an awareness and documentation of where exactly sensitive data is stored and how it is transmitted across applications, databases, servers, and network infrastructure.
3. Verify alignment with defined retention periods and end-of-life disposal requirements.
4. Data protection controls are in place to guard against unauthorized use, access, loss, destruction, and falsification.
5. Obtain and inspect data governance/classification policies and procedures.
6. Review to determine if the relevant topics identified through inquiry are covered at an adequate level of detail to allow for a practical data classification assessment.
7. Based on the frequency with which data classification assessments are performed, select a sample of data classification assessments performed by management. Inspect the review artifacts to determine the following:
8. that the sample data classification assessment(s) were performed promptly and by the appropriate personnel (based on frequency and ownership established by policy)
9. that the data classification assessment is for evidence that an inventory of where sensitive data is stored and transmitted was included and reviewed, and any necessary updates were documented promptly.
10. that data was classified per company policy.
11. Management reviewed the alignment with the retention period and disposal/deletion, and the items that did not align were tracked to resolution.

 

1. Inquire with responsible and accountable individuals to verify the following:
2. Mechanisms used to facilitate the connection from the on-premises environment to the AWS environment, including:
3. Access to the AWS environment via the network
4. Access to the AWS environment via remote connection (if applicable)

iii. Policies and procedures govern the administration of the technology identified to support connections to the AWS environment.

2. Obtain a list of:
3. Setups for infrastructure services approved by management.
4. Encryption implementation and changes for the period.
5. Obtain assurance over the completeness and accuracy of the list of encryption implementation/changes for the period (for example, no inappropriate filters, parameters, or exclusions).
6. For the sample selected:
7. Inspect that implementation and changes were designed, reviewed, approved, and tested per company policy.
8. Observe that there’s evidence that encryption technology is used to connect to the AWS environment both remotely and via the network.
9. Inspect the encryption technology configurations for evidence that the technology is configured per policies.

 

1. Inquire with management to obtain an understanding of the existing policies and standards in place for encryption key management, including the frequency with which the specification and standards document is reviewed and who is responsible for performing that review
2. Obtain essential management specification standards and policy documents and inspect whether key topics are incorporated and formally documented. Some of the key issues may include:
3. Encryption key management requirements,
4. Cryptographic practices,
5. Crypto-periods and key rotation,
6. Key storage and protection mechanisms for cryptographic information at rest and in transit,
7. Key distribution and access,
8. Key accountability and audit,
9. Key archive, backup, and recovery,
10. Key compromise and recovery,
11. Key revocation and destruction, and
12. Authentication mechanisms are configured and in place to ensure critical material confidentiality.
13. Inspect to determine whether a periodic review and updates have been performed and signed off at least annually by the authorized reviewer.

 

1. Inquire with management to obtain an understanding of the periodic review process in place, including:
2. Various security roles and permissions configured within AWS.

KMS that allows users to define usage policies, manage keys, and administer AWS KMS

1. How does management determine that the individual(s) responsible for review are sufficiently competent to understand and interpret access to key management, and how does management address the risk of self-review?
2. Obtain a complete population inventory of relevant KMS key policies, explicitly reviewing the last modification date. This includes identity and access management (IAM) policies where AWS KMS permissions are granted. Select a sample of AWS KMS key policies modified during the audit review period.
3. If the key policy was modified during the audit period, request evidence that the modification was reviewed/approved by the authorized policy owner.
4. For all selections, inspect the configuration to determine that it is aligned with management expectations. Some of the key considerations may include:
5. Are IAM policies enabled to enforce the principle of least privilege? If so, are these IAM policies configured to be consistent with management expectations? What users, groups, and roles have been attached to the customer master keys (CMK)?
6. Is the key policy attached to the CMK defined to limit the use and management of the key consistent with management expectations?

iii. Is the key limited to only specific AWS services?

1. Is access to update/change the key policy limited to authorized individuals?
2. Are CMK grants being used? Do these follow management policies?
3. Is CMK auditing enabled in CloudTrail to allow for management monitoring?

vii. Are CMK key tags being applied to enable visibility/monitoring of appropriate usage?

1. For any AWS KMS key policies that do not meet with management policies, obtain evidence (for example, documented risk acceptance, compensating controls, or approval) that an exception to management requirements was made.

 

1. Inquire with management to understand crypto-periods defined per specific key types and processes.
2. Obtain and inspect a sample of periodic reviews completed by management to determine the following:
3. A system-generated and complete listing of in-scope key types is included for review, including evidence of key rotation validated by management.
4. An authorized reviewer performs the review promptly.
5. The review incorporates existing key types and whether they are rotated per the defined crypto-period and rotation intervals established.
6. The selection of datasets is included in the review to validate that they are encrypted according to the policy.
7. Discrepancies identified are tracked to resolution.
8. Inquire with management to obtain an understanding of relevant production deployment templates for the environment.
9. Include inquiry to determine how management identifies relevant privacy requirements to assign the appropriate region, apply relevant encryption configurations, and manage access permissions consistent with these requirements.
10. Obtain company policies regarding approved configurations for the given regions.
11. For each relevant production deployment template type (for example, all Amazon RDS deployments, all Amazon DynamoDB deployments, and so on), select a sample (for example, CloudFormation/Terraform) for inspection.
12. For each sample selected, determine that the deployment templates have been set up in permissible locations, consistent with policies, to verify alignment with regulatory and legal requirements (AMI, Region, instance size, encryption models, and so on).

 

1. Obtain an understanding of management’s review (for example, level of precision, who performs, how frequently, relevant legal/regulatory requirements, and so on)
2. Based on the frequency of review performed by management, request a sample of reviews
3. Inspect the sample for the following:
4. Evidence that all relevant systems/services have been reviewed within the assessment period.
5. Evidence that the reviewer inspected the relevant configuration setups to determine their appropriateness based on legal and privacy requirements.
6. For misaligned instances, obtain evidence that the misalignment was researched and resolved promptly.
7. Evidence of sign-off by an appropriate approver

Network Management

1. Obtain evidence of the business requirements and network design documentation.
2. Obtain an understanding of how management gains assurance over the completeness and accuracy of documentation.
3. Inspect the review artifacts to determine:
4. That documentation review was performed over all relevant configurations, as defined by the company policy and by the appropriate personnel (for example, someone with sufficient understanding of the configurations subject to review), at the right level of precision and promptly.
5. If the reviewers requested any modifications, inspect evidence that appropriate action (configuration update) was performed.
6. Evidence of approval.

 

1. Obtain a list of permitted data flows to verify the AWS services are used according to the principle of least privilege. Obtain review evidence from the following cloud services that control data flow and network connectivity:
2. Amazon VPC,
3. Amazon CloudFront,
4. AWS WAF,
5. Amazon Route 53, and
6. Elastic Load Balancing.
7. Examine relevant AWS infrastructure service configurations. Obtain an inventory of deployed network configurations (VPCs, Subnets, security groups, NACLs, PrivateLinks, S3 access control lists, WAF, and so on) and inspect for compliance with stated company policies for network access. For example:
8. If AWS Firewall Manager is deployed, use that to help gather firewall configuration information.
9. Determine the current VPC configuration (Classless inter-domain routing [CIDR]) range, subnets, route tables, and gateways to external networks (Internet/NAT/PrivateLink/VPC Peering/AWS GlobalAccelerator).
10. Determine if there is an AWS Transit Gateway. If so, what other networks does it allow routing access to?
11. Examine other AWS services attached to the VPC as an Elastic Network Interface. These must also be in scope and have a VPC security group configuration.
12. EC2 instances – what is the routing configuration for their subnet? What security groups are attached to them?
13. Load balancers – what ingress rules do they have? What ports on the EC2 instances can they forward to?
14. Inspect management’s risk assessment and mitigation plan for policy deviations.

 

1. Obtain evidence of the annual configuration review.
2. Obtain an understanding of how management.
3. Gain assurance over the completeness and accuracy of the review (for example, inventory of AWS networking infrastructure, including VPCs and components like route tables, NACLS, security groups, and so on, as well as the associated configurations).
4. Determine the configuration requirements (for example, company security policy and the latest list of configuration setting standards) to be used in the review.
5. Inspect the review artifacts to determine:
6. That review was performed over all relevant configurations, as defined by company policy (for example, VPCs route tables, security groups, NACLS, PrivateLink endpoints, monitoring services), by the appropriate personnel (for example, someone with sufficient understanding of the configurations subject to review), at the right level of precision, and promptly, including any configuration modifications requested by the reviewer.
7. If the reviewers requested any modifications, inspect evidence that appropriate action (configuration update) was performed.
8. Evidence of approval.
9. Evidence of completeness – Each network security-related change recorded by AWS Config should have a corresponding configuration change review.

 

1. Obtain evidence of the quarterly AWS Config logs review.
2. Obtain an understanding of how management gains assurance over the completeness and accuracy of the review (for example, is AWS Config logs integrity configured? Are logs appropriately protected from change?).
3. Inspect the review artifacts to determine:
4. That the review was performed by the appropriate personnel, for example, someone with sufficient understanding of the logs and associated configurations; and at the right level of precision, for example, is there enough information in the review to determine each configuration change, and who made the change; and promptly, including investigation of unauthorized changes identified by the reviewer.
5. If the reviewers identified any changes made by an unauthorized user or process, inspect evidence that appropriate action (investigation, impact analysis, configuration modification, and so on) was performed.
6. Evidence of approval
7. If the reviewers identified any changes by unauthorized users or processes, inspect evidence that appropriate action (investigation, impact analysis, configuration modification, and so on) was performed.
8. Evidence of approval.

 

1. Verify relevant AWS services are enabled and appropriately configured.
2. For relevant services that are enabled, inspect a sample of activity to make sure that alerts and logs are being captured.

 

1. Obtain management’s procedure for monitoring, detecting, investigating, and resolving network incidents (Incident Response Process).
2. Request and inspect logs and events in Amazon CloudWatch and Amazon GuardDuty to identify whether any relevant network incidents occurred during the period. This includes AWS Flow Logs and other relevant AWS log sources, such as WAF logs.
3. If incidents occurred, request evidence (for example, ticket, email, and so on) of management investigation and resolution, including review and approval by an authorized owner and evidence that follow-up activities were actioned.

 

1. Obtain network architecture and understand DDoS protection and resiliency controls.
2. A resilient and secure DNS such as Route 53 should be used to resolve domains related to the solution. AWS Shield Advanced should be enabled for Internet-facing resources requiring DDoS protection. This includes:
3. Amazon CloudFront distributions,
4. Internet-facing Elastic Load Balancers (ELBs), and
5. Elastic IP addresses.
6. The VPC architecture should follow AWS best practices for resiliency, for example, those detailed in the Amazon VPC best practices documentation.
7. Multiple AWS Availability Zones (AZs) are used for high availability.
8. Elastic Load Balancers distribute traffic among EC2 instances across multiple Availability Zones and EC2 instances behind ELBs, configured in an auto-scaling group set to increase EC2 capacity when required.
9. Database components are designed to withstand network attacks, for example, by increasing capacity if there is an increased load. This can include a design that can accommodate adding read replicas, enabling multi-AZ failover, or using database caching technology to lessen database load during an attack.

Configuration Management

1. Obtain the most recent configuration management policies and procedures from management.
2. Inspect the policy documentation to determine the following:

• Determine if the documentation contains the configuration requirements for all systems, services, or platforms. For example,

Assess whether AWS CloudFormation templates and stacks are used to manage and automate configuration requirements and whether there are resource tagging requirements for AWS CloudFormation.

Assess whether AWS OpsWorks is used to manage and automate configuration requirements.

You want to make sure that the CSC manages its configurations using an automated and repeatable toolset with appropriate change controls (potentially a Git workflow) for updates and inclusion of tagging requirements.

• Determine if configuration ownership is included in the documentation. Ownership may be indicated through tagging or account structures.
• Determine if configuration access and change management requirements are included in the documentation. Who can update configurations (who has access), and how is that managed? How are configurations updated (for example, is there a Git workflow, formal approvals, or other processes)?

3. For more detailed standards and procedures, determine if standards and procedures are defined for specific AWS services that your company uses, such as AWS IAM, AWS Key Management Service (AWS KMS), Amazon Simple Storage Service (Amazon S3), Amazon EC2, and Amazon EBS. The following are examples of some of the areas you can assess.

• For Amazon EC2, determine whether there are instance-sizing requirements and definitions (t2.micro, t2.medium, c4.xlarge) and whether there are auto-scaling configuration requirements.
• For the Amazon S3 standard, determine whether there are requirements for allowed storage class and encryption methods (for example, encryption is required using AWS KMS). Also, determine whether requirements are defined for public access restrictions and access control list requirements.
• For Amazon EBS, determine whether Amazon EBS types are allowed (magnetic, throughput optimized, GP2) and whether there are encryption requirements (for example, encryption is required using AWS KMS).
• For AWS Config, determine whether there are managed rules, custom rules, and cross-account sharing requirements.

 

1. Understand relevant configuration rules management sets to automate or enforce continuous monitoring. Ensure the AWS Config service has been enabled for the services/resources in scope for the audit.
2. Obtain a copy of management’s policy for configuration monitoring (for example, who is responsible for review/resolution of non-compliance, what configuration thresholds/settings are required, and so on) (instructions for reviewing AWS Config reports), (procedures to be performed for all relevant rules in scope for the assessment).
3. Review the AWS Config reports for all relevant rules.
4. In the AWS Management Console, navigate to AWS Config.
5. In the left navigation pane, select Rules.
6. On the Rule page, choose the rule’s name evaluating your relevant resources.
7. Select the resources from the Resources evaluated table on the Rule details page.
8. Compare a sample of non-compliant events with the notifications received.
9. From the Resource actions menu, select Compliance timeline.
10. In the compliance timeline, evaluate the compliance of the selected rules over the observation period.
11. Compare non-compliant events with notifications received.
12. Select a sample of the non-compliance notifications and inspect evidence that instances of non-compliance were reviewed and actioned by management.

 

1. Obtain evidence of management’s change review performed before deployment based on the policy requirements.
2. Ensure you understand how management ensures the review’s completeness and accuracy. For example, how does management ensure that all changes are performed per their change management process?
3. Inspect the evidence you’ve gathered to determine the following:

• The review was performed by the appropriate personnel, for example, someone with a sufficient understanding of the systems and associated configurations.
• The review was performed at the right level of precision; for example, there is enough information to determine each configuration change, appropriate backout or rollback procedures, and transparent information about who made the change.
• The review was performed promptly, and the unauthorized changes identified by the reviewer were investigated promptly.
• Whether one or more reviewers identified any changes by unauthorized users or processes. If such changes were identified, you should inspect the evidence that the appropriate action (investigation, impact analysis, configuration modification, and so on) was performed.
• Is there evidence that the review received the approval of management?

 

1. Open the AWS Management Console and navigate to AWS Config.
2. On the left navigation pane, select the Aggregated Rules (or select Rules if they are not aggregating AWS Config to another account).
3. Select the rule’s name on the Aggregated Rules or Rules page and evaluate your relevant resources.
4. On the Rule details page, select the Required-Tags rule.
5. On the Resource actions menu, select Compliance Timeline. The compliance timeline is displayed.
6. Obtain a population of the non-compliance events for selected rules over the audit period.
7. Select a sample of non-compliant events and inspect that evidence to determine that management has taken corrective action (such as tagging respective resources).

 

1. Obtain an understanding of how management has designed the tagging requirements for AWS resources, including what information is required, what types of tags are used, who is responsible for tagging, who reviews the tagging classification, what the approval process is, how policies and procedures for setup are documented, and so on.
2. Based on the frequency of review performance, select a sample and obtain evidence that the CSC’s management did the following:

• Obtained a complete and accurate list of relevant resources for review (consider the parameters used to generate system lists, the process for adding to manual lists, and so on).
• Inspected that the list is consistent with policies to determine that each resource is tagged per the resource structure and requirements.
• We ensured that evidence of research and resolution existed for any non-compliance instances (instances where no tags or the wrong tag is assigned).
• Evidence of authorized approval within the review period.

Vulnerability Management

1. Obtain an understanding of how management evaluates patches released by AWS to determine whether they are relevant and required for the environment (i.e., perform a periodic assessment).
2. Obtain evidence of management’s periodic assessment to identify and obtain a population of relevant security patches and updates.
3. Obtain an understanding of how management gains assurance over the completeness and accuracy of the population (e.g., inventory of AWS resources and the associated required patches).
4. Inspect evidence to determine that the assessment and application of patches were performed promptly.
5. Select a sample of patches applied during the period and obtain evidence demonstrating that implemented patches were appropriately tested and approved before migration to production.

 

1. Inspect the CloudWatch notification configuration to determine that:
2. CloudWatch is configured to generate automated notifications to management in case of non-compliant VMs.
3. Notification groups are appropriately configured to notify responsible personnel.
4. Based on the number of alerts, select a sample and inspect the evidence that management investigated and resolved them.

 

1. Understand how the intrusion prevention system, vulnerability detection application/software, and data loss prevention application/software have been configured to identify potential security issues in existing systems, services, or platforms.
2. Inspect the intrusion detection system, vulnerability detection application/software, or data loss prevention application/software configurations to determine whether they are configured to detect activity from potentially malicious code within cloud systems, services, or platforms and generate automated alerts for detected issues.
3. Determine whether the automated alerts are configured to notify appropriate personnel (as defined per the company’s policy) for timely investigation and resolution.

 

1. Obtain an understanding of how management evaluates patches released by AWS to determine whether they are relevant and required for the environment (i.e., perform a periodic assessment).
2. Inspect evidence to determine whether the population is complete and accurate (e.g., inspect the parameters used to generate the population).
3. Select a sample of identified events and inspect the evidence to determine that management investigated and followed up to the resolution, as applicable, in line with the Company’s policy.

 

1. Understand the vulnerability detection application/software and the configuration or rule sets to identify security issues in code changes before deployment to production.
2. Inspect the configuration to determine that the software requires all code to be evaluated for security issues before deployment to production and that the vulnerability detection configuration aligns with management’s requirements.
3. Obtain a population of all relevant security issues identified by the vulnerability application/software during the audit period.
4. Inspect evidence to determine whether the population is complete and accurate (e.g., inspect the parameters used to generate the population).
5. Select a sample of identified security issues and inspect the evidence demonstrating that management has investigated and followed up to resolve the issue.

 

1. Obtain evidence of the periodic penetration test review.
2. Understand how management gains assurance over the completeness and accuracy of the test (e.g., inventory of AWS infrastructure).
3. Inspect the penetration test review to determine whether the results review was performed overall and relevant to the customer’s AWS infrastructure.
4. Inspect the penetration test results, and if any security issues were noted, request evidence demonstrating that a remediation plan was implemented and assigned to an owner responsible for following it to resolution.
5. Inspect the penetration test results to determine whether they have been completed promptly and approved (e.g., by signature, ticket, or email) by authorized stakeholder(s).

User Device Management

1. Inspect AWS configurations and validate the system is configured to enforce multi-factor authentication for remote users to access the corporate network.
2. Click on Services >> Click IAM >> Under the Access Reports, click the Credential report >> Click the Download Report button.
3. For root and any other user if “password_enabled” = true, ensure “mfa_active” is also true.
4. Another way to check is in the AWS Management Console, open

SSO console >> choose Settings >> choose Configure >> verify Always On or Context Aware is selected.

1. Also use AWS Config to monitor the MFA settings.
2. To check the MFA status of a root user:
3. Sign in to the AWS Management Console with your root user credentials and open the IAM console at https://console.aws.amazon.com/iam/.
4. Check under Security Status to see whether MFA is enabled or disabled.

iii. If MFA has not been activated, your root user displays an alert symbol next to Activate MFA.

1. To check the MFA status of IAM users:
2. Open the IAM console at https://console.aws.amazon.com/iam/.
3. In the navigation pane, choose Users.

iii. If necessary, add the MFA column to the user’s table by completing the following steps:

1. Choose the settings icon above the table on the far right.
2. In Manage Columns, select MFA.
3. Choose Close to return to the list of users.
4. The MFA column tells you about the enabled MFA device.
5. If no MFA device is active for the user, the console displays Not enabled.
6. If the user has an MFA device enabled, the MFA column shows the type of device enabled with a value of Virtual, U2F Security Key, Hardware, or SMS.
7. Observe unsuccessful login attempts (each iteration of a failed attempt as determined by predefined lockout thresholds, for example, one failed attempt vs. multiple) and confirm that user lockout occurs based on the defined configuration.

 

1. Use AWS Config to obtain a population of all role modifications/creations during the coverage period.
2. Select a sample based on the number of role additions/changes over the period. For the sample selected:
3. Inspect evidence that approval was obtained before role creation or modification.
4. Inspect evidence that the appropriate personnel approved.

 

1. Obtain management’s procedure for monitoring, detecting, investigating, and resolving network incidents (Network Incident Management Process).
2. Request and inspect logs and events in Amazon CloudWatch and Amazon GuardDuty to identify whether any relevant network events occurred during the period. This includes Amazon CloudWatch Logs and other relevant AWS log sources, such as AWS WAF logs.
3. If incidents occurred, request evidence (for example, ticket, email, etc.) of management investigation and resolution, including review and approval by an authorized owner and evidence that follow-up activities were actioned.
4. Obtain an understanding of device issuance and user assignment process.
5. Obtain a list of devices issued to users from the device inventory system and confirm that all active devices are maintained within the inventory system with unique device IDs, issue dates, and individual user IDs.
6. Inspect the device issue log to determine that each device is assigned to an active user ID only by reconciling to the active user listing (if any discrepancies are noted, determine if there is a valid business rationale).
7. Select a sample of devices from the log and obtain associated service tickets. Inspect the tickets for evidence of device ID, issue date, and user ID, and compare them to the system log.
8. Obtain an understanding of the device registration process. Observe a new device registration and validate that network access is denied without registration of the user’s network credentials.
9. Obtain an understanding of how management evaluates patches released by AWS to determine whether they are relevant and required for the environment (that is, perform a periodic assessment).
10. Obtain evidence of management’s periodic assessment to identify and obtain a population of relevant security patches and updates.
11. Obtain an understanding of how management gains assurance over the completeness and accuracy of the population (for example, inventory of AWS resources and the associated required patches).
12. Inspect evidence to determine that the assessment and application of patches were performed promptly.
13. Select a sample of patches applied during the period and obtain evidence demonstrating that implemented patches were appropriately tested and approved before migration to production.
14. Obtain an understanding of how management evaluates patches released by AWS to determine whether they are relevant and required for the environment (that is, perform a periodic assessment).
15. Obtain evidence of management’s periodic assessment to identify and obtain a population of relevant security patches and updates.
16. Obtain an understanding of how management gains assurance over the completeness and accuracy of the population (for example, inventory of AWS resources and the associated required patches).
17. Inspect evidence to determine that the assessment and application of patches were performed promptly.
18. Select a sample of patches applied during the assessment period and obtain evidence demonstrating that implemented patches were appropriately tested and approved before migration to production.
19. Obtain the CSC’s most recent user device security configuration management policies and procedures.
20. Inspect the policies’ documentation to determine whether they include:
21. Security configuration requirements for devices used,
22. Security configuration ownership, and
23. Security configuration access and change management requirements.
24. Inspect if the policies are reviewed/approved within one year (i.e., current policy).
25. Inspect the policies to determine if the reviewer was appropriate to perform the review (i.e., sufficiently competent).
26. Obtain an understanding of relevant rules set by management to automate/enforce scans and periodic monitoring of issued devices.
27. Obtain a copy of management’s policy for compliance monitoring (for example, who is responsible for reviewing/resolving non-compliance, what configuration thresholds/settings are required, etc.).
28. Inspect AWS IoT Device Defender to check all relevant automated configurations and determine that computerized alerts are sent to AWS IoT Console, Amazon CloudWatch, and Amazon SNS.
29. Obtain a complete list of all alerts for the period and select a sample. For a sample of notifications, inspect evidence that management reviewed and actioned instances of non-compliance according to the policy’s defined criteria.
30. Obtain an understanding of relevant rules set by management and inspect configuration to determine how alerts have been set up for each instance of non-compliance of the user devices (i.e., at a device level).
31. Obtain the security management policy and review the predefined thresholds/time frames in place (for example, the priority level dependent on instances of non-compliance).
32. Obtain a population of alert notification logs for the period. Select a sample of the non-compliance notifications and inspect evidence that management reviewed and promptly took action on non-compliance as per the security management policy in place.
33. For any long-standing alerts noted, confirm understanding of why resolution has not occurred and inspect evidence that management is doing follow-up.

Logging and Monitoring

1. Obtain management’s policies and procedures over logging and monitoring.
2. Inspect the policy documentation to determine whether it includes:
3. logging and resolution requirements for different systems/services/platforms used,
4. logging and monitoring ownership, and
5. logging and monitoring configuration access and change management requirements.
6. Inspect if the policy:
7. It is reviewed/approved at the company’s required frequency.
8. Is reviewed by the appropriate reviewer.
9. Understand how management determines the required configuration.
10. Obtain the policy and procedure documentation and the build document that outlines the expected configuration definition.
11. Inspect logging configuration is set in CloudTrail and VPC Flow Logs to monitor events.
12. Request and inspect the Amazon S3 bucket:
13. configuration to determine if it is configured to store log files.
14. retention policy to determine that S3 is configured per the policy and procedure requirements.
15. Evaluate logging of systems/services/platforms that are appropriately set as outlined in the company’s policy.
16. Obtain evidence of a periodic configuration review related to the collection and retention of logs.
17. Understand how management:
18. gains assurance over the completeness and accuracy of the review.
19. determined the configuration requirements to be used in the review.
20. Inspect the review artifacts to determine that the review was performed:
21. over all relevant configurations
22. as defined by the company policy,
23. by the appropriate personnel
24. at the right level of precision
25. in a timely manner
26. And has evidence of approval
27. Understand how the management configures log and monitoring data to forward to a central location.
28. Request and inspect the data store to determine that logs and monitoring data are collected in compliance with company policy.
29. Understand how management defines events that require logging and analysis. If a formal policy or build document has been created to outline the expected logging and alerting definition, obtain a copy for comparison.
30. Inspect the logging and alerting configurations within AWS Config, CloudWatch, and GuardDuty to determine that they are consistent with inquiries/policies.
31. Inspect the threshold configurations to determine that appropriate thresholds/triggers are established in line with company policy.
32. Based on the number of threshold scenarios, select a sample and inspect that management was notified of events and management performed remediation actions such as clean-up or analysis without exceptions.
33. Obtain management’s procedure for investigation and resolution of incidents.
34. Request and inspect Amazon CloudWatch, AWS Config, or GuardDuty logs to identify whether any relevant events or incidents occurred during the period.
35. If events requiring corrective action occurred, based on the number of the incidents, select a sample and inspect that management performed investigation and resolution, including review and approval by an authorized owner.

Incident Response

1. Obtain the Incident Management policy.
2. Inspect the policy for evidence of approval and distribution to all employees consistent with management requirements.
3. For example, if the policy supports a Sarbanes-Oxley (SOX) control, the auditor would expect it to be reviewed/distributed at least annually. This may be more or less frequent if the policy supports a compliance requirement.
4. Validate AWS configurations
5. If AWS service configurations are not already validated with another control, ensure that the monitoring tool and service configurations mentioned in the policy are correctly configured. For example, logging should be enabled on monitored services, and alerts and notifications should be set up correctly.
6. Obtain evidence of the periodic (for example, quarterly) incidents review.
7. Obtain an understanding of how Management gains assurance over the completeness and accuracy of the review (for example, does the reviewer inspect parameters used to generate the Incidents log from GuardDuty, CloudTrail, etc., to determine if no relevant data is excluded?).
8. Inspect the review artifacts to determine
9. That the review was performed by the appropriate personnel (for example, someone with sufficient understanding of the incident response procedures) and at the right level of precision (i.e., is there enough information in the review to determine which attributes were evaluated by the reviewer: root-cause analysis, response, and resolution in line with the AnyCompany Restaurant’s policy?).
10. Was the review performed in a timely manner, including investigating and resolving deviations from the incident?

The reviewer identified the response policy.

1. Whether approval was evident.
2. Understand how management determines required configuration (for example, triggering events and remediation responses). Obtain a policy and build document (should management maintain standalone build documents) that outlines the expected configuration definition.
3. Inspect the configuration of auto-remediation setup (i.e., AWS Config rules definitions) within AWS Config to determine that they are consistent with inquiries/policies.
4. Inspect the threshold configurations (for example, in Amazon CloudWatch) to ensure that appropriate thresholds/triggers are established by policy.
5. Based on the number of threshold scenarios, select a sample and inspect that auto-remediation (for example, through AWS Lambda) is triggered as configured without exceptions.
6. Based on the frequency of the reviews, select a sample and obtain evidence of management’s configuration reviews.
7. Obtain an understanding of how management
8. Gains assurance over completeness and accuracy of the review (types of incidents configured, thresholds, etc.).
9. Determined the configuration requirements to be used in the review.
10. Inspect the review artifacts to determine
11. That review was performed over all relevant configurations, as defined by policy, by the appropriate personnel (for example, someone with sufficient understanding of the configurations subject to review), at the right level of precision, and promptly, including any configuration modifications requested by the reviewer.
12. If any modifications were requested by the reviewer(s). If such requests were made, inspect evidence that appropriate action (configuration update) was performed.
13. Whether approval was evident.

Business Continuity and Contingency Planning

1. Understand how the BIA process is carried out, including but not limited to:
2. Frequency of performance/refresh
3. Who is involved in performing the assessment
4. Who are the key stakeholders (for example, RACI)
5. Who is responsible for final approval
6. What essential requirements are captured as part of the BIA?
7. Obtain a complete listing of business units in scope for the BIA.
8. Select a sample of relevant business units to determine
9. Whether BIAs are completed and requirements are appropriately captured within the template.
10. Whether it defines and prioritizes business processes based on the impact of downtime, including requirements surrounding critical facilities, key personnel, key technology and technology services, and critical vendors.
11. How were the impact thresholds determined, and did they align with overall enterprise risk management thresholds (for example, financial, regulatory, contractual, reputational, and so on)?
12. Whether RTOs and RPOs are documented, correlated to the BIA, and agreed upon by IT, the business, and senior management.
13. Whether BIAs have been formally approved and signed off by key business and IT management stakeholders.
14. First, obtain the BIA list and maintenance criteria, including the established frequency.
15. Obtain a complete listing of BIAs in place and the corresponding refresh schedule, including the frequency.
16. Select some refreshed BIAs to
17. Inspect the evidence of review and updates made to the existing BIAs, including evidence of agreement on any significant changes with the business and IT stakeholders.
18. Obtain approval evidence showing that the corresponding business continuity plan was appropriately updated and approved to reflect any significant updates from the BIA refresh.
19. Document findings
20. Obtain an in-scope list of AWS services.
21. Review the scope of AWS service level agreements (SLAs) to understand the service dependencies, availability, and design goals to align with the business requirements.
22. Review the architecture design, including DR architecture, and calculate SLA to validate that the application architecture meets the RTO and RPO defined by the BIA process.
23. Inquire with management to understand:
24. The formal process and framework (for example, template) in place for completing the DR plan.
25. The process periodically reviews existing DR plans so that critical changes to IT infrastructure, architecture, and dependent systems are tracked and updated in the respective DR plans.
26. Assess the plan development process to determine how stakeholders are involved, including reviewing plans for completeness (e.g., including assumptions, timelines, contacts, and so on).
27. Obtain a population of relevant systems/platforms/infrastructure, select a sample, and inspect DR plans to determine whether one is in place and formally documented.
28. If the plans were updated during (for example, annually). For changes requested as a result of the review, inspect the plans to determine whether changes were made according to the updates from the business and IT stakeholders and ensure that final sign-off and approvals on agreement of the changes are documented.
29. For a selection of DR plans, inspect to determine:
30. It adequately defines the procedures and requirements to activate, run, and support the recovery of dependent systems and IT assets.
31. Whether appropriate stakeholders’ input was captured and final approval and sign-off are documented for each DRP document.
32. Whether DR plans include failback procedures.
33. Identify all stakeholders who need to be updated during disruption. In addition to stakeholders involved in the recovery (such as engineers, technical support, and executives), CSCs should also pinpoint members of their public relations and marketing teams, vendors, third-party suppliers, and even key customers.
34. Inquire with management to understand the testing plan, strategy, and method (for example, tabletop, simulation, parallel testing) adopted by management to periodically test and validate business continuity plans such as disaster recovery, business continuity, pandemic, and crisis management.
35. Obtain a test schedule maintained by management
36. Select a sample of documented test results during the period to assess whether recovery tests were performed as planned, including completeness of scenarios, complexity, depth, and scope as per management requirements.
37. Obtain the test results document to determine whether a review of the testing was carried out and whether final sign-off from authorized stakeholders is documented.
38. Inquire management about the post-mortem process in place and the activities carried out by management after each testing exercise.
39. Obtain a test schedule maintained by management and select a sample of post-mortem reports completed during the period.
40. Obtain and inspect after-action reports to identify gaps and remediation actions tracked by management.
41. For a selection of remediation actions identified, inspect evidence to determine:
42. If remediation has been carried out per the agreed-upon plan and gaps have been appropriately closed.
43. If the testing exercise resulted in BCP and testing program updates, validate whether management has updated and approved subsequent changes.