Cloud security fundamentals Part 1: Identity

The public cloud has unique differences compared to on-premise environments, which require rethinking at an architecture level. Organizations can focus on certain key fundamentals to securely navigate in the cloud. A simplified approach is to imagine cloud security in layers. At a high level, the fundamental controls are at the core, followed by use case specific considerations and then, individual cloud resource hardening. The multi part blog will focus on key fundamentals that can help you to get started on strong and consistent guardrails in the public cloud. Part 1 discusses identity as one of the key fundamentals and its role in establishing perimeter in the cloud.

The shift in the cloud access model and the on-premise environment

The cloud is a public service that you access over the internet. From a network standpoint, the cloud access model (including cloud APIs) is the same for you and the adversary. IAM control establishes validity of access to differentiate between you and the adversary. And this is how the concept of “identity is the new perimeter” was born as we no longer relied on a network firewall to allow or deny traffic unlike a traditional on-premise environment.

In an on-premise environment, the firewall limits access to external or internet facing resources while blocking all other access. The model therefore, allows a way to distinguish between resources as external or internal. The model benefits internal resources from defense in depth as the adversary needs access to the internal environment to target them. However, the internal environments end up being less mature compared to external because of natural lean on external resources due to internet and customer exposure. There are 2 interesting arguments (and you may have heard them) that lead to a security parity problem between internal and external environments:

1. Internal resources can follow a less mature lifecycle because they are not external.

2. Internal resources are not externally facing and therefore, can be held to a lower standard.

Both 1 and 2 amplify each other, causing the security maturity gap to widen.

The defense in depth owing to firewalls also created a false sense of security that has been repeatedly targeted by adversaries, resulting in lateral movement. The 2 arguments highlighted were a result of over reliance on firewalls (i.e. no direct access from the internet) and under investment in security hygiene. Inadequate security hygiene is a problem even today for many organizations, which also makes zero trust implementation challenging. The following are key examples that impact security hygiene in the internal environment:

1. Unrestricted network access i.e. a flat network

2. Unencrypted network traffic

3. Un-patched vulnerabilities

4. End of life and legacy systems (both infrastructure and application)

5. Bad credential management (e.g. long-term secrets, over privileged accounts, limited abuse monitoring)

6. Limited security assessment and testing

7. Potentially higher risk appetite with undue weightage to firewall as a compensating control

The internal environment in the cloud and what if I don't need one?

Given public cloud does not provide a perimeter in the classic sense, an organization has a choice to either somehow design the classic on-premise model with a notion of external and internal environments or operate as an external only environment where all systems and applications are accessible over the internet, like a modern platform much like cloud. In either case, the fundamental access control in the cloud is IAM. Sure you can use public and private IP addresses to regulate access but that only applies to workloads (e.g. apps on compute) or cloud services that support IP address for access (eg. EC2). From the management plane and data plane perspective (e.g. SaaS), the cloud APIs are public, which makes network controls inapplicable. This creates an interesting problem of choice but may be there is a way to think differently.

If we think about zero trust, it disregards the idea of network boundaries as a way to differentiate trust. It does not mean you should not use them but understand that network boundaries alone do not create trust, it is a fallacy. Which means that internal and external environments are not different because of the network association i.e private v/s public. If we build upon this idea, it seems logical that a risk based approach can help to identify the set of controls for systems and applications based on some criticality classification. The benefit of this approach is that an organization can still map the concept of internal and external environments in the public cloud but based on identity and not entirely focused on network controls.

The reason I bring up the continued concept of internal and external in public cloud is because of expectations from the old ways of doing things. As an example, an application intended for corporate use only may be less critical compared to an internet facing application for an organization however, if that corporate application is compromised, there is a likelihood that the reputation damage is comparatively more if not the same. Why? It may end up creating a public perception that the organization cannot even protect its "internal" assets so how as a customer can I trust it with my data (assuming that organization matters to the larger public and has brand worthiness). While, the actual information loss or operational impact may not significant. As I have learnt, perception matters more than reality and if you agree with the premise, you may wonder how often organizations walk on thin ice given the state of internal environments.

The identity-based perimeter in the cloud

