Internal Use

System Access Control Policy and Procedures

Dispel

Document Control

1. PURPOSE AND SCOPE

1.1 Purpose

This document defines detailed System Access Control policy and procedures, including FedRAMP-focused controls for the Dispel Zero Trust Engine and related systems.

1.2 Scope

This policy and procedures document covers access to Dispel systems and applications for workforce members, customers, and other authorized parties, and aligns with the System Access Control Policy.

The Access Control (AC) policy for FedRAMP outlines the requirements for managing and controlling access to information systems. This policy mandates that access to systems and data is granted based on the principles of least privilege and need-to-know, ensuring that users only have the necessary permissions to perform their job functions. The policy includes provisions for user identification and authentication, access enforcement, and the management of access control lists. Additionally, it requires regular reviews and updates to access permissions, as well as the implementation of automated mechanisms to support the management of access controls. The policy also emphasizes the importance of monitoring and auditing access to detect and respond to unauthorized access attempts promptly.

Access to Dispel systems and applications is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, and consultants. Access by any other entity is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized use or access of the organization’s information systems.

The basic principle is that access to all systems, networks, services, and information is forbidden, unless expressly permitted to individual users or groups of users. There should be a user registration procedure for each system and service.

Policies and Procedures specific to FedRAMP Systems (deployments of the Dispel Zero Trust Engine) are marked with the <FedRAMP Specific> designator in the section or paragraph level.

1.3 Regulatory and Framework Alignment

2. POLICY STATEMENTS

2.1 Purpose

NIST 800-53: AC-1

This covers, at the Organizational and FedRAMP System (the Dispel Zero Trust Engine)-level, the purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, requirements, and compliance for creating, modifying, or removing access to the company’s network and data (or, in the case of FedRAMP Systems, said FedRAMP Systems) by creating, changing or deleting the network account configuration for a User.

This document also covers procedures to facilitate the implementation of the access control policy and the associated access controls.

2.2 Scope

NIST 800-53: AC-1

This policy and defined process covers the allowance of access to the company’s data and systems by individuals. This policy governs individuals who are granted access that is necessary to support the business. This policy relates to all data used, processed, stored, maintained, or transmitted in and through the company’s systems.

For the purposes of the Dispel Zero Trust Engine FedRAMP environment, this policy covers access controls within the Authorization Boundary.

2.3 Covered Persons

NIST 800-53: AC-1

All workforce members are Users of this document.

2.4 Dissemination, Acceptance, and Acknowledgement

NIST 800-53: AC-1

The process of dissemination shall be made failsafe by holding, as a prerequisite to being authorized as a Covered Person, that an individual must first review, accept, and acknowledge this document. All Covered Persons must review, accept, and acknowledge this document at least Annually.

2.5 Roles and Responsibilities

NIST 800-53: AC-1

The Policy Owner of this document is the Chief Operating Officer.

The Policy Owner is responsible for managing the development, documentation, and dissemination of the Audit and Accountability policy and procedures.

Control-level responsibilities by role are listed below.

2.6 Management Commitment

NIST 800-53: AC-1

Management Commitment Statement

Senior Management at Dispel is dedicated to the protection of our information assets, industrial control systems, and Protected Health Information (PHI). We assume full accountability for the effectiveness of our security program, ensuring it is integrated into all business processes and aligned with our strategic goals. To maintain compliance with ISO 27001, IEC 62443, HIPAA, and NIST 800-53, we formally commit to:

• Resource Provisioning: Providing the necessary financial, technical, and human resources to sustain a robust security posture.
• Risk-Based Governance: Approving security policies and overseeing a continuous risk management process that prioritizes both data privacy and operational safety.
• Operational Resilience: Supporting the security of industrial automation and control systems (IACS) to ensure safety and reliability.
• Continuous Oversight: Conducting regular management reviews to evaluate program performance, audit results, and opportunities for improvement.

2.7 Policy and Procedures Review Tempo

NIST 800-53: AC-1

The Policy Owner must review and, if necessary, update policies and procedures:

1. At least once annually;
2. Policies following discretionary off-cycle formal policy reviews; and,
3. Procedures following significant changes (as defined by the current revision of NIST SP 800-37).

3. REQUIREMENTS

3.1 Account Management

NIST 800-53: AC-2

<FedRAMP Specific> Within any FedRAMP system, there will be two major user classifications:

• Those that interact with the delivered scope of the DZTE Platform - including roles such as platform users, VDI users, facility administrators, approvers, platform administrators, etc. This class of user will be referred to as “Platform Users.”
• Those that manage the infrastructure underlying the DZTE Platform - including maintenance, troubleshooting, and security functions. This class of users will be referred to as “Platform Managers.”

Users within these classifications may be created by Dispel or by the Customer, assuming proper permissions and approved workflows.

[AC-2(d)] The Customer shall be responsible for specifying for their users and administrators:

• Authorized users of the system:
  • Platform Users will have their roles and permissions tracked within the platform.
  • Platform Managers will have their roles and permissions tracked by Dispel. The customer may also track these users.
• Group and role membership; and,
• Access authorizations and attributes for each account. Attributes may be defined by the system, such as user email, access permissions, and group assignment.

Dispel authorized users of a FedRAMP Customer environment are limited to operations personnel with a support role or those directly involved in supporting a Customer for another reason.

3.2 Account Types

NIST 800-53: AC-2(a), AC-2(7)

DZTE-RA

There are two areas with applicable account types within the Dispel Zero Trust Engine Remote Access Environment: Platform Users (Engine Dashboard & Remote Access) and Platform Managers (or Management Operations). The types of accounts are set by the system programming itself [AC-2(a), AC-2(7)].

