Zero trust means a lot of different things to a lot of different people, but I think we all can agree that the zero trust is NOT a single product or platform but a collection of capabilities. The premise of zero trust and its framework can provide a more consistent security approach that reduces risk and increases security posture and overall effectiveness. Never trust and always verify!

So, what does Zero trust mean to me, well exactly that; trust nothing and no one capability is going to provide an end-to-end approach to zero-trust, and this is where unfortunately the complexity can very quickly hinder your ability to drive the outcomes realized by zero-trust.

What does zero trust really look like from my perspective? Well, let's take an example use case and that is a user with their corporate asset accessing the campus network connecting to an email service: Please note that changing the requirements may shift the capabilities required to achieve the outcomes you are expecting. The bottom line is that you never fully trust anything, and decisions need to be dynamic and changes as needed. You accept the level of trust achieved for a period of time based on your risk profile.

Let's peal back this onion and determine what I believe is required to achieve a zero-trust approach to this use case but before we do let's set up some conditions that we want to consider when going through this exercise.

• We need to understand the capabilities we are expecting to achieve zero-trust. This is not a vendor's product but a capability that moves us towards a zero trust model. It's time to challenge these flows with hacker/auditor mind set while achieving business outcomes.
• Prevention is key but cannot be the only thing we consider, we must incorporate all aspects of prevention, detection, and response. Prevention will never be 100% and we need to be ready for that "what if" scenario.
• Zero-trust is not just about technology and should include people and process although we will be focusing on technical capabilities throughout this article.

This process is meant to challenge and invoke discussion and is just a simplified example of the things to consider when moving towards a zero-trust model. Again, use case is campus corporate user accessing a service and the team needs to vet what are the capabilities required to drive a zero-trust outcome.

• Identity of user and asset and the posture (system hygiene) before it considers any connections to the network. What if the disposition of the asset changes once it passes authentication and authorization?
  • The ongoing disposition and health of the asset once connected cannot be fully trusted for the entire period it is connected. We need to be vigilant and adjust as the conditions change
• Should we care about a user clicking on a weaponized PDF from a USB drive and processes now making outbound SMB probes looking to move laterally, or what about screen scraping images of sensitive application data?
  • At any point multiple threat vectors can be exposed and automation can assist with threat mitigation and re-evaluation of an assets disposition.
• The asset will start communicating on the network once access is granted. Protocols will start doing their magic once invoked by any process. Do we trust the IP, DNS, Web, and Other based request coming from the asset?
  • We never trust and if requests are behaving in a manner in which deem risky we need to readdress our position of the asset.
• What about the payload itself being sent from the asset? Should we just trust the payload?
  • Just because you get access because the device connecting meets a level of trust does not mean we trust the payload and deep inspection to ensure nothing nefarious is taking place is a must.
• Flows will be coming and going and may or may not be trusted even if the asset communications has made it this far in our zero-trust approach. Should we trust them?
  • We need to ensure that any deviation from what is considered normal triggers an alert and perhaps an action to reassess the assets position on the network.
• The service the user and asset connect to will require authentication and authorization. Should the service mandate an understanding of how trustworthy the user and asset are before accepting any connections?
  • Just because the asset gets onto the network does not mean we trust it to access an application, this is an opportunity to re-evaluate the access to the service.
• The host providing the services should it be trusted automatically?
  • No, it should also go through its own criteria before accessing the network and only be allowed to communicate based on what is required for that service to function.
• The service will respond to the client. Do we trust the services payload when responding to the client?
  • Not a chance, we need to ensure we are inspecting and evaluating both sides of the connection.

You get the idea; it is a broad discussion and should be collaborative as you walk though your use cases to determine what capabilities are required to achieve a zero-trust model. Now wait, we only covered the prevention type capabilities but what about detection and response? Glad you asked ?

What happens if zero trust fails and a compromise takes place? Considerations must be made in regards to having the ability to not only detect activities that may suggest nefarious activities are taking place but also having the ability to reduce the scope and quickly respond. This can increase complexity so tying this into your zero-trust model should prove advantageous in the end. I have captured a couple of detection and response capabilities when considering your use cases.

• flow analytics (endpoint and network) to determine what is normal so we can identify what is abnormal and understand which process invokes which network connections
• centralized DNS analytics, full URI capture, and sandboxing with full analytics
• event packet captures and strong event workflows for complete analysis
• deep email analytics and full message tracking (since this is the application called out in the example flow)
• health status for the device and insight into denied authentications
• endpoint detection and response as a minimum but drive towards extended detection and response
• forensic snapshots with Mitre attack framework alignment
• host isolation (both at the endpoint and/or network layers)
• drive response and automation capabilities with full workflow/playbook capabilities
• threat hunting and incident response handling
• streamline event correlation for faster time to resolution
• vendor and third-party threat intelligence consumption and real time analysis

The below image is an example use case driving zero-trust methodology and extending the capabilities beyond prevention and includes both detection and response which is determined based on a company's risk profile.

Final thoughts: remember this is just an example of things to consider and one may add or remove elements based on the executive drivers, threats, and risks to the business. The focus is on capabilities and this approach drives the right business outcomes for the specific use cases in question. The process should include multiple stake holders, focus on the outcomes, and remove constraints in this initial phase which includes complexity, skill sets, and budgets. Removing the constraints allows you to drive the right capabilities to satisfy the need and move on to the next phase of the zero-trust model which includes people and process.