Cloud Compliance Security, Part 1: Understanding Expectations & Building Requirements
Most organizations associate their cloud compliance programs together with governance and risk. Governance, risk and compliance (GRC) programs represent a collection of controls designed to ensure that your organization manages their information security risks appropriately and that your security controls operate effectively. GRC programs work to identify gaps in your cloud security controls and also provide a framework for prioritizing mitigation and remediation activities. Compliance measures the effectiveness of your security controls against relevant security requirements. Put simply, compliance looks for proof that organizations do what they say they do.
Cloud compliance security requirements defined by your internal security policy that is specific to your organization may be subject to external security requirements as well. Most of these security requirements come in the form of third-party audits and assessments. Some of these assessments may be elective, for example the International Standards Organization (ISO) 27001, the Service Organization Control (SOC) 1 and SOC 2, and the Cloud Security Alliance (CSA) Security Trust Assurance and Risk (STAR) program. Organizations pursue these programs for different reasons. Some seek third-party assurance that their program is operating effectively, while others see these certifications as important competitive differentiators. Compliance with elective standards like these is often assessed through third party auditing firms.
Understanding compliance requirements
Some security requirements originate from laws or by specific industries or business verticals, for example the Payment Card Industry Data Security Standard (PCI-DSS) or the Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health Act (HITECH). The PCI-DSS security standard is mandated by the major credit card brands and required if your services processes or stores credit cards. HIPAA and HITECH acts are a United States laws designed to protect individual’s electronic health information and personal identifiable information (PII) from fraud and theft. Your service may fall under HIPAA/HITECH obligations if US healthcare organizations share their patient information with you. Unlike ISO27001 or SOC 1/2 for which you might hire an assessor to certify your service against these standards, HIPAA/HITECH are simply laws your organization must abide depending on jurisdiction.
Security requirements may also be defined by specific groups or types of customers. For example, many United States government contracts require that cloud services and providers (among others) comply with the Federal Information Security Management Act (FISMA) and Federal Risk and Authorization Management program (FedRAMP). FISMA/FedRAMP includes a large set of compliance obligations beyond simply meeting specific security requirements, for example, it also includes a formal risk assessment and requires strict documentation of all service dependencies. FISMA/FedRAMP requires the continuous monitoring of controls and using tools to automate the collection of data from your cloud environments is key.
Automating cloud compliance
To demonstrate compliance with a standard you will likely be asked by your auditors for evidence that your controls effectively meet the defined cloud security requirements. Look for tools that automate these controls to save time and reduce the chance of human error. For example, to show the effectiveness of your role-based access control you might choose to configure a tool to automatically log in to your cloud environment and query and report on the number of users with privileged access. Or, one better, your control might send an alert anytime a new privileged user is added to the environment.
As these examples demonstrate, tools and automation dramatically reduce the time to gather compliance evidence and they often can be modified and extended as your environment changes over time. Auditors also favor cloud security automation because it lowers the chance of human error or omissions when assessing whether a control is effective. This is especially true in an ephemeral containerized environment where containers are continuously being added or torn down and automation is the only way to keep up with these dynamic changes.
Cloud user responsibilities
Customers and cloud service providers (CSP) like AWS, GCP, and <Azure, must clearly understand their control responsibilities and accountabilities to ensure that the entire set of controls protecting the cloud application or service remain effective across the entire stack from the physical layer up through the application layer. In a cloud computing model, a security requirement will likely be met by controls managed by the CSP, the cloud customer, and any partners used by the CSP and customer. Take for example controls designed to meet the security requirements around authentication:
- The CSP that contracts space from a third-party data center will take a dependency on that landlord to correctly authenticate people physically entering the datacenter space and access to critical environments and systems like HVAC and electric power.
- The CSP that uses this datacenter for their on-premises equipment must manage the authentication of the shared network and infrastructure- including lower level remote (out of band) access to network equipment and servers.
- Software-as-a-service (SaaS) providers that are customers of the CSP must manage the authentication to their cloud management console and all the services and applications they provide.
- The SaaS provider might also take dependencies on other services like identity and access management services which in turn must also manage their own authentication controls.
- Lastly, the end consumer of the SaaS application must manage their own authentication to the application.
Even in this basic example it is easy to see that many teams and organizations have an important role to play in ensuring the overall security of the system. A break in any one of these security controls could give an attacker a foothold to break the larger system.