Dispel’s permissions schema for the Remote Access Engine Platform Users resides within a stacking hierarchy framework where roles and permissions are scoped within their respective tier. Users can belong to or have permissions to multiple tiers simultaneously.

Dispel’s permissions schema for the Remote Access Engine Platform Managers resides within a stacking hierarchy framework where roles and permissions are scoped within their respective tier. Where applicable, Platform Managers can belong to or have permissions to multiple tiers simultaneously.

3.3 Shared Group Accounts

NIST 800-53: AC-2(9)

Group accounts shall not be used in the DZTE FedRAMP environment. Root and emergency accounts will be individually authorized for emergency use only by the System Owner.

3.4 Administrators

NIST 800-53: AC-2(b), AC-2(7), AC-6, AC-6(1), AC-6(2), AC-6(7)

The Customer shall be responsible for assigning account managers for their deployment and for their users within the Dispel Zero Trust Engine. This holds for both Platform users, and, where applicable, Platform Managers.

Customers shall be responsible for establishing and administering privileged user accounts in accordance with their policies.

With respect to Platform Users, Customers can use the various account types and associated roles set in the Dispel Zero Trust Engine to assign levels of access. Customers shall revoke access when privileged role or attribute assignments are no longer appropriate, and it is the Customers responsibility to do so.

With respect to Platform Managers, user creation and role assignment should follow Dispel’s Identification and Authentication Policy and Procedures or follow an equivalent customer-provided procedure.

Customers shall monitor privilege role and attribute assignments for their users. Customers shall monitor for changes made to roles or attributes by reviewing their own edits to groups in the Dispel Zero Trust Engine. When Dispel makes edits to roles that are code-based, those changes are noted in the Dispel changelog when they are published found at https://dispel.com/changelog.

To the limited extent Dispel creates user accounts, the following policies apply:

Access by Dispel personnel to business function components through a DZTE Dashboard component shall be governed by the Customer and shall be the Customer’s responsibility. Privileged access to underlying DZTE system infrastructure (Platform Managers) by Dispel personnel is restricted to those directly supporting the Customer or the deployment and follows Dispel’s Identification and Authentication Policy and Procedures. Dispel monitors privileged role assignments/attributes for users with system infrastructure access. This monitoring shall be done as part of broader user monitoring. At each access audit, Dispel will review the roles and attributes used for user assignment and update these as needed. When privileged role or attribute assignments are no longer appropriate for Dispel personnel in system infrastructure systems, access shall be revoked by Dispel in accordance with the Disable Accounts Section in this policy document.

Dispel roles with access to security functions are:

• Deployment tier, maintenance, patching, and operations role
• Security tier, monitoring, response, and user management roles
• Business tier, operations role

<FedRAMP Specific> Within Dispel FedRAMP systems, the only Dispel roles with access to security functions in a given deployment are those in the Security Tier. These user accounts are governed by the Identification and Authentication Policy and Procedures. System infrastructure user roles are tied to their authenticator, which uniquely identifies them to the system they access and enables privileges on a system/service account. For clarity, there may be a singular system/service account on a given piece of infrastructure in the system infrastructure section, but each user is uniquely authenticated when signing into that account.

Users shall be assigned on a least privileged basis when given access to a system. This means their permissions should be as minimally scoped as possible. Permissions shall be expanded only when needed and reduced to required levels no later than at the next quarterly access audit.

Accounts with access to security functions in the Dispel Zero Trust Engine shall be assigned to specific individuals who have a need for such access. Examples of security functions include but are not limited to: establishing system accounts; configuring access authorizations (i.e., permissions, privileges), setting events to be audited; and setting intrusion detection parameters, system programming, performing security audits, system and security administration functions. Deployment management and Business Operations functions include configuring routing tables, setting environment variables, and performing network audits.

The Dispel Zero Trust Engine shall be built so that sensitive security information is only available to authorized individuals who have properly authenticated.

Users shall use non-privileged accounts (e.g., accounts without access to security functions) when connecting to the Dispel Zero Trust Engine to perform primarily non-security functions (Development or Business Tier roles). For clarification: if a user’s primary function when connecting to the Dispel Zero Trust Engine requires security functions then they do not need to use a non-privileged account.

Customers are responsible for conforming to Dispel’s Identification and Authentication Policy and Procedures or for establishing equivalent policies and enforcing procedures related to privileged and non-privileged accounts and accessing security functions.

3.5 Group and Role Types

NIST 800-53: AC-2(c), AC-2(d), AC-2(k)

Groups and roles types (groups with assigned permissions) are supported by the Dispel Zero Trust Engine.

Customer Responsibilities

The Customer shall be responsible for setting the prerequisites and criteria for group and role membership for their users [AC-2(c)].

The Customer shall be responsible for creating groups of users and role types (groups with assigned permissions) within the Dispel Zero Trust Engine. The Customer shall be responsible for specifying the personnel or roles responsible for approving requests for accounts.

The Customer shall be responsible for establishing and implementing a process for changing shared or group account authenticators (if deployed) when individuals are removed from a group in the Dispel Zero Trust Engine [AC-2(k)].

Group attributes are set within the software. They are name, description, access (device, facility, region), and stack membership. [AC-2(d)(3)]

3.6 Account Creation, Modification, Deletion

NIST 800-53: AC-2(d), AC-2(e), AC-2(f), AC-2(h), AC-2(j), AC-2(i)

The Customer is responsible for account creation, modification, and deletion within the Dispel Zero Trust Engine (for Platform Users). As the administrators of the system, Customers will oversee who has access to the environment.

