Enterprise cloud security : Introduction

Part I: Introduction to enterprise cloud security

Shekhar Jha
Dec 26, 2020 · 5 min read

This article is part of Enterprise Cloud Security Series with Part I: Introduction introducing the space and how it differs from on-premise security. Part II: Foundation covers the security consideration for building the cloud foundation. Part III: Developing secure applications focuses on security considerations of devops environment.

Most of the traditional enterprises with significant on-premise infrastructure and associated processes and organization structure have seen a significant impetus to migrate to cloud. This migration journey is significantly different from 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 has 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 following ways

  1. Impact of “in-secure by default” and other new threats — in traditional on-premise castle-and-moat deployments, the in-secure default settings of most of products had limited impact. The cloud platforms “always-on-internet” approach had a significant impact on developer’s productivity but can have significant security implication for “in-secure by default” services.
  2. API and Automation while losing visibility to bare metal and network — Cloud platform brought a level of API based automation that people and processes associated with on-premise infrastructure was 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 in to the idea of developers being responsible for all the aspects of application including underlying infrastructure. This can be a significant change in 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 cyber security frameworks like ISO 27001, COBIT, NIST, PCI DSS that provide varying degree of prescriptive details about what cyber security should cover. In addition to that there are organizations like CIS, SANS that provide best practices and 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 field.

Security Architecture

Cloud security reference architecture

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) aspect 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 management of on-premise infrastructure.

The architecture, at a high level, is divided in to three layers

  1. Security Governance: focuses on overall management of the cloud security. The primary output of this layer is the policy, standards and guidelines which drives the bottom two layers.
  2. Infrastructure: layer covers the components that need to be protected. This primarily consists of clients, cloud platform 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 is 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.

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.

  1. Vulnerability and drift: Vulnerability identifies the inherent defect in the component that can result in compromise of confidentiality, availability or integrity of that component. The vulnerability may be due to people (e.g. phishing), process (e.g. storing password in configuration file in clear text) or technology (e.g. unpatched bug). In a shared-responsibility model of 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 makes the active state of component different from “desired state” and thus introduces vulnerability. These drift may occur as part of regular operations either due to malicious or accidental intent.
  2. Logging: and monitoring of the component ensure that all the changes are audited and activities are recorded. This is important from security operations’ perspective to ensure adequate oversight of the security posture.
  3. Access: Identity form the core of any modern security posture. It focuses on ensuring that principle of least privilege and consistent identity propagation is consistently applied as part of securing the infrastructure. The access can also be controlled at network layer and is sometime considered to be part of this aspect of security.
  4. Data: is the information owned by 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.
  5. Resilience: ensures the availability of the component in case of any infrastructure failure that can have impact on component. This typically focuses on failover approaches along with backups and disaster recovery.

There are alternate approaches like Azure Security Benchmark or AWS Well Architected Framework (Security) which can be used to build similar security model.

In next few articles we will dig deeper in to how cloud security works in enterprise.

Changes
1. Added reference to Drift and desired state

jhash-ings

Shekhar Jha’s blog

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store