Most enterprises today now strive for zero-trust (ZT) as a best-practice security stance. But it’s also the proposition that enterprises should take their most valuable digital assets and put them directly on the internet.
Sounds crazy, but it’s true. What could possibly go wrong?
But ZT has more rational foundations. Before ZT, IT security architecture was a burly firewall facing the internet, probably a DMZ zone between the outer firewall and an inner firewall where the public web servers live, and then behind the inner firewall was “corpnet,” a network of LANs that are implicitly trusted.
So what’s wrong with that traditional design? It’s a “crunchy outside, gooey middle.” It doesn’t take much to get inside: phishing, Wi-Fi sniffing, SQL injection, and just clamping a malicious node to the corpnet wires are all easily accomplished, and because machines on corpnet trust one another, it’s easy for hackers to move laterally.
In contrast, zero-trust proposes to remove the practice of trusting machines just because they are connected to corpnet. Instead, we must harden endpoints to the point where they ignore whether other endpoints are on corpnet, and instead demand proper authentication from all requests. Similarly, teams must also properly encrypt network communications with TLS or IPsec.
Once all endpoints are zero-trust hardened, there’s not much value anymore to the firewalls, and one can consider just exposing all of it to the internet. But how do teams know if all of their endpoints are hardened enough for direct internet access? It's not easy; the enterprise needs to assure that every machine exposed to the internet has been adequately protected, and that’s a lot of work. That’s why we need a zero-trust certification program.
The need for more security standards and guidance
Cybersecurity teams face difficult and complicated challenges, so guidance and standards from the government and the security industry help enterprises stay secure. As anyone with a smartphone knows consumer IoT business has flourished, resulting in millions of consumers installing smart doorbells, thermostats, security cameras, and appliances.
Unfortunately, the first wave of popular products were not so secure, resulting in massive hacking of these poorly-secured and not-at-all monitored internet devices, up to and including attackers cussing at children via the speaker in a “smart” thermostat. That was enough of a problem that NIST saw fit to create an IoT device certification program so consumers could know which IoT products are safe.
Last week, the NSA released guidance on how to deploy and operate ZT networks. But ZT has the same problem as IoT: how can purchasers know whether a given product is adequately secure to join an enterprise’s ZT fleet? Wouldn’t it be nice if products came with a NIST stamp of approval that this product has been evaluated and suitable for ZT deployment? Of course, but such a program would need objective criteria for whether a product comes ZT fit, such as:
- Most network ports closed by default.
- All open network ports only accept properly authenticated and encrypted connections, such as TLS, SSH, or IPsec.
- Teams can manage the platform remotely and securely.
- Management authentication is passwordless, so the management interface does not become subject to credential stuffing
The establishment of a comprehensive certification program for ZT means enterprises can take the next step in ensuring their ZT environments are not just theoretically secure, but practically impervious. Just as the NIST IoT device certification program has offered a beacon of trust in the consumer IoT world, the industry needs a similar framework for ZT technologies. A certification “stamp” would set the gold standard for security, and also offer a clear, objective benchmark for evaluating the resilience of ZT products.
There are of course many questions as to how we can accomplish this. Which organization would take charge of this kind of standardization? What are the precise benefits to becoming ZT certified? Would companies face penalties for opting not to pursue it? The industry needs to consider all these questions, but hopefully this column offers some motivation for further work specifying, standardizing, and automating the checking of whether computers and networks are actually ZT-ready.
Crispin Cowan, security architect, Beyond Identity
