NetFoundry and Zero Trust Outcomes in ISA/IEC 62443

NetFoundry and Zero Trust Outcomes in ISA/IEC 62443

NetFoundry | NetFoundry and Zero Trust Outcomes in ISA/IEC 62443

Introduction to ISA/IEC 62443 Standards

ISAGCA has published a paper titled Zero Trust Outcomes Using ISA/IEC 62443 Standards. This paper investigates the intersection of IEC 62443 and Zero Trust principles and the benefits of various roles of the adoption of Zero Trust concepts to enhance ISA/IEC 62443-based security practices. Specifically, the paper identifies some of the direct overlap between Zero Trust and the requirements of the IEC 62443 specification. NetFoundry can enable these requirements at the network level as part of an overall security design, and we will explain how.

NetFoundry Cloud, powered by NetFoundry’s Ziti architecture and the OpenZiti open source, is a software-defined networking solution, designed to provide secure connectivity and enable Zero Trust architectures, providing full network operations capabilities. It is well suited for use in the OT/ICS space as it does not assume a human user-to-application use case, as many solutions do, though it can serve that need. 

The network layer focus of the solution allows it to be used in much more resource-constrained environments and in a broad set of use cases, many of which are applicable to the industrial space. It also has a focus on availability which is critical for safety first, can run in air gapped networks, and can support L2 and real-time communications all of which are critical for running in OT environments which need to comply to 62443 and other regulations.

Zero Trust Framework

Explore how NetFoundry enhances IEC 62443 security through Zero Trust principles and architecture.

Secure OT Framework

Integrating NetFoundry’s Zero Trust with IEC 62443 standards for enhanced security.

ISA/IEC 62443 Overview

Exploring the integration of NetFoundry’s Zero Trust principles within ISA/IEC 62443 security standards.

Protect Surface, Network Flow / Zones, Conduits

The ISA/IEC 62443 concept of a zone is a grouping of 1 or more nodes that share a set of security requirements.  Zero Trust refers to these as segments, network segments, that can be protected as a unit to enforce certain security requirements. As the number of hosts or applications approaches one, these are referred to as microsegments. A microsegmented network provides a more generally secure environment, limiting many attack vectors allowing for lateral movement within an environment.

NetFoundry has made their Ziti Platform available via open source in the OpenZiti project. OpenZiti software and the SDKs used to embed the solution into applications allows for many forms of segmentation, including application specific microsegmentation – or ‘AppNets’. There are 3 general architectures for deploying Ziti technology. It is important to note that these are not mutually exclusive, and all 3 can be deployed within the same network and even overlapping, depending on the requirements of the given situation. You can read more here.

  • ZTNA – Zero Trust Network Access: A common term in Zero Trust discussions, ZTNA deployments utilize the Ziti network for most of the path, with the first and/or last “mile” outside the actual Ziti network. This is also commonly referred to as a gateway model. While the least secure, this offers many benefits in terms of simplicity, and to deal with situations where being on host or embedded is simply not an option due to the nature of the connected devices. This model uses external security configuration, simple access control lists, to prevent access to any resources other than via the authorized Ziti network components – which we can refer to as having zero trust of the external WAN network.
  • ZTHA – Zero Trust Host Access:A more microsegmented approach, ZTHA provides a secure path from or to the host compute node. In many cases, embedding the software with Ziti technology is not an option, as it is owned by a third party or is not under active development. The use of host based access controls similar to network ACLs can prevent any unauthorized access to the node, while easily allowing the secured Ziti network connectivity. Blocking all inbound communications while allowing outbound enables the functionality while being simple to manage. In higher security requirement environments, the controls can whiltelist the Ziti network components specifically outbound. This, of course, brings additional operational requirements, and should be decided based on the risk analysis.- This model extends zero trust principles to the external WAN as well as internal LAN network.
  • ZTAA – Zero Trust Application Access:The most microsegmented deployment model is ZTAA. The software development kits (SDKs) provided by the OpenZiti project allows the secure connectivity to be built into the applications themselves. This can then be used as the sole network connectivity option for the application, ensuring it always initializes into a secure network state, or can be built as an option, based on configuration, like the Caddy project providing a configurable option for a Ziti interface. This model ensures the app has no listening ports on any underlay network, WAN, LAN, or host OS network, rendering all conventional network threats immediately useless.

 

Whether the zone is served as a subnet/VLAN in a ZTNA gateway model, a host, or an application, the connections between that zone and any others meet all the requirements of a secured conduit per IEC 62443. They are individually encrypted and routed, and only authenticated and authorized identities can dial the circuits (channels) within the conduit. As the entire path between identities is encrypted, it passes over the existing physical network infrastructure as a virtual conduit from initiating to the target zone.

Microsegmentation Strategies

Integrating ISA/IEC 62443 zones and NetFoundry’s Zero Trust for enhanced security solutions.

Trusted Authentication Framework

OpenZiti utilizes X.509 certificates for secure device authentication and identity management.

Strong Identity

