Before you can go beyond something, you have to get there first.

The perimeter’s imminent demise has been forecast by any number of people and, to a certain extent, they have a point. Once you start placing lots of gates in your fence and move half your livestock outside of it, you start to wonder why you still have a fence. But even if you have a BYOD policy (Bring Your Own Dogs), you want to make sure they’re well behaved dogs—and you still have to protect the cows.

Plenty of cloud-first organizations don’t have a classic network perimeter because they never had to build one, but if you asked them to identify what was “theirs,” they could still tell you their perimeter is enforced by a combination of logins, encrypted network connections, and whatever tenancy controls their providers have in place. But most existing enterprises didn’t start in the cloud, and they still have physical assets that are networked on their premises.

Many of these companies with networked assets didn’t get an effective firewall until recently, if at all. They thought their Internet Service Provider was taking care of it; or they had something that could be used as a firewall, but didn’t realize it; or the firewall was set up by an employee who has departed, and since it didn’t cause anything to break, they left it alone. It wasn’t until they were confronted by an external threat (an attacker or an auditor, take your pick) that they realized they needed to step up their perimeter game.

So, it doesn’t make sense to say that the perimeter is dead, but the perimeter does need to change along with that organization. Wherever your data lives, you need a perimeter that’s appropriate to the situation, and to the risk that you need to mitigate. If your cows are happy where they are, you should keep your fence, but add controls for the eventuality that someone gets inside the fence (or you have a rogue cow). And who let the dogs out? Someone’s always letting the dogs out. So, make sure they have protection that travels with them.

This is the idea behind Google’s BeyondCorp security model in which they recognized that their former perimeter didn’t address the new reality. They built a new, flexible set of trust boundaries based on the combination of validated user and validated device. With this model, you can still keep track of what data belongs to the organization, but continue to protect it no matter where it resides (internal, in the data center, or external, in the cloud). You protect it by more carefully vetting who can access the applications, from known and trusted endpoints.

From a technical point of view, you will need several components to play a part in this architecture:

• User/group database. This is where you keep the information and attributes about your users, and group them where necessary according to organizational, geographical, or other aspects.
• Device inventory database. An up-to-date repository for information on all devices you are allowing to access the network, including type, purpose, network addresses, asset tags, components, configuration, and responsible user or maintainer.
• Managed devices. If you do not allow BYOD, this will be the allowlist of corporate-owned devices you will allow to access your resources.
• Certificate issuer. This is used to mark your managed or otherwise approved devices with a client-side certificate.
• Trust inference. Deciding what conditions will cause you to place or lose trust in a given device (such as hardware changes).
• Access control engine. The location of all your access policies, such as “only this group of users, together with their up-to-date, assigned managed devices, may use this sensitive application.”
• Access proxy. The component that carries out the connections and policy enforcement. Note that most reverse proxies are only used for one direction (from “outside” to the “inside” of the network), but this one will have to handle connections for internal clients, as well.
• Single sign-on. Make it much easier on your users by providing one jump point for access to all of their applications and systems.