For the purposes of this book, the terms “Industrial Network” and “Critical Infrastructure” are used in somewhat limited contexts. “Industrial Network” is referring to any network operating some sort of automated control system that communicates digitally over a network, and “Critical Infrastructure” is referring to critical network infrastructure, including any network used in the direct operation of any system upon which one of the defined “critical infrastructures” depends. Confusing? It is, and this is perhaps one of the leading reasons that our critical infrastructures remain at risk today: many an ICS security seminar has digressed into an argument over semantics, at the sake of any real discussion on network security practices.

Luckily, the two terms are closely related in that the defined critical infrastructure, meaning those systems listed in the Homeland Security Presidential Directive Seven (HSPD-7), typically utilizes some sort of industrial control systems. In its own words, “HSPD-7 establishes a national policy for Federal departments and agencies to identify and prioritize [the] United States critical infrastructure and key resources and to protect them from terrorist attacks.” HSPD-7 includes public safety, bulk electric energy, nuclear energy, chemical manufacturing, agricultural and pharmaceutical manufacturing and distribution, and even aspects of banking and finance: basically, anything whose disruption could impact a nation. ¹ However, while some, such as global banking and finance, are considered a part of our critical infrastructure, they do not typically operate industrial control networks, and so are not addressed within this book (although many of the security recommendations will still apply, at least at a high level).

The security practices recommended within this book aim for a very high standard, and in fact go above and beyond what is recommended by many government and regulatory groups. So which practices are really necessary, and which are excessive? It depends upon the nature of the industrial system being protected. What are the consequences of a cyber attack? The production of energy is much more important in modern society than the production of a Frisbee. The proper manufacture and distribution of electricity can directly impact our safety by providing heat in winter or by powering our irrigation pumps during a drought. The proper manufacture and distribution of chemicals can mean the difference between the availability of flu vaccines and pharmaceuticals and a direct health risk to the population. Regardless of an ICS’s classification, however, most industrial control systems are by their nature important, and any risk to their reliability holds industrial-scale consequences. However, while not all manufacturing systems hold life-and-death consequences, that doesn’t mean that they aren’t potential targets for a cyber attack. What are the chances that an extremely sophisticated, targeted attack will actually occur? The likelihood of an incident diminishes as the sophistication of the attack—and its consequences—grow, as shown in Figure 2.2. By implementing security practices to address these uncommon and unlikely attacks, there is a greater possibility of avoiding the devastating consequences that correspond to them.

Although the goal of this book is to secure any industrial network, it focuses on Critical Infrastructure and electric energy in particular, and will reference various standards, recommendations, and directives as appropriate. Regardless of the nature of the control system that needs to be secured, it is important to understand these directives, especially NERC CIP, Chemical Facility Anti-Terrorism Standards (CFATS), Federal Information Security Management Act (FISMA), and the control system security recommendations of National Institute of Standards and Technology (NIST). Each has its own strengths and weaknesses, but all provide a good baseline of best practices for industrial network security (each is explored in more detail in Chapter 10, “Standards and Regulations”). Not surprisingly, the industrial networks that control critical infrastructures demand the strongest controls and regulations around security and reliability, and as such there are numerous organizations helping to achieve just that. The Critical Infrastructure Protection Act of 2001 and HSPD-7 define what they are, while others—such as NERC CIP, CFATS, and various publications of NIST—help explain what to do.

The HSPD-7 attempts to distinguish the critical versus noncritical systems. HSPD-7 does not include specific security recommendations, relying instead upon other federal security recommendations such as those by the NIST on the security of both enterprise and industrial networks, as well as the Homeland Security Risk-Based Performance Standards used in securing chemical facilities.

Which regulations apply to your specific industrial network? Possibly several, and possibly none. Although more information is provided in Chapter 10, “Standards and Regulations,” some of the more common regulations are summarized here in order to help you determine which standards you should be striving to meet.

