What is Zero Trust?

Understanding Zero Trust Architecture Per NIST SP 800-207

iboss Zero Trust Secure Access Service Edge

Purpose Built for Zero Trust to Protect Organizations from Breaches and Data Loss

The iboss Zero Trust SASE prevents breaches by making applications, data and services inaccessible to attackers while allowing trusted users to securely and directly connect to protected resources from anywhere

Learn how the iboss Zero Trust SASE meets all requirements of NIST SP 800-207

Platform Overview

Applications, data and services have moved from the datacenter to the cloud, making them easily accessible by attackers. Users have left the office and are working from anywhere. Legacy security and visibility approaches rely on resources and users to be located in the office to provide protection which is no longer possible. The iboss Zero Trust SASE is focused on protecting sensitive resources by making them completely inaccessible and invisible to attackers while strictly granting access to trusted and approved users from wherever they work. With the surface area of protected applications, data and services reduced to zero and only accessible through the iboss Zero Trust SASE, cyber risk is greatly reduced, breaches and data loss are prevented and visibility and security are delivered consistently throughout the organization.

The iboss Zero Trust SASE allows all protected resources within an organization to be labeled and categorized, including Security Objectives and Impact Levels. This provides organizations with a clear understanding of where sensitive applications and data reside while providing insight into what users and assets are interacting with those protected resources. The iboss Zero Trust Service follows the NIST Risk Management Framework (RMF) and implements the NIST 800-207 Zero Trust Architecture Special Publication acting as the Policy Decision & Enforcement Point (PDP/PEP) which is the heart of the NIST Zero Trust architecture model.

With all protected resources connected and only accessible via the iboss Zero Trust SASE, organizations can connect their users to the iboss cloud which dynamically provides direct access to applications and data without ever needing to turn on a VPN. The protected resources can reside on-prem or in the cloud. The iboss Zero Trust SASE handles connecting only the approved and trusted users to the resources automatically. This improves end-user experience and dramatically increases productivity as users get ultra-fast connections from any location.

The iboss Zero Trust SASE goes beyond authentication and instead inspects and authorizes every single transaction between a user and protected resource, using authentication as one of many signals to allow or deny access to protected resources. This ensures every transaction is inspected for CASB, malware defense and data loss prevention to eliminate the shadow risk that typically exists between authentication and sensitive data access. The iboss Zero Trust SASE continuously evaluates, protects and logs every access to every protected resource, preventing breaches and data loss.

Download the Full NIST Publication

NIST Risk Management Framework Applied To Zero Trust

Designed To Manage Risk Centered Around Effectiveness & Efficiencies

Greatly reducing cyber risk resulting in breaches and data loss is easily made possible using the iboss Zero Trust SASE because it tackles the problem from the various angles that make organizations vulnerable to attacks. The platform provides the tools to follow processes outlined in the NIST Risk Management Framework which starts by understanding and classifying what resources exist and need to be protected. Resources are any application, data or service that an enterprise owns and wants to protect from breach which can exist on-prem or in the cloud. The sensitive resources are then connected to the iboss Zero Trust SASE. Next, users and assets that need access to connected sensitive resources are pushed through the iboss Zero Trust SASE for access. This allows for security and visibility as the users and assets interact with the protected resources. Once all users are connected to the iboss Zero Trust SASE, the resources are locked to the iboss Zero Trust SASE so that they are completely invisible and inaccessible directly and can only be accessed through the iboss Zero Trust SASE. Cyber risk is reduced as each resource is connected to the iboss Zero Trust SASE and ultimately a complete Zero Trust transformation occurs when all resources have been protected by the service. Users also gain the benefit of eliminating the need to turn on VPNs to access resources as they are always connected to resources from wherever they work.

NIST Risk Management Framework

This definition focuses on the crux of the issue, which is the goal to prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible. That is, authorized and approved subjects … can access the data to the exclusion of all other subjects (i.e., attackers).

– Page 4, NIST SP 800-207

NIST Zero Trust Architecture (SP 800-207)

  • NIST SP 800-207 provides a detailed definition of Zero Trust that can be implemented by technology (i.e. iboss)
  • NIST Zero Trust is centered and anchored around the resources an organization is actively trying to protect
    • Resources are any resource the organization wishes to protect (including applications, data and services, IoT, etc.)
    • Includes resources at any location – cloud resources and on-site resources
    • An organization must understand and categorize those resources

Zero Trust Basics

Core concepts of
NIST 800-207 Zero Trust Architecture

NIST Zero Trust Definition goal –

