FoxPointe Security Hub

By Brandon Agostinelli, CISA, CCSFP; Christopher Salone, MBA, CISA, CCSFP; and Carl Cadregari, CISA, CTPRP

What is the Zero Trust Architecture?

As our world changes and evolves, so does the way organizations operate. Business models change, and infrastructures and networks grow and become more complex. In the past, perimeter-based architecture was accepted as sufficient because networks were simpler and more easily identifiable. Today, perimeter-based security is deemed to be insufficient as hackers have the ability to move laterally once a perimeter is compromised. As networks become remote, mobile, and often shifted into the cloud, a new model and approach are needed for cybersecurity. Enter Zero Trust Architecture (ZTAA). The Zero Trust model is a cybersecurity approach that implicitly denies access to an organization’s network.

The History of Zero Trust Architecture

In the early 2000s, members of an online security forum called Jericho discussed the issues with perimeter-based defenses and architectures and workshopped a new concept they called deperimeterization. This new model called for more robust security controls that were not prevalent at the time. Then, in 2010, John Kindervag, a Forrester Research Analyst, introduced the term Zero Trust when he proposed the notion that an organization should not extend trust to anything, either inside or outside the perimeter. This idea and model were expanded, and by 2021, a Microsoft research report was published, noting that many organizations deemed Zero Trust as critical to their security. The hyper-expansion of remote work options during the pandemic further thrusted the ZTAA model into conversation. By 2021, the Federal Government released an Executive Order to improve the Nation’s cybersecurity defense. In the report, the White House suggested a move towards Zero Trust Architecture.

In the National Institute of Standards and Technology (NIST) Special Publication 800-207, Zero Trust is described as follows:

“Zero Trust (ZTA) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero Trust architecture (ZTAA) is an enterprise’s cybersecurity plan that utilizes Zero Trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a Zero Trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a Zero Trust architecture plan.”

With Zero Trust, the protection of resources and data is maintained by focusing on identity, credentials, access management, operations, endpoints, hosting environments, and infrastructure. At the core of these controls is an emphasis on least-privilege, where an organization restricts resources to only those with a business need and access is granted based on the minimum required. The goal of these models and concepts, as again stated by NIST, is to ultimately “prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible.”

Why Zero Trust Architecture?

The Zero Trust Architecture is important for organizations that wish to continue to maintain an updated and forward-thinking information security infrastructure. Regardless of the network environment (i.e., local, cloud-based, hybrid, etc.), security-conscious organizations strive to implement consistent and reliable authentication and authorization mechanisms for users that access networks, applications, and information resources. This is where Zero Trust comes in: by implementing this framework, organizations can gain more confidence knowing that every user is authenticated and authorized before every network request and connection, all without negatively affecting business processes and overall productivity.  During the last several years, real-world use cases have become quite frequent, and organizations relying on Microsoft products (such as Azure Active Directory and Microsoft 365) have applied this Zero Trust strategy to deliver secure and efficient user access to organization data resources, email services, and applications from anywhere.  The Zero Trust security model yields several valuable benefits to any organization:

Overall Risk: The perimeter-less cybersecurity model that is Zero Trust places emphasis on authenticating users and devices instead of protecting physical or virtual walls that may or may not surround data, users, and devices accessing that data. Protection under a Zero Trust model is focused on implementing security controls as close as possible to the most critical asset of an organization – its data. Implementing new and emerging technologies that provide the ability to require verification of a user’s identity and device make it immensely more difficult for threat actors to gain access to or even identify an organization’s network.  An organization’s attack surface is significantly reduced in a Zero Trust environment.

Deny-All Approach: One of the core functions of a Zero Trust environment is its “deny-by-default” approach.  These solutions prohibit all connections from users, devices, external systems, and applications until identity verification is received by way of predefined and unmodifiable properties of the origin of the connection request. Zero Trust is one of the most robust strategies for controlling a cloud-based environment because by continuously validating the identity of the connecting user and device, the risk of uncontrolled and unauthorized access is severely limited.

