What is Zero Trust?

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 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, 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

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

• 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

• 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

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

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.

• 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?

• 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)

• 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

• 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

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

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

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.