OCBC, A Cloud Security Governance Framework
A Cloud Security Governance Framework
by Li Lei, December 17, 2022, Guangdong, China
About the Author: Li Lei, Currently employed at an internet company as a senior security expert and head of security for several VB banks. I specialize in cloud security, data security, and security operations. I look forward to creating new opportunities and untapped potential in the field of cloud security.
1. Introduction
Recently, I was chatting with a friend who mentioned that their company is undergoing digital transformation and gradually migrating its business to the cloud. My friend jokingly remarked that security in the cloud and off the cloud is handled by the same person—and that the cloud has everything it needs, so maybe it’s actually more security. Maybe, just maybe, that’s true.
The wave of digitalization is sweeping in, forming a close connection with the cloud. As corporate strategies shift toward the cloud,
At the moment, the business is ready—what about security? Let’s put this issue aside for now and take a look at some data first.
2. Cloud-Based Data Breach Incident
Data 1: 45%
According to figures from the IBM Data Breach Cost Report, 45% of data breaches occur in the cloud. The average cost of a data breach in a hybrid cloud environment is $3.8 million, while the cost of a data breach in a private cloud is $4.24 million, and the cost of a data breach in a public cloud is $5.02 million.
Data 2: Cloud-Based Data Breach Incidents
Based on online sources, I compiled a list of several typical cloud-based data breach incidents that occurred from 2017 to 2022. According to the data, several companies have experienced data breaches in the cloud—including major cloud service providers themselves, such as Microsoft. The volume and sensitivity of the data involved were also extremely high.
In addition, the author has specifically identified the causes of data leaks and the associated cloud products. From this data, the primary causes of data leaks in the cloud are configuration errors or leaks of Access Keys (AKs) and Secrets (SKs), and these leaks are closely linked to commonly used cloud products in the cloud environment. On the other hand, data leaks can occur regardless of whether the cloud is public, private, or hybrid.
Perhaps you’re wondering: Is the cloud itself insecure? Does this apply to all cloud platforms? Is enterprise cloud adoption still secure?
To answer these questions, we first need to clarify: What is the biggest difference between the cloud and traditional IDCs? And why do certain issues—issues that weren’t problems in the first place—become problems once you move to the cloud?
To ensure the accuracy of our description, in the following text, when referring to cloud product names, we will use Alibaba Cloud product names as the reference point; other cloud providers can be similarly interpreted. At the same time, to avoid any misunderstanding, we would like to emphasize that every cloud vendor, at this stage of development, more or less carries some “historical baggage.”
Therefore, enterprises should not abandon cloud adoption simply because of these challenges—choosing the right solution is what truly matters most.
3. Differences Between Cloud and Traditional IDCs
In the author’s view, the biggest differences between cloud platforms and traditional IDCs are primarily determined by the inherent characteristics of the cloud itself and the specific business scenarios of enterprises. These differences mainly manifest themselves in the following ways:
1. Cloud-native
Containers, microservices, K8S, and other such concepts are exclusive to the cloud—novelties that simply don’t exist in traditional IDC infrastructure. Cloud-native transformation fundamentally brings about earth-shattering changes to infrastructure; these cloud-specific services inherently define the unique characteristics of the cloud itself.
2. Product Flexibility
Flexibility refers to the ease of use of cloud products and their ability to support a wide variety of business scenarios. From a business perspective, this is an advantage; however, from a security standpoint, it could very well be a disadvantage. Flexibility means there are many different ways to use these products—and any way you choose could potentially introduce numerous security risks. For example, consider buckets.
OSS buckets support both public and private access modes. However, even private buckets can still lead to data leaks—history has already provided numerous lessons on this.
3. Security Attributeization
Given the flexibility of cloud products, each cloud product needs to independently meet the specific requirements of enterprise use cases while also ensuring a certain level of security. As a result, in addition to the core functionality of the cloud product itself, these products will also come equipped with various security-related features. Let’s continue using the example of buckets: In some scenarios, you might need a particular bucket to be accessible only from a specific IP address (via ACL control) or only by a specific RAM user account (via permission control).
4. Boundary diversification
Another change brought about by the cloud is the diversification of security boundaries—any cloud product could potentially become an enterprise’s boundary in the cloud. For example, with ECS: a small business might only use ECS and nothing else. In this case, ECS could very well serve as the enterprise’s network boundary in the cloud.
5. Streamlined procurement
Due to the aforementioned characteristics of the cloud, some enterprises, when procuring cloud products, do not necessarily purchase all available security products. For example, if a company has dozens of ECS instances, it might only buy a few more SLB and EIP instances and then start providing services externally. In such a scenario, how can security protection be effectively implemented?
The above five typical differences of the cloud mean that we can no longer rely solely on traditional perspectives when it comes to security governance. How can we strike a balance between short-term and long-term needs and elevate the security posture of cloud-native enterprises to a relatively ideal level?
4. OCBC, Cloud-Based Security Governance Framework
I proposes a new perspective—the OCBC, cloud-based security governance framework—to address this issue. OCBC stands for: Operation, Control, Baseline, and Cloud Native Security. The following sections will provide an introduction to the OCBC framework.
4.1 Operations
Operations—or, more specifically, security operations—refer to a process that leverages data (log) capabilities as its foundation, analytical capabilities as its means, and metric capabilities as its measurement tools, thereby achieving a closed-loop risk management system and enhancing both quality and efficiency, while helping to strike a balance between security control and business experience.
In essence, operations focus on detection, which can be structured around four dimensions: data (logs), scenarios, rules, and metrics. Here, drawing on the characteristics of cloud environments, the author will highlight the special aspects of data and scenarios in particular.
4.1.1 Data
On the one hand, cloud application greatly facilitates the acquisition of security data and enables most data to be stored in a unified manner by nature. On the other hand, it significantly reduces the difficulty and complexity of data generalization, thereby saving substantial costs associated with building and operating capabilities.
From the perspective of data sources, cloud-based security data is generated either through cloud security products or by centrally collecting and aggregating data via security tools installed by the enterprise itself—typically, both approaches are used in combination. For example, Alibaba Cloud provides a unified log service called SLS. You only need to enable the corresponding audit log feature in the global configuration of the log audit service. Enterprises can leverage SLS at a relatively low cost to implement basic SIEM functions and capabilities.
Basic data sources such as Action Trail operation audit, OSS, WAF, firewalls, and Cloud Security Center are essentially essential. However, it is particularly worth noting here that the storage of cloud product logs generally needs to be manually enabled. Opening them from different locations may lead to variations in the stored fields, and some critical fields could also increase the complexity of building rules. Moreover, not all data will be available in SLS, nor can it be uniformly aggregated. For example, configuration audit logs, DMS logs, and DW logs—these types of data require special handling in such cases.
4.1.2 Scenarios
The scenarios are categorized based on different dimensions of security risks, facilitating the subsequent development of more granular rules. Globally speaking, cloud-based risk scenarios are divided into data leakage risk scenarios and external attack risk scenarios.
In scenarios involving data security breach risks, particular attention should be paid to the security risks posed by data falling onto uncontrolled endpoints due to the use of big data products such as DW, DMS, and AK. As cloud products, they inherently lack the distinction between the internet and office networks, necessitating special configuration measures.
In scenarios involving external attack risks, particular attention should be paid to the potential security risks that may arise from privately deploying certain cloud products. For example, due to regulatory compliance requirements, privately deploying a cloud product WAF could introduce the risk of HOST header bypass.
4.1.3 Rules and Metrics
Finally, rules are generally the technical implementation of scenario-based risk assessments, while indicators constitute the evaluation system for the first three dimensions. As for practices such as red-blue exercises or crowd testing, these can be categorized as technical methods for indicator validation.
It’s worth noting that operations are not merely an optional pursuit at a certain stage of an enterprise’s security development—they are, rather, a simultaneous consideration right from the start of building cloud-based security for the enterprise.
4.2.Control
Control is one of the core components of security management within the entire OCBC framework. At its essence, control focuses on prevention. Control comprises three components: Border control, Access control, and Bucket control—collectively referred to as the “3 Controls.”
4.2.1 Border control
This refers to implementing robust security controls at the network boundary in the cloud from a cybersecurity perspective. Let me elaborate on the term “border” mentioned here, which carries three distinct meanings:
The first meaning is: Properly implement boundary protection for the outermost layer of cloud-based networks—namely, internet boundary protection.
The second meaning is: layer upon layer forms the perimeter, with controls deployed in depth. Although the cloud blurs boundaries, from the perspective of enterprise network protection, it’s still necessary to define precisely where your security perimeter lies—based on the outermost boundary. The boundary gradually extends inward to the innermost container; any cloud product equipped with access control can be considered part of this boundary.
The third meaning is that within a cloud-based enterprise network, there are boundaries not only between different VPCs horizontally but also between different security groups within the same VPC and between containers. Therefore, it’s essential to properly control these boundaries—namely, VPC boundaries, host boundaries, and container boundaries.
For example, on Alibaba Cloud, you can build layered protection by using WAF, Internet boundary firewalls, SLB, host security groups, and container firewalls. You can also build lateral protection through VPC boundary firewalls and host security groups.
It is particularly worth noting that host security groups are categorized into enterprise security groups and ordinary security groups. The different default security policies directly determine whether ECS instances within the same security group have default network connectivity. Moreover, in practice, security groups lack logging capabilities, which significantly increases the complexity of both usage and troubleshooting when issues arise.
4.2.2 Access control
This refers to the management of permissions for people, applications, and cloud services across all cloud products. It forms the cornerstone of overall access control in the cloud environment.
Typically, cloud platforms offer access control products such as IAM/RAM, which are used to centrally manage access permissions for their own services. Users can leverage IAM/RAM to manage and use the cloud products they’ve purchased. IAM/RAM can be regarded as the central entry point for all permission management in the cloud. Usually, when people think of IAM/RAM, they immediately associate it with the terms “AK/SK,” which are essentially equivalent to the account and password used to access cloud services. AK/SK has a remarkable characteristic: under the premise of no rotation, the SK is known only at the moment it’s generated. Moreover, by default, AK/SK does not possess the boundaries mentioned in the boundary control and management framework. It’s about the concept of “credentials.” Having both an AK and an SK means that you can access the permissions associated with that AK/SK from any terminal, at any time.
The core of access control is, taking IAM/RAM as the center, and adhering to three security principles—categorized management, least privilege, and special-case attention.
Therefore, based on the above reasons and business scenarios, the author categorizes control rights into PRAM, ARAM, roles, and others.
PRAM, or the user account, is a user account permission control system. PRAM can only log in to the cloud console and cannot have any form of Access Key (AK). Among these, ROOT is a special type of P-RAM that has 2FA enabled and is prohibited from use in regular business scenarios and by users—its sole purpose is for special scenarios that only privileged RAM administrators are authorized to handle.
ARAM, also known as AK, is an application account—a user account system centered around applications and designed for application-specific access control. ARAM can only be used by applications, must adhere to specific naming conventions, maintains separate read and write permissions, and is prohibited from logging into the console. Meanwhile, AK adheres to an IP-based and source-controlled security mechanism—specifically, controlling the IP addresses from which AK calls are made and limiting the scope of resources accessed by AK, thereby maintaining the principle of least privilege.
Role is a virtual user with a defined identity that can be assigned a set of permission policies but does not have a fixed login password or access key. A RAM role must be assumed by a trusted entity user. Upon successful assumption, the entity user will receive a security token for the RAM role and can use this security token to access authorized resources as the role. For certain special reasons, any form of role-assumption logic is prohibited.
Other—here, specifically referring to the account and permission control logic within cloud products themselves. Generally, there are two scenarios: one is where P-RAM serves as the account system but not as the permission control system—for example, DMS, DW, and Holergres; the other is where PRAM is not used as the account system at all and instead forms its own independent system—for example, ES, Bastion Host, and Redis.
Given the importance and complexity of access control, and in alignment with the lifecycle management objectives for accounts and permissions—namely, that they be manageable, controllable, auditable, and traceable—we recommend implementing an access-control mechanism through platform-based capabilities. Here, the author provides a brief framework for building unified control and management capabilities for reference.
4.2.3 Bucket control
A bucket is a cloud-specific product—a centralized repository for unstructured data. As clearly illustrated in the preceding section on “Cloud Data Breach Incidents,” approximately 60% of cloud data breaches are significantly linked to storage buckets.
Why does the use of buckets pose so many security risks?
As one of the longest-standing cloud products, its status is partly due to its complex authentication and authorization control model; on the other hand, its general-purpose nature combined with application-specific usage—and the resulting improper implementation—only exacerbates this severity.
The authentication logic for non-anonymous requests in Alibaba Cloud Object Storage Service (OSS) buckets is very complex, so does other cloud.Therefore, to properly manage bucket controls, you need to take a two-pronged approach—addressing both buckets and objects—and, from a security perspective, do your utmost to avoid situations where the security policies for objects and buckets are inconsistent.
The three principles of bucket control are: separation of public and private, standardization and unification of the access control model, and privileged-access management.
The separation of “public” and “private” refers to distinguishing between Public-type buckets and Private-type buckets when designing application storage buckets, and prohibiting the storage of any sensitive data in Public-type buckets.
The unification and standardization of access control models refer to giving priority to Bucket policies or RAM policies as the models for managing bucket permissions, thereby simplifying the authentication and authorization logic to a certain extent. Essentially, both models can grant a user operational permissions over a bucket; however, they differ significantly in terms of their target objects and policy syntax.
Privilege control refers to the management of privileged operations such as the ListObject operation on buckets, which are removed by default.
4.3. Baseline
The baseline is another core component of the entire OCBC framework’s security management. At its essence, the benchmark also focuses on prevention. The baseline consists of two parts: the cloud product security baseline and the security management baseline. It is referred to as the “Dual Baseline.”
4.3.1 Cloud Product Security Baseline
The solution addresses the challenges of “selecting,” “using,” and “retaining” cloud products, systematically avoiding the introduction and use of cloud products that are neither essential nor secure, and adopting a left-shift approach to reduce business security risks.
Many people might be curious: Are there still insecure cloud products out there? Are there any products that simply can’t be used at all?
The answer is yes. There are numerous cloud-based products, each with its own specific use cases and business scenarios. From the perspective of the cloud platform itself, different types of products will be developed based on product planning and evolution. Cloud products are designed to meet user scenarios, but from this perspective, we’re looking at individual product categories rather than the broader context of how the entire cloud product portfolio is applied. As a result, there tend to be more “pitfalls and hidden complexities” in this approach.
Therefore, the security baseline for cloud products should be managed across five dimensions: cloud product assessment, adopt criteria, security baselines, exit mechanisms, and policy governance.
Cloud Product Assessment: This involves establishing a security assessment mechanism for all cloud products selected by the enterprise. First, it confirms the reasonableness and necessity of the requirements; then, it conducts a security assessment specifically tailored to the use of each cloud product, identifying risk levels, risk items, and mitigation measures.
Adopt Criteria: Establish a baseline list , using “Red,” “Yellow,” and “Green” labels to indicate the eligibility of cloud products.
Products that, following a comprehensive security assessment, are identified as having excessively high usage risks, lacking effective risk control measures, or bypassing existing security control mechanisms—and which are neither essential nor urgent for business operations—will be placed on the Red-listed prohibited access list.
Products that, after a comprehensive security assessment, can have certain features trimmed while still meeting the product’s security baseline standards will be listed on the Yellow-listed eligible products and may be procured.
Products that, following a comprehensive security assessment, meet moderate security baseline standards will be listed on the Green-listed eligible products and may be procured.
Security baseline: refers to the security baseline for cloud products, targeting the cloud products themselves. Cloud products that have undergone security assessment must meet the corresponding security baseline requirements.
Exit Mechanism: The exit mechanism shall be triggered when a cloud product is no longer used due to significant security risks, business adjustments, or other reasons. For example, a cloud product may be decommissioned due to budget constraints.
Policy Management: Technically implemented and supported management of cloud product security baselines, covering the entire lifecycle of enterprise cloud product usage.
4.3.2 Security Management Standards
The security management baseline is a framework for managing the security of cloud-based business from the perspectives of application security and data security.
Application Security Construction will be carried out around the SDL lifecycle, employing both horizontal-depth closed-loop and single-point-depth closed-loop approaches. The horizontal-depth closed-loop refers to ensuring that security controls are implemented, enforced, and verified at each stage—from requirements gathering through development, testing, go-live, and operation. The single-point-depth closed-loop means that for each individual stage, multiple layers of control requirements are in place, and each layer’s control requirements likewise follow the principle of being managed, implemented, and verified. In addition, establishing a cloud application security baseline tailored to the characteristics of the cloud is also an important component. Data security.
Data security revolves around application data security, big data security, and endpoint data security. It’s important to note that the cloudification of enterprises has led to blurred boundaries in office networks and introduced issues such as the AK/SK characteristics, significantly increasing the risk of data leakage and its spillover effects beyond controlled channels. For instance, by implementing a console-based masking access control mechanism, enterprises can define and confine controllable office boundaries, thereby mitigating similar risks. As for data security, I will introduce it in other articles.
4.4. Cloud-native security
Cloud-native security is also an infrastructure environment scenario that does not typically arise in traditional IDC architectures. Specifically, it includes cloud platform security, K8S security, image security, and container security.
Cloud platform security refers to the need, from the perspective of the cloud service provider, to ensure the security of the cloud platform itself. The development of security capabilities and the overall security posture in this area entirely depend on the cloud platform itself. Historically, there have been no shortage of cases where flaws in the cloud platform’s own security led to data breaches. As the client enterprise using the cloud platform, you can take a multi-faceted approach when selecting a cloud platform.
K8S security, container security, and image security are the most critical infrastructure components for enterprises transitioning to cloud environments. Most cloud-based escapes occur through security vulnerabilities in containers and other components, ultimately allowing attackers to gain control over K8S clusters. Image security is also a key focus in supply chain security management. It can be managed from aspects such as API permissions, network access, port controls, and privilege management.
The above is a brief introduction to OCBC, the overall cloud-based security governance framework. The focus remains on implementing cloud security management from the perspective of the client enterprise using the cloud.
5. Conclusion
The cloud not only simplifies the complexity and onboarding costs of traditional IDC network architectures, but also brings about new changes in infrastructure and architecture.
Building cloud security for enterprises is not something that can be achieved overnight. In addition to facing new risks brought about by business changes, enterprises must also contend with emerging risks arising from the launch of new cloud products and the continuous iterative updates of the cloud platform itself. Therefore, it requires a commitment to long-term, ongoing learning and investment. Finally, here are a few points I’d like to share with everyone:
The C controls within OCBC’s cloud-based security governance framework inherently possess security attributes. If security responsibilities or requirements are merely delegated through management, security will always be relegated to a reactive, catch-up role. It is recommended that the security team proactively assume responsibility for, or provide standardized, platform-based security capabilities to support operations.
Cloud security infrastructure is both universal and replicable across different cloud vendor platforms. Based on the consistent understanding of cloud products required by users, various cloud platforms tacitly take user cognition into account during cloud product design—particularly for typical products such as permission management (IAM) and storage buckets—thereby avoiding the learning costs associated with migrating from other cloud platforms to their own.
The cloud is a particularly complex entity, involving a wealth of new knowledge and perspectives—especially for client enterprises whose businesses run entirely on the cloud. If you wish to become proficient in cloud security-related fields, you’ll need to deepen your understanding of the cloud’s underlying infrastructure from the perspective of the cloud platform itself, while also gaining a thorough grasp of the features and characteristics of cloud-based products from the client’s standpoint. Only by doing so can you better apply these insights in real-world business scenarios and fundamentally avoid or mitigate security risks.
It is unrealistic to rely solely on the security capabilities and platforms provided by cloud vendors to build an enterprise’s own cloud-based security governance. Similarly, adopting a “plug-and-play” approach for all cloud products is also not advisable. At the same time, when considering introducing third-party security products that are not part of the cloud platform, it’s essential to take into account their integration with and complexity within the cloud platform environment.
Every cloud platform may have security vulnerabilities—though the extent of these vulnerabilities and the timing of their discovery can vary. However, more often than not, it’s actually the client enterprises themselves that fail to use the cloud in a secure and compliant manner, leading to security vulnerabilities or data breaches. As a result, the cloud platform inadvertently becomes the correspond-er. Therefore, it’s crucial to consistently uphold the role of being the primary responsible party for cloud security.