NIST’s 800 series documents provide best practices and information of general interest to information security. All 800 series documents concern information security and should be used as references where applicable. Of particular relevance to industrial network security is SP 800-53 (“Recommended Security Controls for Federal Information Systems”), which defines many aspects of information security procedures and technologies, and SP 800-82 (“Guide to Supervisory Control and Data Acquisition [SCADA] and Industrial Control Systems Security”), which discusses industrial control system security specifically. Although of the entire SP 800-53 is applicable to the protection of critical infrastructures, the technical aspects defined under SP 800-53 as Access Control, Security Assessment and Authorization, Configuration Management, Identification and Authentication, Risk Assessment, System and Communications Protection, and System and Information Integrity are directly applicable to industrial networks. ⁵

SP 800-82 (currently in draft) details control system architectures, protocols, vulnerabilities, and security controls. Specific security recommendations of SP 800-53 and SP 800-82 are addressed in more detail in Chapter 10, “Standards and Regulations.”

The NERC CIP reliability standard identifies security measures for protecting critical infrastructure with the goal of ensuring the reliability of the bulk power system. Compliance is mandatory for any power generation facility, and fines for noncompliance can be steep. The CIP reliability standards consist of nine sections, each with its own requirements and measures. They are Sabotage Reporting, Critical Cyber Asset Identification, Security Management Controls, Personnel & Training, Electronic Security Perimeter(s), Physical Security of Critical Cyber Assets, Systems Security Management, Incident Reporting and Response Planning, and Recovery Plans for Critical Cyber Assets.

The NRC is responsible for ensuring the safe use of radioactive materials for beneficial civilian (nonmilitary) purposes by licensed nuclear facilities. Part of this responsibility is the establishment of cyber security requirements and recommendations, which are defined primarily within two documents: Title 10 Code of Federal Regulations (CFR), section 73.54 (10 CFR 73.54), and Office of Nuclear Regulatory Research’s Regulatory Guide 5.71 (RG 5.71), which explains in detail the specific cyber security requirements of 10 CFR 73.54. RG 5.71 provides recommendations to nuclear agencies or “licensees” in how to secure their facilities against cyber attack. These recommendations indicate that a licensee “shall protect digital computer and communication systems and networks associated with safety, security, emergency preparedness, and any systems that support safety, security and emergency preparedness”⁶ and that they shall protect the systems and networks that impact the integrity or confidentiality of data and/or software; deny access to systems, services, and/or data; and prevent any activity that might adversely impact the operation of systems, networks, and associated equipment. ⁷

To accomplish this, RG 5.71 makes recommendations in how to identify critical digital assets, as well as how to implement a defense in depth strategy to mitigate the adverse effects of a cyber attack against those critical assets, all to “ultimately ensure that the functions of protected assets are not adversely impacted due to cyber attacks.”⁸

Important components of RG 5.71 include⁹

In addition, Appendix B of RG 5.71 is exceptionally useful, as it provides in depth detail on recommended security technical controls, of which the following apply directly to network security: ¹⁰

For the most part, the NRC’s guidelines are consistent with NIST recommendations. The NRC classifies the criticality of an asset or system based on the risks to operations and safety that could result from its compromise. A severity level (SL) is assigned to a cyber asset or mechanism, and the recommendations for cyber security vary based on the assigned SL. There are five SLs, Severity Level 0 to Severity Level 4. One unique recommendation made by the NRC for the protection of nuclear facilities is the use of unidirectional access to the most critical systems, indicated by a severity level of 4—which may be accomplished using a data diode or a physical air gap—represents one of the most stringent cyber security practices recommended by any of the regulatory agencies mentioned within this book. The specific recommendation to validate sessions and monitor access to proprietary protocols is also more stringent than the requirements of other regulations—both of which are important considerations when attempting to secure industrial networks, which often use proprietary protocols and/or specialized standard protocols that may or may not include session authentication or validation. Unfortunately, RG 5.71 is purely a recommendation for complying with the broader requirements provided in 10 CFR 73.54 and is not an enforceable standard at this time.