This definition focuses on the crux of the issue, which is the goal to prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible.

– NIST 800-207

  • Zero Trust, according to NIST 800-207, is about resource access
  • Goal is to reduce risk of breaches and data loss by isolating resources with Policy Enforcement Points (PEP)
  • Provide “per-request” access decisions to resources – for each and every transaction, the PEP approves or denies the connection + logs transaction
  • Resources fall primarily into three categories – applications (i.e. Office 365), services (i.e. Remote Desktop) and data (i.e. Word Document)
  • Provides key security and compliance controls:
    • Access Control
    • Visibility via Logging (for every transaction)
    • Security (DLP, malware defense, compliance controls for every transaction)
  • Policies based on “default deny” construct – only approved users can access the resource to the exclusion of all other users

What is the difference between Authentication and Authorization?

Each request needs to go through both authentication and authorization

Use an “airport security checkpoint” as your basis for understanding NIST 800-207 Zero Trust Concepts

  • Authentication – Knowing who the person is
    i.e. Check the traveler’s ID before getting through the checkpoint
  • Authorization – Giving the privilege to access the resources
    i.e. Allow the traveler to pass the security checkpoint and board the plane (resource) only after security screening is completed (the bags and passenger is checked)
  • Step-Up Authentication – Require a Passport versus State Issued ID at the checkpoint
    Both can be used for identity, but this gives more confidence about the identity
  • Client Certificates – Traveler must have TSA Pre-Check to be authorized pass through the TSA Checkpoint

What is a Session?

According to NIST, a session is as granular as a single transaction between a user and a resource

  • Understanding what a “session” means is VERY important
  • A transaction is as granular as a SINGLE API call – a read followed by a write to a database consists of TWO transactions
  • Each transaction ideally goes through authentication AND authorization
  • This is what allows for “per-request” access decisions required by core definition of Zero Trust according to NIST
  • This provides granular access control in addition to visibility (via logging) of every interaction between a user and a resource

“The unit of “session” can be nebulous and differ depending on tools, architecture, etc. The basic definition in a zero trust context is a connection to one resource utilizing one network identity and one privilege for that identity (e.g. read, write, delete, etc.) or even a single operation (similar to an API call).”

– Page 2, NIST – Planning for a Zero Trust Architecture
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.20.pdf

The Purest View of Zero Trust Access

A subject wants to interact with a protected enterprise-owned resource

Zero Trust Access

Figure 1: Zero Trust Access

  • Notice NIST 800-207 Zero Trust Architecture drops the word “Network” from the acronym ZTNA (Zero Trust Network Access) and simply calls this “Zero Trust Access”
  • This nuance is VERY important – Zero Trust is not about access to a Network, it’s about about access to a resource (application, data or service)
  • Ideally, there is no direct access to any NETWORK object – such as a subnet, server or network port on a server
  • Access is granted to the service or application itself – for example, multiple applications may be running on the same server and on the same server network port
  • For example, when multiple HTTPS applications are running on the same network port (TCP 443) on the same server, Zero Trust Access will only allow a user to access the single application they have access to
  • The location of the user AND the resource is irrelevant – this is IMPORTANT

Subjects, Assets and Resources

The three actors that are interacting must be catalogued and understood

Subject

– This is typically the user new line of text needed

  • The term “subject” is used because this might be a non-human entity (such as a service running on a server, an AWS Lambda function, etc.)
  • Although the term “user” will be used in place of subject, using the term subject instead sets a strong foundation to extending Zero Trust across non-human entities later

Asset

– This is typically a laptop, desktop or server

  • This can also be IoT or OT

Resource

– This is an application, data or service that is being protected

  • It’s important to understand that from the NIST 800-207 perspective, you want to START with enterprise-owned resources that need to be protected
  • Do NOT start with the public internet when thinking about resources!
  • The goal is to protect enterprise-owned applications, data and service and prevent the leakage of data to the public internet

A catalogue or database is required of subjects, assets and resources so that a clear understanding of what is being protected is achieved

The Tenets of Zero Trust

Getting the Tenets right gives a solid foundation
for Zero Trust to build on into the future

Tenet 1 – All enterprise-owned apps, services and data sources are considered resources, regardless of location

  • This is one of the most critical tenets of Zero Trust to get right
  • Do not think of Zero Trust as meaning access to on-prem resources (i.e. replacing your VPN)
  • All resources regardless of type and location should be made private by putting them behind the Zero Trust service
  • This includes on-prem, SaaS and Cloud (Azure, AWS) applications, data and services

