Last updated November 25, 2019.

Across IT, we are seeing a shift from centralized, monolithic systems to distributed, containerized applications and microservices. With this transition, a fundamental change in the shape and makeup of networks and nodes is required. Traditional IT network security’s “castle-and-moat” approach does not work in the cloud, where every endpoint can be potentially exposed and lead to a breach if not secured properly. A Zero Trust security stance is a new approach in which no-one is trusted automatically, whether they are inside or outside the network. Verification is always required from anyone trying to gain access to resources on the network.

Table of Contents:

  • check icon

    “Trust”? What does trust have to do with network security?

  • check icon

    Why does the rise of the cloud mean trust-based perimeter-centric security models are falling short?

  • check icon

    Microsegmentation: part of the solution

  • check icon

    What does a Zero Trust network model look like?

  • check icon

    Zero Trust use cases

  • check icon

    The Aporeto Zero Trust model

“Trust”? What does trust have to do with network security?

Asset-8@2x

Understanding the role trust plays in the world of network security requires a brief bit of internet history.

 

The internet began life as a rudimentary networking system. This system was created by DARPA – the Defense Advanced Research Projects Agency, a department of the US Department of Defense – in the sixties and seventies. This was the peak of the Cold War, and DARPA’s priority was to construct a network that could continue to interact even in the case of a nuclear disaster. To meet this need, the internet was constructed, at the most foundational level, as fundamentally open. This was necessary so that, even if three quarters of the network were to go down – as in the case of a nuclear strike – the rest of the network could still function and communicate.

solutions-asset-05

This open design meant that the internet was built with every single node being discoverable by design. Everything could communicate with everything, unless explicitly prohibited. This is the basic structure of TCP/IP. IPs can connect with other IPs, as long as there is a route. And this is what north/south firewalls create: exceptions to the full discoverability principle.

 

Traditionally, networks haven’t had to worry about all of the computations produced by this multitude of open nodes, because these computations were finite and restricted. Firewalls could handle the bad interactions, and everything else could be processed in the background. But the rise of the cloud is changing all that.

Why does the rise of the cloud mean trust-based perimeter-centric security models are falling short?

Webinar-15-01

For two decades, the nature of network security, and its technical demands, remained relatively unchanged.

 

Traditional networks relied on VLANs, which sit on top of physical networks, and then segment the network traffic in customizable ways that give the impression of a web of virtual networks. In this setup, many devices in one layer -two switch fabric make up a physical network, and routers are used to bridge layer-two networks.

 

Firewalls have been reliant upon IP addresses (and optionally port numbers) to identify the identities of source and destination. IDS/IPS systems, meanwhile, rely on already detected and detected signatures, derived from network and port scanning patterns.

How to Achieve a Successful Cloud Migration Strategy with Aporeto

All of this is the foundation for what is called a perimeter-centric security model. The basics of this are: everything inside the perimeter is okay, and everything outside the perimeter is regarded with suspicion.

 

The problems start because the cloud brings a major change in scale. In the cloud, there is more rebooting, much more movement, and much more change. VMs are up and running, and containers can come and go in a matter of days, hours or minutes. With every network interface, the network topology changes. This creates a huge uptick in scale, as there is a constant increase in the amount of endpoints in the network.

 

Traditional network security models can handle a high rate of change if the number of nodes are small, or a high number of nodes if the rate of change is steady and relatively low. But the cloud-native topography is such that both these factors are always present at the same time. This creates a problematic situation where, in a cloud ecosystem, a high rate of change and a high rate of computation co-exist.

Aporeto vs Open Source (OSS) Security Platforms

This is why the cloud is such a dynamic environment offering flexibility and high availability. Compared to legacy on-prem constraints, the computing and resource potential of the cloud is unlimited. The cloud’s very power lies in the fact that it isn’t constrained by any hardware-derived perimeters. Endpoints are endlessly proliferating and network communication is a richer and more complex phenomenon than was ever conceivable in the pre-cloud era.

 

This is also why a lift-and-shift approach won’t work. Replicating on-premises apps in the cloud is destined to leave gaps. The security and data conditions are so radically different that a simple infrastructure copy and paste misses all of the new potential for threats produced by a post-perimeter setting.

 

Remember: Most cyberattacks don’t begin at the actual target location of the attack. The point of infiltration will be somewhere else, and the threat will move laterally. An attacker will come in through an endpoint and then make their way laterally to the data center. And with a dynamic cloud environment and ever increasing endpoints, more potential entrances for a lateral attacker emerge.

compliance