The Customer shall be responsible for defining the policies, procedures, prerequisites, and criteria for creating, enabling, modifying, disabling, or removing their users’ accounts.

The Customer shall be responsible for defining who approves requests to create accounts in their deployment of the Dispel Zero Trust Engine. For Dispel Platform Managers, the Dispel Chief Operating Officer is responsible for approving Dispel support personnel requests for accounts to underlying infrastructure. [AC-2(e)]

The Customer shall be responsible for providing notices to its relevant account managers when accounts are no longer required (no later than 24 hours after a finalized decision), when users are terminated or transferred (no later than 8 hours after the termination or transfer event taking place), or when system usage or need-to-know change for the individual (no later than 8 hours after a finalized decision).

Relevant Dispel personnel, such as those with a Platform Manager role within Development, Security or Business Tiers, shall notify the relevant account managers overseeing Dispel personnel within time frames no less stringent than those listed above for the same activities. Notification shall be delivered through the company messaging system Slack and accompanied by a corresponding ticket for user status changes. [AC-2(h)]

The Customer shall be responsible for reviewing their accounts for compliance with account management requirements monthly for privileged access and every six months for non-privileged access. Dispel shall review their accounts for compliance with account management requirements monthly for privileged access every month, and every three (3) months for non-privileged access using an Access Audit form located in an approved business process tracking platform. [AC-2(j)]

The Customer shall be responsible for aligning account management processes with their personnel termination and transfer processes.

Dispel shall explicitly assign employees to an operations support or account management role if one is required or requested by the Customer. The scope of this role will be defined by the Customer [AC-2(f)].

Dispel system administrator and user authorization is granted based upon [AC-2(f), AC-2(i)]:

1. A valid Vendor business need;
2. The successful completion of a pre-employment background check;
3. A need to know for the information to which access is granted; and,
4. Whether the individual has received adequate education, experience, and technical skill to perform the assigned task(s).

The Customer shall be responsible for authorizing access to the system based on a valid access authorization, intended system, usage, and other Customer-defined attributes (as required).

3.7 Automated System Account Management

NIST 800-53: AC-2(1)

The Dispel Zero Trust Engine supports the management of system accounts using federated authentication and single sign-on. The Customer is responsible for maintaining their authentication system and managing the users and authenticators in that environment. Reference the User Guide and User Naming and Authentication Standard for more details on the configuration and implementation. In general, the OIDC and SAML authentication mechanisms enable customer central management of not only authenticators but also user management.

3.8 Automated Temporary and Emergency Account Management

NIST 800-53: AC-2(2)

All users on the Dispel Zero Trust Engine must have a user account. Dispel provides just-in-time access tied to each user instead of anonymous emergency “break glass” accounts.

Web Application Layer:

During the deployment of a new web application, a one-time-use temporary account is pre-seeded for Platform Users and Platform Managers to facilitate initial configuration tasks such as Single Sign-On (SSO) setup and new user creation. The temporary account is promptly deleted upon completion of the configuration process, ensuring it cannot be reused or compromised. Plans are underway to further automate this deletion process. After this initial set up process, all users on the DZTE must have a user account. Dispel provides logged just-in-time access tied to each user instead of anonymous emergency “break glass” accounts. This is all conducted IAW the Secret Management Standard.

Customer Network Layer:

Emergency accounts (e.g., Wicket accounts, root accounts for Linux servers) for Platform Administrators and Managers are configured as individual user accounts with unique credentials. Credentials for these accounts are stored in encrypted password vaults and only accessible to authorized personnel. Access to these accounts is strictly controlled and logged, ensuring they are used only during verified emergencies. This is all conducted IAW the Secret Management Standard.

Cloud Infrastructure Layer:

Emergency and root accounts are created for administrative troubleshooting and critical operations. These accounts are not used for daily operations. Credentials are stored in encrypted password vaults and only accessible to authorized personnel. Access to these accounts is audited, and they are locked down to prevent unauthorized and accidental use. Automated alerts are configured to detect and respond to unauthorized access attempts. This is all conducted IAW the Secret Management Standard.

3.9 Disable Accounts

NIST 800-53: AC-2(3), AC-2(13)

The Customer is responsible for disabling user accounts within twenty four (24) hours of the accounts having expired, ceased to be associated with a user or individual, been found in violation of organizational policy, or been inactive for thirty five (35) days. This responsibility rests with the Customer for all their system’s users.

<FedRAMP Specific Section> Dispel personnel user accounts shall be disabled within 24 hours of the user leaving the company, no longer being in a role necessary for access, having been determined to have violated organizational policy, or having been inactive for 35 days.

Customers are responsible for all non-user accounts that they create, and must manage them in accordance with their company policies in order to meet FedRAMP requirements. Dispel non-user accounts (e.g. accounts associated with devices) must be disabled if at the next quarterly access audit it is no longer in use. Dispel automatically invalidates sessions from stale devices and revokes that access in accordance with IA-04 Identifier Management policy in Identification and Authentication Policy and Procedures. Where applicable, Dispel will disable accounts of individuals within one (1) hour of discovery of a significant risk to the confidentiality, integrity or availability of the DZTE platform. Significant risk is taken to mean high probability of compromise to a system that has been designated with a high business impact.

3.10 Access Enforcement

NIST 800-53: AC-3

Access to DZTE resources, either active entities or passive entities, assumes no level of trust on the logical layer and is built along zero-trust principles. This means that in order to gain access to any resources, you will have access controls enforced at multiple layers along a defense-in-depth construct.

3.11 Separation of Duties

NIST 800-53: AC-5

Web Application & Customer Network

