Blog Continuous Compliance Cloud Enablement
Last updated on February 3rd, 2023 at 5:27pm
Getting cloud resources in compliance with regulations and standards is a must for many organizations. Whether it’s internal or external standards, you’re likely expected to enforce some security measures in the cloud. In fact, on average, organizations comply with 13 different compliance and/or privacy regulations.1
But some of the data around this is not very reassuring. 77% of IT decision-makers believe that they would not pass all of their cloud compliance audits for cloud resources.2 81% of security professionals personally dread when their organization is audited.1 It seems that the majority of IT leaders are lacking in compliance confidence.
That makes sense; it’s a big undertaking to understand, implement, and document the security controls you need to better secure your cloud environment. The sheer number and dynamic state of resources in the cloud make manual tracking a logistical nightmare. NIST 800-171 alone — just one example of NIST’s security standards — includes 110 requirements, and each requirement can apply to multiple resources. And of course, 800-171 is not the only standard in NIST, and NIST is not the only standard there is.
That’s why we’re dedicating a blog article to the discussion of regulations and standards, and how you can simplify the compliance process and restore your compliance confidence.
Types of Regulations and Standards
There are many different external regulations and standards with which you might need to comply. Many are specific to your sector (healthcare, finance, government, etc.). Examples in the commercial and government spaces include:
- Payment Card Industry (PCI) Data Security Standard (DSS) 3.2: The PCI DSS Version 3.2.1 is a standard for entities that process credit cards. It enhances cardholder data security and facilitates consistent data security measures globally.
- National Institute of Standards and Technology (NIST) Special Publication 800-171 Rev. 1: The NIST 800-171 standard defines how non-federal systems and organizations should safeguard and distribute non-classified sensitive material.
- Center for Internet Security (CIS) AWS Foundations Benchmark v1.2.0: The CIS Benchmark for AWS provides best practices to secure cloud accounts.
For more details on standards in the Government space, Increment has a very comprehensive history of cloud adoption, including details on some of the government regulations and standards such as FedRAMP, NIST, FISMA, etc.
In addition, the Office of the Under Secretary of Defense for Acquisition and Sustainment (OUSD(A&S)) is working with the Defense Industrial Base (DIB) sector to enhance the protection of controlled unclassified information (CUI) within the supply chain. The output of this is the Cybersecurity Maturity Model Certification. The CMMC provides multiple maturity levels and is intended to be incorporated into the Defense Federal Acquisition Regulation Supplement (DFARS) as a requirement for contract award.
The CMMC basically provides levels to NIST 800-171 requirements. The five levels consist of practices and processes; CMMC Levels 1-3 encompass the 110 security requirements specified in 800-171.
CMMC is an example of how the government and industry are working together to try to build maturity into broad government standards. AWS provides guidance on how organizations can plan for CMMC.
Obviously, organizations may also have internal rules around cost control, security, and compliance with which they must comply. These may be formally outlined or more informal.
But the question for all of these standards remains: whose responsibility is it to make sure these rules are enforced?
Understanding the Shared Responsibility Model
Cloud providers offer guidance on how their services comply with many published standards. For example, AWS provides a comprehensive matrix regarding the list of AWS Services in Scope by Compliance Program.
But it's important to note this key piece of information from AWS: "If a service is not currently listed as in scope of the most recent assessment, it does not mean that you cannot use the service. It is part of the shared responsibility for your organization to determine the nature of the data. Based on the nature of what you are building on AWS, you should determine if the service will process or store customer data and how it will or will not impact the compliance of your customer data environment."
Simply put, it's on the organization. Just because the cloud provider builds it – for example, the AWS Rekognition service – doesn’t mean you should use it. And the reasons why you maybe shouldn’t use it are many: internal security or compliance concerns, pushback from employees, or ethical implications.
In summary: the shared responsibility model in the cloud is not necessarily clear and it’s certainly not one-size-fits-all. Gartner estimates that “through 2025, 99% of cloud security failures will be the customer’s fault.”3
The Solution to Low Compliance Confidence
Jumpstarts and Cloud Rules
To bridge the gap, cloudtamer.io built compliance jumpstarts. The jumpstarts are available out of the box to help speed adoption and enforcement of standards and regulations. Specifically, jumpstarts provide support in two key ways:
- Customers get a comprehensive mapping of the compliance security controls against cloud provider- and cloudtamer.io-inherent capabilities. The jumpstarts also give customers guidance on capabilities that can be achieved via cloudtamer.io cloud rules.
- Customers get a resource library of pre-defined cloudtamer.io cloud rules, which contain AWS Identity and Access Management (IAM) policies and CloudFormation templates, Azure policies and role definitions, and more. Our AWS cloud rules are even pre-configured to help meet NIST 800-171 and CIS Benchmark standards (with NIST and CIS Azure support coming soon).
In the commercial sector, organizations often struggle to ensure compliance with HIPAA, PCI, and more. We use the same functionality (cloud rules) to let customers define what can and can't be done in the cloud to enforce compliance with these standards and regulations. And we deliver a large reference library of cloud rules to give customers a "leg up" on this process.
And when it comes to internal regulations, our cloud rules come to the rescue again by doing things like:
- Preventing cloud users from spinning up an EC2 instance in AWS that costs more than $1/hour
- Preventing use of particular regions offered by the cloud service provider to keep data and cloud activities 'onshore'
Complying Through Automated Governance
Without a common governance approach across an organization, you’re likely to see misconfigurations (as well as other issues, like inadequate cost tracking and cost overruns). The key is to enable organizations to enforce governance controls that cover both third-party-mandated regulations and internal requirements.
Organizations need flexibility to address their unique needs. They also need governance that doesn’t require a lot of manual effort. We’ve seen many customers implement governance controls with a largely trust-based approach: documentation and acceptable use policies (AUPs) that users simply acknowledge. In other words, they have no assurance that it's actually being enforced.
Automated governance works because you set the boundaries that determine parameters of what a user can and can’t do. Then you get out of the way and let users realize the benefits of governance without impacting the benefits of the cloud (speed, agility, scale up/down flexibility). When users discover that their cloud provider released a new service, instead of immediately using it, they can request access in non-production sandbox accounts while the organization evaluates if the service satisfies the security requirements.
The bottom line: you should feel confident that your cloud can pass an audit. The question is, what are you doing to make that a reality?
1 The Harsh Reality of Audit Fatigue, Telos, 2020.
2 State of Cloud Compliance, Logicworks, 2019.
3 Is the Cloud Secure?, Gartner, 2019.