Blog / Apr 04, 2017

Wait, Don’t Throw Out Your Firewalls!

by wendy nather

Wendy Nather is Principal Security Strategist at Duo Security. She was previously the Research Director at the Retail ISAC, as well as Research Director of the Information Security Practice at independent analyst firm 451 Research. Wendy led IT security for the EMEA region of the investment banking division of Swiss Bank Corporation (now UBS), and served as CISO of the Texas Education Agency. She speaks regularly on topics ranging from threat intelligence to identity and access management, risk analysis, incident response, data security, and societal and privacy issues. Wendy is co-author of The Cloud Security Rules, and was listed as one of SC Magazine's Women in IT Security "Power Players" in 2014.

 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 whitelist 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.

The good news with the BeyondCorp concept is that you don’t have to make a change all at once. You’ve still got your fence, so every control you add from there is going to make things better. Corral your users, their devices, and your applications, and start adding controls to the groups that are critical and the most routinely exposed. For example, you could enforce a policy that privileged users of ERP and HR systems must use corporate-owned devices that have up-to-date software. Think about what building blocks you could use now to enhance your perimeter, according to what your organization really does. The firewall still has a place in your network; it just won’t be as lonely anymore.


To read more from Wendy Nather, please visit the Duo Security blog at


MODIFIED: Jul 24, 2017

Follow us on social media.