Zero Trust Network
Problems with traditional network models
Businesses are increasingly depending on cloud platforms to manage a wide range of devices and networks, and bad actors are using the disarray to increase account hacking. It gets increasingly difficult to maintain the network secure as the number of users climbs. Hackers’ ways of attacking and exploiting massive systems are becoming more complex, making them more dangerous.
The idea that datacenter systems and traffic can be trusted is erroneous. The traditional network security architecture divides the network into different zones, each separated by layers of firewalls. Each zone has different trusts, resource access rights. This model is very safe from outside attacks.
But what will happen if the attack is from the inside?
If an attacker acquires network access from a low-security zone, they can utilize the resources of that zone and interact with other servers in the higher-security zone, then move and take over the server in a highly secure zone.
What is Zero Trust?
The Zero Trust network was intended to address the inherent issues with trusting a network. This is a security model that requires strict verification of all requests, assuming that requests to access a private network’s resources come from the public Internet. Whether the request comes from outside or within the private network itself, zero trust says: “Never Trust, Always Verify”.
Putting it more simply:
- Traditional network security: Trusts device, users, anything inside the network.
- Zero trust network: Never Trust anyone or anything.
Putting it more simply:
- Traditional network security: Trusts device, users, anything inside the network.
- Zero trust network: Never trust anyone or anything.
A Zero trust network is built on 5 fundamentals:
- The network is always assumed to be hostile.
- External and internal threats exist on the network at all times.
- Network locality is not sufficient for deciding trust in a network.
- Every device, user, and network flow is authenticated and authorized.
- Policies must be dynamic and calculated from as many sources of data as possible.
According to IBM Technology, three Zero trust principles are:
- Never Trust, Always Verify
- Implement Least Privilege
- Assume Breach
Why you need to use ZTA
Because of advantages of itself
Zero Trust is not a single architecture but a set of guiding principles for workflow, system design and operations that can be used to improve the security posture of any classification or sensitivity level.
Verify explicitly. Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and anomalies.
Use least privilege access. Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA), risk-based adaptive polices and data protection to protect both data and productivity.
Assume breach. Minimize blast radius for breaches and prevent lateral movement by segmenting access by network, user, devices, and application awareness. Verify all sessions are encrypted end to end. Use analytics to get visibility, drive threat detection, and improve defenses.
Because of the market require
With the development of infomation technology, the risk of service is increment. So many company are having plan or on moving to zero trust network architecture.
Because of the trust of end user/engineer/professional
Nowaday Zero Trust Network is a trend at cybersecurity network. Why your company don’t plan to implementation it now !!!
Comparison to alternative technology
Software-defined Perimeter (SDP) vs. Zero Trust Network
SDP | Zero Trust |
---|---|
Build a barrier between trusted and untrusted resources | No resources is trusted and all have to identify themselves |
Is an network that sit on top of another network to coceal it | Is a network that restrict access an assume that all actors are malicious |
Controllers are used for continuous authentication and validation of users to the network assets | All hosts must provide identification and data has to be encrypted |
Virtual Priavte NetWork (VPN) vs. Zero Trust NetWork
VPN | Zero Trust |
---|---|
Blindly trusts authorized users and gives them access to the network | Takes a much more holistic approach to security |
Encrypt connections between remote, authorized users and company network | Restrict access from all traffic that try to access the network resources |
Require investments to deploy appliances and scale | Easier to deploy, maintain and scale |
Have bottleneck issues at VPN gateway causing backhaul and latency | Do not have this issues |
Design
In this section we explain the concept of ZT which was wrote since 2015 in book Zero Trust Network (publis by Ororeilly), one’s in NIST Special Publication 800-207 (wrote by engineers of NIST and NCCoE since 2018 and publish by DOI at 8/2020), one’s in The UK National Cyber Security Centre (known as UKNCSC).
Making Authorization Decisions by Gilman and Barth
Authorization is the most important process in a Zero trust network. According to the main idea of security Zero trust, for every flow or request that occurs, an authorization decision needs to be made.
These decisions will be made primarily based on a factor called the Trust Score. The thing is calculated based on the data (user data, device data, or otherwise) of the system and the object making the request.
Here we will focus only on the high-level architecture, including the components for making an authorization decision in the Zero trust model.
Authorization Architecture has four main components:
- Enforcement: ensures that clients are authenticated (a load balancer, proxy, or even a firewall,…)
- Policy engine: compares the request and its context to policy, and informs the enforcer whether the request will be permitted or not.
- Trust engine: is used by the policy engine for risk analysis purposes (Google’s BeyondCorp)
- Data stores: user data, device data, or otherwise, (authenticated) are heavily leveraged by both the policy engine and trust engine
Enforcement
Enforcement is the gateway to secure access for corporate resources. This components intercepts the access request and ensures that clients are authenticated.
Then the Enforcement calls the policy engine for authorization. The results returned will determine the next action. Only authorized, trusted requests are allowed to access the resources.
Policy engine
Requests forwarded from the Enforcement will be reviewed with policies (should be stored separately from the engine) to decide if they are trustworthy for authorization.
Since the policy of a Zero trust System generally expects as much detail as possible and changes reasonably, it is common for organizations to let small groups define their own policies for their services and let security teams review each proposed change.
Trust Engine
Trust Engine will evaluate the riskiness of allowing a particular request/action (which can be represented by Trust Score). This result will be used by the Policy engine to make the final authorization decision.
Risk assessment:
- Define a set of ad hoc rules that score an entity’s riskiness.
- Using Machine Learning to calculate Trust Score:
- The training data are observations from the behaviors of trusted and untrusted entities.
- Model results are compared with human risk assessment and fine-tuned.
Data Stores (DS)
Data Stores are the sources of truth for the current and past state of the system.
Zero trust networks two primary types DS:
- Inventor: save the current state of the resources. Eeach entity has an primary key. (Example: User - Primary key is Name)
- Historical: store the data, behavior in the past (use for risk analysis).
Implementation
There are a lot of opinions on how a zero-trust network should be implemented. These are the most commonly agreed upon steps:
1. Identify areas that need to be protected In today’s threat scenario, working relentlessly to decrease the attack surface is no longer possible. It’s impossible to define, reduce, or fight against the assault surface since it’s increasing continuously. Instead of focusing on the attack surface’s macro level, you determine what you need to protect or keep a eye on. These include: - Actors: employees, Service accounts, robotic process automations (RPAs/bots), serverless functions, system administrators, developers. - Data: User accounts, digital certificates, credentials, credit card information. - Devices: Personal computers, smartphones, tablets, IoT devices (printers, smart security cameras), switches, routers, modems. - Application: - Services: DNS, DHCP.
2. Understand the transaction flows Examine and document how different apps interact with one another. Even if you don’t have all of the data, your administrators will obtain a clear understanding of where restrictions are required. Understanding how your systems function can help you determine where access controls are needed. To put it another way, know what you’re defending before you construct a defense around it.
3. Establish policies You’ll need to set Zero Trust rules to whitelist which resources should have access to others after the network is built. The “Kipling Method” or the “‘Who? What? When? Where? Why? How?’” system is a is an effective way to detect if a user or entity meets the requirements for access to your restricted areas. - Who should be accessing a resource? What application is being used to access a resource inside the protect surface? - When is the resource being accessed? - Where is the packet destination? - Why is this packet trying to access this resource within the protect surface? - How is the packet accessing the protect surface via a specific application?
4. Continuous Monitoring Documenting as much activity circulating your environment as you can, is at the forefront of what makes Zero Trust effective. Knowledge is power, so this data can provide valuable insights into how to improve the network overtime.
Eight Core valuable by UKNCSC
This a a set of instruction to help you design and deploy a zero trust architecture.
- Know your architecture including users, devices, and services
- Know your user, service and device identities
- Know the health of your users, devices and services
- Use policies to authorise requests
- Authenticate everywhere
- Focus your monitoring on devices and services
- Don’t trust any network, including your own
- Choose services designed for zero trust
More detail: https://github.com/ukncsc/zero-trust-architecture
Model by NIST 800-207
Seven tenets
- All data sources and computing services are considered resources
- All communication is secured regardless of network location
- Access to individual enterprise resources is granted on a per-session basis
- Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes.
- The enterprise monitors and measures the integrity and security posture of all owned and associated assets
- All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
- 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.
Six addition assumptions
- The entire enterprise private network is not considered an implicit trust zone (Tenet 2)
- Devices on the network may not be owned or configurable by the enterprise
- No resource is inherently trusted.
- Not all enterprise resources are on enterprise-owned infrastructure
- Remote enterprise subjects and assets cannot fully trust their local network connection. (Tenet 2)
- Assets and workflows moving between enterprise and nonenterprise infrastructure should have a consistent security policy and posture (prepare for migrating system)
Core ZTN concept
- Core:
- PE: Policy Engine
- PA: Policy Administrator
- PEP: Policy Enforcement point
- Additional:
- CDM Systems: Continuous diagnostics and mitigation Systems
- ICS: Industry compliance system
- Threat intelligence feed
- Network and system activity logs
- Data access policies
- Enterprise public key infrastructure (PKI)
- ID management system
- Security information and event management (SIEM) system
Trust Algorithm
For an enterprise with a ZTA deployment, the policy engine can be thought of as the brain and the PE’s trust algorithm as its primary thought process. The trust algorithm (TA) is the process used by the policy engine to ultimately grant or deny access to a resource. The policy engine takes input from multiple sources the policy database with observable information about subjects, subject attributes and roles, historical subject behavior patterns, threat intelligence sources, and other metadata sources. The process can be grouped into broad categories and visualized in Figure below.
- Access request
- Subject database
- Asset database (and observable status)
- Resource requirements
- Threat intelligence
There are different ways to implement a TA but the two type which people usually implement is:
- Criteria- versus score-based a set of qualified attributes that must be met before access is granted to a resource or an action (e.g., read/write) is allowed. These criteria are configured by the enterprise and should be independently configured for every resourceIf the score is greater than the configured threshold value for the resource, access is granted, or the action is performed. Otherwise, the request is denied, or access privileges are reduced (e.g., read access is granted but not write access for a file).
- Singular versus contextual Treats each request individually and does not take the subject history into consideration when making its evaluation. This can allow faster evaluations, but there is a risk that an attack can go undetected if it stays within a subject’s allowed role.
Variations of Zero Trust Architecture Approaches
Enhanced Identity Governance - Enterprise resource access policies are based on identity and assigned attributes. The primary requirement for resource access is based on the access privileges granted to the given subject. Other factors such as device used, asset status, and environmental factors may alter the final confidence level calculation (and ultimate access authorization) or tailor the result in some way, such as granting only partial access to a given data source based on network location.
Logical micro-segmentation - In this approach, the enterprise places infrastructure devices such as intelligent switches (or routers) or next generation firewalls (NGFWs) or special purpose gateway devices to act as PEPs protecting each resource or small group of related resources. Alternatively (or additionally), the enterprise may choose to implement host-based micro-segmentation using software agents.
Software Defined Perimeters - This can be achieved by using an overlay network (i.e., layer 7 but also could be set up lower of the OSI network stack). These approaches are sometimes referred to as software defined perimeter (SDP) approaches and frequently include concepts from Software Defined Networks (SDN).
Trust Algorithm Variations
- Criteria- versus score-based
- Singular versus contextual
More detail: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
Six scenarios attacking by NCCOE
Six scenarios of attack network security:
- Employee Access to Corporate Resources
- Employee Access to Internet Resources
- Contractor Access to Corporate and Internet Resources
- Inter-server Communication Within the Enterprise
- Cross-Enterprise Collaboration with Business Partners
- Develop Trust Score/Confidence Level with Corporate Resources
More detail: https://www.nccoe.nist.gov/sites/default/files/legacy-files/zta-project-description-final.pdf
Enterprise
- The concept of ZTN was implemented in many big enterprise like Google, Cloudflare, Gitlab, Microsoft … Many other enterprises was implemented zero trust architecture and they’re not have more special feature compare to basic ZTN. But if you’re interesting, there a few name of companies for your research:
- HashiCorp: a big company deliver many security solution in Japan
- Okta: an American identity and access management company, it uses cloud software that helps companies manage and secure user authentication into applications
- …
Required to transform existing systems to ZTN
- All network flows MUST be authenticated before being processed. In a zero-trust network, all packets received by the system are immediately suspicious. As such, they must be rigorously inspected before allowing the data contained within them to be processed. Strong authentication is the primary mechanism by which we accomplish this.
Authentication is absolutely required in order to gain confidence in the provenance of network data. It is, perhaps, the single most important component of a zero trust network. Without it, we have nothing and are forced to place trust in the network.
- All network flows SHOULD be encrypted before being transmitted. A network link cannot be trusted to reliably convey data or signals from one system to another. The physical accessibility of a network link to unsafe actors makes it trivial for that network to be compromised. Moreover, even in a physically secure network, bad actors can digitally infiltrate a system and passively probe the network for valuable data.
By encrypting data on a device before transmitting it on the network, we reduce the attack surface of that communication to the trustworthiness of the device itself, namely application and physical device security.
- Authentication and encryption MUST be performed by the endpoints in the network. Since zero trust networks recognize the threat that trusting network links pose to the security of a system, it is important that secure communications be established between application-layer endpoints. Adding middleware components that handle these responsibilities (like VPN concentrators or TLSterminating load balancers) can leave upstream network communications exposed to physical and virtual threats.
As a result, a system that claims to be zero trust is required to implement encryption and authentication at every application-layer endpoint on the network.
- All network flows MUST be enumerated so that access can be enforced by the system. Zero trust networks depend on data that defines the expected characteristics of the network. Therefore, defining every expected network flow is critical to safeguarding the network.
We should be careful to note that enumerating flows does not require onerous change management controls to provide value. A simple process for defining expected flows brings enormous value in terms of network enforcement and change auditing.
Without the list of expected network flows, zero trust systems are unable to highlight unexpected communications which need attention from administrators or should be denied.
- The strongest authentication and encryption suites SHOULD be used within the network. Zero trust networks assume a hostile network environment, so strong authentication and encryption suites are an important component in the security of a zero trust network.
Which suites offer strong security unfortunately changes so system administrators should always aim for the strongest suites possible, but device and application capabilities might limit the types of suites that are available. In these cases, administrators should be aware that by reducing the strength of these suites, security is being compromised in their network.
- Devices SHOULD be regularly scanned, patched, and rotated. Scanning can be used to discover and prevent known malicious software from running on the device. Keeping devices fresh is also very important. System administrators should have a plan for regularly installing the latest security patches. Additionally, a regular device rotation will help ensure that devices don’t accrue cruft, which can compromise the security of that system.
Further reading
The zero-trust security model was first articulated by John Kindervag in 2010, and by Google in 2011 as a result of the Operation Aurora breach. What follows is a curated list of resources that covers the topic in more depth.
Recommendations
- Jericho Forum™ Commandments - Jericho Forum™ Commandments - May 2007
- NCCoE IMPLEMENTING A ZERO TRUST ARCHITECTURE - Oct 2020
- UK National Cyber Security Centre Zero trust architecture design principles - 2020
- NIST SP 800-207 Zero Trust Architecture - August 2020
- Department of Defense (DOD) Enterprise Identity, Credential, and Access Management (ICAM) Reference Design Aug 2020
- Department of Defense (DOD) Zero Trust Reference Architecture - February 2021
- ACT-IAC Zero Trust Project Briefing - May 2021
- ACT-IAC ZERO TRUST REPORT: LESSONS LEARNED FROM VENDOR AND PARTNER RESEARCH - May 2021
Books
- Zero Trust Networks by Gilman and Barth
- Zero Trust Security by Garbis and Chapman
Papers
- Forrester Build Security Into Your Network’s DNA: The Zero Trust Network Architecture
- Google BeyondCorp 1 An overview: “A New Approach to Enterprise Security”
- Google BeyondCorp 2 How Google did it: “Design to Deployment at Google”
- Google BeyondCorp 3 Google’s front-end infrastructure: “The Access Proxy”
- Google BeyondCorp 4 Migrating to BeyondCorp: Maintaining Productivity While Improving Security
- Google BeyondCorp 5 The human element: “The User Experience”
- Google BeyondCorp 6 Secure your endpoints: “Building a Healthy Fleet”
- ACT-IAC Zero Trust Cybersecurity Current Trends 2019
- Microsoft Zero Trust Maturity Model
- Microsoft Implementing a Zero Trust security model at Microsoft
- Palo Alto Zero Trust Deployment at Palo Alto Networks
- Okta Getting Started with Zero Trust
- Duo Zero Trust: Going Beyond the Perimeter
Posts
- Blog Zero Trust Network Note
- Zero Trust vs VPN vs SDP
- SDP vs VPN vs ZTN and whats the difference
- Zero Trust 5 step methodology https://www.paloaltonetworks.com/cyberpedia/zero-trust-5-step-methodology
- Google How Google adopted BeyondCorp
- Wall Street Journal Google Moves Its Corporate Applications to the Internet
- Gitlab’s Blog series and their reddit AMA
- Microsoft Azure Implementing zero trust with microsoft azure identity and access management 1 of 6
- Microsoft Azure Protecting cloud workloads for zero trust with azure security 2 of 6
- Microsoft Azure Monitoring cloud security for zero trust with azure sentinel 3 of 6
- Microsoft Azure Enforcing policy for zero trust with azure policy 4 of 6
- Microsoft Azure Implementing Zero Trust with Microsoft Azure 5 of 6
- Microsoft Azure Implementing Zero Trust with Microsoft Azure 6 of 6
- NCCoE Zero Trust Architecture Technical Exchange Meeting
- Zero-trust ldap wiki
- Adopt a Zero Trust approach for security — Essentials Series — Episode 1
Videos
- USENIX Enigma 2016 - NSA TAO Chief on Disrupting Nation State Hackers
- What, Why, and How of Zero Trust Networking by Armon Dadgar, Hashicorp
- O’Reilly Security 2017 NYC Beyondcorp: Beyond Fortress Security by Neal Muller, Google
- How Google Protects Its Corporate Security Perimeter without Firewalls
- LISA17 - Clarifying Zero Trust: The Model, the Philosophy, the Ethos
- Be Ready for BeyondCorp: enterprise identity, perimeters and your application by Jason Kent
- SANS Webcast - Trust No One: Introducing SEC530: Defensible Security Architecture - 2018
- Google on BeyondCorp: Empowering Employees with Security for the Cloud Era
- Zero-Trust Networks: The Future Is Here - SANS Blue Team Summit 2019
- Microsoft No More Firewalls! How Zero-Trust Networks Are Reshaping Cybersecurity - RSA Conference 2019
- The Fallacy of the “Zero-Trust Network” - RSA Conference 2019
- Zero-Trust Cybersecurity: Trust No One?
- SANS Could Security - Gigamon Zero Trust What You Need to Know to Secure Your Data and Networks
- A Simplified and Practical Approach to Pursuing a Zero Trust Architecture - RSA Conference 2020
- Using SABSA to Architect Zero Trust Networks - COSAC Connect #1
- ACT-IAC Zero Trust Briefing - May 2021 <!–
Product Vendor Videos
- Cisco 2020 How to approach a Zero Trust security model Cisco
- Microsoft 2020 Modern Security w/ End-to-End Zero Trust Strategy
- Palo Alto Networks 2020 Zero Trust: The Strategic Approach to Stop Data Breaches
- Palo Alto - John Kindervag 2020 Implementing Best Practices for Zero Trust
- Microsoft’s approach to Zero Trust 2020 How Microsoft does Zero Trust
- Okta 2021 Moving the Zero Trust Maturity Needle - University of Newcastle
- Microsoft Mechanics Playlist 2021 Zero Trust Essentials
- Security Architect Podcast SASE ZeroTrust - Remote Access
- Security Architect Podcast SASE Secure Web Gateway - Outbound browsing
- VMware 2021 Trusting Zero-Trust: How VMware IT Reimagined Security and Resiliency
Materials