Customers shall be responsible for enforcing the separation of duties between their administrators, auditors, security teams, and end users of the Dispel Zero Trust Engine. To enable separation, Dispel provides role-based permissions levels in the Dashboard at descending levels of specificity (Organization > Region > Facility > Device).

At no level of permissions in the Dashboard can dashboard logs be edited.

Cloud & Infrastructure

<FedRAMP Specific Section> Dispel shall identify and document the duties personnel can hold, and which ones should be separated from one another. Security risks should be identified and mitigations determined. These shall be identified in this document and within the approved Identity Management System. Authorization for assignment of these duties is covered under the Org Systems Access Request Process Guide where the system owner is required to verify adequate separation of duties prior to account access authorization.

Duties are defined within Dispel’s approved Identity Management System under Separation of Duties Process Guide. Detailed updated separation of duties are found therein.

High Impact Duties and Separation Identification:

3.12 System Use Notification

NIST 800-53: AC-8

<FedRAMP Specific Section> The Customer shall can edit the notification in the Dispel Dashboard that by default says the following: “You are accessing a U.S. Government system; system usage may be monitored, recorded, and subject to audit; unauthorized use of the system is prohibited and subject to criminal and civil penalties; and use of the system indicates consent to monitoring and recording.”

This notice shall be shown on the Dispel Dashboard, a non-publicly accessible service that is the gating platform a user must log into in order to make use of the Dispel Zero Trust Engine system.

This setting shall be set in Dashboard > Settings > Announcements. The system shall enforce a requirement that a user acknowledge the message conditions by clicking “I agree” to further access the system after authentication.

3.13 Privileged Command and Access

NIST 800-53: AC-17(4)

<FedRAMP Specific Section> The Customer shall be responsible for defining the need that led to authorizing the execution of privileged commands, including those that are executed remotely. The Customer shall document the rationale for remote access for their users in their security plan.

For Dispel personnel supporting the Dispel Zero Trust Engine, only support personnel in roles that provide security and operational functions shall have remote access to the system. These roles are defined in the Administrator’s section of this policy. Dispel support users shall have access justified by the purposes defined in the Administrator section.

During a remote access session by Dispel personnel all commands executed by the user on the system shall be logged by the system. Logging shall take place using the bash history in Linux.

4. ACCESS TYPES

4.1 Remote Access

NIST 800-53: AC-17

<FedRAMP Specific Section>

Web Application & Customer Networks

Because Dispel is a cloud-based service, all connections to the Dispel Zero Trust Engine occur remotely. Remote access configurations and connections shall be documented in the Authorization Boundary Diagram documents CSP Remote Access and Customer Data Flow. These documents shall include the ports and protocols used for remote access, the data flow of users through the system for remote access, and the layout of the components within the system for access.

All remote connections to the system shall be authenticated prior to allowing a connection to the system beyond a connection to the login page of the Platform Console dashboard. Users shall be required to either sign in through single sign on or by providing authenticators to the service to log in. The user shall be redirected to authenticate if they attempt to navigate to a protected section of the system.

Cloud & Infrastructure

All remote access to the system and controlled in the change control board (Configuration Management). Standard-defined workflows fall under the “Process Guidance” section of the Dispel information management system or approved SOPs.

All Process Guidance and approved SOPs are addendums to the security guide.

4.2 Network Access

NIST 800-53: AC-6(3)

<FedRAMP Specific Section>

Web Application & Customer Network

The Dispel Zero Trust Engine is connected remotely (i.e., over network access). The Dispel Zero Trust Engine deploys to cloud infrastructure on IaaS providers and, therefore, has no local access with the exception of local administrator connections to on-premises Wicket ESIs.

Cloud & Infrastructure

All privileged commands will be captured in changes to the system and controlled in the change control board (Configuration Management). Standard-defined workflows fall under the “Process Guidance” section of the Dispel information management system or approved SOPs.

All Process Guidance and approved SOPs are addendums to the security guide.

4.3 Privileged Accounts

NIST 800-53: AC-6(5)

DZTE has defined account types (AC-2.a) as well as specific actions to authorize and enable those accounts through Org Systems Access Request Process Guide. Combined, these controls provide restrictions on the creation and utilization of Privileged Accounts. These accounts are monitored and reassessed annually at minimum with guidance from the system owner to review accounts upon granting additional access or users.

4.4 Wireless Access

NIST 800-53: AC-18

<FedRAMP Specific Section>

All components of the Dispel Zero Trust Engine reside on cloud infrastructure. The components in the Remote Access Engine are hardwired into the IaaS data centers and do not support direct wireless access.

Wireless access from Customer devices connecting to the Dispel Zero Trust Engine shall be the responsibility of the Customer and are not within the Authorization Boundary.

4.5 Wireless Authentication and Encryption

NIST 800-53: AC-18(1)

<FedRAMP Specific Section>

No components within the Dispel Zero Trust Engine Authorization Boundary shall allow direct wireless connections. All components must reside within a FedRAMP High IaaS data center. No wireless access points shall be included in the Authorization Boundary.

4.6 Disable Wireless Networking

NIST 800-53: AC-18(3)

<FedRAMP Specific Section>

All components within the Authorization Boundary reside on cloud provider infrastructure on virtual machines in data centers. None of these components have wireless networking capabilities, therefore wireless networking is disabled.

4.7 Restrict Wireless Configuration by Users and Antennas

NIST 800-53: AC-18(4), AC-18(5)

<FedRAMP Specific Section>

No user shall be permitted to configure wireless settings on components within the Authorization Boundary of the Dispel Zero Trust Engine. All components shall have wireless networking disabled.

No radio antennas are utilized in the DZTE.

5. EXTERNAL SYSTEMS

5.1 Use of External Systems

NIST 800-53: AC-20