Visibility: With a fully implemented Zero Trust security model, organizations explicitly approve and authorize every user and device identity each time the controlled network is accessed. This provides an organization with a comprehensive view and knowledge of every access request and network event. The best visibility and oversight of an environment exists when a Zero Trust approach is implemented alongside least-privilege requirements for the assignment of user access rights to functions, applications, and information. Additionally, this level of visibility into individual user and device authentication and authorization results in a more effective audit function, allowing security professionals to easily monitor and validate activity across critical applications and services.

Incident Response: With strictly controlled access enforcement protocols at the user and device level, organizations are better prepared to respond to and contain a potential intrusion or breach. Replacing the traditional perimeter-based information security model by breaking up access to networks, applications, and information resources based on user- and device-specific authorizations minimizes the negative impacts of any potential security event and doing those steps can prohibit, or at the very least significantly lengthen the amount of time a threat actor needs to traverse a network following the breach of a singular machine, a critical measure of an effective incident response program.

Cloud-Based Environments: As described previously, a Zero Trust Architecture is perimeter-less. More devices and endpoints being added to network environments generally results in an increase in reliance on cloud-based business functions and data solutions. With this in mind, combined with the knowledge we already have of what the Zero Trust model is, it is easy to see that a security model that focuses on user identity and device authentication and authorization would perform very well in a network environment that is largely (or even partly) cloud-based.

Ease of Use: People that are familiar with the need to use a virtual private network (VPN) connection to access organization networks, applications, and information resources when working remotely are likewise familiar with the challenges and inefficiencies that come with it. Whether it’s limited use of certain applications, having to login multiple times over the course of a day’s work, or overall poor network performance and response time, we have all been left shaking our heads in frustration while navigating the daily annoyance that VPN use potentially provides. In a Zero Trust security model, single sign on tools along with the enforcement of multi-factor authentication are often leveraged to provide an efficient and secure means of providing authorized users and devices with information access.

Compliance: In order to maintain compliance with security and privacy standards and regulations (i.e., PCI DSS, HIPAA, FERPA, GLBA, etc.), organizations need to invest large amounts of time and money into implementing security controls that protect the confidentiality and integrity of their data. A Zero Trust Architecture makes this easier, by way of centrally managing user access, ensuring user and asset accountability, and establishing explicit boundaries around certain types of legally protected data, and by providing protection over all connections from the internet, organizations can more easily demonstrate compliance with applicable laws, regulations, and standards when auditors come knocking.

With information cybersecurity risks changing and growing rapidly, internal audit and security groups must react quickly and proactively in order to maintain a secure environment.  The likelihood and resulting impact of potential cyber-attacks is increasing, but implementing a Zero Trust model can provide an efficient, reliable, and consistent set of access controls that help limit that risk. The Zero Trust Architecture is not a temporary buzz word or a methodology that will quickly age.  It is a fundamental shift in how organizations across all industries are designing approaches for protecting their information assets well into the future. There are plenty of reasons why implementing a Zero Trust security model is a net positive for security-minded organizations; however, minimizing the impact of a breach, securing remote access connections, and ensuring business continuity in response to a breach are among the most important reasons.

ZTA Proof of Concept (POC) Practices

Now that you’ve decided that moving to ZTA is in the best interest of your organization, what do you do?  Many organizations support a material move like this (and it is a material, disruptive change for the positive) with a senior level, well-managed, actionable proof of concept (POC). The process of a POC is one many of you will have experience with. The idea that a team is gathered to be the “test bed” for a new process or application is a standard one that includes at least the following:

1. Document everything. Every one of the following steps need to be documented and reviewed.

2. The scope is your purpose. Be clear on what you are planning to accomplish, including where and when all the tasks will happen and who needs to be involved, where Management has bought into the tactics needed, definitions of your gates (milestones, go/no go points, etc.), and success criteria in writing.

3. Do your research, both internally and externally. What are others doing? Who can support you? Will you have roadblocks (people, seasons, ecosystem)? What tools and documents do you need?  What amount of time will it take, based on everything you can find out?

