A Cloud Security Architect’s To-Do List

The core of cloud security architecture is transforming the abstract goals of confidentiality, integrity, and availability into a concrete cloud security implementation. IT organizations need an architectural design covering all relevant technical security domains, thereby considering company-specific input factors and managing the security architecture requirements lifecycle.

Cloud Security: A Shared Responsibility

Google Cloud Platform (GCP), Microsoft Azure, Amazon AWS: all prominent cloud vendors have large IT security teams. They praise their ongoing investments in security. So, why would an IT organization have to care about securing its cloud environment?

The cloud vendors fight such misconceptions by highlighting shared responsibility models. These models outline the security tasks the cloud provider address and the ones the customers are responsible for themselves. In essence: cloud vendors provide secure(d) cloud services; their customers assemble them into solutions. Customers must ensure a secure configuration of their individual resources, their various solutions consisting of such resources, and the cloud environment itself. To reach this aim, cloud security architects play a crucial role.

Technical Areas in Cloud Security

Related:Network Encryption: A Double-edged Sword for Cybersecurity

Security architects make various design decisions for their organization’s cloud setup (Figure 1). They design network security and perimeter protection with firewalls and network zones. They are vital in protecting a company against outside attackers and segmenting enterprise networks. The latter reduces the attack surface for insider attacks and hinders lateral movement if hackers break-in. Thus, successful hackers cannot easily jump from one server to another because firewalls and network settings stop them.

Figure 1_3

Figure 1: Main Topics for Cloud Security Architecture

Another design topic is identity and access management. It covers the obvious question of whether to use, for example, Google’s Cloud Identity, an on-prem Microsoft Active Directory installation, or a cloud-native Azure Active Directory. It also covers advanced topics such as authentication of application users (e.g., hundreds of thousands of customers not part of the company itself) or the protection of privileged user accounts and technical accounts. Plus, there are the newest concepts of passwordless authentication or zero trust. All these design decisions are specific to an organization. Missing clarification or solutions causes chaos, though chaos has one advantage: such flaws are quickly identifiable.

The third and final cloud security design area covers security tools and services. Examples are incident detection, incident management, malware detection, or patch management. Architects decide whether to invest in a 3^rd party tool, rely on cloud-native tooling, or accept the risk and not invest in a solution. However, the absence of tools does not create immediately observable issues. Thus, architects and managers might oversee the need until a hacker breaks in unnoticed.

Hardening forms the second group of security architecture topics. As with tooling and services, insufficient hardening is not readily observable, especially without or before an incident. Nevertheless, it is an activity necessary for all cloud resources or resource types engineers need to build and run their applications. Sample resources are VMs, containers, database-as-a-service offerings such as Cosmos DB, and object storage such as AWS S3. One sample measure for hardening a resource type is to prevent the creation of VMs with public IP addresses. This measure reduces the attack surface for hackers trying to break in from the Internet.

Hardening is based on company-specific guidelines for configuring the various resource types and actual implementation and enforcement. It includes strategic decisions on whether to report non-compliant resources or even block their creation. Similar to insufficient security tooling, missing hardening does not impact the success of setting up cloud environments and applications. It can remain unnoticed for months, and attackers can exploit such vulnerabilities. The past decade proved that many severe data leaks in the cloud were not the result of clever attackers. Too often, companies made their data – unintentionally – available to the Internet. It is difficult to blame anybody else if your engineers can put sensitive information on the web without anybody noticing it. Thus, CEOs, CIOs, and CISOs should ask their cloud security architects a simple question: What is your approach to security tooling – and hardening cloud services?

Elaborating Cloud Security Requirements and Architectures

Cloud vendors provide a technical and conceptual toolbox for security architecture (Figure 2). On the technical side, they offer various security tools and services, e.g., for identifying misconfigurations or attacks. On the conceptual side, they publish vendor-specific best practices and configuration guidelines. Google runs a Google Cloud security best practices center website, similar to Microsoft’s Azure security best practices and patterns. The Center for Internet Security is an example of an organization publishing industry benchmarks with concrete technical implementation suggestions. So, why would IT organizations need their own cloud security architect(s) in addition to all these guidelines and tools?

Figure 2

Figure 2: Compiling Organization-specific Cloud Security Requirements

The answer is obvious: tailoring. Tailoring means adapting general concepts to a concrete company-specific context. It is the typical work of cloud security architects.

Four factors are of particular relevance for the tailoring:

These are the four main reasons the cloud security setup differs between IT organizations. However, cloud security architecture is not a one-time activity. It is an ongoing, always rejuvenating task like the circle of life.

Cloud Security Architecture Lifecycle

The famous Benjamin Franklin quote, “Change is the only constant in life. One’s ability to adapt to those changes will determine your success in life,” should be each cloud security architect’s motto. Even superb security designs for cloud environments must adapt to a changing world (Figure 3): risk appetites drop when regulations become stricter, licenses and contracts for existing security services expire, cloud vendors push new offerings on the market, and new technologies gain popularity with developers. These are some of the changes security architects notice when understanding the organization they work for and continuously observing technical progress. However, other factors drive changes in security architecture as well.

Figure 3_0

Figure 3: Cloud Security Hardening - a Lifecycle Perspective

The second factor is feedback, intentional or unintentional. Security reviews or pen-tests – so asking external specialists - are a classic approach to increase confidence in an organization’s security posture and identify gaps. Internal technical audits fall into the same category, so do automated configuration checks by services such as GCP Security Center or Microsoft Defender. Companies want them because these measures help to improve.

The second – and highly unwanted – form of feedback comes from hackers. IT organizations might notice them based on alarms from cloud-native tools such as the Security Center or Defender, from 3^rd party security tools, or just by chance. Successful and failed attacks provide both hints where an organization’s security posture might have room for improvement.

To conclude: Cloud security architecture is a significant effort when setting up a new cloud environment. Afterward, it is a not-to-be-underestimated ongoing task for continuous reworking and improving an organization’s cloud security posture, even after a much-celebrated “go live”!