BeyondCorp, Zero Trust, SDP & a Grand Unified Theory of Network Security

February 28, 2017 |
Decorative image of padlocks over computing

Let me begin with the bad news – I’m not going to be able to articulate a Grand Unified Theory in this short blog post. However, what I am going to do is to provide an argument and structure for how we should be thinking about network security in 2017. It will help you begin the process of creating a network security architecture and philosophy that’s your own, and is appropriate for your organization.

It’s clear to me that there’s a sea change coming in terms of how enterprises are approaching network security, which is finally, in some ways, “catching up” with the rest of the enterprise. (There are some ways in which network security may be leading the enterprise, in particular around IoT, but that’s a topic for the future).

If we look at how different constituencies – enterprises, vendors, and analysts – are talking about how they want and need to secure organizations, things are starting to coalesce around a particular set of requirements. These requirements make up an interesting challenge for network security.

Organizations want InfoSec systems that are:

  1. Identity-centric (sometimes called user-centric)
  2. Automated, to dynamically adapt to both user and server changes
  3. Fine-grained
  4. Able to simplify and unify security across hybrid environments

After reading this list, it should be apparent that while these requirements can be (and often have been) successfully met at the application level, enterprises have largely failed to do so at the network level. In fact, it’s now becoming widely accepted that these requirements simply cannot be met with traditional network security tools or approaches, and that a new security architecture is required.

New Network Security Architecture – Software-Defined Perimeter, Zero-Trust & Google’s BeyondCorp

There are three prominent examples of new architectures in the industry – the Software-Defined Perimeter, the Zero-Trust model from Forrester, and Google’s BeyondCorp architecture. One way to view these three approaches is not as technically defined architectures, but rather as security systems that exhibit a particular set of desirable attributes. For this article, I’m going to treat these three architectures as if they were one uniform thing, which in reality they’re most assuredly not. They have enough in common that this is a useful (albeit temporary) simplification while we discuss the four requirements above. In a future blog posting we’ll drop this pretense of uniformity to compare and contrast BeyondCorp and the Software-Defined Perimeter architecture in detail.

So let’s dive into our discussion of these emerging security requirements, and their implications on network security.

1. Identity-Centric Network Security

Our new security system must be identity-centric, and not network-centric. (We’re focused on user access for this discussion. In fact, server-to-server access should be modeled in a way that’s identity-centric as well, which we’ll cover in a future blog post).

While of course our networking infrastructure is (and will remain) network-centric, and there will always be a place for managing IP addresses, subnets, and ports, our network security systems must have policies that are built around users and attributes rather than IP addresses. This is the fundamental gap that is bridged by these new security architectures:

Defining and enforcing identity-centric security policies on top of a system that’s IP-address centric.

Our three network security architectures accomplish this by overlaying network access control points on top of the enterprise’s varied network infrastructure. This enables the system to control individual user access to systems, regardless of user location, network topology, or IP address sharing. It also enables the creation of access policies that are descriptive and meaningful for all stakeholders – security, business, IT and compliance teams. In this new world, these people can now have a fruitful discussion about a policy such as “People on the finance team can access the ERP system web GUI if they’re on the corporate network OR if they’ve authenticated with multifactor”.

2. Automated Network Security

Our new security architecture must embrace continual changes among users, devices, and server resources. Users change locations and switch from laptop to tablet to phone. Virtualized and cloud-based servers are constantly created and destroyed. In this ever-changing environment, driven by the business imperative for innovation and speed, security teams must leverage automation. Falling short on either security or compliance dimensions is not acceptable, and it’d be impossible to keep up, even with an army of manual administrators.

Automation is truly the only way that security teams can keep up with the pace of the business while maintaining necessary levels of security and compliance. Automation must be driven by identity-centric policies, which control the actual enforcement mechanisms.

3. Fine-Grained Network Security

These policies must allow for fine-grained control of user access to networked resources, with far more precision than was previously possible. That is, security policies must be able to control not only which servers and services that specific users can access, but also the circumstances under which they can access them.

Traditional security tools often grant users access to entire network segments or VLANs, which is an unnecessary violation of the principle of least privilege. It also provides a large (and tempting) attack surface for adversaries, and makes compliance reporting a difficult task. By only exposing those specific resources that each user needs to be productive, the attack surface is minimized and compliance reporting is vastly simplified.

4. Simplify and Unify Security for Hybrid Environments

The “new normal” for today’s enterprises is a complex and heterogeneous environment, with computing resources spread across on-premises, cloud, collocated, and customer or partner data centers. These disparate environments are built with different stacks, managed by different tools, and operated by different teams. The result is a fractured view, with no consistent security or policy model.

Our new security system must embrace this complexity, and simplify it by providing a unified security and policy model that spans the many disparate computing environments in place. (It can do so by overlaying an identity-centric network security model on top of the infrastructure – see an architecture overview here).

In Conclusion

A Grand Unified Theory of security may never be possible, judging by the sheer number and variety of security technologies, architectures, and vendors. But that doesn’t mean we shouldn’t work at making progress. And I believe that these new security architectures – the Software-Defined Perimeter, a Zero-Trust Model, and the Google BeyondCorp approach – are important advances that will become widely adopted in the next few years.

We’re already seeing this – our customers, applying the Software-Defined Perimeter, have begun the process of transforming their security, compliance, and IT operations, in a way that meets the four requirements explored above.

In my next blog posting, I’ll be diving into the Google BeyondCorp architecture, comparing it with the Software-Defined Perimeter architecture, and posing some questions about which may be right for your enterprise.

Enterprise Strategy Group Report on Software-Defined Perimeter

Back to Blog Home

Jason Garbis

Vice President of Products, Cryptzone
Jason Garbis is Vice President of Products for Cryptzone, where he's responsible for the company's product strategy and product management. Garbis has over 25 years of experience with technology vendors, including roles in engineering , professional services, product management, and marketing. Jason joined Cryptzone from RSA, and holds a CISSP certification.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>