Abstraction on the cloud increases the risk of weak links
The power of the cloud is the ability to offer on demand infrastructure through software, a model that has led to an arms race in CSPs to release the most managed services. The move to greater cloud abstraction mandates moving beyond a reliance on a CSP just for physical security.
Abstraction on the cloud is tied directly to the concept of Shared Responsibility. While a helpful mental model, diving into what that means within the definition of abstraction is a good way to understand Complete Cloud Compliance.
Technological abstractions, in their simplest form, are layers of the technology stack that have been removed from the management of the users of those services. Abstraction is a well-established method in computer science for removing certain details to enable focus on other areas of interest. Abstractions created by CSP managed services remove layers of technology that are necessary for creating and maintaining a certain experience, but, in terms of the direct use of the service, are not relevant to the customer. This is where the “managed” part of “managed services” comes in.
Abstraction jumpstarted innovation around economies of scale, which has been a major driver of modern technological advancement. But the issue with abstraction is its relationship to security and compliance, which must be “full stack” in order to be complete. All parties subject to compliance regimes, like GDPR, must ensure every layer of the technology stack is secured with liability properly outlined. In the cloud world abstraction makes this nearly impossible.
The most common example of abstracted cloud services today are managed databases, or DBaaS, like AWS Relational Database Service (RDS), Azure SQL Database, Google Cloud SQL, or MongoDB Atlas. Managed databases offer pre-built, configurable database instances with built-in redundancy, read and write optimization, scaling, and better performance than most organizations could achieve themselves. Managed services like DBaaS change IT staffing too; gone are the days of contacting the local database administrator to set up and manage a database or a local security officer to verify security configurations.
While managed services, like DBaaS, are simple and powerful in their easy-to-consume design, their black box nature is a prime example of the compliance conflict currently present on the cloud.
During an interview with the popular podcast Software Engineering Daily, in response to why Box chose to run its own Kubernetes cluster and not use a managed Kubernetes service from a CSP, Sam Ghods, co-founder and vice-president of technology, said, “We have to chip away at it piece-by-piece because we have strict compliance requirements around what runs on our servers, what software packages are running and how they are configured that support our code. So, we can’t say, ‘Well, just give us an image that works, and we’ll be good with that.’ We have patching requirements and configuration requirements for the kind of workloads that we run.”
Sam understands the compliance tradeoffs of abstraction. In order for Box to meet the compliance requirements of its highly-regulated customers, Sam and his team needed to control certain parts of Kubernetes that were abstracted away from CSP managed services, like AWS EKS, Azure AKS, and GCP GKE. Not to mention at the time of that interview, some of those managed Kubernetes services weren’t available, and none were backed by the CSP business associate agreement.
With more abstraction, more responsibility resides with the owner of the managed service since the customer doesn’t have as much control by nature of what is abstracted away. Using DBaaS, again: Some compliance requirements, like encryption, might be the responsibility of the managed service provider because the customer may not have the capability to properly configure and monitor encryption. In some cases, like encryption, the responsibility may reside with the CSP customer, but the actual configuration is often done by a developer, not an information security specialist, as has traditionally been the case. Some of the power and value of managed cloud services is the ease of use, opening up new personnel to security and compliance responsibilities.
Each layer of abstraction is a link in the chain of security, compliance, and liability. Applying the concept of weak links within the model of Shared Responsibility, organizations must ensure that every link, or every layer of abstraction for a managed service like DBaaS, is secured and does not expose that organization to undue risk. If a CSP makes a mistake in any layer, like the HVAC vendor in the Target breach referenced above, the integrity of the entire cloud environment is at risk.
The breadth and depth of the cloud
The cloud exposes emergent discrete services as software, not hardware, and that software is consumed on demand to virtual endless scale. The CSPs race to offer evermore services that organizations consume to solve business and technical needs. The names and acronyms are hard to remember, let alone the security and compliance implications of each.
Managed databases are a small sampling of abstracted services available for cloud native architectures. Managed services are available for everything from big data and container orchestration to machine learning and artificial intelligence, with CSPs adding new services at a pace of almost one per week. Modern developers are adopting the new CSP services almost as fast as they are launched, with regulated industries lagging behind, or worse, potentially unaware of the managed services being used by their IT groups and developers. The only way for regulated industries to keep pace is to ensure the configuration of all CSP services meets compliance requirements on a continuous basis.
The cloud, and the breadth of managed CSP services, makes even basic compliance functions more difficult. For example, external audits and internal risk assessments require an inventory of IT systems and services, documented networks, and storage destinations. The cloud has made this a much more dynamic and difficult process. The cloud has even changed the data that needs to be collected, or that can be collected. Oftentimes, the audit templates for IT inventory mandates the collection of certain data such as hardware SKU numbers or information about the operating system and disparate software versions, which is typically not available for the hardware and software underlying CSP managed services. A few simple examples: AWS customers cannot ask AWS for SKU numbers for the servers running the RDS software they use; Azure customers cannot inventory the software installed on servers running serverless compute tasks; customers running machine learning algorithms on Google Cloud hardware cannot request state information of the hardware. This is what Sam Ghods referenced earlier.
To complicate matters more, some CSP services are covered by data privacy agreements, such as business associate agreements for HIPAA and data processing agreements for GDPR, and some are not. The list of services covered by privacy agreements is constantly changing. It’s hard enough for an internal auditor or compliance officer to keep track; it’s not realistic to expect developers and cloud end users to stay current and ensure the services they use are compliant.
With more architectures becoming cloud native, an increased adoption of managed services — and consequently abstraction — is happening, which poses a challenge for a 3C program due to misaligned legal practices.
As one can imagine, compliance programs and liability agreements have not kept pace with the rapid innovation of cloud services. Take AWS for example: The number of AWS services included in the company’s BAA, like RDS or serverless computing, has always been a smaller subset of the total number of AWS services available thus limiting compliant options for healthcare customers. This is no one’s fault, but simply the natural process of compliance catching up to technological innovation. It’s the same scenario found at Microsoft Azure, Google Cloud Platform, and other cloud-based platform or service providers.
Actively developing and updating a list of approved cloud services is essential for every enterprise, as is an inventory of all services in use governed by privacy agreements. The challenge with this essential compliance task is that the inventory list will be highly dynamic, requiring employees or trusted third parties skilled in cloud native technologies.
As architectures move from monolithic to microservice-based, the breadth of compliance concerns expands rapidly.
Focus on the weakest links
Achieving complete compliance of, on, and in the cloud means eliminating weak links in the chain of cloud workloads. The abstraction of the cloud creates many new third-party links via managed services. Employing Complete Cloud Compliance dynamically addresses the compliance implications of each of those new cloud services links. The best approach is to think in multiple dimensions: both depth and breadth of compliance coverage are required for modern compliance management programs to minimize the risk of incidents or the liability of breaches across abstractions. Your compliance posture on the cloud is only as strong as the weakest link in your abstracted cloud chain.