4. Focus on reducing complexity everywhere possible. Simplifying the complex is essential. Don’t add areas or infrastructure outside what is needed for success.

5. Frame it from the end user and business process point of view. What does the change mean to your users, the business, the ecosystem, and your stakeholders’ change in their reality?

6. Communicate often. A change of this magnitude will require a change in your communication plan. Plan on communicating all the steps and outcomes, gates, pitfalls, and risks to all the POC members and management sponsors. Be concise and informative, not judgmental.

7. What pain will be eliminated? If you are not moving the risk management needle towards the “green”, why are you doing this? There may be multiple drivers for the program; make sure they are all understood and agreed to.

8. Focus on reducing implementation risk. The primary objective of a proof of concept is to reduce implementation risk. Identify not just what “broke” in the testing, but who is critical to success, when is the best time, and what assets should be included and in what order.

9. Make sure everyone on the team knows what the end goal is. This should go without saying, but if someone is on the team, they need to know what is being accomplished and they have to have the fundamentals of the team and their role fully understood. You’ll always have a subject matter expert (SME) or two, but everyone needs to “know” what’s going on.

10. Document the workflow and plan for changes. Change is guaranteed. In your scope and your communications documents, add a section titled “what we need to change”. Allow all the team members to have an unrestricted, constructive ability to suggest changes.

11. Depending on complexity, utilize internal audit to help communicate project assurances and confirm that the team is staying on task and on track.

12. Don’t be averse to adding external support. The fact that you are having a POC means you are not an expert. A change of this magnitude needs all the support you can apply. Use external SMEs — those with expertise in the product, outcome, steps, integration, and implementation.

The POC is approved — now what? What do you include in a ZTA rollout? What items? What controls?  What should be considered? As noted above and in the relevant publications (i.e., National Institute of Standards and Technology (NIST) SP800-207, Department of Defense Zero Trust Reference Architecture, etc.), the goal is to prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible. You are asking your organization to move from an implicit trust (trust but verify) least rights controls model to a highly data-centric, fine-grained set of measurable and adaptive evaluation of trust set of security controls between users, systems, data, and assets that considers change over time. That will add a more complex controls structure that needs to take into consideration all of the following per NIST:

1. The path to ZTA is a journey (like most cyber controls) that will take years to implement;
2. There will be ongoing changes to the ZTA guidance;
3. The robust sets of guidance towards zero trust differ depending on what products and technologies you look to implement;
4. There are key tenets of ZTA that need to be included as outlined in NIST™ (SP) 800-207:
   1. All data sources and computing services are considered resources (internal and external)
   2. All communication is secured regardless of network location
   3. Access to individual enterprise resources is granted on a per-session basis
   4. Access to resources is determined by dynamic policy
   5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets
   6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed
   7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture
5. Your existing technology ecosystem may not support a zero trust implementation.

Additionally, per NIST, “The above tenets attempt to be technology agnostic. For example, “user identification (ID)” could include several factors such as username/password, certificates, and onetime password. These tenets apply to work done within an organization or in collaboration with one or more partner organizations and not to anonymous public or consumer-facing business processes. An organization cannot impose internal policies on external actors (e.g., customers or general internet users) but may be able to implement some ZTA-based policies on non-enterprise users who have a special relationship with the organization (e.g., registered customers, employee dependents, etc.).”

Other considerations should apply when you are utilizing a third (and fourth) party for any of your data interactions. While you can’t affect the external customers or general internet users, it is likely that your ZTA control surface would include an AWS™, Azure™, and core cloud providers, etc.; however, don’t forget those such as a service centric organizations, your bank, attorney, accounting firm, a statement processor, data aggregator, etc. As noted in NIST SP800-207, ZTA focuses on protecting your resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource.

Please watch for Part Two of our article – Pitfalls and Requirements for Success, Auditing ZTA, and How to Make ZTA Last (i.e., Is There a Maturity Model Right for Me?).