Even if you ignore the environment distinction, identity is a fundamental requirement in the cloud and for zero trust. In the cloud, an entity (user, resource or system) with a valid authentication token can access a target cloud resource provided it has the permissions. The access is legitimate when it is exercised by an authorized entity or classified an attack when accessed by an adversary using compromised credentials. You may be able to relate to it by incidents or breaches in the news where long-term secrets (e.g. IAM API keys) have been used by adversaries to access cloud resources. The adversaries gained access to long term secrets through common avenues such as endpoint compromises (lifting secrets from a developer’s laptop) or from code repositories (when developers accidentally committed secrets in code).

Long term secrets are bad and should not be used for obvious reasons (I will avoid belaboring why). Which leads us to IAM roles that are better and strongly recommended. The use of IAM roles reduce the threat surface in the following ways:

1. The IAM roles use short term credentials when accessing resources requiring the adversary to continuously refresh credentials.

2. The IAM roles simplifies access management by enabling a mapping of different entities into discreet set of permissions and avoids complex permission management for each individual entity and therefore, potential for mismanagement risk.

3. The IAM roles separate permission management from entity lifecycle management and therefore, credential management, which leads to less IAM complexity and associated risks.

Keep in mind that these benefits apply when IAM roles are backed by mature identity and permission management lifecycle from both process and technology perspective.

The IAM roles increase the security bar however, an adversary can still target IAM roles through federated identities as an example. Fortunately, there are options available that can make it harder for the adversary by establishing an "identity-based perimeter". The identity-based perimeter allows to reason access using attributes beyond the credential. It allows to establish context driven authentication where other parameters of source request are taken into account when evaluating access to a given destination resource, which may closely resemble a firewall rule of source and destination pairing.

Regardless of how you view it, the identity-based perimeter introduces additional factors to ensure that credential compromise alone does not constitute to unauthorized access. It is similar to what you would get in an on-premise environment but one without solely relying on network controls of firewalls and IP addresses. The mechanisms and implementations vary between cloud providers, for example, in AWS, there are IAM policies, SCPs, VPC endpoints. While in GCP, IAM, VPC-SC and projects can be leveraged. (See references below). The different controls help to build the identity-based perimeter, which can be regarded as a first step towards zero-trust in the cloud. And if you continue in the zero-trust journey, mechanisms such as device identity, MFA, mutual TLS, least privileges can help you to advance identity maturity.

I have discussed identity-based perimeter in the context of inbound access i.e. access to the resource by an entity. For outbound access, a similar construct can be established. In addition to leveraging IAM to control access to non-organizational accounts, the network can be designed as a hub/spoke model. The hub acts as the central network point for hosts, which are spoke and the hub authorizes outbound traffic from spokes to allowed internet properties.

Last words on this topic

Identity is a key differentiator to establish perimeter in the cloud. What cloud has done is eliminated the network firewall from the control dialogue and challenged its usefulness in context of internal environments, while placing the focus on identity. It is no surprise that organizations often struggle to establish and preserve the internal construct in the cloud because "internal" is not natural in the public cloud. On other hand, the concept of internal environments cannot be completely eliminated from the current dialogue because of risk reasons, which could be perceived or real. The good news is that identity-based perimeter can be leveraged to safeguard resources in the cloud regardless of the reasons.

There is also something to be said about IAM as the only control in the cloud, which lacks defense in depth when compared to the on-premise environment firewall and IAM. If there is an IAM bug or failure, there is no fallback control. In case of on-premise internal environment, there is the “theoretical” benefit of having distinct controls. The failure of one control is complemented by another. The word “theoretical” is important because in practice, maybe we took much comfort in firewalls and private IP addresses that caused maturity to suffer for internal environments. With IAM in the cloud, the situation is akin to putting all the eggs in one basket and doing a really awesome job to protect that basket. The hope here is that if IAM fails, it fails-safe.

Part 2:

I will discuss another important fundamental of tenancy (or isolation principle) that ensures organizations when sharing resources can maintain segregation during processing, transmitting and storing of data.

References to external sources on cloud provider specific implementations and further reading:

1. https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-access-to-company-data-only-from-expected-networks/

2. https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/

3. https://cloud.google.com/vpc-service-controls/docs/overview