Neo..> Looks like we hooked a bunch of PharmaCORP users on our phishing trip
Trinity..> I’m in! I’m on the user’s laptop.
Neo….> What do you see?
Trinity…> I’m scanning now, shit there’s thousands of devices
Neo..> pull the memory and see what creds are there, any DA’s?
Trinity..> yeah, let me do an AD lookup and pull the group details
Neo…> sweet, find another device and open it up for me
Trinity…> found an unpatched linux host and connecting to our C&C
Neo….> thanks, I’m in – let’s get to work
Trinity…> I’m running the scripts now and scanning the network
Trinity…> Now connecting to a mix of Windows devices, unpatched, appear to have outdated AV
Neo…> cool, I’ve found what looks like an engineering lab environment and the hosts are logged into their SCM platform.
Trinity…> I’m connected to a filer, looks like a lot of HR and Finance data – going to dump that to our hosts
Neo…> sweet, I’m dumping source code
Trinity…> I’ve found a couple of old vendor accounts that are stale and changed their passwords, we can use them for return trips
Neo..> looks like we’ve got access to around 4,000 devices – time to run the ransomware script
Trinity…> sounds good, executing now
Neo…> great, we got enough data – lets encrypt and bail
Neo…> I’m out, time to send the demands ;-)

Does this chat sound like fiction, a movie perhaps? I’m afraid it’s only fiction. In real life, hackers are organized and there’s almost never just two of them. Real hacker chats are more like your enterprise Slack workspace, with groups, subjects and a lot going on.

As we see in this example attack, it’s common to begin with a phishing effort driven by clever social engineering aimed at getting the user to click a link. Once the user clicks the link, the bad actor gains control of the device. Once the device has been compromised, it’s easy to access the entire network and launch the full-scale attack.

As enterprise security professionals, it’s our job to stop this attack at some stage before the destructive full-scale attack can begin. One of the key traditional methods for doing this is training users to identify and avoid phishing attempts, alongside other strategies for keeping bad actors out entirely. While ideal and admirable, this is a losing strategy in the long run.

Consider this:

How many end points and users are in your company? No matter how much training we as users have, we are all humans. We will click links.

Every day, you run the risk of users clicking links and devices becoming compromised. This simply can’t be the only defense against a full-scale invasion of your network.

But wait…!

What if I told you it’s possible to halt hackers or bad actors in their tracks before they roam around your network?

Taking a page from biology

Imagine if our own bodies were as vulnerable to attack as our enterprise networks are. If you get any cut or scrape, the bacteria is in and will continue its attack until you are no more – not good. Avoiding cuts and scrapes entirely is not realistic, so our bodies are set up not to keep bacteria out entirely, but rather to contain and manage infections.

You can’t rely on never getting a cut or scrape to keep you alive, and you can’t rely on humans never clicking links for your enterprise network security either. So how do we set up our networks to contain inevitable intrusions?

Since over 80% of attacks begin at the end user and their devices, if we build a defensive infrastructure behind the user, we can contain the attack. How do we do this?

“Turn your corporate network into a guest network”

At some point, your company probably set up a guest network for your visitors. If not, imagine the Starbucks customer Wi-Fi.

In this case, you have set up security so that a visitor’s device is not allowed to see any other visitor’s device nor any of your devices. In fact, all they can do is get to the internet. With some straightforward technology shifts, we can adopt this same principle for our enterprise networks to build the post-user containment infrastructure we need. I propose changing how we think of network security for what I’ll call “office networks” – instead treating them all like “guest networks.”

Den, we’ve been down this road before…

It’s true that this concept isn’t new. Traditionally, we’ve tried to achieve this kind of containment by building very complex segmentation strategies – with less than stellar results.

In my opinion, we should simplify network segmentation and focus it at a high level on datacenter, lab, office and guest networks. I’ve run teams where the segmentation was crazy complicated and while it certainly helped protect and demarcate zones, it also meant more complicated firewall rules, more fragility, and slower execution times.

In my experience delivering Zero Trust over the years, I’ve come to the conclusion that more complexity doesn’t equal more security.

So, what I suggest is there’s no reason for a regular user to access anything in the Data Center directly. Instead, make all those applications available via your Zero Trust platform (which makes them just like all your other cloud apps).

Enforce all lab, engineering, and admin work via an Identity-based service tunnel which removes complex IP-based ACLs and enables just-in-time, privileged-type access via your Zero Trust platform.


OK, so where do you start?

  1. Deploy your Zero Trust platform – I could recommend a vendor if you like. Whomever your vendor is, just ensure they:
    1. Integrate with your IdP (I still recommend Okta)
    2. Integrate with a great XDR vendor like CrowdStrike
    3. Publish applications and services that exist in your Data Centers
      1.     Pick a Zero Trust vendor that does more than just web apps, one that supports many protocols, especially RDP/SSH for admins
      2.     You can replace your VPN if the vendor has a modern VPN that enables visibility into what applications are being accessed and easily ZT-enables them
  2. Now that users are accessing your apps via the internet and your new Zero Trust platform, it’s time to re-route DNS traffic so users are unable to access it internally.
  3. Exceptions, like printers, video conferencing, and IoT devices (let’s assume you have them): Ideally these are on their own segments, in which case you would enable access for only what’s required via your Network Access Control (NAC)/Firewall rules.
  4. Now, it’s a case of picking a small pilot group – a few subnets and applying rules via NAC blocking peer-to-peer access and enabling only internet access. Exactly the same as your guest network.
  5. Once you’ve ironed out the kinks, plan to expand by hitting more subnets until you’re done.

TIP: During an M&A, try not connecting the office networks to your corporate network, ensuring that all new users access your corporate apps via your Zero Trust platform. Read our past blog, Zero Trust for Mergers & Acquisition Scenarios.

With every subnet you can turn into a guest-type network, you’re reducing risk – so don’t get hung up on making things perfect or changing the network in one big go.  Consider a steady pace and remember each change reduces risk. Devices on those networks are better protected when a device is compromised (and it will happen).

I am Den Jones, I have a podcast and hold office hours for those of you who want to get more of my thoughts on improving security.

author avatar
Den Jones