The FISMA may or may not apply to certain critical infrastructures, depending upon their geographic location and/or their jurisdiction within the United States federal government. However, the standards include valid and useful guidelines for the security of critical environments, referring to and relying upon the NIST “800 series” Special Publication documents (especially SP 800-53 and SP 800-82). The management controls of SP 800-53 are divided into 18 security categories: ¹¹

While all of these controls relate to cyber security, the areas that relate most directly to network security practices are Access Control (AC), Audit and Accountability (AU), Configuration Management (CM), Identification and Authentication (IA), Media Protection (MP), Risk Assessment (RA), System and Communication Protection (SC), and System and Information Integrity (SI). ¹²

CFATS is a set of risk-based performance guidelines published by the Department of Homeland Security. CFATS also consists of 18 Risk-based Performance Standards (RBPSs), although these groups differ substantially from those defined by NIST: ¹³

Of these, RBPS 6 (Theft or Diversion), 7 (Sabotage), 8 (Cyber), 14 (Specific Threats, Vulnerabilities, or Risks), and 15 (Reporting of Significant Security Incidents) concern cyber security, with RBPS 8 focusing solely on cyber security. The CFATS RBPSs are not enforceable requirements at this time and are intended as guidance for chemical facilities. ¹⁴

ISA standard 99 (ISA-99) is an industrial control security standard created by the International Society of Automation (ISA) to protect SCADA and process control systems. ISA-99 offers varying security recommendations based on the physical and logical location of the systems being protected as well as their importance to the reliable operation of the system. In order to accomplish this, ISA-99 first attempts to classify functional areas of an industrial system into specific security levels and then provides recommendations for separating these areas into “zones.” ISA-99 also defines the interconnectedness of zones as well as how to enforce security between zones.

Using the example of an industrial network as illustrated in Figure 2.1, the most public systems such as Internet or Internet-facing systems within the business LAN would continue level 5, while the rest of the business LAN may map to level 4. Supervisory networks (i.e., the SCADA DMZ network) would represent level 3, and so on, with the actual “control system” (the SCADA networks, HMI systems, field devices, instrumentation and sensors) at level 0. This concept is very illustrative of the functional isolation of services and the establishment of security “enclaves” (see “Defense in Depth”).

ISA-99 organizes security recommendations into seven foundational requirements: ¹⁵

Each foundational requirement consists of multiple system requirements (SRs). SRs that are especially useful to the protection of industrial networks (excluding policy and procedural recommendations) include¹⁶

ISO 27002 is a set of security recommendations published by the International Standards Organization (ISO) and the International Electrotechnical Commission (IEC), and may be referred to as ISO/IEC 27002 or ISO/IEC 27002:2005. ISO 27002 defines “Information technology—Security techniques—Code of practice for information security management,” and is not specific to industrial network security. ISO standards are widely used internationally and can be easily mapped to the recommendations of NIST, NRC, NERC, and others, as they consist of functional guidelines for risk assessment; security policy and management; governance; asset management; personnel security; physical and environmental security; communications and operations management; access control; asset acquisition, development, and maintenance; incident management; business continuity management; and compliance. ¹⁷

The first step in securing any system is determining what needs to be protected, and this is reflected heavily in NERC CIP, NRC 10 CFR 73.54, and ISA-99. Identifying the assets that need to be secured, as well as identifying their individual importance to the reliable operation of the overall process control system, is necessary for a few primary reasons: it tells us what should be monitored, and how closely; it tells us how to logically segment the network into high-level security enclaves; and it, therefore, indicates where our point security devices (such as firewalls and intrusion detection and prevention systems) should be placed. For North American electric companies, it also satisfies a direct requirement of NERC CIP, and therefore can help to minimize fines associated with noncompliance.

