There was a day when the bad guys were obvious—they were the people “over there.” Lines existed as clear delineators of who you could trust and who you could not trust. On a battlefield, you knew that the people on your side of the line, wearing the same uniform, were your people. They had your back.
The same used to hold true in IT and computer networking. By simply drawing a line at the boundary of a network, one could say that all of the bad guys are “over there,” and all the good guys are “in here.” So, we could simply put up a network firewall and build a boundary of trusted and not trusted. This concept worked great for years as long as the firewall was configured correctly. Of course, there were always those stories of someone forgetting to lock down a port or subnet, thus allowing the riffraff of “over there” to infiltrate the hallowed halls of the private network.
In today’s mobile world, there are no obvious boundaries anymore. Devices like mobile phones, laptops, and tablets move across the boundaries of networks multiple times a day bringing who knows what with them. Like a promiscuous rodent, it’s downright scary to think what infestations these mobile devices are bringing to your sacred, hallowed, “private” computer network. To add to the problem, we now have IoT devices like printers, energy monitors, thermostats, security cameras, and badge access systems that live on the network, bringing a new level of unprotected guests that should never be trusted. Like your daughter’s new boyfriend, you’d better watch those IoT devices like a hawk!
Yes, folks, it’s a scary world out there and when it boils down to it, there isn’t anyone you can trust! Ultimately, that is the point that I want to make—no person, device, or even software application that you should ever inherently trust just because it is on your private network. I once came across a quote that states, “The saddest thing about betrayal is that it never comes from your enemies.” I believe this adequately describes today’s IT landscape. In short, it’s not the devices outside your network that you should worry about; it’s the devices on the inside that should worry you.
Any network, private or not, where the devices connected to it come and go is no longer a secure network. It has been reduced to nothing more than another internet hotspot. It doesn’t matter if you have VLANs and the most sophisticated firewall at the ingress/egress of that network, you now have a dirty network where who knows what kind of debauchery is occurring within the bits and bytes of its subnet walls.
For this reason, highly secure networks have implemented an air gap strategy. Although air gap networks are much better for security, they are not efficient, not convenient, come with a much higher overhead (and thus cost), and are ultimately limited in versatility and adaptability to the future needs of the organization. If you find that you are fine with these downsides, are in a highly regulated industry that requires this level of air gap security, or are too stubborn to consider a better way of doing things then go ahead and stop reading. Let’s admit it, your time is better suited to more productive things.
For the rest of you, I could spend the rest of this article highlighting the obvious reasons why dirty devices on a private network are bad. However, I want to focus more on the non-obvious reason—trust. Trust between network devices. Trust between peer applications. Trust between applications and operating system. Trust between operating system and chipset.
Anyone who assumes that they have built a sufficiently strong, tall wall and treacherous moat around the perimeter of their precious network (we call this a castle and moat network architecture) must have forgotten the story of Troy and the infamous Trojan horse. If you’ve never heard the story of the Trojan horse, then I invite you to read it. One of the leading causes of network security breaches is social engineering leading to a user inadvertently opening a tunnel into your private network. It worked for Odysseus thousands of years ago and is just as effective today.
Let’s dig a little deeper to better understand the problem with trust. Today’s IT puts a lot of effort into monitoring traffic coming and going across the network boundary. They rightfully assume that any threat will come through the internet ingress. However, today’s threat actors know that the front door to the network is being closely watched and any brute force entry will come through that door. Therefore, the bad guys (let’s give them the ominous name of “ethical crusaders”) don’t want to waste time trying to break down the front door. Instead, they want to take advantage of the trust that IT has already bestowed on the private network. If the ethical crusaders can simply get an app downloaded onto any device connected to the private network, then they are “in” and can start wreaking havoc. The crusaders know that they have free reign once they are running on a device connected to the private network because it is trusted. Local subnet traffic isn’t closely monitored and it contains easily discoverable services that assume trust which they can exploit. How do the crusaders download their app onto a trusted device? Where do I begin? Social engineering techniques like phishing emails, malware, email attachments, free mobile apps, image/video file sharing, software vulnerabilities, and many others.
Case in point, some of the biggest cyberattacks in recent history involved simple social engineering attacks based on well-known network vulnerabilities that were exploited because of trusts inherent on private networks. Sony was hacked not once, but twice–PlayStation Network and Sony Pictures (a reminder that one must never upset the North Koreans). Target had its own POS devices compromised allowing credit card data to be sent directly to the hackers in virtual real-time as a credit card was swiped. Adobe had the entire source code for the ColdFusion product stolen as well as parts of the source codes for Acrobat Reader and Photoshop. All of these attacks took advantage of social engineering techniques that allowed a machine to be compromised whether that machine was fixed to a private network with internet access or a device that was compromised on the outside and brought inside the private network. Let me reiterate, these were all private networks. Needless to say, these corporations are large enough to have the IT manpower to prevent successful cyber-attacks. If the big boys can’t defend their private networks, what hope do the rest of us have? There must be a better way, right!?
Zero trust—trust nothing
The good news is that there is a better way. However, the better way requires a different way of thinking. It also requires changes in how software is written, something that will take time and cooperation amongst software technology companies throughout the industry. It puts emphasis on rigorously proving the identities of people, devices, and software services and then using granular access controls to grant the minimum necessary rights to those validated people, devices, and software services. No longer can we assume trust based on network proximity or domains. Simply put, trust no one, trust nothing.
Maybe you have already heard of the term zero trust. It reached fad status in the past year or two. Fad or not, it is a real concept that has a lot of validity. The problem is that it does require fundamental changes in network architectures and software stacks. Let’s dig a little deeper into the zero trust mantra.
According to Doug Barth and Evan Gilman, authors of the book, Zero Trust Networks: Building Secure Systems in Untrusted Networks, there are five fundamental assertions about networks:
The network is always assumed to be hostile
External and internal threats exist on the network at all times
Network locality is not sufficient for deciding trust in a network
Every device, user, and network flow is authenticated and authorized
Policies must be dynamic and calculated from as many sources of data as possible
The challenge to moving to zero trust networking begins with the software stacks many entities currently use. Many of these software stacks are on-premises and legacy, meaning they do not follow the zero trust mantra. It will take time for these on-premises systems to catch up. It could be years before real progress is realized in the on-premises software space. Wait a minute. If on-premises software stacks have to change in order to begin implementing zero trust networking, and it could take years for those on-premises software stacks to change, it sounds like all hope is lost for the time being! Ugh! No, hope is not lost. In the next part of this series, I’ll discuss steps you should consider now to implement zero trust in your corporation.