> For the complete documentation index, see [llms.txt](https://docs.dispel.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dispel.com/regulatory-framework-mappings/section-5-ics-security-architecture.md). # Section 5: ICS Security Architecture Page 49 - 73 of https\://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf ## Introduction ![](https://2668873066-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LqlTpechIfonX0FqSV8%2F-MXhUlS6OCplJSCyzXJ5%2F-MXhVd4c_r8OsVsdgQjY%2F80082.jpg?alt=media\&token=84174749-27dd-4463-a493-89861853393e) The aptly named NIST 800-82 "Guide to Industrial Control System (ICS) Security" provides guidance on how to assess and manage the cyber risks associated with industrial control systems. Section 5 of the document, titled "ICS Security Architecture", provides recommendations on network layouts and communications protocols. Seasoned readers of NIST Standards will note that 800-82 is both remarkably flexible in its recommendations—accommodating a broad range of approaches while noting their drawbacks. In mapping Dispel's product line to this standard, then, we have focused on how Dispel enables the best practices highlighted in the document's recommendations. ### Section 5.1 | Network Segmentation and Segregation #### How Dispel Fits Dispel Wicket External Systems Integrators ("Wicket ESIs") drive data out from a whitelisted subnet of ICS devices through a VPN connection to a single-tenant, Moving Target Defense software-defined wide area network ("MTD SD-WAN") by and through which an authenticated user can access those devices. Portions or all of a Dispel MTD SD-WAN can be set to self-destruct after a connection is completed. The result of the foregoing is that segmentation is achieved cryptographically, topologically, and temporally. ### Section 5.2 | Boundary Protection #### How Dispel Fits Dispel's Wicket ESIs sit on the OT-IT DMZ, providing an authenticated user with whitelisted access to a subnet of ICS devices. Dispel's Virtual Desktop components act as intermediary boundaries between users and the ICS systems to which they are connected. When set with the appropriate restrictions, Dispel Virtual Desktops can be used to conceal the network addresses of the ICS devices from the end user. At a higher level, Dispel MTD SD-WANs serve to conceal the ICS system from network reconnaissance. ### 5.3 | Firewalls #### How Dispel Fits When properly installed, a Dispel Wicket ESI acts as the exclusive point of entry to an ICS network; only affords an authenticated user with access to a whitelisted subset of devices; and, rejects all inbound communications, reaching out instead to establish a link to the MTD SD-WAN. Dispel's Virtual Desktops can be outfitted with Screen Recording. Moreover, only authenticated users with a tool capable of finding an entrance to the correct MTD SD-WAN can even begin the process of reaching a Dispel Wicket ESI. These factors, collectively, meet the characteristics of a firewall as provided within section 5.3. *However,* Dispel would strongly recommend the implementation of at least one independent Layer 3 and Layer 4 firewall ahead of, and at least one Layer 7 firewall behind, any Dispel Wicket ESI. ### 5.4 | Logically Separated Control Network #### How Dispel Fits A Dispel Wicket ESI acts as the exclusive point of entry to an ICS network; only affords an authenticated user with access to a whitelisted subset of devices; and, rejects all inbound communications, reaching out instead to establish a VPN to the MTD SD-WAN through which an authenticated user can reach the Wicket ESI. ### 5.5 | Network Segregation #### How Dispel Fits Dispel is typically deployed into environments that already have network topologies mapping to 5.5.2, 5.5.3, 5.5.4, or 5.5.5. The placement of the Dispel Wicket ESI is variable based upon what subsystems the customer desires to remotely access. ### 5.6 | Recommended Defense in Depth Architecture #### How Dispel Fits When placing Dispel within the context of the Control Systems Security Program NCCIC/ICS-CERT "Control Systems Cyber Security: Defense in Depth Strategies" recommended architecture, please treat Dispel as an MTD SD-WAN sitting on a time-dependent DMZ for use by remote operators and business peers. ### 5.7 | General Firewall Policies for ICS #### How Dispel Fits While this section largely is oriented towards Layer 3, 4, or 7 firewalls, it bears repeating that the Dispel Wicket ESI prevents all inbound connection attempts, proactively reaches out to establish a connection with the relevant MTD SD-WAN; and employs whitelisting to give authorized users access to relevant connected ICS devices. ### 5.8 | Recommended Firewall Rules For Specific Services **How Dispel Fits** All of the connections made into a Dispel Wicket ESI are done through a VPN. The specific services addressed by 5.8 are frequently observed inside of the perimeter of Dispel customer networks, but none are engaged as a means of transmitting through the Dispel system. ### 5.9 | Network Address Translation (NAT) #### How Dispel Fits Natting frequently takes place before data reaches the Dispel Wicket ESI. However, Dispel does not participate in this process. ### 5.10.12 | Remote Support Access #### How Dispel Fits A Dispel Wicket ESI acts as the exclusive point of entry to an ICS network; only affords an authenticated user with access to a whitelisted subset of devices; and, rejects all inbound communications, reaching out instead to establish a VPN to the MTD SD-WAN through which a user can reach the Wicket ESI after authenticating using a multi-factor authentication mechanism (typically a temporary one time password). As part of the access process, users typically are required by Dispel's customers to perform a second authentication at the Control Network Firewall prior to interacting with the relevant ICS system. This second authentication step brings the remote access process fully into alignment with the recommendations of section 5.10.12. ### 5.11 | Unidirectional Gateways #### How Dispel Fits Dispel can implement unidirectional gateways into ICS remote access deployments. Typically, however, they are already embedded into the environments Dispel is engaged to afford remote access to. ### 5.12 | Single Points of Failure #### How Dispel Fits Dispel, when properly deployed, is the single means of accessing an ICS system remotely. While Dispel certainly hopes that its system will continue to work so long as large portions of the Internet remain functional, we work with our customers to develop viable fallback plans, often in the form of independent medium (telephone) communications to on-site or physically proximate personnel. From a deployment resiliency perspective, Dispel recommends a mixed redundancy model at both a network and hardware level, budget permitting. ### 5.13 | Redundancy and Fault Tolerance Dispel does not assist with this subsection. ### 5.14 | Preventing Man-in-the-Middle Attacks #### How Dispel Fits By wrapping the ICS system in a Moving Target Defense network, Dispel prevents attackers from locating the communication channel through which the ICS system can be accessed. Transmissions through a Dispel MTD SD-WAN are double wrapped with AES-256 using independent 4096 bit keys for the initial key exchange, reducing the risk of an attacker delivering correctly parsable data to the target. Finally, Dispel MTD SD-WANs use servers from multiple global cloud providers, often traversing virtual machines serviced by multiple hypervisors. This approach further reduces the risk of an attacker successfully consuming the network in a mass hyperjacking event, breaking AES-256, and acting as the intermediary. ### 5.15 | Authentication and Authorization #### How Dispel Fits Dispel has, generally, been agnostic to the type of authentication methodology selected by its customers - finding it easier for everyone to tie into pre-existing Active Directory and LDAP structures as well as whatever multi-factor authentication tool the customer already uses. ### 5.16 | Monitoring, Logging, and Auditing #### How Dispel Fits Dispel affords customers with the ability to live stream the activities of users to a supervisor's screen for real-time monitoring. An alternative, associated, option offered by Dispel involves screen recording all connected users' actions for auditing. All of the components of a Dispel network speak syslog and their records can be streamed to the monitoring system of a customer's choice. ### 5.17 | Incident Detection, Response, and System Recovery #### How Dispel Fits Dispel MTD SD-WANs are composed of virtual machines that, from time-to-time, are replaced with fresh components. This embedded process of self-destruction and renewal affords Dispel networks with a unique level of resiliency to regional disruptions. However, in the context of 5.17, perhaps the most valuable aspect of Dispel's system is its comprehensive logging of activity. As a consequence of Dispel MTD SD-WANs being single-tenant and, in ICS remote access deployments, single-purpose, Incident Response teams are able to view these networks as hyper-quiet, reducing the ground that must be covered to find an attacker. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.dispel.com/regulatory-framework-mappings/section-5-ics-security-architecture.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.