In a hybrid cloud environment, this is an even more dangerous situation. Why? Because any potential hacker isn’t limited to your cloud assets; once in, they can move laterally to your internal data center network. Even those elements of the network that were assumed to be safer because they hadn’t been fully migrated remain, and are now an exposed target.

 

The fundamental easy scalability of the cloud means tracking IP addresses are an issue and will no longer work. In the cloud – in the era of containers cycling in and out, and virtualized endpoints constantly shifting – IP addresses are simply ephemeral. Thus network- and perimeter-centric approaches, which were built on the predictability of IP addresses, will no longer work.

 

Users are now scattered everywhere across the world. Enterprises are comprised of remote workers, suppliers, and contractors. The network is overwhelmed by activity and change. In this landscape, what is required is secure network connectivity regardless of the location of the app, workload, or user and regardless of the device being used.

Microsegmentation: part of the solution

cloud perimeter

Microsegmentation is the approach of dividing security perimeters into smaller zones to maintain separate access for separate parts of the network. Through IP whitelisting, network microsegmentation technologies shrink a large IP perimeter behind a firewall, creating a smaller perimeter.

 

Microsegmentation can be an important part of a Zero Trust model. It helps provide granular control, and can contain the blast radius and limit east-west lateral movement should a breach occur. However, on its own, it isn’t enough.

 

Why? Because an IP-based perimeter continues to exist. All network segmentation solutions tie back to IP infrastructure in some way, even if they conceal the complexity of defining IP rules behind abstractions. This means that the crucial issue of scale limitations isn’t being addressed. A change in any one of the endpoints requires an update to all other endpoints. As the number of endpoints increases the operational burden of managing these rules increases in tandem.

Cloud Applications Challenge Blog Illustration Aporeto

Scale and IP convergence becomes the crippling issue. If there are changes at an endpoint, then IP tables must be updated in order to achieve security-dependent convergence. But with more endpoints, you need more updates, and this spirals into slower performance. Eventually, you hit the scale limit and you can’t keep up, which means immediate gaps in your security coverage. On top of this, in the cloud, there are overlapping IP addresses. This makes extending private data center-based microsegmentation difficult to manage and operate.

 

Hybrid and multi-cloud environments introduce multiple IP domains that can’t be spanned with an IP whitelisting approach. It is well understood that IP networks are not one flat layer today. Network Address Translation (NAT), Proxies and Load Balancers are common and all of these technologies mask IP addresses. You are in a position to enforce course IP whitelists that allow all traffic from a certain IP domain. In this setting, a single compromised host within the on-premises data center can laterally contaminate the cloud, and bad actors can fake their IP.

 

Microservices and the adoption of cloud-native technologies strain IP-based security policies even further. Microservices are exposed through APIs accessible via HTTP/gRPC. Containerized workloads can be replicated, rescheduled and rehosted. Applications spanning heterogeneous environments always span multiple IP domains, meaning you would have to complete the impossible task of stitching IP flow data across disparate environments to get real visibility.

In short, microsegmentation remains reliant on IP addresses, and on various forms of ill-advised trust. It isn’t enough to establish a Zero Trust security stance.

 

Microsegmentation can just about be made to work inside of internal data centers and cloud infrastructure. But as soon as enterprises are looking outward and needing to give access to customers, employees, users and contractors, things get exponentially more complicated. For this, a full Zero Trust security model is required.

Read More
Cube Graphics-01

What does a Zero Trust security model look like?

“Zero Trust” was first coined by the analyst firm Forrester Research. It refers to the general post-perimeter approach, in which to cope with the dynamic cloud-native environment, anything inside the perimeter is no longer automatically regarded as non-threatening. You assume that in principle, everything is accessible to everyone, and anything might be breached at any time.

 

Rather than the old castle-and-moat mentality, in which inside perimeter = okay / outside perimeter = suspicious, everything must be verified at all times. Nothing is automatically trusted.

solutions-asset-04

In a Zero Trust security model, identity and authorization is always required before any connection can be made. It doesn’t matter if an app or workload is within the enterprise perimeter; there is still zero trust, and the perimeter is what is called software-defined. This architecture is cloud-native and scales exponentially.

 

Rather than hard-coded boundaries, you have logical and dynamic boundaries. Instead of trust, least-privileged access to the network is allowed only after an assessment of the identity, the system, the intention and the context. And that assessment includes real-time context like location, time of day, type of device, the trust and management profile of the device. This makes all security decisions relating to connection inherently context-aware and identitiy-aware rather than static and dumb.

 

As analyst firm Forrester defines it, Zero Trust can be thought of as possessing seven key elements:

Aporeto - Icons Compilations

Zero Trust data

Data needs to be encrypted both at rest and in transit. It should be secured, managed and categorized within watertight classification schemas, and transmitted through a connection method that verifies all activity.

