AWS Cloud
Compute & Storage SOX Control Considerations
As the 2023 KPMG Cloud Transformation survey shows, organizations are rapidly moving application and IT workloads to cloud-hosted platforms such as Amazon Web Services (AWS). Compute services like Elastic Compute Cloud (EC2), Lamba, and Elastic Container Service (ECS) allow organizations to host a wide variety of workloads and processes in the cloud, while database and storage services like Simple Storage Service (S3), Relational Database Service (RDS), and DynamoDB offer flexible, scalable cloud storage solutions.
However, as enterprises reap the benefits of these services, we must work to ensure the unique risk points are being addressed that inherently come with leveraging cloud services. According to the 2023 KPMG Cloud Transformation survey, in 87 percent of respondents’ organizations, auditors or regulatory authorities identified at least two audit issues related to public cloud services in the last year. By considering key public cloud service risks and how they impact an organization’s environment, we can implement effective cloud controls to reduce compliance issues, auditor fees, and damages to business performance and reputation.
Challenge 1: Gauging SOX-related AWS Cloud footprint
Given the vast range and dynamic nature of AWS Cloud service offerings , it can be difficult to inventory these services within our environment to adequately determine SOX relevant infrastructure components. Having a thorough understanding of an organization’s cloud footprint is key to addressing the SOX risks that may arise from these services. Specifically, we must be able to accurately identify critical Compute and Storage infrastructure components that support SOX relevant processes and applications.
To complement the traditional business process walkthroughs which identify SOX relevant technologies that could materially impact financial reporting, AWS Config, an AWS native service, can be leveraged to tag critical SOX resources for visibility, real-time monitoring, reporting, and centralized proactive or detective control implementation across the environment.
Once the initial SOX technology inventory is identified, to begin scoping the breadth of required technology controls, we must consider the nature of resources supporting the organization’s SOX applications. For example, are the resources serverless or comprised of more traditional architecture in the cloud? Is the organization utilizing a monolithic or microservice based Compute architecture? How does the Shared Responsibility Model impact the user entity’s obligations for risk mitigation activities? When we can accurately answer these questions, we can understand the unique cloud risk points within each infrastructure component and design a controls strategy that not only mitigates each risk, but enables compliance at scale across large, segmented environments.
Challenge 2: Access & Session Management in the AWS Cloud
Identity and access management is a key area where SOX-related risks arise in the cloud. Organizations must be able to restrict and monitor access to its production Compute environments and critical Storage resources, which is often challenging given the highly configurable and dynamic nature of AWS resources.
A cloud access management program that leverages leading practices and technologies will facilitate the implementation of strong, proactive controls and reduce the burden on organizations to produce evidence for SOX auditors. To ensure scalability of the organization’s AWS cloud access controls, managing access centrally across the environment is essential. Integrating Compute and Storage resources with a Centralized Access Management (Ex: SailPoint, Okta, Oracle IM, etc.) and Privileged Session Manager (PSM) tools (Ex: CyberArk PSM, HashiCorp, StrongDM, etc.) will allow organizations to centrally manage many of the critical logical access domains, including access provisioning, revocation, user access reviews, secrets management, and more. Federating AWS IAM Roles to Active Directory enables thorough integration with a Centralized Access Management platform to centrally manage provisioning, revocation, and user access reviews.
Leveraging a PSM gives management the ability to govern and control session access to Compute and Storage resources and provides an automated solution for disabling local compute access, key management, and privileged account credential storage. Some PSM solutions can be integrated with the change ticketing system and require a valid Change Order or Incident Ticket be input before granting privileged session access to critical compute resources. Federating PSM access to Active Directory, with integration of those Active Directory groups in your Centralized Access Management platform, further enables centralized governance and compliance at scale.
AWS Cloud makes it simple to assign granular permissions (I.e. API Actions) at the IAM role/policy level for native Compute and Storage resources; however, if leveraging more traditional Infrastructure as a Service (IaaS) architecture (Ex: EC2, ECS with EC2, Oracle on EC2, SQL on EC2, etc.), the responsibility for configuring, securing, and maintaining the logical security of those infrastructure components does not differ from an on-prem environment. Even with native Compute or Storage resources governed through AWS’ native Identity and Access Management service, organizations must ensure there are appropriate controls to govern and restrict access permissions. For example, permission boundaries can be configured at the Organizational Root level through Service Control Policies (SCPs) which propagate to all child objects within the AWS Organization. IAM Roles/Policies should be configured to enforce least privilege, along with a mechanism to prevent or detect IAM Role/Policy “drift” in which permissions for IAM Roles/Policies no longer align with the organization’s permission baselines. Depending on the maturity and capabilities of the respective organization, this can be achieved through automated means or through a more traditional and manual IAM Role/Policy periodic review.
Challenge 3: Ensuring Baseline Security Configurations of AWS Compute Instances
The ability to spin up AWS Compute instances (I.e. EC2, ECS, EKS, EMR) on demand offers greater flexibility and agility compared to traditional on-premises solutions. However, how can we be sure that all the Compute instances in our environment adhere to an organization’s baseline security configurations?
We recommend following the industry leading practice to enforce periodic rehydration of instances with deployment of enterprise-approved Application Machine Images (AMIs). Rehydrating – or refreshing – Compute instances periodically with up-to-date AMIs ensures that the most current baseline security configurations are applied across the organization’s environment. For example, AMIs can contain the PingID agent which is installed on all instances to enforce MFA requirements, or the respective PSM agent that automatically disables local user access and vaults all system accounts. Furthermore, rehydrating periodically limits the potential exposure of an inappropriate change made to a production Compute resource, as that inappropriate change will only persist until the next iteration of rehydration.
Discover more KPMG technology risk insights at visit.kpmg.us/TRMCOE
Explore more
Insight
What you can’t see can hurt you
An 8-step approach to designing, implementing, and improving monitoring capabilities
Insight
Keys to a successful API Management Strategy
Embrace the API-first digital transformation
Insight
Building trust in cloud environments
2023 KPMG Cloud Transformation Survey
Meet our team
