Initiating your Zero Trust Security Framework

Initiating your Zero Trust Security Framework

Moving to the Cloud: The SASE Puzzle Part 2

What is a Zero Trust Network?

Zero Trust as a security practice embodies the personality of a personal bodyguard: trust no one. A Zero Trust network requires all users to be authorized and continuously validated on a variety of checkpoint decisions before accessing corporate applications and data. It requires continuous monitoring from organizations so they can validate a user has the right access and privileges. Zero Trust is implemented and supported by the controls available in the SASE architecture but is not the same thing as SASE.

The graphic below shows a common, high-level Zero Trust execution with example checkpoints; however, it does not represent a complete Zero Trust architecture and is not the full extent of implementation options.

Zero Trust Network Access vs. Zero Trust Extended

While the Zero Trust framework has typically been known for protecting just your network, we are now realizing that Zero Trust can be used for anything. According to NIST SP 800-207, a Zero Trust Architecture (ZTA) “uses zero trust principles to plan industrial and enterprise infrastructure and workflows.” Enter Zero Trust Extended (ZTX). A report by Forrester explains ZTX is the application of the Zero Trust framework to your enterprise; meaning, ZTX extends the adaptive trust model of no implicit trust, only granting access on “need to know,” with least privileged basis policy across the organization.

Forrester identifies key pillars for identifying whether a technology or solution qualifies as ZTX framework:

1. Network: What does the technology do to enable the principles of network isolation, segmentation, and security?
2. Data: What does the technology do that enables data categorization, schemas, isolation, encryption, and control?
3. Workforce: How does the solution work to secure the humans that are using the network and business infrastructure, and does the solution reduce the threat that users create?
4. Workload: Does the solution or technology secure areas such as cloud networks, apps, and anything else that a business or organization uses to make the business operate technically?
5. Automation and Orchestration: How does the technology or solution automate and orchestrate Zero Trust principles and empower the business to have more powerful control of disparate systems?
6. Visibility and Analytics: Does the technology or solution provide useful analytics and data points and eliminate dark corners of systems and infrastructure?

Zero Trust Implementation

Begin with an Assessment – Any new project should always start with examining what tools you already have in place. You may already have some of the tools necessary to respond to Zero Trust policy checkpoints. When it comes to Zero Trust, it is not necessarily a set of new technologies; rather, a unique way of looking at security and the amount of trust given to certain people and systems. Look at Zero Trust as a way of requiring additional information from a user before giving them access. Establishing what you truly need sets you up with what technologies, current or new, will accomplish what you need in the most efficient way.

An emerging Zero Trust implementation method is multifactor authentication (MFA). MFA requires multiple methods of authentication to verify a user for a login or other transaction. Just like Zero Trust, MFA gathers additional information through an extra verification. Many organizations are choosing to implement MFA as a part of their Zero Trust security plan, and can include methods such as SMS, OTP Token, Mobile OTP, Mobile Push, Smart Card, or FIDO/Web Authentication Device.

If MFA does not sound familiar, 2-factor authentication (2FA) may ring a bell. 2FA is just a subset of MFA. 2FA is exactly as it sounds – two pieces of evidence, or factors, to prove your identity before logging into a system. The goal of both is the same: provide an extra method (or methods) of verification to an identity. MFA uses additional information about the user in deciding whether to offer a 2FA of another type, such as password and SMS or SMS and then a third-party token. Traditional 2FA does not consider user access information (new system, previously seen system, new IP address, new country) when determining authentication factors. Overall, MFA is more secure than 2FA since it can leverage multiple identity factors based on additional data points (location, time, IP address, etc.).

Newer to the terminology is AMFA, Adaptive Multi-Factor Authentication. Where MFA is not as aware of what could be considered unusual authentication behavior, AMFA comes into play. AMFA allows for offering different patterns of MFA based on a variety of information beyond what MFA alone provides. It also can determine when a step-up authentication is required to access information, but not require it when it is not needed. This is an improvement over the always-on of 2FA that completes the request every time. It is important to keep in mind that not all vendors support or offer AMFA. If you find a vendor that does support AMFA and you can leverage that vendor in connection with other vendor products, then you extend the value of AMFA across the board.

After Implementation- After implementing Zero Trust, evaluate your environment. Is it executing the way you expected? Is it doing everything the vendors indicated it would? Do you find yourself looking for simpler ways to troubleshoot? There is no such thing as stagnant implementation, unfortunately you cannot just install and move on! Your organization is constantly changing and adapting to serve your customers in the best way possible, and your growing employee base and device changes all impact your implemented solutions. Look at your auditing history and behavior analytics in your environment. There may be a new requirement on the horizon that you did not have before, so you need to start scoping out what solution will be a good fit and budget accordingly knowing the product you need.

Connecting Zero Trust and SASE

Secure Access Service Edge (SASE) restricts access at all edge access points including mobile, users, locations, cloud datacenters or resources, which aligns to the ZTNA principles. SASE is a cloud architecture model; however, Zero Trust is emphasized as a piece of the execution because it helps enforce the least permission model while still providing strong authentication and authorization controls. As a whole, Zero Trust expects the execution of POLP (principal of least privilege) for network access. ZTNA, or Zero Trust, is adding a portion of SASE by leveraging the microlevel evaluation about the access attempt (who, what, where, when) along with other variables to provide enriched information influencing policies for permitting or denying. Zero Trust is a core element of SASE and should be present in a SASE deployment scenario along with a Cloud Access Security Brokers (CASB).

In the simplest way, SASE is the “how” to Zero Trust’s “what.” You can implement Zero Trust without SASE, and vice versa; however, in such a configuration you may miss some of the components necessary to secure all desired points of access. Many use the terms interchangeably, but SASE is delivered as a service, acting as individual checkpoints that are constantly evaluating the risk, timing, user, user location, user device, and authorization. Zero Trust, in turn, is implemented and supported by the controls available in the SASE architecture. Zero Trust may verify everything, but inherently the tools may not provide the level of security offered by SASE. SASE may combine network security functions to cover digital enterprise spread, but without Zero Trust, it will miss additional user/device identity data enrichment during connection request that expands in-depth permission policies to protect the data and resources accessed.

At Braxton-Grant, we are a multi-vendor integrator that has deep experience in Zero Trust implementation that you can leverage. Reach out to us today to get started today!