Application-aware Security, Part 2: Trust Profile Technology

By: Amir Sharif 04.24.2019
Application-aware Security, Part 2: Trust Profile Technology

Trust Profile Technology

The Aporeto Platform automatically generates a Trust Profile to be used by each service (PU) in the environment. A Trust Profile includes information such as who (the host-id, process-id, user account that the process is running under), where (network address), what (type of service), metadata (any number of name-value pairs), reputation (from ratings services), and behavior (from past history running in the environment). Trust Profiles are hashed and cryptographically signed by Enforcer on a trusted host to ensure they are genuine and cannot be tampered with. You can think of a Trust Profile as a passport. Every service (PU) that wishes to operate in the environment presents its Trust Profile to the Aporeto Enforcer, where it is used to determine if access should be allowed or denied.

By combining multiple factors into the Trust Profile, using the NIST ABAC model, an unsurpassed security posture can be accomplished. Because the creation of the Trust Profiles is done automatically on-the-fly, security is finer grained than perimeter security around the application, and is constantly kept current without requiring tedious manual efforts.

Network Policy and Procedures

A Network Policy controls what a PU with a given Trust Profile can do within the system. The syntax to define a new Network Policy is intuitive, leading to better application security, visibility, auditability. They are easily understood because they use a simple subject, verb, object syntax.

Aporeto automatically generates the list of Network Policies that reflect how all PUs in the application have interacted for a period of time. This saves SecOps personnel a lot of time, is comprehensive and is precise. To refine the security of the application, Policies can be easily inspected and edited.

How Trust Profiles work With Network Policy

Automatic Encryption

Once the connection is established, if the Network Policy requires traffic between PUs be encrypted, the Aporeto Enforcer encrypts all data using the AES256 GCM algorithm. This provides encryption of data in flight with no changes to source code or key management administration required!

Aporeto Enforcer

Naturally, a Processing Unit (Linux process or Docker container) that wishes to interact with another PU does so over a TCP/IP connection. When the Aporeto Platform is installed on a node, it becomes a proxy for the TCP/IP stack in the underlying operating system so that all TCP connection requests go through the Aporeto Enforcer.

Runtime Environment

Aporeto provides comprehensive, automated security for cloud-native applications built with Docker containers, microservices, serverless architectures, as well as traditional Linux or Windows processes running on VMs or bare metal servers. It supports popular orchestration engines including Kubernetes, Red Hat OpenShift, Mesos DC/OS and Docker Swarm as well as popular infrastructure administrative tools including Chef, Puppet, and Ansible, to name a few.

Automated security for cloud-native applications built with Docker containers, microservices, serverless architectures.

Aporeto can be used in hybrid cloud environments that span on-premises, (private cloud) and public clouds. Applications can span multiple availability zones to ensure uptime and multiple clouds can be utilized simultaneously to provide business agility and optimize costs based on varying pricing policies. In order to support logically isolated virtual networks for billing, regulatory or other purposes, multiple simultaneous VPCs such as Amazon Virtual Private Cloud (VPC) environments are also fully supported. Aporeto has been designed with strict multitenancy security in mind from the very beginning. This allows a single instance of an application to serve multiple companies, business units or groups with full isolation based on hierarchical namespaces that can be arbitrarily deep and policies that may be propagated from parent to children namespaces to ease the administrative effort. Users are mapped to Roles within namespaces with predetermined Authorization Policies for data, filesystems, and API access control.

Next week, we will discuss the last phase of this 3-part series on Application-aware Security. Stay tuned! If you missed part one, read it here.

Recent Posts Secure Your Cloud Credentials with Identity Federation for Airtight Kubernetes Security Aporeto Launches New Identity Federation Capabilities for Kubernetes Pods & Istio Service Mesh, Delivering Security as Code to Accelerate DevSecOps Easy Application Network Encryption and Access Control Without Re-coding Your Application