BeyondCorp – The Identity Management of the Future

Google’s BeyondCorp is a bold step towards de-peremiterization access. Unlike relying deriving trust based on network perimeter, the system works on the principle of “zero-trust”. That means trust is inferred by validating each access request and not based on the network boundary from where the request has been originated. Typically, employees access to enterprise systems is  provided by the ability to connect via VPN. A VPN extends an extranet into secured extranet. A gating process authenticates a user before allowing to create a VPN channel. Enterprise applications are generally available into the intranet and once someone gets access to intranet,  they can get access to many enterprise applications and the validation of the request varies based on the strength of AAA mechanism of the respective application. So a breach of perimeter security allows an attacker to relatively easily breach internal application. With the growing mobility of users and increasing use of BYOD, maintaining network perimeter while providing better user experience to the employees becomes challenging. So, a new approach was required. Google came up with BeyondCorp to implement the approach.

BeyondCorp is built on the following premises:

1. Access requirements are organized into Trust Tiers representing levels of sensitivity. For example, a public application where very few or no sensitive information is stored or processed can be mapped to low trust-tier and hence the requirement to attain the trust tier is less stringent. Whereas, a system handling highly sensitive information must be accessed by a user who has attained higher trust-tier and attaining that would require a stringent claim validation process.
2. Any asset – server, hosts, services, applications are considered to be Resources and an enumeration of them maintained in a management system. Every resource must be assigned to a trust tier.
3. The Trust Inferer is a system that continuously analyzes and annotates device state. The system sets the maximum trust tier accessible by the device and assigns the VLAN to be used by the device on the corporate network. These data are recorded in the Device Inventory Service. Reevaluations are triggered either by state changes or by a failure to receive updates from a device
4. The Access Policy is a programmatic representation of the Resources, Trust Tiers, and other rules that must be satisfied for a successful authorization
5. The Gateways are the components that are accessed by resources. Gateway would be protocol specific. Example: SSH, HTTP, IEEE 802.1x gateways
6. The Access Control Engine is the Policy Decision Point (PDP) that executes policy validation rules. The Gateways host Policy Enforcement Points (PEP) and they work in tandem with Access Control Engine to implement authorization policies. Authentication can be integrated with the Authorization system.
7. The Device Inventory Service continuously collects, processes and publishes changes about the state of known devices

The following diagram visualizes BeyondCorp components and access flow. The event flows are explained by an end-to-end example.

End-to-End Example

Let us assume there is an application to be taken to BeyondCorp which allows a subset of engineers to review engineering design of a manufacturing plant. The application is identified by a URL: designer.capgemini.com. The application must be accessed from any managed device without the need of a VPN connectivity.

Configuration

Configuring Internet Facing Proxy: the owner of the domain registered the application to the access proxy. It configures the backend where the application is hosted and other traffic related parameters. The owner also makes sure that the domain name is registered to public DNS and CNAME points to the access proxy.

Configuring the Access Control Engine: the access control engine is configured with a default rule that restricts access to the specific set of engineers. It is also configured with two more rules to further restrict access: a) to managed device with highest level trust and b) a subset of engineers that are allowed by default rule to the highest level of trust.

Scenarios

• An engineer accesses the application when she is connected with enterprise LAN
  • The engineer connects using a laptop provided by the enterprise. The carrier network could be anything – WiFi at a public place or Wired Ethernet by a broadband service provider. There is no need to connect using VPN.

• An engineer accesses the application when she is not connected with enterprise LAN
  • The engineer connects using a laptop provided by the enterprise which is connected to the enterprise LAN. The laptop provides the device certificate in IEEE 802.1x handshake with the RADIUS server. Assuming a valid certificate is provided, the laptop is assigned an IP address on an unprivileged network. If the device is not a corporate device or the certificate has been expired, it connects to a remediation network with very limited privilege.

Flow of Events

1. The request is directed to the Access Proxy (as pointed by the DNS record of capgemini.com)
2. The laptop provides device certificate
3. The Access Proxy does not recognize the user and redirects to the SSO endpoint
4. The challenge-response for authentication happens and after successful authentication, the SSO system issued a token and redirects back to the Access Proxy
5. The Access Proxy now has a device certificate which identifies the device and an SSO token which identifies a user
6. The Access Proxy raise validation requests to Access Control Engine
7. The Access Control Engine applies the rule (as configured; see the configuration section). The following general checks are made:
   1. The user is confirmed to belong to the restricted group
   2. The user is confirmed to attain sufficient trust level required to access the resource (i.e. application function)
   3. The device is confirmed to be a managed device with good health
   4. The device is confirmed to possess sufficient trust level
8. If the Access Control Engine validations (all of them) passed, the request is granted else denied
9. Every request directed towards the application will undergo all the steps described above

Implementing BeyondCorp has its own challenges:

1. Data quality and correlation: for a large and dynamic enterprise, the number of devices are likely to be large.
2. Data set is sparse. Few quick example will illustrate the challenges: MAC addresses may collide, hard disk might be fitted to a different motherboard. There seems to be an endless variations and the heuristics to handle them becomes very complex for a small variety of corner cases in order to get closer to 100% accuracy and a tiny portion of use cases can lock up hundreds of other valid cases.
3. Pipeline Latency: since data about a device and user is ingested from different sources, it introduces latency that may impact user experience adversely.
4. Communication and acceptance: fundamental change to security infrastructure can at time create problems for users, at least at the beginning. So, to get the system accepted, strong and clear communication about the benefits and adequate remediation services are must for successful implementation.
5. Disaster Recovery: since BeyondCorp infrastructure is complex, a catastrophic failure would stop even the support staff to get access to the system leading to the total lockdown of corporate systems. So, a very strong but very selective privileged access must be provided to very trusted administrators with strong non-repudiation in place