Identifying critical systems isn’t always easy, however. The first step is to build a complete inventory of all connected devices. Each of these devices should be evaluated independently. If it performs a critical function, it should be classified as critical. If it does not, consider whether it could impact any other critical devices or operations. Could it impact the network itself, preventing another device from interacting with a critical system and therefore causing a failure? Finally, does it protect a critical system in any way?

The NRC provides a logic map illustrating how to determine critical assets, which is adapted to more generic asset identification in Figure 2.3. This process will help to separate devices into two categories:

However, in many larger operations this process may be over simplified. There may be different levels of “criticality.” A general rule to follow once the basic separation of critical versus noncritical has been completed is as follows: are there any critical assets that are not functionally related to other critical assets? If there are, next ask if one function is more or less important than the other. Finally, if there is both a functional separation and a difference in the criticality of the system, consider adding a new logical “tier” to your network. Also remember that a device could potentially be critical and also directly impact one or more other critical assets. Consider ranking the criticality of devices based on their total impact as well. Each layer of a separation can then be used as a point of demarcation, providing additional layers of defense between each group.

The separation of assets into functional groups allows specific services to be tightly locked down and controlled, and is one of the easiest methods of reducing the attack surface that is exposed to attackers. Simply by disallowing all unnecessary ports and services, we also eliminate all of the vulnerabilities—known or unknown—that could potentially allow an attacker to exploit those services.

For example, if five critical services are isolated within a single functional group and separated from the rest of the network using a single firewall, it may be necessary to allow several different traffic profiles through that firewall (see Figure 2.4). If an attack is made using an exploit against web services over port 80, that attack may compromise a variety of services including e-mail services, file transfers, and patch/update services.

However, if each specific service is grouped functionally and separated from all other services, as shown in Figure 2.5—that is, all web servers are grouped together in one group, all e-mail services in another group, etc.—the firewall can be configured to disallow anything other than the desired service, preventing an e-mail server from being exposed to a threat that exploits a weakness in HTTP.

In an industrial control system environment, this method of service segmentation can be heavily utilized because there are many distinct functional groups within an industrial network that should not be communicating at all outside of established parameters. For example, protocols such as Modbus or DNP3 (discussed in depth in Chapter 4, “Industrial Network Protocols”) are specific to SCADA and ICS systems and should never be used within the business LAN and Internet services such as HTTP, SMTP, FTP, and others should never be used within supervisory or control network areas. In Figure 2.6, it can be seen how this layered approach to functional and topological isolation can greatly improve the defensive posture of the network.

Note that within this book, these isolated functional groups or enclaves are often depicted as being separated by a firewall. Although in many cases a separate firewall may be needed for each enclave, the actual method of securing the enclave can vary and could include dedicated firewalls, intrusion detection and prevention devices, application content filters, access control lists, and/or a variety of other controls. In some cases, multiple enclaves can be supported using a single firewall through the careful creation and management of policies that implicitly define which servers can connect over a given protocol or port. This is covered in detail in Chapter 7, “Establishing Secure Enclaves.”

All standards organizations, regulations, and recommendations indicate that a defense-in-depth strategy should be implemented. Although the definitions of “defense in depth” vary somewhat, the philosophy of a layered or tiered defensive strategy is considered a best practice. Figure 2.7 illustrates a common defense-in-depth model, mapping logical defensive levels to common security tools and techniques.

Interestingly, because of the segregated nature of most industrial systems, the term “defense in depth” can and should be applied in more than one context, including

Access control is one of the most difficult yet important aspects of cyber security. By locking down services to specific users or groups of users, it becomes more difficult for an attacker to identify and exploit systems. The further we can lock down access, the more difficult an attack becomes. Although many proven technologies exist to enforce access control—from network access control (NAC), authentication services, and others—the successful implementation of access control is difficult because of the complexity of managing users and their roles and mapping that to the specific devices and services that relate specifically to an employee’s operational responsibilities. As shown in Table 2.1, the strength of access controls increases as a user’s identity is treated with the additional context of that user’s roles and responsibilities within a functional group.

