Zero Trust | November 9, 2022
By Keith Bromley : Sr. Manager, Product Marketing
It is a Journey and not a Destination
Starting and adjusting along the way is key.
Once you start planning a Zero Trust architecture, you’ll find out pretty fast that there isn’t a single Zero Trust solution.
Once you start planning a Zero Trust architecture, you’ll find out pretty fast that there isn’t a single Zero Trust solution. As many people say, it’s a journey, not a destination.
The first thing to consider is a look at the original framework that John Kindervag (when he worked for Forrester Research) designed. This lets you get an overview of the original concept. For instance, the original Forrester framework contains seven pillars as follows:
1. Network – the ability to segment, isolate and control the network
2. Data – secure and manage the data, categorize and encrypt data both at rest and in transit
3. People – secure the people using the network and business infrastructure
4. Workload – secure cloud networks, apps, and other things used to make businesses operate
5. Devices – isolate, secure, and control all devices accessing enterprise resources
6. Visibility and Analytics – provides useful analytics and data points for correlation
7. Automation and Orchestration – automate Zero Trust elements and provide more control of disparate systems
Based upon this input, you can start to map that to your architecture goals and requirement. This is where you probably want to look at best practice implementation guidelines like the following:
Personnel in government agencies should also review OMB memorandums like M-22-09 and M-21-31.
Another good source of information can be found in this white paper – What You Need to Know for a Successful Zero Trust Security Deployment. This paper will give you a lot of information on network visibility. Creating visibility and analytics (number six in Forrester’s list above) is one of the most overlooked, but most important considerations of any security architecture. After all, if you can’t see the threat, how do you plan to stop it? Unless you get very lucky, the answer is you won’t stop it.
After you’ve done your general research to jump start your intellectual security juices, then you’ve researched best practices, then you’ve designed your architecture, don’t forget to validate it. Validation is needed for all parts of the architecture.
Here are some validation examples:
- Have you verified the actual performance of each type of component?
- Did you test your security tools to see if they really have the visibility they need to detect and mitigate threats?
- Do you have a plan to validate that your Zero Trust solution is configured correctly and working as designed?
The first important validation component needs to be conducted by the design so that they have verified the actual performance of each type of component. Unfortunately, spec sheet data is usually captured by the manufacturer in a lab under ideal situations. What happens when the equipment is stressed under real-world conditions? Does the security component actually process as much data as fast as stated on the data sheet or is the performance reduced? Most equipment will have diminished load under high stress. This may mean that you need more components than you originally designed for.
Second, are your security tools seeing everything they should be. You should validate this by making the equipment process realistic traffic that threats injected into it to see what your tools find. You should also analyze the traffic you provide to the tool. As an example, if your design includes pulling data from SPAN ports, then you may not even be feeding the tools all of the data as SPAN are known to drop data. In addition, if you are using a CPU-based network packet broker then that device could drop packet data and not tell you either. Therefore, your security and monitoring tools really need to have complete visibility to detect and mitigate threats.
The third area is to focus on continually validating your production architecture. Is it working as designed? Is it stopping known malware? Is the right analysis being conducted and forwarded to your SIEM? You don’t want false security that the design is working when there may be hidden problems.
If you want more information on these topics above, read this whitepaper. More resources are located on the Zero Trust Resource page.