<FedRAMP Specific Section>

Terms related to external systems shall carry their meaning as defined by NIST 800-53 Rev. 5 (September 2020). External systems mean: systems that are used by but not part of organizational systems and for which the organization has no direct control over the implementation of required controls or the assessment of control effectiveness. Dispel may inherit controls from external systems that are FedRAMP approved at a level commensurate to the system, or establish trust systems with the external system provider through contractual obligations, imposed controls, and security reviews.

External services used in the Dispel Zero Trust Engine shall be identified in the “External Services” section of the Authorization Boundary Diagram (ABD). Within the ABD, the data type shared with the external services shall be identified. For instance, the ABD shall specify if metadata or Customer data is sent to the external service.

All external services will be evaluated IAW System and Services Acquisition Procedures as well as be authorized by the Connection Authorization and Review Process Guide.

The ABD shall identify the protection methods used to transmit information to external systems by type. The following categories shall be used:

All external systems shall meet the following criteria:

• Meets the requirements of Dispel’s System and Services Acquisition Policy and Procedures (Version 1.0, December 8, 2023).
• Data shall reside within the United States of America, unless permitted by the Customer by their technical requirements, request, or policy.

Any potential external system that does not meet the above criteria shall be prohibited as acting as an external system.

Access to and from external systems shall take place through the use of the external system’s APIs. The access flows from the external systems shall be identified and diagrammed in the ABD.

Prohibited systems include:

• Systems lacking formal authorization
• Systems associated or adjacent to other national interests
• Systems and services that have no formal certification

5.2 Limits on Authorized Use

NIST 800-53: AC-20(1)

<FedRAMP System Specific>

Only Dispel System Administrators or the Customer shall be permitted to configure connections to external systems in the deployment of a Dispel Zero Trust Engine. Before configuring the connection, the Dispel administrator shall verify that a completed system acquisition form has been completed and approved in Jira for that external system. The system acquisition form shall provide the verification that sufficient controls have been implemented by the provider and that the proper approved system connection or processing agreements are in place.

5.3 Portable Storage Devices - Restricted Use

NIST 800-53: AC-20(2)

<FedRAMP Specific Section>

Dispel personnel shall not use any portable storage devices on external systems with the exception of authorized workflows with authorized devices on Dispel Managed assets for the purposes of initial device imaging and maintenance. For specifics on this process reference maintenance process and procedures. Dispel-controlled or otherwise, on any external system.

6. FLOW CONTROL

6.1 Encrypt Data in Transit

NIST 800-53: AC-17(2)

The system shall encrypt all data in transit to protect confidentiality and integrity. All remote sessions shall be encrypted in accordance with the specifications of the system. The system shall prohibit usage of less secure algorithms.

6.2 Information Flow Enforcement

NIST 800-53: AC-4

Dataflows in the DZTE are outlined in the Data Flow Diagram and can be broken into three levels of control points that enforce these logical data flows.

Web Application:

Data flows outlined in the Data Flow Diagram are enforced via both applications (layer 7) specific controls using a cloud-native Web Application Firewall. Information flow at layers 2-6 is controlled via cloud-native IDS/IPS systems within the web application pod.

Customer Network:

Data flows within the customer network are dictated via dynamically applied access control rules acting on a per user basis, controlled by the DZTE Web Application. Additional flow enforcement is obtained via host-based firewalling as well as the ability to enhance network and flow enforcement via cloud native firewalls at layers 2-6. Additional customer network control points can be added as needed to enhance flows that are inherently insecure.

6.3 Encrypted Information Bypass Protection

NIST 800-53: AC-4(4)

Dispel Virtual Desktops and Wicket ESIs shall ensure the prevention of encrypted information from bypassing intrusion detection mechanisms and system isolation. To achieve this, the system shall actively decrypt all incoming and outgoing encrypted information at the Virtual Desktop and Wicket ESI to allow for thorough inspection and analysis by intrusion detection systems. Furthermore, the system shall be configured to automatically terminate any communication sessions that attempt to transfer encrypted information without proper decryption.

6.4 Managed Access Control Points

NIST 800-53: AC-17(3)

<FedRAMP Specific Section> All remote access to the system shall route through Trusted Internet Connections via the Dashboard, Virtual Desktop Subnet, and Remote Access Engine Bastion Jump Host as defined within the Authorization Boundary Diagram. Components within the system shall only permit connections through the identified managed access control points, and not permit direct connections. This shall be enforced by firewall rules, certificate-based authentication, credentials, and/or network routing.

6.5 Physical and Logical Separation of Information Flow

NIST 800-53: AC-4(21)

The Dispel Zero Trust Engine shall enforce the separation of information flow through the following methods:

All DZTE FedRAMP environments live on top of FedRAMP-approved cloud providers (IaaS). For that reason, there are only varying levels of logical flow enforcement either at the cloud level or within the DZTE.

Tenant Separation: Each DZTE client receives its own single-tenanted instance launched on virtual machines spun up by cloud providers through their standard reservation process. This means, probabilistically, that physically separate infrastructure is used for all clients.

Logical Separation: The Dispel Zero Trust Engine shall implement logical separation of information flows within each client’s environment. Network traffic and resources will be segmented, ensuring that different systems or user groups can only access necessary data. This will be achieved through firewall rules and access control lists.

Encryption: All remote access sessions through the Dispel Zero Trust Engine shall employ strong encryption to protect data confidentiality, particularly when traversing shared infrastructure like the internet.

Customers are responsible for determining the appropriate level of physical and logical segmentation. Customers shall set the correct number of Regions and appropriately assign Facilities to Regions in accordance with their information security policies. Data is segmented by type within the environment:

7. USAGE CONDITIONS AND INFORMATION SHARING

7.1 Usage Conditions

NIST 800-53: AC-2(11)

The Customer shall be responsible for setting the usage conditions/circumstances for all of their user accounts.

Dispel support personnel usage circumstances are:

7.2 Information Sharing

NIST 800-53: AC-21

Dispel administrators shall verify that a sharing partner has the following controls in place with Dispel covering the applicable information prior to sharing information:

Information shall be marked according to its data classification. Information in Dispel Zero Trust Engine databases is CONFIDENTIAL unless otherwise specified. Dispel shall track signed NDAs for sharing partners in the company’s e-signature system to assist users in making information sharing and collaboration decisions. Users shall also have their access to information restricted on a need-to-know and role basis.

7.3 Publicly Accessible Content

NIST 800-53: AC-22

Information made publicly accessible on the dispel.com website shall be subject to this section.

The following individuals are authorized to make information publicly accessible at the commensurate data classification levels:

Individuals authorized to make information publicly available shall receive training at a virtual seminar every six months on company data classification and declassification. This training shall include instruction to ensure that publicly accessible information does not contain nonpublic information.

Prior to making information public, authorizers shall ensure that no non-public information that is classified at a higher level than Public (e.g., Internal Use or higher) is made public.

<FedRAMP Specific Section> Within the Authorization Boundary of the Dispel Zero Trust Engine, no pages shall be made publicly available with the exception of the login page to the Dispel Dashboard. No information shall be posted to the Dispel Dashboard login page that is not approved as public information. The Dispel Dashboard login page shall be reviewed at least quarterly for non-public information. Any non-public information shall be removed, if discovered.

8. MOBILE DEVICES

8.1 Access Control for Mobile Devices

NIST 800-53: AC-19

No mobile devices shall be permitted within the Authorization Boundary of the Dispel Zero Trust Engine. No Dispel personnel shall use any mobile devices for the act of directly servicing components within the Authorization Boundary, and no Dispel personnel mobile devices shall be authorized to connect to a component within the Authorization Boundary.

The Customer shall be responsible for their users’ use of mobile devices, if any, when accessing the Dispel Zero Trust Engine. If the Customer uses mobile devices, they shall establish configuration requirements, connection requirements, and implementation guidance for Customer-controlled mobile devices, to include when such devices are outside of controlled areas.

8.2 Full Device or Container-Based Encryption

NIST 800-53: AC-20(2)

<FedRAMP Specific Section>

No mobile devices shall be permitted within the Authorization Boundary. Dispel personnel shall not use mobile devices to connect to the Dispel Zero Trust Engine. Regardless of this restriction, all Dispel-issued mobile devices shall employ full disk encryption using Apple’s Data Protection functionality. Data Protection shall be enforced through Dispel Mobile Device Management.

If the Customer chooses to allow mobile devices to connect to the Dispel Zero Trust Engine they shall set the requirements for encryption on mobile devices, and define which mobile devices are permitted.

9. MONITORING

9.1 Account Usage

NIST 800-53: AC-2(g), AC-2(12)

The Customer shall be responsible for monitoring the usage of their user’s accounts in the Dispel Zero Trust Engine. The Customer is responsible for defining what constitutes atypical usage and monitoring for it. Customers must set their own policies and procedures for reporting atypical usage of system accounts to the appropriate roles within their organization. [AC-2(12)]

Dispel monitors account users for atypical usage. The Security Operations Center is tasked with central logging and monitoring of Account Usage across environments. This implementation will look for unusual activity including: unusual login times, geolocation, and device activity. When unusual behavior is detected, administrators will be alerted or managed through single sign-on system controls.

Atypical usage shall be reported to the Chief Executive Officer and the Dispel Security Officer. Reporting shall be done through a notification in the Dispel security platform.

9.2 Automated Account Disabling

NIST 800-53: AC-2(13)

Customers must define significant risk actions that would warrant an account being disabled. Customers are responsible for disabling accounts of individuals within one (1) hour of discovery of a user reaching that risk threshold.

Dispel Insider Threat Program will provide input into understanding what is deemed “high-risk” individuals or behaviors. These items will be monitored for, and developed as threat conditions change and continually added into the Security Operations Center in order to better correlate user action and trigger alerts and actions.

• Users with leaked credentials.
• Sign-ins from anonymous IP addresses.
• Impossible travel to atypical locations.
• Sign-ins from IP addresses with suspicious activity.
• Sign-ins from unfamiliar locations.

Users will also have their accounts suspended or terminated if Dispel believes the individual poses a security risk to the organization.

9.3 Automated Audit Actions

NIST 800-53: AC-2(4)

The Dispel Zero Trust Engine automatically logs actions, including account creation, account modification (e.g., editing user type), enabling, disabling, and removal actions. Logs are captured when an action is taken by an administrator. These logs are available by navigating to the Engine Dashboard page and then clicking on “Logs”. Some logs are not exposed directly to the user but instead stored in the database. For all detailed logging and audit requirements, reference the Dispel Logging Standard.

9.4 Monitoring and Control of Remote Access

NIST 800-53: AC-17(1)

Web Application & Customer Network

Dispel shall automatically log all login events into the Dashboard and make these available on the Dashboard > Log section of the site. These shall be automatically updated in a live view for continuous monitoring and IAW the Dispel Logging Standard.

Cloud & Infrastructure

The cloud control plane automatically logs all remote access as well as data plane remote access to associated resources through central logging. This function is also monitored in the Security Operations Center.

10. PROCEDURES

10.1 Access Establishment, Approvals, and Modification

NIST 800-53: AC-2(e)

