Identity Powered Security

www.aporeto.comCloud-Native Security

www.aporeto.com

Executive SummaryAs the move towards a digital world continues Enterprises have a greater

responsibility to protect access to their data from bad actors. Security breaches are

no longer an if condition but a when condition. When there is a breach the best

option is to reduce risk by containing the breach blast radius.

At Aporeto we have taken a unique approach to mitigate lateral attacks while

allowing our customers to consume cloud, build cloud-native applications and

improve application velocity. De Facto workload/application segmentation

technologies in the industry are IP infrastructure centric. An IP centric approach to

security introduces an overwhelming amount of complexity and a failure to establish

a strong security posture. Our assertion is security must be abstracted from IP

infrastructure to address application segmentation requirements and improving

your application risk posture.

All network segmentation solutions that exist today tie back to IP infrastructure in some way. This goes for micro-segmentation solutions or cloud security groups offered by popular cloud providers. The above illustration demonstrates the problem with IP whitelisting. If you are to consider a set of six workloads that need to be whitelisted you will need to define and/or manage (6*(6–1))/2 number of rules; it boils down to an (N*(N-1))/2 problem where N is the number of endpoints. As the number of endpoints increases the number of policies increases and the increase is non-linear. Some vendors hide the complexity of defining these IP rules with abstractions but hiding complexity does not address scale limitations. 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. Whitelisting is the right approach but the complexity has to move towards an order of N problem – more on that approach later.

How Network segmentation does not reduce your risk posture Shrinking a large IP perimeter with IP whitelisting

increases complexity & reduces scaleNetwork segmentation technologies today can shrink a large IP perimeter behind a firewall to a smaller perimeter utilizing IP whitelisting. Unfortunately an IP based perimeter still exists and is ineffective in reducing the threat surface for your high value assets. Let’s address some of the limitations of this approach to segmenting your applications.

www.aporeto.com

# of endpoints 4 6 8

6 15 28# of whitelist policies

Hybrid and multi-cloud introduce multiple IP domains. It is well understood 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. IP whitelisting cannot span multiple IP domains. The only way to get around this issue is to enforce course IP whitelists that allow all traffic from a given IP domain.

This Illustrates the consequences of this approach. A single compromised host in within the on-premise data center now has the ability to laterally move to the cloud. As a bad actor, Ii can also spoof my address to pretend Ii am originating from a specific IP range even though Ii am not.

IP whitelisting increases threat surface for hybrid/multi-cloud

www.aporeto.com

!

API

Cloud IP Perimeter

Microservices

FW

VPNs,Tunneling/SDN

DC IP Perimeter

App App

Containers

API

Cloud nativetechnologiesbreak IPwhitelisting

Agile development practices with microservices and the adoption of cloud-native technologies such as containers further strain security policy enforcement based on IP. Microservices are exposed through APIs accessible via HTTP/gRPC making IPs irrelevant.

Containerized workloads can be replicated, rescheduled and rehosted. The dynamic nature of container workloads implies IP addresses are no longer persistent identities to be used for security policies.

www.aporeto.com

Visibility is critical to understanding sanctioned and unsanctioned communications for your applications. All network & security visibility solutions today rely on IP as the application identifier. Applications spanning heterogeneous environments always span multiple IP domains which means one would have to stitch IP flow data across these disparate environments to get an end-to-end picture; almost an impossible undertaking.

Application visibility in heterogeneous environments

www.aporeto.com

Cloud Region 2

CloudFlowLogs

Cloud Region 1

CloudFlowLogs

App

On-prem flow logs

On-prem DC

App

Identity-powered application segmentation

www.aporeto.com

The concept of identity is well understood for users logging into popular web applications such as email. Source IP of a user can come from anywhere on the internet making IP whitelisting users impossible and extremely insecure since IPs can be spoofed. Strong user identity can now be provided by popular identity providers such as Ping, Okta, Google Auth etc.

Modern application workloads depict the same characteristics as users; workloads can now exist on any cloud and be rescheduled or re-hosted much like ephemeral users. Application workloads need a persistent identity that can be used for security policy enforcement.

Authenticateand Authorizeusing identity

User

IdentityProvider

App

Assign every workload cryptographic identity.

Distribute policies to end-points but manage policies centrally.

Segment every app and API by authenticating & authorizing all requests.

At Aporeto we are bringing the concept of user identity to applications. Our approach is to assign every workload with a cryptographically signed identity that is dynamically derived by introspecting multiple sources:

www.aporeto.com

Operating system (OS): Derive which user (UID, GUID) launched the application

Cloud Instance metadata: Example is AWS EC2 instance identity document

Orchestrators such as docker, kubernetes, mesosphere, and nomad: Derive applications tags that describe the role of the application, container image data

1

2

3

I II III

Identity

Identity

Identity

Infrastructure

Private Cloud

Private Cloud

Every time a workload initiates a request to another workload, cryptographic identity is used to first authenticate both endpoints and then authorize the request with a local policy. Any other requests are implicitly denied.

Strong portable policies that are abstracted from the underlying IP infrastructure.

Policies can be codified for automation.

Attributes from these sources serve as strong machine generated identity and

are less prone to human errors.

With cryptographic workload identity, we can now build:

www.aporeto.com

Cloud provider instance data

What is theworkload running

User who launchedworkload

Application Tags/Labels

Workload

E-W traffic segmentation between workloads in hybrid cloud or heterogeneous environments. Traversing multiple IP domains is no longer an issue since IP is no longer an identifier.

We are utilizing a whitelist approach which is very scalable because the use of an identity turns policy enforcement into and order N problem and no longer an N^2 problem.

Getting visibility for your applications across heterogeneous environments now becomes a possibility since you have a common workload identifier that is abstracted from infrastructure.

Dynamic containerized applications now have a trusted identity that can be used for security policy enforcement while allowing seamless microservice replication, load-balancing, and rescheduling. Access to microservice APIs can also be restricted with this trusted identity.

This unique approach resolves all the issues we highlighted earlier:

I

II

III

IV

www.aporeto.com

Thank you.

www.aporeto.comCloud-Native Security