Most companies operate with a traditional perimeter security model, where the firewall guards a border.

In a conventional setup, “inside the firewall” often means “safe.” The firewall protects the internal network from external access. You type a username and password into your device to authenticate and connect to a server on the network. That’s a standard client-server setup that most system administrators recognize.

When you venture outside the firewall, you’re no longer safe. Want to connect to your server? Set up a virtual private network (yes, the much loved VPN) to allow your system to act as if it’s on the corporate network–even when you connect from home or a coffee shop. The VPN encrypts network traffic between your device and your company’s systems.

Get past the firewall and very few defenses protect your network in a conventional setting.

A few Googlers rightly recognized there may be a few issues with this conventional configuration. First, people are mobile these days; lots of devices connect from outside the firewall. Second, VPNs require setup that isn’t always easy for everyone. And third, attackers go after devices (like laptops!) that connect to networks, since devices tend to be less secure than servers.

Google’s “BeyondCorp: A New Approach to Enterprise Security” seeks to solve each of these problems.

The BeyondCorp model

BeyondCorp envisions a world where attacks occur anywhere–from inside or outside the firewall. BeyondCorp devises a defense that doesn’t depend on a firewall. (If you’re of a certain age, feel free to envision an alternate universe where Ronald Reagan says, “Mr. Google, tear down this firewall.”) Instead, BeyondCorp presumes that app access occurs from a browser. This has a few important implications.

To connect, both you and your device need to be authenticated. People still need to login. Strong passwords help, as does two-factor authentication. No surprises so far.

But device data increases in importance. The BeyondCorp approach verifies not only your login, but also your device security state and health. Connect with an unpatched, unmanaged device, and you might not be allowed access.

An administrator may configure trust levels for different sets of data. From an unpatched system, you might able to view the cafe menu but not access sensitive financial data, for example.

Google’s BeyondCorp model adds one more element: access to applications with a reverse proxy. You may be familiar with a forward proxy: configure your system to connect to another system elsewhere. Network requests from your device will appear as if they’re initiated from the proxy server to which you’re connected. You know information about all three systems: your system, the proxy you used, and the target server you accessed.

A reverse proxy does the opposite: it hides the target server. When you connect to a domain, such as, the reverse proxy first encrypts traffic. The proxy then checks that the user and device are allow access to the application. Finally, the proxy routes requests to the appropriate application. (You know information about only two of the systems: your system and the reverse proxy you accessed.)

Unlike a VPN, a reverse proxy setup doesn’t require users to configure anything. Type a web address, and the reverse proxy secures the connection and performs authentication. This eliminates a lot of support headaches for enterprises.

The perimeter-less BeyondCorp approach works well for today’s mobile workforce. The approach might require significant changes to your company’s systems–and, more critically, a fundamental shift in how you think about security. (Read Google’s “BeyondCorp: A New Approach to Enterprise Security,” by Rory Ward and Betsy Beyer, or watch an older video presentation on the topic.)

I can imagine that once you’ve lived in the BeyondCorp environment, a return to a corporation that still operates with restrictive firewalls and VPNs might seem like a return to medieval times.

Has Google’s BeyondCorp approach prompted you to rethink your organization’s security perimeter? Why or why not?