There are few people more passionate about the topic of zero trust security than Raj Bhadwar, who was a featured speaker at Machine Identity Management Summit 2023. He started his career as a security engineer at Netscape and then at AOL. And since then he’s led security at several additional organizations. He has a couple of patents. He’s on a couple of boards. And he’s written a couple of books. In fact, after reading this blog, you may want to check out his book The CISO Guide to Zero Trust Security. Here’s what he presented at Machine Identity Management Summit 2023.
What is zero trust?
So, we've all heard the term zero trust. We hear it all the time. Vendors use it. Forrester championed it. And even Gartner uses it. As do implementation teams. So many folks know basically what it is. It's a capability. It's a framework. It's a methodology that provides us the security controls to protect our systems and networks from advanced attackers and sophisticated malware.
In 2014, John Kindervag wrote a pioneering paper that launched zero trust. In a nutshell, zero trust is the fundamental concept that professes the principle of don't trust but verify. It outlines why you shouldn’t trust authentication or users or machines without performing a verification of that entity before allowing it to do whatever action it is requesting.
And basically what it boils down to is that an IT asset or user cannot be intrinsically trusted. All user and machine actions must be authenticated and authorized. And that needs to happen on a continuous basis. Obviously, all network traffic must be encrypted and we’re doing a pretty good job of that.
Also, any access that is provided to a user or to a machine needs to be provided on the basis of least privilege. And that least privilege access needs to be continuously assessed. The downside of this is that it leads to complexity when you start implementing security controls at various security domains. You will ultimately run up against skill set scarcity for operating at the various security control levels. And that can lead to performance issues if you start doing end-to-end encryption.
In practice, zero trust is basically done during security domain hardening, implementing security controls at each security domain. However, this is not a tool that you can implement and say, OK, we have zero trust. You must go in into each of these security domains at the device, in the network, or on the data layer and harden them using security controls that are very well defined in NIST.
Identity is the Linchpin of Your Zero Trust Strategy
Zero trust for devices
Let’s start with devices. All of us have devices. We have laptops. We have mobile devices. We have systems. We have servers. We have a lot of infrastructure out there especially on the device. So we need to make sure that the physical and the virtual devices are hardened, making sure that you know that access to those devices is tamper resistant.
Zero trust for network security
The other area obviously is network security. We all know about that. So, we’ve got to make sure that our public and our private networks are end-to-end encrypted. You shouldn't have a situation where you offload TLS at your gateway, at the load balancer, or at the at the web server and after that leave unencrypted traffic in the rest of your network. That's a big problem. So we shouldn't do that. We've got to make sure that you know we start implementing macro segmentation and then follow that up with micro network segmentation.
Zero trust for application security
The other area is in the application security realm. So you know there are applications everywhere in the cloud. There are legacy applications. There are applications of web services. There are APIs, micro services, SAS and more. You’ve got to make sure that as these applications that are operating in your ecosystems or in the ecosystems of your partners, access to these applications is secure.
But there are more APIs are the gateway to the application world these days. Everything is an API and we've got to make sure that these APIs, as they are exposed, are protected. API keys, for example, have been commonly used. We shouldn't be using them because API keys are actually a very long lived. So if you are using API keys, you've got to make sure that they have each Mac protection on them.
Zero trust for infrastructure and workload security
The other area is infrastructure and workload security. We are all in some kind of a cloud journey and all of us are using infrastructure as code. We are using platform as code. But it’s not possible to do that manually at scale. So we’ve got to make sure that infrastructure and workload security are indeed hardened. Because if you know there's a configurational problem with infrastructure as code, whether it’s configurational drift or user access issues, then your entire infrastructure could be at risk.
Zero trust for OT and IoT
Now on to OT and IoT security. So we all are running a lot of IoT, and we've got to make sure that we know IoT devices are properly protected. So what I recommend is, especially for IoT and even for OT, is that they be segmented off the corporate network. They should not be sitting on the corporate network. They should have their own DNS server. They should run their own firewall stack. They should be segmented off on their own VLAN or other networking constructs so that you know if there's something were to happen in those in the IoT RAM.
Because the problem is that a lot of the IoT devices are kind of still unmanaged. The ecosystem that they run on, sometimes they have vulnerabilities, and the patches are not available. And patching IoT or OT device has also been difficult. So there are some fundamental network segmentation constructs that are available to make sure that we can protect our IoT and OT systems. So, I think that's an area that we should not kind of sort of neglect just because of IoT.
Zero trust for cloud security
The other area is of cloud security. We all are on cloud journeys. So we've got to make sure that as we go into the multi cloud-ecosystem because all of us now at least have maybe three or four cloud providers. And then you add the SaaS on top of that, you add Salesforce, you add various other constructs and suddenly you have an ecosystem that is very diverse, and they don't share identities, right.
But they have their own authentication schemes. So making sure that the cloud security realm of the identity is that glue vehicle, the identity and access management paradigm for cloud is uniform and standardized and that can be done through federation.
The other thing is that what I have done with a lot of success in cloud security realm is publishing security patterns to the development teams and to the cloud infrastructure teams. That way I can make sure that they securely configure a firewall or a VAF or segment or key management in the various types of clouds that they may be operating in. This is important because sometimes the cloud native services are a little bit different.
Zero trust for machine identities
And now machine identities. So you know the certificate issuance must be done in an automated manner and it has to be done securely. So that whether you are using an internal CA or using an external CA, the certificate expiration must be managed in an automated manner because certificate based authentication is key in the machine identity or in the machine security space. And there are few other tokens that it can be used as well.
So you need to make sure that these certificates or so-called tokens are stored in a hardware security module that is first validated. And automation is key in that area. So I think we’ve got to make sure that in the machine security space these capabilities are implemented and obviously there. And last and not the least, we've got to make sure that we do have the capability to do breach remediation. If there is a breach, how do you remediate that and how do you recover from that.
If for example if the if the CA itself was compromised, now how are you going to recover from that? Because if the private key is stolen, how are you going to deal with that? So you must make sure that you have dual root CAs, or you have recovery capabilities built in, whether it's a domain controllers or other issuing authorities. So you must think of this in advance.
Conclusion
In summary, the Zero Trust is a framework. It’s a methodology. And it is not a tool. It is not something we can deploy and say that we have zero trust. It is basically security controls that you all already have, that have been published by NIST. You must implement them in the various security domains you have. And you must do it in a way that matters to your specific business requirements, based on your risk tolerance. So that's what zero trust is.
We should prioritize which domain we should start our zero trust journey with and then slowly build upon that. And it can be implemented using existing security controls that we know about. We just must start that journey and we should again use risk based and a phased deployment approach. You don't want to try to do all of this in one year and one release or in one phase. You’ve got to slowly start in a multi-year, multi-phase journey.