Zero-Trust and the Public Cloud

The ancient times’ mythological hero Ikarus sends a warning to today’s zero-trust programs: aiming too far and flying too high might result in getting burned and crashing miserably. Ikarus’ father attached feathers to his own and his son’s body with wax. They wanted to fly away to escape from Crete, where they were held captive. Despite his father’s warning, Ikarus flew high and close to the sun. Thus, the sun melted the wax. Ikarus plummeted. Like overambitious Ikarus, today’s zero-trust programs risk aiming too far and high.

The Zero-Trust Project Scoping Challenge

Zero-trust is an umbrella term. Nearly every problem and technology find cover under this term – perfect for technology aficionados aiming to push “their” solutions. More concrete, umbrella programs come with two risks:

Bitter disappointments and wasted money are potential consequences of not taking these risks seriously. Still, at its core, zero-trust addresses two explosive security realities of enterprises and their CISOs and CIOs. First, in today’s world, hackers have a realistic chance to break into every network, server, application, or end-user device if they try hard and long enough. Second, foreign attackers are not the only potential enemies. Even employees might turn against their company and run inside attacks. Perimeter security alone (!) does not mitigate these risks adequately. Security architectures today need capabilities to expel successful hackers already in the network and reduce their potential damage. So, welcome to the zero-trust school of thought, residing on three pillars: attack containment, attack identification and defense, and a higher bar for attackers regarding identity protection.

Related:Nine Best Practices for Zero Trust

Attack Containment in the Cloud

Containment means restricting and reducing the blast radius. Assuming that attackers might succeed, we should prepare to limit their damage if they gain access, e.g., by taking over a technical or personal account.

The severity of the direct damage of an attack depends on the account’s access rights. All data or just very few tables? Read-only or read and write? The “need-to-know” principle is vital for damage control, meaning that accounts should have as few rights as possible (Figure 1, A). The challenge: each and every development team has to implement roles with restricted rights – and employees should only get roles they really need. It is an old truth but especially essential for zero-trust.

Related:Zero-Trust Model Gains Luster Following Azure Security Flaw

Figure 1: Containing successful attacks

Besides direct, there might also be indirect damage (Figure 1, B). Attackers already in the network might flood middleware services or APIs, thereby crashing other components. For example, suppose they flood a Kafka middleware installation until it slows down considerably. In that case, they hinder business processes that depend on Kafka for coordination and collaboration between services and components.

Limiting traffic or throttling are features such middleware components hopefully support. It is up to the software vendor or the cloud provider to implement such features. Thus, considering such features during software product evaluation is more likely to succeed than trying to implement such controls at a later stage. From a CISO perspective, middleware is desirable for which an operations team just has to configure their product to mitigate such indirect damage risks. It is less troublesome than identifying all applications using a specific middleware and convincing the engineers to implement security features against indirect attacks.

Fighting lateral movement is an aspect of containment most organizations work on heavily (Figure 1, C). The task has network and application layer aspects. Multi-factor authentication (MFA) for personal users and certificates for technical accounts reduce the risk of stolen credentials, allowing breaking into additional VMs or applications. For service accounts, certificates are a way to restrict service calls for callers knowing a secret and coming from a specific IP range. Middleware tools with such features and run by a dedicated product team ease enforcing homogenous standards.

Network segmentation, i.e., structuring the network into different zones, is the standard approach in the cloud and the pre-cloud era (Figure 1, D). It is easy to implement measure on the network layer, especially if the IT organization has standard templates for creating zones for new applications. Certainly, default connectivity settings must be restrictive, and extensive openings of firewalls have to be prevented – or reported and fixed in a timely matter

Identifying and Fighting Attacks

When successful attacks are a likely scenario, capabilities to identify and fight attacks are a necessity. However, identifying attacks was never easier than in today’s public cloud environments, especially for smaller companies. Security architects can rely on cloud-native threat and attack detection solutions such as Microsoft Defender or Google Security Center. Activate their advanced features with a click and let them help you protect your environment from the first second.

The cloud security services bring various benefits (Figure 2, green components):

Figure 2: Monitoring cloud infrastructures for security incidents

Still, significant work remains with company security experts (Figure 2, yellow components). The first area covers application-level events. The cloud knows what happens on cloud components but not what happens on the application layer with your applications. Does an attacker try and succeed in breaking in on the GUI level? It is up to the application to write suspicious events to the log and raise the alarm. How do you consolidate and correlate such events, especially together with cloud component events? Are you using different clouds? Customers must implement themselves a solution in a multi-cloud scenario to get a complete, holistic picture spanning all clouds.

Some thought leaders also classify automatic response as a zero-trust concept. Blocking a user for a few minutes after three failed logins is a clear and easy-to-implement response rule. The rule is likely to have only limited side effects. In contrast, automatically shutting down VMs or blocking any access to object storage can have an unforeseeable impact on applications making automatic responses and defense measures more a vision for many components than a concept widely rolled out in the following weeks.

Improving Identity Protection

J. Hawley’s famous slogan “Identity is the new perimeter” symbolizes the shift in security from perimeter to identity protection, be it users or services. R. Bird’s enhancement to “If identity is the new perimeter, then Bob in accounting is the new port 80” points out the need to protect the identity and accounts. MFA and certificates hindering lateral movements are one aspect (Figure 3, A), and mobile device protection is a second (Figure 3, B). Mobile devices are a risk if they cannot prevent stealing an employee’s identity by taking over the device — bring-your-own-devices and working from home foster this security risk. Third, conditional access with more fine granular permissions such as time restrictions or approval workflows makes attacks more challenging to succeed (Figure 3, C).

Figure 3: Identity protection improvement options

Attack identification, containment, and defense capabilities together with improved identity protection: It is exciting to see how and which recent security technology advancements in the market help make a zero-trust vision a reality. Understanding the context enables engineers to link their daily work on single components to an organization’s overall zero-trust vision. Architects need this understanding to validate the completeness of their architectural blueprint. Zero-trust is like a bouquet - combining different colors and technologies is the source of aesthetic beauty for flowers and the source of technical success in security architecture.