The NIST Special Publication 800-82 serves as a comprehensive guide to securing industrial control systems (ICS), including Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), and other control systems configurations such as Programmable Logic Controllers (PLCs). As they have done with other recent publications, NIST publications are now more guideline recommendations rather than prescriptive checklists, leaving their implementation more open to interpretation. While this strategy makes sense given technology changes rapidly, the onus now rests with the individual to understand and interpret what NIST suggests. If you haven’t read the Special Publication 800-82 and would like to gain a more comprehensive understanding of the following recommendations, it might be worth the read. If you’re looking for a checklist format of recommendations, take a look at NIST 800-53.
Section 5 of the NIST publication focuses specifically on network security architecture for an ICS deployment. In the following section, we dive into a handful of the more complicated recommendations more in-depth. Keep in mind that we also recommend that you read the full publication yourself—it’s less intimidating than you might think.
Sections We Discuss:
- Network Segmentation and Segregation (see sections 5.1 &5.5)
- Boundary Protection (see section 5.2)
- Firewalls (see sections 5.3, 5.7, 5.8 & 5.10)
- Specific ICS Firewall Issues: Remote Access (5.10, 5.10.2)
- Preventing Man-in-the-Middle Attacks (see section 5.14)
- Authentication and Authorization (see section 5.15)
- Network Segmentation and Segregation (see sections 5.1 & 5.5):
- Network Segmentation and Segregation (see sections 5.1 & 5.5):
- What You Need to Know: Network segmentation partitions a network into smaller networks. Network segregation both develops and enforces a ruleset controlling which communications are permitted through the boundary. The idea is that OT should not connect to IT at all. NIST devotes an entire section to network segregation separately, focused on segregating ICS networks and corporate networks to increase security.
- What You Can Do: The idea behind network segmentation and segregation is to limit the level of access to sensitive information that individuals have. NIST recommends logical separation enforced by encryption or network device enforced-partitioning, physical network separation, and network traffic filtering. Additionally, NIST lists four common themes considered part of defense-in-depth: (1) applying technologies at more than the network layer, (2) using least privilege and need to know, (3) separating information and infrastructure based on security requirements, and (4) implementing whitelisting.
- For network segregation specifically, dual-homed computers/dual network interface cards (NICs) can pass network traffic from one network to another, while placing a firewall between a corporate network and control network can reduce the risk of attack on the control network. Other suggestions recommended by NIST include placing a firewall and router between the corporate and control network, using a firewall with DMZ between corporate network and control network, or using paired firewalls between the corporate network and control network.
- Importantly, NIST notes that dual-home computers do not provide suitable isolation between control networks and corporate networks, and two-zone solutions only provide weak protection. The most effective control network and control network segregation typically comprise of three zones (with one or more DMZs).
- Boundary Protection (see section 5.2):
- What You Need to Know: Boundary protection devices protect ICS against malicious cyber adversaries and other unauthorized communication by determining whether data transfer is permitted. For example, you can isolate ICS and business system components performing different functions or missions. The idea is that you protect the risky connection made between the ICS and corporate networks. These devices include gateways, routers, firewalls, guards, network-based malicious code analysis and virtualization systems, intrusion detection systems, encrypted tunnels, managed interfaces, mail gateways, and unidirectional gateways.
- What You Can Do: Boundary protection devices must work with your organizational security architecture to enforce your security policies. When designing your security architecture, you must consider domains to permit direct communication, the policies that dictate permitted communication, devices used to execute this, and the topology for implementing these decisions. Suggestions for implementing boundary protection include denying communications traffic by default and/or exception, implementing proxy servers, preventing the unauthorized exfiltration of information, limiting communications between authorized and authenticated source and destination address pairs, extending the DMZ concept to other separate subnetworks, and enforcing physical access control. Other recommendations include concealing network address components from discovery, disabling control and troubleshooting services and protocols, configuring boundary protection devices to fail in a predetermined state, configuring security domains with separate network addresses, disabling feedback to senders during failure in protocol validation format, implementing one-way data flow, and establishing passive monitoring of ICS networks.
- Firewalls (see sections 5.3, 5.7, 5.8, 5.10 & 5.10.2):
-
What You Need to Know: A firewall is an inter-network gateway that controls the flow of traffic between networks with differing security postures. Some choose to use firewalls on their corporate networks to restrict access to and from internal networks tending to more sensitive functions. Not only can firewalls drastically restrict undesired access to and from control system host computers and controllers, but they also can improve a control network’s responsiveness by eliminating non-essential traffic from the network.
-
What You Can Do: The main three classes of firewalls include packet filtering firewalls, stateful inspection firewalls, and application-proxy gateway firewalls. For the purposes of ICS, firewalls are most often used between the ICS network and the corporate network. Firewalls can also be host-based or small standalone hardware devices.
NIST recommends that firewalls possess the following characteristics:- a base rule set that is deny all, permit none,
- ports and services between the control network and corporate networkshould be enabled and permissions granted on a case-by-case basis,
- “permit” rules should be IP address and TCP/UDP port specific,
- all rules should restrict traffic to specific IP address(es),
- traffic should not transit from the control network to the corporate network directly,
- protocols allowed between the control network and DMZ should explicitly not be allowed between the DMZ and corporate networks (and vice versa),
- outbound traffic from the control network to the corporate network should be source and destination-restricted by service and port, and;
- outbound packets should only be allowed to travel from the control network or DMZ if they have a correct source IP address.
-
Additionally, control network devices should not be allowed to access the internet or be directly connected to the internet, all firewall management traffic should be carried on a separate and secure management network or over an encrypted network with MFA, all firewall policies should be tested periodically, and all firewalls should be backed up prior to commissioning.
-
If you want to learn more about firewall rules for specific services, be sure to read section 5.8 in the NIST Special Publication 800-82. Remote support access is covered in this section.
-
- Specific ICS Firewall Issues: Remote Access (see sections 5.10 & 5.10.2):
- What You Need to Know: In conjunction with the firewall and ICS issues previously discussed, NIST selects three specific ICS firewall issues to explore further. For the purposes of this guide, we focus on remote access. Remote access allows users and/or vendors to access the control network off-site.
- What You Can Do: Remote access is an ideal way for operators or third parties to gain access to OT networks. Keep in mind that traffic should be encrypted and utilize a form of MFA, such as a token-based mechanism, if you pass through the general corporate network. Once connected, authentication should be required a second time before interacting with the industrial control system. However, there are alternative options to running VPNs to the corporate network and the control network. Dispel’s Wicket ESI serves as an exclusive form of entry to your ICS network, only allowing those who are whitelisted to gain access and rejecting all inbound communications. Rather than using a static VPN, Dispel’s Wicket reaches out to establish a VPN to a moving target defense SD-WAN that allows the user to find the Wicket and gain entry.
- Preventing Man-in-the-Middle Attacks (see section 5.14):
- What You Need to Know: An Address Resolution Protocol (ARP) man-in-the-middle attack requires knowledge of the protocol being manipulated and is used by an adversary to gain access to the network flow of information on a target system. An adversary attacks the network ARP cache tables of the controller and workstation machines, and can use the compromised computer on the control network to poison the ARP tables on each host and tell them to route all of their traffic through a specific IP and hardware address—one of their machines.
- What You Can Do: Although protocol manipulation and man-in-the-middle attacks are common practices, they can be mitigated through various techniques. MAC address locking, or port security, secures the physical connection at the end of each port on a network switch, preventing any open network jack to be used as a way onto the corporate network. Security should flag and block duplicate MAC addresses to prevent spoofing attempts. Statically coded ARP tables, encryption, protocols with strong authentication, and consistent monitoring for ARP poisoning are potential methods of defense as well.
- Authentication and Authorization (see section 5.15):
- What You Need to Know: The process of authentication verifies a user’s identity, whereas authorization grants the user access privileges. A distributed approach to authentication and authorization means that every system must store its own user accounts, credentials, and roles. A centralized approach is typically used to manage a large number of users and accounts and often incorporates a centralized authentication system.
- What You Can Do: Authentication and authorization are common practices in IT, but ICS integration can pose new challenges. In some cases, ICS may require their own application-specific accounts and authentication mechanisms that have trouble interfacing with third party servers and protocols. Monitoring, logging, and auditing are important activities you need to account for with ICS. Network security monitoring can tune you in to compromised systems, and all three behaviors are necessary to perform troubleshooting. Incident detection, response, and system recovery are key facets to consider when forming a good security program as well.
Keep in mind that this document is by no means a comprehensive guide to the entire NIST 800-82 framework. Areas covered more in-depth in NIST 800-82 include logically separated network control, recommended defense-in-depth architecture, network address translation (NAT), unidirectional gateways, single points of failure, and redundancy and fault tolerance.
REFERENCES:
NIST 800-82: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf
NIST 800-53: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
Remote access has become a necessity to organizations operating ICS. Your time matters, and your systems should work. Invest in a remote access system built from the ground up for industrial control networks, uniquely secured with moving target defense, with no compromises on security.
Get your quote at https://dispel.io