The Secure Network Principle

Admittedly, in many companies, the idea of a secure local network dates back to a time when the threat scenario in IT was completely different from the current scenario. Moreover, anyone who had to plan security for a company at the end of the 1990s did not have even a fraction of the tools available to admins today. Accordingly, most companies took a crude approach: The IT department simply divided the world into good and evil, or, as it was usually implemented, into "them" (evil hackers) and "us" (corporate users).

The people in charge followed through with this segregation with total consistency at all levels of the company's IT. Most admins still encounter this basic idea in the data center today (e.g., when there is an internal zone containing the most important systems that do not have a direct connection to the Internet). Also in the mix is the demilitarized zone (DMZ), to which access from outside is meticulously regulated by firewalls (Figure 1). The third network segment, the Internet, is evil, ugh, and to be avoided to the greatest extent possible. Larger enterprises and deployments have further refined this principle by segmenting their networks even further.

Figure 1: DMZ strategies are one of the oldest implementations of the secure local area network principle, but in today's IT, this approach has had its day.

In this case, the servers with the particularly important data are not located in the internal zone but in a "very internal" zone, which in turn is separated from what is already an internal zone by a DMZ with an integrated firewall. The division into segments has one flaw: Once you are on the "local network" with a client, you are given access to the other components of the setup, even if your intentions are dishonest. In environments of this type, a client gets access to infrastructure simply because it is in a certain physical or logical location.

What may not sound so dangerous at the data center becomes a real problem in the context of clients. Because the principle of a secure local network is so tempting at first glance, many companies have quickly applied it to their client landscapes, too. They are actively supported by many service providers who generate horrendous revenues with VPN solutions (Figure 2). The result is that some of a company's services can no longer be used in any meaningful way because they are practically inaccessible. If the company's own service laptop breaks down, an employee is practically unable to work until they are issued replacement hardware that is allowed to talk to the VPN.

Figure 2: VPN networks also propagate the principle of the secure local network but fail to acknowledge the complex attack scenarios of today.

Why the Secure Network Principle Fails

The big problem with the secure network idea is that it is patently false and didn't work well even years and decades ago. The idea that a client of any kind is trustworthy simply because it has access to a certain network segment is nonsense. The rule implicitly assumes that the users who use the respective clients know what they are doing and can handle the privileges they have been granted. The opposite is the case, as various examples from the past prove.

The stories in which security researchers succeeded in gaining access to employees' systems with floppy disks labeled "porn" left in company restrooms are the stuff of legend – because the floppies naturally contained viruses. In this case, the entire security strategy is doomed, because once an attacker has access to a system inside the setup, most security precautions no longer work.

Other examples of the nonsensical nature of the secure network approach are the countless cases of hacked Docker containers and OS images that are now roaming the net. Admittedly, from the user's point of view, it is tedious to build your own OS image from the providers' sources. The temptation to organize a ready-made image off the web is great, even if the image might be of dubious provenance. Admins struggle with the results of such thoughtlessness every day. If the ready-made image contains not only what it says on the box but also a virus or a cryptocurrency miner that generates traffic without end, security has already gone to pot.

To aggravate things, modern IT is extremely complex – companies that deal with IT forensics consequently make a lot of money, and for good reason. After all, in a software-defined environment, tracing the paths attackers have taken after illegally accessing a network element is difficult and often even impossible. Entire government agencies, hospitals, and companies go offline for days and weeks after such problems, until the network is patched back together with some degree of difficulty.

Security Until IT Shutdown

Companies with legacy security strategies are usually aware of their shortcomings, and the most abominable workarounds tend to sprout up: Mail servers are hidden in even deeper internal network segments, or complex firewall constructs are created that have to be extended by rules with hyper-complex processes. At the end of the madness is one big something that the admins of a company often can no longer keep track of in its entirety, partly because it is unclear which security measures take effect where and when. The usability of a company's IT services falls victim to the quest for the greatest possible and most complete security.

Administrators then come to the bitter realization that a client being located in a certain place (or not) cannot be a valid indicator for or against protective measures. Tools that propagate this approach (e.g., VPN-based products) are a relic of the past, propagating dubious security strategies and limiting the usability of services but offering few effective benefits.

Once this incontrovertible fact has seeped in, it sharpens the eye for real opportunities. Once again, industry leader Google has shown how this can look. At Google, the idea of the secure network became obsolete years ago. Instead, the company is pursuing a strategy known as BeyondCorp [1]. The core aspect of this strategy is that the focus is no longer on the individual client, but on its applications and the way they communicate with the existing infrastructure.