Again, the more layers of complexity applied to the rules of user authentication and access, the more difficult it will be to gain unauthorized access. Some examples of advanced access control include the following:

Although many think of a “network” as a Transmission Control Protocol/Internet Protocol (TCP/IP) network running on Ethernet, that assumption cannot be made when talking about industrial network security. Because many areas of industrial networks are connected using serial or bus networks, which operate via specific protocols, we need to expand our definition to include these areas of the industrial control systems. To make it easier to discern between the two network types, and to align with NERC CIP terminology, the terms “routable” and “non-routable” are used. A routable network typically means Ethernet and TCP/IP, although other routable protocols such as AppleTalk, DECnet, Novell IPX, and other legacy networking protocols certainly apply. “Routable” networks also include routable variants of SCADA and ICS protocols that have been modified to operate over TCP/IP, such as Modbus/TCP or ICCP over TCP/IP.

A “non-routable” network refers to those serial, bus, and point-to-point communication links that utilize Modbus/RTU, point-to-point ICCP, fieldbus, and other networks. They are still networks: they interconnect devices and provide a communication path between digital devices, and in many cases are designed for remote command and control.

Routable and non-routable networks generally interconnect at the demarcation between the control systems and the SCADA or supervisory networks, although in some cases (depending upon the specific industrial network protocols used) the two networks overlap. This is illustrated in Figure 2.8 and is discussed in more depth in Chapter 4, “Industrial Network Protocols,” and Chapter 5, “How Industrial Networks Operate.”

An asset is a unique device that is used within an industrial control system. Assets are often computers, but also include network switches and routers, firewalls, printers, alarm systems, Human–Machine Interfaces (HMIs), Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), and the various relays, actuators, sensors, and other devices that make up a typical control loop. As of version 3, NERC CIP defines a “cyber asset” as any device connected via a routable protocol, which limits the role of a cyber asset to those devices communicating on a routable LAN. ¹⁹ A “critical cyber asset,” again as defined by NERC, is a cyber asset whose operation can impact the bulk energy system. ²⁰

In this book the broader definition of “asset” is used, in order to extend (as much as possible) cyber security to the non-routable devices such as PLCs and RTUs, which have been proven to be both targetable and vulnerable to cyber attack during the 2010 outbreak of Stuxnet (see “examples of Industrial Network Incidents” in Chapter 3, “Introduction to Industrial Network Security.”

An “enclave” is a convenient term for defining a closed group of assets, similar to the functional “zone and conduit” model supported by ISA-99, ²¹ that is, the devices, applications, and users that should be interacting with each other legitimately in order to function, as illustrated in Figure 2.9. One example is a control loop: an HMI interfaces with a PLC which interacts with sensors, motors, valves, etc. to perform a specific control function. The “enclave” here includes all devices within the control loop including the PLC and HMI, and ideally the authorized users allowed to use the HMI. Nothing outside of this group should be interacting with anything inside of this group.

Enclaves are an important aspect of security as they define acceptable versus unacceptable behaviors. However, because a single asset can exist in multiple logical enclaves, the mapping and management of enclaves can become confusing. The concept of enclaves is expanded later in Chapter 7“Establishing Secure Enclaves”; for now it’s enough to understand the term and how it will be used.

The outermost boundary of any closed group of assets (i.e., an “enclave”) is called the perimeter. Again, this supports NERC CIP terminology, where “Electronic Security Perimeter” or “ESP” refers to the boundary between secure and nonsecure enclaves. ²² The perimeter itself is nothing more than the logical “dotted line” around an enclave that separates the closed group of assets within its boundaries from the rest of the network. “Perimeter defenses” are the security defenses established to police the entry into the enclave, and typically consist of a firewall and/or an Intrusion Prevention System (IPS).