Many of the enterprises with significant on-premise infrastructure and associated processes and organization structure have seen a significant impetus to migrate to the cloud. This migration journey is significantly different from the journey of traditional cloud-native tech organizations that have limited governance, informal or sometimes non-existent business processes, small and generalist teams with limited or no legacy on-premise infrastructure. These differences between the traditional and modern tech enterprises have a significant impact on how cloud infrastructure is architected, deployed, operated and secured in traditional enterprises.The cloud platform differs from traditional on-premise infrastructure in the following ways.

1. Impact of “in-secure by default” — in traditional on-premise castle-and-moat deployments, the in-secure default settings of most products had limited impact. The cloud platforms' “always-on-internet” approach had a significant impact on developer’s productivity but can have significant security implications for “in-secure by default” services.
2. API and Automation — Cloud platform brought a level of API based automation that people and processes associated with on-premise infrastructure were not ready for. This significantly changes the speed at which the platform configuration can be accessed, security posture can be compromised or improved.
3. Developers as Operators — As some of the enterprises transform from an on-premise to cloud, they are buying into the idea of developers being responsible for all the aspects of the application including underlying infrastructure. This can be a significant change in the security RACI (Responsible, Accountable, Consulted, Informed) matrix that has a big impact on how the security is embedded into the process, technology and corresponding impact on people

These differences must be considered while developing the security approach for cloud platforms. There are a lot of cybersecurity frameworks like ISO 27001, COBIT, NIST, PCI DSS that provide a varying degree of prescriptive details about what cybersecurity should cover. In addition to that, there are organizations like CIS, SANS that provide best practices and a more pragmatic approach to securing the IT infrastructure across on-premise and cloud. This is an attempt to bring a descriptive approach to cloud security that uses these valuable sources and builds on with lessons from the field.

Security Architecture

The following is a cloud security reference architecture that I have used to understand this domain.The architecture above tries to bring together the various components that form part of cloud infrastructure that needs to be considered as part of cloud security. Please note that the above architecture is technology-focused and does not cover the people (e.g. training, skill management) and process (e.g. asset management, change management): aspects covered by most of the security frameworks. The choice was made since it is assumed that most traditional enterprises are familiar with these aspects as part of the management of on-premise infrastructure.The architecture, at a high level, is divided into three layers.

1. Security Governance: focuses on the overall management of cloud security. The primary output of this layer is the policy, standards and guidelines which drive the bottom two layers.
2. Infrastructure: layer covers the components that need to be protected. This primarily consists of clients, cloud platforms across IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service) and development infrastructure.
3. Security infrastructure: consists of security services and operations that are used to protect the infrastructure above. This layer can be any combination of on-premise and cloud-based products and services unique to an organization.

Vulnerability and Drift, Logging, Access, Data, and Resilience (V.L.A.D.R.)

The security infrastructure protects the infrastructure based on the policies provided by security governance. Security of a component of infrastructure can be evaluated using various approaches as long as the approach is consistent. I have found the V.L.A.D.R. approach using the following aspects to be helpful.

Vulnerability and Drift 
Vulnerability identifies the inherent defect in the component that can result in the compromisation of confidentiality, availability or integrity of that component. The vulnerability may be due to people (e.g. phishing), process (e.g. storing password in the configuration file in clear text) or technology (e.g. unpatched bug). In a shared-responsibility model of the cloud, depending on the layer (IaaS, PaaS, SaaS) of component either CSP (Cloud Service Provider) or customer may be responsible for managing this. 
Drift refers to changes to component configuration or data that make the active state of the component different from the “desired state” and thus introduces vulnerability. These drifts may occur as part of regular operations either due to malicious or accidental intent.

Logging and monitoring of the component ensure that all the changes are audited and activities are recorded. This is important from a security operations’ perspective to ensure adequate oversight of the security posture.

Access: Identity forms the core of any modern security posture. It focuses on ensuring that the principle of least privilege and consistent identity propagation is consistently applied as part of securing the infrastructure. The access can also be controlled at the network layer and is sometimes considered to be part of this aspect of security.

Data is the information owned by the organization (or at least responsible for its protection) and stored in the infrastructure component we are trying to protect. The basic approaches focus on ensuring the data is secured at rest (when stored) or in motion (during transfer or access) through encryption to prevent data loss (DLP). In addition to that additional techniques like data masking, tokenization may be used to protect sensitive data as part of data security.

Resilience ensures the availability of the component in case of any infrastructure failure that can have an impact on the component. This typically focuses on failover approaches along with backups and disaster recovery.

There are alternate approaches like  or  which can be used to build a similar security model.

Also published on //medium.com/jhash/enterprise-cloud-security-introduction-970a63f50914