Aporeto - Icons Compilations-09c

Zero Trust networks

Enterprises must be able to segment, isolated and control their network(s). Key technologies are multi factor authentication, IAM, orchestration, and scoring and file system permissions.

Aporeto - Icons Compilations-09b

Zero Trust workloads

Just like the rest of the stack components, workload components must be treated as a threat vector, and be looped into the whole Zero Trust framework. Workloads running in public clouds should receive special oversight.

Aporeto - Icons Compilations-09c

Zero Trust devices

IoT and network-enabled devices have introduced a large threat surface. In a true Zero Trust setting, security teams should be able to isolate, secure, and control every device on the network at all times.

Aporeto - Icons Compilations-09

Visibility and analytics

A well-functioning Zero Trust model needs to provide powerful and real-time insights into the network and any potential threats.

 

Aporeto - Icons Compilations

Automation and orchestration

Enterprises must start to leverage tools and technologies that enable security automation and orchestration (SAO). These platforms help to increase analyst capacity, reduce incident response times, and integrate disparate security. Orchestration also extends security policies to cloud environments just as you orchestrate cloud applications.

 

Aporeto - Icons Compilations-09

Zero Trust users

User access should be strictly enforced and limited. Users should be thoroughly authenticated, and their access and privileges should be constantly monitored and optimized. Enterprises should leverage a least-privileged access strategy, and strictly enforce access control. Ideally, advanced technologies like remote browser isolation technology and biometric authentication should be used.

 

A Zero Trust security model puts the security team back in control of applications by making security automated, scalable and infrastructure agnostic.

The Aporeto Zero Trust security model

 

There are many ways to approach the implementation of a Zero Trust security model. At Aporeto, our Zero Trust security model is an inherent element that makes up the Aporeto application identity, a multi-attribute contextual identity for any application component created and managed by the Aporeto platform. Unique identities for each application resource allow Aporeto to automatically create custom protection policies and enforce security at a granular process level regardless of where the application runs. At runtime, the addition of behavioral and vulnerability data enriches the resource identity to create dynamic security visibility and protection capability.

In this Zero Trust model, contextual identity is automatically created for every service. Each time a resource – which can be a container, VM, process, or external service – attempts to access another resource, a userland process that resides on each host automatically creates application identity which travels along with the I/O request. The application identity includes information such as:

  • check icon

    User-ID as verified by authentication

  • check icon

    Network address of requester

  • check icon

    What service or resource is being accessed

  • check icon

    Metadata from Linux processes, Dockerfiles, Docker containers, Kubernetes labels, etc.

  • check icon

    Threat, vulnerability and risk scoring

  • check icon

    Behavior from past history running in the environment

During runtime, Aporeto orchestrates authentication, authorization and encryption for all application resources. All access and behavior to the resource is controlled via policy. System level run-time protection is achieved through inspection of all communication, and if suspicious behavior is found – an alert is issued or a policy action is taken. Automated remediation can be orchestrated through a variety of actions like resource quarantine or container snapshot. Vulnerability and behavioral data is fed back into the resource identity to enrich the identity profile and dynamically influence policy. Cloud-native security automation and orchestration is achieved without writing code or changing the network.

The heart of the Aporeto platform is the Aporeto Security Orchestrator, which includes the automated application identity management infrastructure and the policy engine for defining and operating the policy that is distributed to all of the individual workloads. Powerful APIs allow the Aporeto platform to integrate seamlessly into the entire infrastructure, from CI/CD pipeline to user Single Sign-on to security operations center incident response. The Aporeto Enforcer is deployed as either a container, as an enforcement node on an individual host or virtual machine, or as a Daemon for Public Cloud workloads including serverless, Lambda functions or service mesh including Istio. Any workload instrumented with the Enforcer and working in conjunction with the Orchestrator is enabled with automated issuance and management of security policy.

Aporeto provides comprehensive cloud network security through microsegmentation and secure access to applications and infrastructure using identity rather than IP addresses for a Zero Trust security solution. Aporeto’s identity-based security model moves security policy control to the application, up the stack, and enables granular control at L3, L4 and L7, to create policies that are portable and persistent regardless of infrastructure or workload type. When users or workloads span different clouds, Aporeto harmonizes and unifies those identities. Wherever workloads go, Aporeto security policies travel with them. Aporeto gives you distributed protection with centralized visibility and control.

By decoupling security from IP infrastructure, Aporeto allows DevOps, DevSecOps and security teams to define policy-as-code, allowing easing integration into continuous deployment pipelines. The end result enables enterprises to innovate rapidly at all times, while managing to stay protected at all times.

Featured Resources