There are many side effects of Zero Trust which go far beyond just VPN replacement

  • Direct to resource access for employees wherever they work
  • Access to resources within Azure and AWS
  • Elimination of data backhaul to the datacenter for faster connections resulting in better productivity and better end-user experience
  • Reduced datacenter space with the reduction of network proxies and firewalls
  • A lot more

Getting this concept right is critical and will avoid foundational mistakes in architecture which may result in inconsistent security, visibility and access controls due to treating resource access control differently depending on where they are located

Three Key Components
Subject, Asset and Resource

Resources Cannot Be Accessed Without Going Through The Policy Enforcement Point And Gaining Authorization

NIST SP 800-207 Zero Trust Framework

iboss Implementation Of NIST SP 800-207

Key Definitions

Resource

Data, application, or service being protected, can be on-prem or in the cloud

“Policy Enforcement Point” (PEP) /
“Policy Decision Point” (PDP)

A binary “checkpoint” which either grants or denies the subject/asset access to the resource – iboss Zero Trust Service

Asset

Laptop – or IoT device, etc.

Subject

User – although a subject can be non-human (e.g. an API service)

A Guide To Implementing Zero Trust
with a Zero Trust SASE

Identified & Classified Resources Added To iboss Platform

Add All Company Resources To iboss Platform

Add all identified & classified resources to the iboss platform, enabling complete visibility into the traffic flowing to and from those resources

iboss cloud PDP/PEP initially set to allow all traffic, operating only in visibility mode

Subjects (users) seamlessly access company resources, while the iboss platform invisibly observes

Classify Resources

Categorize and Classify Protected Applications, Data and Services

Identification & Classification Of All Company Resources And Their Associated Impact Levels

1. Identify All Resources Within An Organization

Identify all resources that are input, stored, processed and/or output from each system – a resource is any data, application, or service either on-prem or in the cloud that needs to be protected

2. Tag All Resources With A Resource Type Label

iboss facilitates resource identification and grouping with smart labels, which tie a particular resource to a Resource Type (e.g. HR System, CRM System, Code Repository System)

3. Determine Potential Impact Level Of Resource Type

For each identified Resource Type, determine the potential impact level if the Security Objective is compromised. This critical step determines where risk lies within the organization.

Assign Security Objectives and Security Impact Levels to Resources

iboss smart labels allow for Impact Levels assigned to each Resource Type to be automatically applied to every associated resource

Once resources are labeled, they can then be assigned security objective impact levels. The iboss Zero Trust SASE focuses on three Security Objectives as defined by FIPS199:

  • Confidentiality – Preventing Data Loss
  • Integrity – Preventing the destruction of information (Preventing ransomware or insider threat)
  • Availability – Ensuring that critical resources are available to the organization

For each of the three security objectives above, the platform allows a Security Impact Level to be assigned:

  • Low – Limited adverse effects on the organization
  • Moderate – Severe adverse effects on the organization
  • High – Catastrophic adverse effects on the organization

Once each resource is associated with security impact levels, the iboss Zero Trust SASE will track and log interactions between users, assets and the resource to provide clear and continuous visibility into organizational risk. Additionally, this provides the enterprise a clear understanding of what impact a resource has on organizational processes for continuity planning.

An Expanded View of Zero Trust

The heart of the Zero Trust Architecture stays the same and is based on the Policy Enforcement Point

An Expanded View of Zero Trust

Figure 2: Core Zero Trust Logical Components

The inputs into the heart of the Zero Trust Architecture are designed to make higher confidence decisions when providing “resource access” which is the foundation of what Zero Trust is all about

Deployment Variations of the NIST 800-207 Zero Trust Architecture

The deployment variations are designed to cover the different use cases when providing access to enterprise-owned resources

  • There are FOUR deployment variations designed to meet the different use cases when protecting access to sensitive enterprise-owned applications, data and services
  • There are different security requirements and objectives depending on how a user accesses the resource (for example, on a company-owned laptop versus BYOD)
  • The goal is to prevent breaches AND data loss
  • Data cannot end up on a personal laptop or the data is lost for good
  • Concepts based on traditional network connectivity and security ideas such as VLANs for isolating resources and Virtual Desktop Infrastructure (VDI) for allowing untrusted devices to interact with data
  • The transformation that Zero Trust provides is that the same goals can be accomplished in a world where users and resources are scattered everywhere (outside of the datacenter)

Deployment Scenario 1
Agent/Gateway Based Deployment

The most popular of all deployment models designed for enterprise-owned devices such as laptops

Device Agent Gateway Model