The Customer shall be responsible for establishing access, approving access requests, and modifying accounts.

Requests for access to Dispel systems and applications are made formally using the following process:

1. A Dispel workforce member initiates the access request by creating an Issue in the Dispel ticketing system.
   1. User identities must be verified prior to granting access to new accounts.
   2. Identity verification must be done in person where possible; for remote employees, identities must be verified over the phone.
   3. For new accounts, the method used to verify the user’s identity must be recorded on the Issue.
2. The Chief Operating Officer will grant or reject access to systems as dictated by the employee’s job and role. If additional access is required outside of the minimum necessary to perform job functions, the requester must include a description of why the additional access is required as part of the access request.
3. If the request is rejected, it goes back for further review and documentation.
4. If the review is approved, the request is marked as “Done”, and any pertinent notes are added.

10.2 Code Execution

NIST 800-53: AC-6(8)

<FedRAMP System Specific> All components will require correct user level permissions. Users are not allowed to bypass their permissions via software applications present on the system without providing credentials to prove they have the elevated permissions.

Customers shall be responsible if they choose to elevate user privileges.

10.3 Log Privileged Function Execution

NIST 800-53: AC-6(9)

<FedRAMP Specific Section> Dispel components shall log when privileged functions are executed in the Remote Access Engine. Privileged functions exist at three levels: within the Dashboard, in Virtual Desktops, and in the underlying infrastructure.

Web Application

Privileged functions are those actions set for Organization, Region, and Facility administrators. They include actions such as adding new users, changing user privileges, and approving access windows. Events shall be logged and presented in the Dashboard.

Customer Network, Cloud & Infrastructure

Logging of privileged commands is a control administered when the baseline STIG or CIS is applied to the IaaS or Operating System. Examples below for common platforms.

On Microsoft Windows in Customer Networks, Audit Sensitive Privilege Use shall be enabled to track the following events:

• 4673(S, F): A privileged service was called.
• 4674(S, F): An operation was attempted on a privileged object.

Cloud-native logging enables granular control of all control plane actions.

On *nix Infrastructure, audit-privileged actions shall be enabled by (or as is otherwise set, if the command is changed in the Linux operating system):

Add or update the following rules in the /etc/audit/rules.d/stig.rules file:

-w /var/log/sudo.log -p wa -k actions

10.4 Prohibit Non-Privileged Users from Executing Privileged Functions

NIST 800-53: AC-6(10)

The Dispel Zero Trust Engine shall implement role-based access control (RBAC) by defining and assigning specific roles to users within the Dispel Dashboard, each with its designated set of permissions and access levels, aligning with the user’s organizational responsibilities and authority. The system shall ensure security through a combination of authentication and authorization processes. When a user attempts to access a resource or execute a function, their identity shall be verified, and their role shall be checked to confirm whether they possess the necessary permissions. The engine shall enforce strict access control policies, clearly delineating what actions each role can and cannot perform, thereby preventing users from executing functions beyond their assigned privileges. Moreover, every action taken by a user shall be correlated with their role, and the system shall block any action that requires higher privileges than what the user’s role permits. To further enhance security, the engine shall continuously monitor and log user activities, ensuring the detection and investigation of any attempts by non-privileged users to execute privileged functions.

10.5 Unsuccessful Logon Attempts

NIST 800-53: AC-7

Web Application

The Dispel Zero Trust Engine and web application layer has login failure rate limiting enabled and shall enforce a limit of 100 consecutive invalid access attempts by any user during a period of 15 minutes. The failed logon count shall reset after a successful authentication. After this limit has been exceeded, access is denied for 3 hours or until unlocked by an administrator. The system shall log failed logon attempts in the Dashboard. This shall be enforced programmatically in the Dashboard. The timings and limits shall conform to NIST 800-63B.

Customer Network

On the customer network layer, the moving target defense components are hardened and VDI rate limiting is in place. It is currently a configurable setting on the VDI to only allow logon from specified IP addresses. The timings and limits shall conform to NIST 800-63B.

Cloud & Infrastructure

On the cloud level, this is enforced by IaaS controls on the cloud management interfaces and administrative portals. The settings are managed through IaaS Identity and Access Management policies, and logs of session activities are maintained for monitoring and audit purposes.

10.6 Session Termination

NIST 800-53: AC-12, AC-2(5)

Customer Networks

The Dispel Zero Trust Engine Customer Network is the mechanism that the DZTE Dashboard creates to allow users access to their remote network resources. Dispel has identified the following conditions that will trigger the termination of an active session on this network through halting the virtual machine that the user is using, removing access control list firewall rules and cloud level security groups:

• Conclusion of Access Window
• Administrator-defined usage conditions (via observed activity)

Web Application

On the web application layer, we implement a 15-minute inactivity logout. The timeout period is configurable to allow future adjustments based on evolving security policies or operational requirements. Post-logout behavior redirects users to a secure login page to re-authenticate before resuming access.

Furthermore, the Dispel Dashboard shall terminate an authenticated session after the user is inactive for a set period or the user logs out. This is defined in the Re-Authentication section of the Identification and Authentication Policy and Procedures (Version 1.0, December 8, 2023). This shall be enforced programmatically through:

1. Session token expiration dates assigned to every session token; and,
2. A logout functionality on the Dashboard.

Inactivity logout for VDI sessions on the customer network layer is achieved via a configurable timeout mechanism. The VDI automatically terminates idle sessions and requires re-authentication for access restoration.

Cloud & Infrastructure

On the cloud level, a 15-minute inactivity logout mechanism is implemented on the cloud management interfaces and administrative portals.

10.7 Device Lock

NIST 800-53: AC-11

Web Application

