The 2021 Dragos Year in Review (YIR) notes that 77% of Dragos services engagements performed that year involve issues with network segmentation. One of the top four findings is Poor Security Perimeters.
Dragos considered findings to be related to poor security perimeters if they involved issues such as porous firewall rules, network boundary bypasses, or flat networks. This includes instances where the only segmentation is the initial firewall between the IT-OT boundary and when there are unnecessary communication pathways to critical assets within the network.
Dragos 2021 ICS/OT Cybersecurity Year In Review
A security perimeter is “a physical or logical boundary that is defined for a system, domain, or enclave; within which a particular security policy or security architecture is applied.”1 When properly implemented it acts as a barrier to traffic from other security perimeters or trust zones.
Problems with Flat Network Design
A flat network is problematic for several reasons. Flat networks often combine assets that should be separated into their own networks such as VoIP Phones and IP Cameras. These readily accessible assets may use vulnerable protocols which are easily compromised. Additionally, once an adversary gets initial access, a flat network allows access to the entire network and any connected assets.
This is especially true of industrial control system/operation technology (ICS/OT) networks as the assets they connect may lack the traditional security controls found on a Corporate/IT network. To illustrate this, consider:
- a critical piece of equipment running on an unsupported operating system (OS) which is prohibitively expensive to upgrade to a supported OS,
- the workstation managed by a vendor whose warranty you would violate were you to add the software agent required for your antivirus software, or
- that mysterious piece of equipment no one wants to touch because it just seems to work (and don’t forget “if you touch it, you own it”).
One method for addressing a flat network is with firewalls. Firewalls segment networks by inspecting the network traffic and filtering the traffic based on security policies. A well configured firewall permits desired traffic and denies unacceptable traffic.
Managing a firewall can be challenging because overly restricted firewall rules block traffic that should be allowed whereas promiscuous firewall rules result in unsafe or unwanted traffic. Since an overly restricted firewall policy results in a denial of service, the consumer, failing to get access to a certain service, quickly identifies and voices their concerns (“hey IT, my application no longer receives weather feeds…”). On the other hand, no one complains if an application they use has access to something it should not. They may not even be aware it has access.
Over time, without the right controls in place, it is natural for a firewall to become less restrictive resulting in porous firewall rules and reducing the barriers an adversary must overcome to access critical networks and assets.
Even with firewalls and other boundary controls, it is not unusual to see some traffic bypassing network boundaries. In some instances, this seemingly harmless activity might even be expected or required by the organization. Common reasons for bypassing network boundaries include:
- resolving domain names through DNS,
- applying windows patches or updating antivirus signatures,
- accessing a corporate historian,
- accessing files from a shared drive, and
- remotely accessing a host through a secure, encrypted tunnel such as a virtual private network or VPN.
Planning the Network with Security in Mind
Proper network design and implementation of network segmentation is the first step in avoiding poor security perimeters. Investment in “the planning, establishing, and upkeep of systems with security in mind,” yields the largest return on investment dollars according to the sliding scale of cybersecurity.2 In terms of strengthening security perimeters, this investment focuses on updating, improving, and maintaining network design and network segmentation.
Of the 12 verticals analyzed in the Dragos YIR, the “poor security perimeters” finding was common in all industry verticals except for Datacenters and Nuclear. It should come as no surprise that the Nuclear Regulatory Commission (NRC) requires separating assets into five security zones based on criticality.3
It Comes Down to Trust: Using the Purdue Enterprise Reference Architecture
A tiered network architecture such as the Purdue Enterprise Reference Architecture (PERA) shown below is an example of organizing common operational elements into zones with differing levels of trust.4 These zones progress from least trusted public networks such as the Internet (Level 5), to the most trusted equipment used to control the physical process such as sensors and actuators (Level 0).
These zones communicate to each other over connections called conduits. The conduit must be secured to the same level of criticality as the most trusted zone it connects. For example, the communication path from Level 2 to Level 3, the conduit, must be secured to the same level of criticality as Level 2 the more trusted zone.5 Physical and logical network modifications may be necessary after the networks are conceptually segmented (divided), segregated (isolated), and connected via zones and conduits to accommodate the network design and apply the appropriate security requirements.
In general, flat networks allow unrestricted communications between devices. In a network with minimal segmentation, devices can communicate with each other without connecting to a boundary device, such as a firewall or router. Additionally, flat networks have few security measures in place to monitor traffic. A well-segmented network will utilize multiple solutions like subnetting, switches, routers, firewalls, and security products to control and monitor communications.
Firewalls are a great security control for segmenting networks and protecting perimeters (zones) and the connections (conduits) between the perimeters. Firewalls are configured with access control lists (ACLs). ACLs are assigned to network interfaces on the firewall and act as a sequential list of rules which determine if network traffic will be permitted or denied into an adjacent network. These individual rules are referred to as access control entries (ACEs). ACEs permit or deny network traffic based on several criteria including, but not limited to IP addresses, protocols, User-IDs, and/or specific applications. Porous firewalls or firewalls with less restrictive rules reduce the barriers an adversary must overcome to traverse between trust zones, potentially allowing them to access critical ICS/OT networks and assets.
An adjacent network policy rule refers to a policy restricting all traffic to adjacent networks based on trusts. A network boundary bypass refers to any communications that traverse multiple layers of trust (bypassing zones) thereby violating this policy.
Securing Common Network Boundary Bypasses
One example of a self-inflicted network boundary bypass commonly seen in an ICS/OT environment occurs when a historian, located in the same network as the SCADA or DCS, is accessed by clients in the corporate network or when the historian, located in the corporate network, is accessed by clients from the SCADA or DCS networks. Both examples frequently allow access by multiple clients and require the use of insecure protocols such as certain versions of SMB, NetBIOS and OPC.
The historian access referred to above is a legitimate configuration in terms of functionality. The misconfiguration, i.e., the network boundary bypass, is often characteristic of an architecture partially designed by Corporate/IT and partially designed by ICS/OT. There are several ways to enhance the security of this architecture, including:
- limit the number of hosts with access and closely monitor,
- require multi-factor authentication (MFA),
- monitor internal network traffic using OT specific sensors.,
- limit the session times at the firewall,
- closely monitor firewall logs,
- replication of the historian from one network to another,
- limit the flow of traffic to one direction using a data diode,
- the use of proxies, and
- use of a demilitarized zone (DMZ).
Other network boundary bypasses such as patching described in the previous section can be addressed using similar security enhancements. One method which is commonly used to address this issue is the use of a DMZ. This method is described in the next section.
Establishing a DMZ
A key element of a well-segmented network is the presence of a DMZ. DMZs, sometimes referred to as level 3.5, are zones which facilitate the transfer of information between other security zones of differing levels of trust. Network DMZs should contain security features to force connections and information to terminate, undergo inspection, and then reconnect or wait for retrieval.
Most organizations have DMZs between their corporate environment and the internet where they host internal applications like web servers, internet proxies, and email servers. Internet and internet accessible networks like the corporate network, are typically considered untrusted from the ICS/OT standpoint.
In industrial-related organizations, a DMZ should exist between the corporate and ICS/OT networks. This DMZ is designed using firewalls and configured so all connections terminate in the DMZ. A tiered network architecture with a DMZ such as that shown in Figure 1 above provides a security buffer between the trusted and untrusted networks and typically contains hosts that facilitate patching, remote access, and mirrors for historian data and applications.
Other security features such as MFA, network monitoring, enhanced logging and hardening of the hosts should be considered to help strengthen the security in the DMZ.
In Summary
Fortifying your security perimeters requires a solid understanding of your OT architecture. The strategies for strengthening the security perimeters discussed in this post can be accomplished using well known cybersecurity tools. A focus on securing the perimeters will positively impact the other three key findings of Dragos’s 2021 Year in Review: lack of visibility, external connections to the ICS environment, and lack of separate IT & OT user management.
References
- Committee on National Security Systems Instruction No. 4009, Committee on National Security Systems (CNSS) Glossary, April 2015, https://www.cnss.gov/CNSS/issuances/Instructions.cfm.
- Robert M. Lee, “The Sliding Scale of Cyber Security”, SANS Institute, September 1, 2015, https://www.sans.org/white-papers/36240/.
- U.S. NRC, “Protection of digital computer and communication systems and networks,” NRC, March 24, 2021, https://www.nrc.gov/reading-rm/doc-collections/cfr/part073/part073-0054.html
- Stephen Mathezer, “Introduction to ICS Security Part 2,” SANS, July 16, 2021, https://www.sans.org/blog/introduction-to-ics-security-part-2/
- See standards such as ANSI/ISA 62443-3-2 for additional guidance on creating zones and conduits
Ready to put your insights into action?
Take the next steps and contact our team today.