Figure 3: Device Agent / Gateway Model

  • Used when the enterprise owns the asset and data can be trusted on that asset (laptops, desktops, etc.)
  • An agent is installed on the asset which serves the following primary purposes
    • Redirects traffic to the gateway to access a resource regardless of where the user or device is connected from (i.e. work from home)
    • Performs asset posture checks – is the firewall on, is the disk encrypted, is anti-malware enabled?
Learn more

Deployment Scenario 2
Enclave Gateway Model

The gateway sits close the resource, for example within a datacenter

Zero Trust Enclave Gateway Model

Figure 4: Enclave Gateway Model

  • Allows the Policy Enforcement Point (Gateway) to sit close to the resource which isolates the resources and provides access control to the resources
  • This is typically accomplished by replacing legacy on-prem proxy appliances with modern Policy Enforcement Point appliances within the datacenter
  • The Gateways can also be inside of a cloud provider, for example the Gateway can run inside of Azure to protect resources in Azure and provide access to those resources
  • The Policy Enforcement Point appliances that are on-prem should be 100% linked to the Policy Enforcement Points that run in the cloud so consistent policies, visibility, security and access controls can be guaranteed across all resources (on-prem, SaaS, Cloud)
Learn more

Service Edges Should Extend into the Datacenter via the Enclave Model

All Security Features & Functionality Are Preserved When Extending Cloud Security Service Into Customers On-Prem Datacenter

Current

On-Prem Appliances Process All Traffic

Hybrid

Seamlessly Extend iboss Cloud Into Any Datacenter, On-Prem Or Cloud Based

Future

Eliminate Network Security Appliances Altogether

Deployment Scenario 3
Resource Portal Model

This model is used when the device is NOT enterprise-owned – guests, contractors or other high risk device situations

Figure 5: Resource / Portal Model

  • This is the modern equivalent of VDI and uses Browser Isolation to perform the VDI function within the browser
  • Prevents data from landing on the device itself which will result in data loss
  • Note this is the first model that shows a non-enterprise owned device
Learn more

Deployment Scenario 4
Application Sandbox Model

Zero Trust Application Sandbox Model

Figure 6: Application Sandboxes

Supported on some mobile devices, such as Android with a “personal space” and a “work space”

  • Least popular because it is operating system dependent and allows data onto an untrusted device
  • This use-case can also be solved with Browser Isolation (Deployment Model 3)
  • Only data from the “work space” is sent to the policy enforcement point
Learn more

Trust Algorithms

There are two types of Trust Algorithms –
Criteria-Based Access
and Score-Based Access

Criteria-Based access allows for explicit access rules

  • These users can access the resource
  • These groups of users can access the resource (groups are typically tied to Active Directory or Azure AD such as HR-Staff can access the Accounting Application)

Score-Based access allows for “adaptive” access and security controls

  • Depending on the scenario, cut access to a resource or allow access to a resource
  • For example, if the device is infected with malware, automatically cut access regardless of whether explicit criteria-based access is met
  • If a user did not authenticate with multi-factor authentication, use browser isolation (the modern VDI equivalent) to put a pane of glass in front of the resource
Continuous Adaptive Access Algorithm
Continuous Adaptive Access Algorithm 2

Confidence Level Algorithms Configured For Each Resource Policy To Allow For Real-Time Decision Making

Resource policies configured for each Resource Type factor in Security Objective and Impact Level to determine if subjects and assets have access to protected resources.

iboss resource policies encapsulate the decision-making process of the PDP/PEP to either allow or deny access based on the decision of the confidence algorithms

Criteria-based decision metrics and confidence level algorithms assign a confidence score in real-time to primary actors in the zero-trust framework: Subject, Asset and Resource

Confidence Level Algorithms - iboss Zero Trust Secure Access Service Edge

iboss confidence score is calculated at the time of transaction – when the risk occurs:

  • For example, there is no risk for a user/hacker who has no access to resources at that time (e.g. in jail), an infected laptop that cannot access a resource (e.g. it is powered off), or a resource that is not connected.
  • Risk occurs when all three (Asset, Subject and Resource) meet in an exchange

Greatly Reduce Cyber Risk from Breaches and Data Loss as All Sensitive Resources Are Now Private

With access to resources being made available only through the iboss Zero Trust SASE, an enterprise greatly reduces cyber risk and can prevent breaches and data loss. With resources spreading throughout the cloud and on-prem, the iboss Zero Trust SASE serves as the interface between users and assets that need access and the resources that need to be protected from breaches and data loss.

Experience the Power of Zero Trust: Replace Your Legacy VPN, Proxy Appliances, and VDI with iboss