Introduction
We are all witnesses to the changes that the IT landscape is undergoing. Critical infrastructures, applications, and data are moving to the cloud, leveraging either public, private or hybrid cloud deployments.
According to Gartner,“Cloud-first, and even cloud-only, is replacing the defensive no-cloud stance that dominated many large providers in recent years. The aggregate amount of cloud shift in 2016 is estimated to reach $111 billion, increasing to $216 billion in 2020.”
Employees, especially when working outside of the office, no longer need to connect to the corporate network or VPNs to get work done. To be as productive as possible, they often use personal devices and connect through public networks directly to cloud services, which means they’re left with very little protection.
Since traditional network security solutions do not offer good visibility into users’ transactions in this modus operandi, unsurprisingly, the top concern for security professionals is how to secure data in the cloud and protect against its loss. Inevitably, to solve these new challenges, existing controls should make room for new ones that ensure data is protected throughout its end-to-end lifecycle .
This post describes a novel approach of defending data whether in transit or at rest with four essential pillars in its foundation: user, device, network and service. The method, proposed by Coronet is grounded in a concept of trust and aims at addressing shortcomings of the existing solutions that have little-to-no visibility across all of the parts of the data security chain.
The crux of the system is a data fusion engine that incorporates a multitude of continuously monitored contextual parameters. Ultimately, the system produces a unified security posture, used to make intelligent access decisions and take automatic governance actions based on organizational policies.
Problem: Current Fortress-Based Approaches Are Broken
Most of the traditional information security solutions are based on the assumption that malicious individuals cannot pass the perimeter from outside. The implicit corollary of this philosophy was that additional security measures are unnecessary, since it was unlikely that an attacker would be able to access an organizational network in the first place. In today’s ubiquitous connectivity and cloud-based everything-as-a-service landscape, this fortress-based model of information security is no longer an effective way of protecting data. The problem is amplified by the explosion of mobile devices, used for accessing corporate resources. Mobile devices are more vulnerable to theft and human neglect than traditional technological means. A perimeter-based “trust-but-verify” approach does not compensate for these types of threats, because they would come from devices which are considered to be “trusted”.
Zero Trust Model
In 2013, Forrester outlined a “Zero Trust Model” (Zero Trust) of information security. It declared that the widespread M&M (“hard crunchy outside and a soft chewy center”) philosophy is obsolete as it doesn’t take into account the possibility of threats coming from an internal network.
The framework banishes the “trust but verify” approach (where you trust the inside user, but verify it is them), that dominated network security for a long time. It proves the “verify” part is difficult and inefficient in today’s landscape — where new vulnerabilities and attacks are introduced everyday and flips this mantra into “verify and never trust“.
Zero Trust spinned-off new security architectures and implementations. One of the prominent examples of adopting this strategy is Google, which has made large strides in implementing it, dubbed it “BeyondCorp” and, as with many other important contributions, released it to the community.
BeyondCorp Framework
Targeted attacks on Google (“Operation Aurora”) back in 2009, purportedly by China state hackers, became a game changer for the industry. It proved that traditional perimeter security controls fall short in defending against such sophisticated tactics. This realization prompted Google to undertake a new initiative to completely redesign their security architecture.
BeyondCorp meant to improve the security with regard to how Google’s employees and devices access internal resources. The fundamental idea is that access policies are based on information about a device, its state, and its associated user. Google has modeled Zero Trust by weaving in a key assumption that — both internal and external networks — are considered to be completely untrusted.
The following diagram depicts the architecture of BeyondCorp:
Source: “BeyondCorp: Design to Deployment at Google” (2016)
As illustrated in the diagram above, multiple data sources are interrogated to dynamically infer the level of trust to be assigned to a single user or device. For example, a device that has not been updated with a recent OS patch level, might be relegated to a reduced access level, and the user accessing applications from a new/unknown location might be assigned a different level.
SecureCloud – BeyondCorp for Cloud Services
Many organizations, enterprises and SMBs, which took note of BeyondCorp and found a good alignment with their operational requirements, are now looking for the ways to leverage it.
VPN solutions are being disrupted by alternative technologies such as Zero Trust , not only because the “network” is dissolving in today’s BYO and cloud era, but also because the end user experience is horrible. However, to implement it properly requires substantial budget, resources, expertise, and most importantly, a commitment from all levels of management.
In March 2017, Google started offering individual components of BeyondCorp to other organizations, in the form of Cloud Identity-Aware Proxy (IAP).
Unfortunately, IAP only controls access to applications that are running on Google Cloud Platform and narrows down customers’ options of deploying in-house tools exclusively into GCP.
Now that we set the scene for the zero-trust approaches and the challenges that impede their wide adoption, let’s take a look at Coronet’s implementation of the BeyondCorp framework, called SecureCloud. SecureCloud forges a path to a novel method for cloud security, resting on the concept of combined trust, derived from correlation of user, device, network and service postures. SecureCloud consists of two fundamental components, cooperating together in order to ensure that only trusted devices and users are authorized to access the requisite cloud services:
- “Cross-Domain Context Aware Proxy”
- “Context Monitoring Agent”
“Cross-Domain Context Aware Proxy” works in tandem with the “Context Monitoring Agent”, which is installed on endpoint devices, to secure access to cloud services based on the following information:
- User security posture & context
Examples: roles within the organization, privileges, profile, etc. - Device security posture – assessment aiming to identify device vulnerabilities.
Examples: outdated software, disabled antivirus or firewall, jailbroken device, etc. - Network security posture – monitoring of network traffic and suspicious networks to identify rogue and compromised networks and Wi-Fi access points used to conduct man-in-the-middle (MitM) attacks.
- Service security posture – auditing of cloud services security configuration to identify vulnerabilities, non-compliancies and insecure settings
The Definition of Trust
The requirements of what is “trust” are determined by each organization as a part of its policy definition. To make this process as streamlined as possible, SecureCloud takes a user-centric approach, and provides the user with a set of boilerplate workflows as an abstract way of looking at the problem in the light of specific use-case one seeks to cover. For example, if you’re interested in defending cloud services from intrusions formed as man-in-the-middle attacks, it’s an assessment of the network that matters, therefore the network security posture will be the key component of the protection rule defined by information security professionals operating SecureCloud within the organization.
“Monitored” vs “Unmonitored” Devices
SecureCloud distinguishes between monitored and unmonitored endpoint devices, based on the presence of context monitoring agent and the certificate installed together with it. To this end, the agent’s role is three-fold:
- Uniquely identify the user + the device
- Collect and communicate the device security posture to the “Cross-Domain Context Aware Proxy”
- Trigger automatic threat prevention actions and drive compliant behavior
This differentiation is important, since the very absence of “Context Monitoring Agent” results not only in the inability to tap into the device security posture, but also means a weaker authentication scheme as it’s implicitly used as a second factor of authentication (something that the user has).
It also lets SecureCloud administrators set device access policies and block any unmonitored devices or, in case of monitored endpoints, seamlessly grant secure access to the applications in question.
An End-to-End Example
In this example, let’s assume that a cloud application is protected by SecureCloud. The application is used by customer support engineers to review support requests, comment on it, upload attachments and when resolved, provide the customer with the resolution steps. The service is restricted to all engineers from any managed device.
- The user tries to log into customer support cloud service.
- The request is directed to the Cross-Domain Context Aware Proxy which asks for a client digital certificate.
- Once presented, the request is chained to the enterprise identity provider (IdP) for SSO authentication and, at the same time, the certificate is used to fetch the device’s unique fingerprint along with its existing records residing within the device inventory database.
- At this point authorization data is correlated with the collected device, network and service postures in order to make an access decision.
- SecureCloud continually monitors the component parts behavior to detect changes that impact the overall security posture and thwart the associated risk by adjusting access level, blocking access and terminating the authentication sessions.
Examples of such changes could be disabling the AV, connecting to suspicious Wi-Fi networks and security-related changes on the service side. - SecureCloud automatically triggers governance actions to minimize the associated risk of data loss.
Conclusion
As with many disruptive shifts that transform business and engineering processes, the zero-trust model poses challenges to companies that wish to adopt it. Therefore, those companies are looking for or are likely to seek out new alternatives to enhance and fortify their cloud security controls.
That’s what drove Coronet to bring forth an alternative framework, which is inspired by the principles of BeyondCorp on one hand and delivered as a service on the other. It extends the zero-trust model and augments it by tapping into rich contextual data, such as user, device, network, and service postures. Assessing a security posture at each junction of data flow enables one to take an holistic view of authorization decisions, enforce compliant behavior, and guide users to self-remediation actions.
Since BeyondCorp is a framework, and not a specific product, I expect that more security vendors and models will begin to surface to support this direction.
New, emerging security models propose more practical approaches that are not restricted to services running on-premises or on a specific vendor’s cloud infrastructure.
It is my belief that in order to provide cloud security solutions that works, new approaches should operate in a “set-it-and-forget-it” fashion, without interrupting the usual user’s workflow or hindering their productivity.
It becomes clear that in the current state of affairs with today’s bring-your-own-devices accessing cloud services, providing enterprise-grade security is a challenge, aggravated by the advent of new attack vectors. Consequently, I surmise that BeyondCorp-based security architectures will supplant legacy paradigms and will be widely adopted in the next few years.
[su_box title=”About Dror Liwer” style=”noise” box_color=”#336588″][short_info id=’65689′ desc=”true” all=”false”][/su_box]
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.