By Jamie Doherty
Zero Trust means exactly that: trust nothing and no one. Applications and networks have co-existed with nearly unlimited trust since the beginning of time to achieve interoperability. The problem with that philosophy is that threat actors are taking advantage of that inherent trust in this new landscape. Administrative tools and networks are now ground zero for cyber-attacks. Neighboring applications which are not directly related to each other are becoming launch points for criminals and your end users are being targeted for ransom.
How can we defend against it? It’s simple to say it: we need to move from a blacklist approach to a white list approach for everything. Reality check: approving and configuring every trusted move or operation within your scope is impossible for any human to calculate and the AI/ML train isn’t saving the day anytime soon. Instead, you need to compartmentalize known quantities and take a lifecycle approach that can be applied to different use cases, or to steal a military term: Area of Responsibility (AOR). With all things security, getting to 90% is easy, getting to 95% can be more challenging, but the real work is done in the last 5% - and no matter how hard you try, 100% secure is not achievable under normal use cases. You will always have to contend with that.
While we don’t know the specifics of everyone’s environment or what is installed and operational, most Zero Trust strategies the goal is the same: maximum security with as little disruption as possible. The nuance is where that line is drawn. We do have basic knowledge of the core AOR’s and more detailed information on the mobile and end user segments. In this overview I’d like to discuss (at a very high level) the operational strategy for implementing Zero Trust across the enterprise and how different technologies can be leveraged to get to the 99%. Since Zero Trust can go to a somewhat infinite level of complexity, for the purpose of this document we are going to focus on network access and network segmentation as an initial phase of a Zero Trust Strategy.
Server and Application Workloads (a.k.a. Private and Public Clouds):
Core to any Zero Trust strategy the applications and associated data – or more appropriately characterized as the crown jewels of the organization. Whether it is privately hosted or in a public cloud, the concept of virtualized or containerized workloads have made enabling Zero Trust an easy task. The critical challenges to addressing Zero Trust in cloud are usually time and budget. Inherently, public clouds have Software-Defined Networking (SDN) and Access Control List (ACL) functions built in at little to no cost, but the management plane and time commitment to determining which traffic to allow (or whitelist) proves to be the primary barrier to entry. On premise workloads (virtualized or physical) require leveraging additional technologies like Cisco’s ACI or VMware’s NSX-T to perform those functions, which introduce the additional barrier of product cost and in some cases migration projects.
In all cases, however, vendors have made significant progress in removing the “time” barrier at the trade of higher cost. Application dependency mapping solutions have well defined the “whitelists” required for implementation and have continuous operations to ensure any new requirements are met. Cisco and VMware offer product options in this space that tie nicely to their solutions. There are also significant options from an enforcement perspective; with workloads in VMware and AWS, you are a candidate for NSX with on premise and cloud management. Cisco’s ACI can be a factor when we add physical data center workloads to the equation. Again, it all comes back to bridging the gap between 99% and 100%. Whether we focus solely on the private cloud, or public cloud – or maybe just the connections between the two – the only true obstacle will be budget.
The Campus
The further away we get from the workloads, the more challenging it becomes to enforce a true Zero Trust policy. That being said, within your own campus infrastructure we still have significant control. Your mindset can transform from application dependency to application access. While you might not know each TCP/UDP port that is in use between applications, it is relatively easy to know what ports are required to access applications, so enforcing Zero Trust between end users within your own campus and to your applications is straight forward. That can be done with an edge firewall design or even the NSX/ACI/Cloud ACL stack we discussed earlier. Where it gets tricky is planning for local services to the campus; a file share, a domain controller, printers and scanners, IoT devices – things that threat actors love to exploit. All of these devices, however, have pre-defined access methods that are conducive to a whitelist policy, so the goal of any IT organization is selecting the most effective enforcement. This is where we introduce the concepts of Identity Management, which is the first step in the critical path to assigning the proper access to the proper resource. Don’t get me wrong, you can have Zero Trust without Identity Management, you just need to focus your energy in responding to constant change requests and performing all of those tasks manually. We (IT personnel) have always had the capabilities to enforce policy East/West and North/South, but the change rate has outpaced our ability to keep up and the user experience was suffering. Unfortunately, the solution was always to remove security controls, rather than increase identity and automation. Technology also wasn’t helping much, even our favorite vendors really didn’t have what we were hoping for…until now. In Campus networking there are two products we focus on to achieve this goal - and make no mistake it is achievable. I promise I’m not trying to sell a solution in this manifesto, but rarely does a product over-deliver on a promise and exceed my expectations like Cisco’s Software Defined Access (or SDA). It is the easiest logical adoption of complex topics like Identity Management, 802.1x, VRF’s, BYOD, etc. The problem is it can be challenging to brownfield. I wouldn’t let it dissuade you from making it a stated goal, but it isn’t as easy as adopting NSX in your data center and cloud workloads. Those products can be overlayed without a requirement of re-design (see: NSX Service Defined Firewall for an example), whereas Cisco’s SDA is a completely different architecture. It is a beautiful architecture, but certainly different.
The approach to Zero Trust that products like SDA share is to identify assets and devices as accurately as possible to limit the services to only what is needed, thereby shrinking the attack service or the attacker’s capabilities. This allows you to hone your software tools (i.e. XDR software) in on only what matters, which ultimately leads to a better experience for the customer. All of this works when the devices are within the campus – this is the key. The network has the control, enforcement and can automate any decisions into the network with ease. Interop capabilities with additional product sets are also significantly easier when the foundation has been set. Since all of the security is enforced at the network layer, there is no dependency on software, which makes it impossible for a threat actor to evade if they only have Command and Control of the endpoint. This technology shares the same protection methods as the data center, only it isn’t servers and applications, it’s users and devices. This is also commonly defined as micro-segmentation.
Cloud Applications (SaaS)
This is the wildcard in any Zero Trust strategy. You are playing by someone else’s rules with your data. It is incumbent on your organization to know every security control offered by the SaaS partner and enforce it in line with your corporate policy. Sounds easy, right? Well, I’d argue that it is the hardest thing to do. For starters, Zero Trust isn’t a thing, because you just extended your trust to the provider. While that opens another can of worms, I want to try and keep this focused on a practical Zero Trust strategy – which means only one thing in this environment: Cloud Access Security Broker, or CASB.
CASB itself is not a strategy, but rather a definition of products that are tied to a mechanism offered by SaaS providers to outsource some level of control back to the customer. These products allow you to enforce a level of application access and login capabilities based on criteria met in the CASB. Using Conditional Access policies, backed by a universal Identity Management strategy (same as discussed under Campus) is the first step. If CASB is unable to apply network or application policies, you will be limited in your control of the application and will have to seek an alternate route.
Sometimes you can enforce Zero Trust and sometimes you can’t. When you are caught in between lack of security policy and a business relevant application, build the safest environment you can with the best airbags. I use that analogy because we hope cars will never see an accident, but if it does happen, we want to make sure we can handle any impact without the worst fate. IT security carries a very similar model.
Mobile and Cloud
Remember when I said it was easy to get to 90% and the real work was at the end? Well, here we are – the mobile users and direct access model. The good news is this is easy to lay down the foundation for, the bad news is the policy and integration can be as complex or as simple as you want it to be. If this were 5 years ago, the solution would be simple, but the end user experience would suffer. It would be a relatively simple VPN with all Internet based traffic hair pinned to adhere to your security policy. VDI solutions can solve part of this problem – they can make the experience feel better – but they have significant dependencies in the architecture and provide a less direct route to any cloud services.
Enter Service Access Service Edge (or SASE). SASE providers have been tasked with finding a solution to this problem: provide identified, secured, filtered, and optimal network access to users and sites with the rich controls of next generation firewalls and XDR technologies. Their goal is to bring the security stack as far to the edge as possible to minimize delay and control the ingress and egress points of all private and public traffic. This is our Zero Trust policy extended to the endpoint. Each client has a personal firewall, centrally controlled, performing basic networking segmentation. This is the mechanism to extend the Campus strategy to the mobile endpoint and beyond. It allows complete control of the experience and enforces the Zero Trust strategy as close to the endpoint as possible.
SASE’s true extensibility is with cloud applications and access. Whereas we have limited control with CASB, SASE allows us to source our network access from a common set of IP addresses which can identify and categorize this traffic to limit the sources of access. This feature allows us to enforce Zero Trust policies across multiple AOR’s. We leverage the intel and operations of SASE to help determine the policy of our Server and Application workloads. It’s a perfect eco-system.
SASE isn’t limited to solely client access, there are use cases which replace WAN or SDN solutions to perform the same functions. The largest benefit being the centralized policy from which it is managed – something required to reduce complexity at scale. SASE vendors have compiled lists of differentiators.
While implementation of SASE involves client and gateway access, adoption is easy. It can be deployed primarily through software and the security can be implemented in a gradual way to reduce end user impact. Palo Alto’s Prisma Access marries the common user interface of Panorama – a location where you might find your other Zero Trust configuration items – with the scale of a network built for low latency application access.
Summary
The implementation of a Zero Trust strategy can be complex and ongoing but compartmentalizing the use cases can simplify the implementation. Not everything needs to be accomplished at once, we should focus on the vulnerable and targeting population before embracing the harder tasks. Choosing common management techniques can increase the likelihood of successful implementations and taking steps forward towards your goal.
I like to think of each section of this document as a strategy within a strategy. Each AOR can be addressed in several ways, and while they bring additional values to our organizations beyond their intended design, ultimately they move us to a less vulnerable, more predictable position.