OpenZiti uses X.509 certificates as the root of trust for authentication. Cryptographically signed by the Network Controller – see 5 part blog on ‘Bootstrapping Trust’ – or imported into the network instance for use cases involving external certificate authorities like those installed when the device is manufactured, the certificate can be protected in a number of ways. By default, the certificate is in the file system. The permissions applied to the file can be restricted as necessary, provided the Ziti application can read if for the necessary operations. For higher security applications, Ziti supports PKCS11 interfaces, so the certificate material and all necessary operations can use a hardware security module or similar device. The certificate authenticates the device’s identity, so by itself it is meaningless, the device must also have a configured identity in the network, which can be modified or removed.

Having a standardized cryptographically secured authenticator meets the highest level of strength for identities, and the protection model of that authenticator is an implementation choice, depending on the requirements of the environment. This identity only allows network access to those configured services, and does not provide any access to the applications themselves that are defined as services. Also, ensuring the identity is sovereign to the endpoint ensures that no one else has the ability to decrypt/inspect on the data plane, even if the data plane is hosted by a 3rd party.

Secure Comms

As noted previously, all communications across the Ziti network are encrypted, double encrypted “on the wire”, as the circuit is encrypted end to end, and the channels or links that carry them are independently encrypted as well. The use of device or host based options to protect the local physical connection is a design point of the overall system, as Ziti does not natively provide protection at that point. These decisions also affect whether or not the device allows any nonZiti access to the device, and should be taken into consideration. Appropriate to the risk level, Ziti can be used to allow low friction access to and from devices, while maintaining the necessary security, allowing only authenticated and authorized persons or processes to send or receive data to and from the device. OpenZiti encryption is built for extensibility which allows ‘crypto agility’ – e.g., towards quantum encryption – which are increasingly important topics in OT and critical infrastructure covered by 62443. It should also be noted that Ziti separately encrypts and routes each AppNet.

Enhanced Encryption Standards

Ziti employs double encryption for secure communications, ensuring robust protection across devices.

Dynamic Access Control

Ziti leverages policies for secure connectivity, enabling real-time management and monitoring.

Data Flow Policy

Ziti uses policy to allow connectivity between identities and services. A single service can be allowed to be hosted by a single identity, with another single identity accessing it, even in a large network. The use of attribute tags can allow for groups of identities to be allowed to access groups of services, or to host services via an addressing system. Built-in tools, such as the policy advisor, can be used to verify accessibility, taking into account all the applied policies, and the APIs can be utilized to extract the information for auditing or other external purposes.

The API and event driven nature of Ziti also allows for dynamic updates to the configuration. It is straightforward to create a solution for tying access to business and other rule sets in real time.

Beyond the ability to manage these policies, Ziti also provides detailed event and metric data to allow for the auditing of the connectivity, an important use case in forensics and incident response, as well as behavioral analysis and other monitoring. The access of any identity to a service is emitted, and the data volume transferred is emitted every minute (by default, configurable). The ingestion of these records by a UEBA or other system can allow for immediate actions to terminate connectivity. The removal of authorization to a service will result in the termination of current connections, as well as prevent any new ones. These changes are effective within seconds of the change being made. 

As you can see, not only can Ziti create and enforce appropriate data flow policies, it enables the monitoring and appropriate response to anomalous behaviors, or changes in business rules with real time effect.

Least Privilege Access

Least privilege generally concerns privileges granted within an application. Ziti does not act above the data plane, so does not affect the permissions directly. However, the available specificity of network connections can enhance a least privilege model by controlling who can reach the application at all. Depending on the complete design, involving many of the concepts above, even individuals with physical access to a network port can be blocked from accessing the information or device without proper authentication and authorization. Individual network service on the same device can also be separately managed, allowing access to a UI, for example, to the appropriate personnel, while allowing access to a ssh port to administrators only.

While OpenZiti does not provide features for least privilege in the most common usage, it certainly can enforce least connectivity as a part of the overall strategy.

Enhanced Least Privilege

Ziti supports least privilege by controlling network access, enhancing application security strategies.

Continuous Monitoring Solutions

OpenZiti enables ongoing authentication and behavioral analysis for enhanced security oversight.

Continuous Monitoring

There are 2 current forms of continuous monitoring, depending on definition. Continuous authentication, verifying that the user’s session continues to be allowable based on the rules sets, and behavioral analysis.

Using the authentication policies defined in OpenZiti, the simplest form of continuous authentication is MFA via one-time tokens (with many other posture checks supported and being developed). These posture checks can be configured based on time, and/or events such as a laptop being “woken up”, or unlocked. This ensures that the authenticated user is still in control of the device prior to allowing access to any services. 

As noted in the Data flow policy section above, OpenZiti can be configured to output a wide range of information. These events and metrics can indicate the operations of the network in general, as well as highly specific information about its usage. Every connection (circuit) within the network is logged at creation and deletion, giving the initiating identity, service, hosting identity, and the path through the network.  Every circuit is authorized by a session created when the identity attaches to the network, and this session is also logged for creation and deletion. This record contains the Network Controller’s view of the IP address the device is attaching from, the time of the event, etc. Even when the deployment model is ZTNA, and an Edge Router is operating as a gateway to a nonZiti portion of the network, initiating or terminating, the socket information (IP:PORT) is collected and reported in the events. This allows for correlation of translated addresses or nonZiti clients with other systems in auditing or forensic investigations.

All changes made to the network model, services, identities, policies, and entities are also emitted as events, allowing the monitoring of changes made to the network in real time or as an audit function.