The web application is used by customer devices and controlled by sessions and thus falls outside the scope of this control and the responsibility of the device owner. Dispel authorized FedRAMP devices conform to the CIS Baseline.

Customer Network

Customer networks utilize VM Desktops that are hardened to the STIG standard, which has device lock capability and automatic device locks after 15 minutes of inactivity.

Cloud and Infrastructure

Machines that have inactivity locks within the approved boundary will have STIG standards applied and implement OS level locking due to inactivity.

10.8 Actions without Authentication or Identification

NIST 800-53: AC-14

The Dispel Zero Trust Engine shall not permit any action to be taken within the system without authentication or identification previously being established except for the following actions:

This shall be enforced programmatically.

10.9 Concurrent Session Management

NIST 800-53: AC-10

<FedRAMP System Specific> The Dispel Dashboard shall limit the number of concurrent sessions a user or administrator may have when logged into the Dashboard. The system shall limit administrators (privileged) accounts and user (non-privileged) accounts to two (2) concurrent sessions. This shall be enforced programmatically in the Dashboard.

Web Application

On the web application layer, Dispel restricts all users to a maximum of two concurrent sessions. This restriction is enforced via backend configurations that monitor and control session token issuance. The system invalidates tokens beyond the maximum session limit, ensuring active sessions are capped.

Customer Networks

On the customer network layer, users are restricted to only reserving only one VDI session per network at any given time. This limitation is enforced through system-level configuration. DISA-STIG guidelines are applied to further harden this layer and ensure secure session management.

Cloud & Infrastructure

On the cloud layer, IaaS provider configurations enforce session limitations for administrative and user accounts. Session policies are configurable and tailored to organizational requirements, ensuring no user exceeds the defined concurrent session threshold. The settings are managed through AWS Identity and Access Management policies, and logs of session activities are maintained for monitoring and audit purposes.

10.10 Automatic Logoff

<Non-FedRAMP System> For Dispel company devices, users are required to make information systems inaccessible by any other individual when unattended by the users (e.g., by using a password protected screen saver or logging off the system).

10.11 Access Reviews

All access to Dispel systems and services is reviewed and updated on a quarterly basis to ensure proper authorizations are in place commensurate with job functions. The process for conducting reviews is outlined below:

1. The Security Officer initiates the review of user access by creating an Issue in the Dispel Ticketing System.
2. The Security Officer is assigned to review levels of access for each Dispel workforce member.
3. If user access is found during review that is not in line with the least privilege principle, the Security Officer may modify user access and may notify the user of access changes.
4. Once the review is complete, the Security Officer then marks the ticket as “Done”, adding any pertinent notes required.

<FedRAMP Specific> Notwithstanding the foregoing, reviews of privileged accounts held by Dispel employees on FedRAMP systems will be reviewed on a monthly basis.

10.12 Workforce Clearance

• The level of security assigned to a user to the organization’s information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user’s job classification.
• All access requests are treated on a “least-access principle.”
• Dispel maintains a minimum necessary approach to access to Customer data.

10.13 Unique User Identification

• Access to the Dispel Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
• Password requirements mandate strong password controls.
• Passwords are not displayed at any time and are not transmitted or stored in plain text.
• Default accounts on all production systems, including root, are disabled.
• Shared accounts are not allowed within Dispel systems or networks.
• Automated log-on configurations other than the company’s approved Password Management provider that store user passwords or bypass password entry are not permitted for use with Dispel workstations or production systems.

10.14 Employee Workstation Use

All workstations at Dispel are company owned, and all are laptop products running Windows, Mac OSX or Linux.

• Workstations may not be used to engage in any activity that is illegal or is in violation of organization’s policies.
• Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or “X-rated”. Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual’s race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through the organization’s system.
• Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to organization’s best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
• Solicitation of non-company business, or any use of organization’s information systems/applications for personal gain is prohibited.
• Users may not misrepresent, obscure, suppress, or replace another user’s identity in transmitted or stored messages.
• Workstation hard drives must be encrypted.
• All workstations have firewalls enabled to prevent unauthorized access unless explicitly granted.

10.15 Employee Termination/Offboarding Procedures

1. The People & Places Department (or other designated department), users, and their supervisors are required to notify the Security Officer upon completion and/or termination of access needs and facilitate completion of the “Termination Checklist”.
2. The People & Places Department, users, and supervisors are required to notify the Security Officer to terminate a user’s access rights if there is evidence or reason to believe the following (these incidents are also reported on an incident report and is filed with the Privacy Officer):
   1. The user has been using their access rights inappropriately;
   2. A user’s password has been compromised (a new password may be provided to the user if the user is not identified as the individual compromising the original password);
3. The Security Officer will terminate users’ access rights within 1 business day of termination/separation, and will coordinate with the appropriate Dispel employees to terminate access to any non-production systems managed by those employees.
4. The Security Officer audits and may terminate access of users that have not logged into the organization’s information systems/applications for an extended period of time.

11. PRECEDENCE AND COMPLIANCE

11.1 Precedence

NIST 800-53: AC-1

Whenever inconsistencies are found to exist between the above policy and any applicable laws, executive orders, directives, regulations, policies, standards, or guidelines, the latter will prevail. Upon discovery of any inconsistency, the Policy Owner will revise the impacting sections of the Policy within no more than 30 days to align with all applicable laws, executive orders, directives, regulations, policies, standards, or guidelines.

11.2 Compliance

NIST 800-53: AC-1

Compliance with the policies and procedures stated within this document will be, at a minimum, tracked using the following methods. Additional processes may be listed within sections of this document or supporting documents.

12. DOCUMENT HISTORY

13. APPROVAL SIGNATURES