Recommended Practices

Control Systems Cyber Security Defense in Depth Strategies

Research has shown that information infrastructures across many public and private domains share several common attributes in IT deployment and data communications for control systems. A majority of the systems use robust architectures to enhance business and reduce costs by increasing the integration of external, business, and control system networks. However, multi-network integration strategies often lead to vulnerabilities that greatly reduce the security of an organization, and can expose mission-critical control systems to cyber threats. This document provides guidance and direction for developing 'defense-in-depth' strategies for organizations that use control system networks while maintaining a multi-tier information architecture that requires:

• Maintenance of various field devices, telemetry collection, and/or industrial-level process systems
• Access to facilities via remote data link or modem
• Public facing services for customer or corporate operations

Creating Cyber Forensics Plans for Control Systems

Cyber forensics has been in the popular mainstream for some time, and has matured into an information-technology capability that is common among modern information security programs. Although scalable to many information technology domains, especially modern corporate architectures, developing a cyber forensics program can be a challenging task when being applied to nontraditional environments, such as control systems. Modern IT networks, through data exchange mechanisms, data storage devices, and general computing components provide a good foundation for creating a landscape used to support effective cyber forensics. However, modern control systems environments are not easily configurable to accommodate forensics programs. Nonstandard protocols, legacy architectures that can be several decades old, and irregular or extinct proprietary technologies can all combine to make the creation and operation of a cyber forensics program anything but a smooth and easy process.

This document takes the traditional concepts of cyber forensics and provides direction regarding augmentation for control systems operational environments. The goal is to provide guidance to the reader with specifics relating to the complexity of cyber forensics for control systems, guidance to allow organizations to create a self-sustaining cyber forensics program for their control systems environments, and guidance to support the maintenance and evolution of such programs.

This document is organized into three major sections:

• Section 1, Traditional Forensics and Challenges to Control Systems
• Section 2, Creating a Cyber Forensics Program for Control Systems Environments
• Section 3, Activating and Sustaining a Cyber Forensics Program.

The document addresses the issues encountered in developing and maintaining a cyber forensics plan for control systems environments. This recommended practice supports forensic practitioners in creating a control systems forensics plan, and assumes evidentiary data collection and preservation using forensic best practices. The goal of this recommended practice is not to reinvent proven methods, but to leverage them in the best possible way. As such, the material in this recommended practice provides users with the appropriate foundation to allow these best practices to be effective in a control systems domain.

Good Practice Guide on Firewall Deployment

In recent years, Supervisory Controls and Data Acquisition (SCADA), process control and industrial manufacturing systems have increasingly relied on commercial information technologies such as Ethernet, TCP/IP and Windows for both critical and non-critical communications. The use of these common protocols and operating systems has made the interfacing of industrial control equipment much easier, but there is now significantly less isolation from the outside world. Network security problems from the enterprise network (EN) and the world at large can be passed onto the SCADA and process control network (PCN), putting industrial production and human safety at risk.

Hardening Guidelines for OPC Hosts

This report is the third of three white papers outlining the findings from a study on OPC security conducted by Byres Research, Digital Bond and the British Columbia Institute of Technology. The objective of this study was to create a series of simple, authoritative white papers that summarized current good practices for securing OPC client and server applications running on Windows-based hosts. The full study is divided into three Good Practice Guides for Securing OPC as follows:

• OPC Security White Paper #1 – Understanding OPC and How it is Used: An introduction to what OPC is, what are its basic components and how is it actually deployed in the real world.
• OPC Security White Paper #2 – OPC Exposed: What are the risks and vulnerabilities incurred in deploying OPC in a control environment?
• OPC Security White Paper #3 – Hardening Guidelines for OPC Hosts: How can a server or workstation running OPC be secured in a simple and effective manner?

All three white papers are intended to be read and understood by IT administrators and control systems technicians who have no formal background in either Windows programming or security analysis.

Mitigations for Security Vulnerabilities Found in Control System Networks

Industry is aware of the need for Control System (CS) security, but in on-site assessments, Idaho National Laboratory (INL) has observed that security procedures and devices are not consistently and effectively implemented. The Department of Homeland Security (DHS), National Cyber Security Division (NCSD), established the Control Systems Security Center (CSSC) at INL to help industry and government improve the security of the CSs used in the nation’s critical infrastructures. One of the main CSSC objectives is to identify control system vulnerabilities and develop effective mitigations for them. This paper discusses common problems and vulnerabilities seen in on-site CS assessments and suggests mitigation strategies to provide asset owners with the information they need to better protect their systems from common security flaws.

Securing Control System Modems

This recommended practice provides guidance on the analysis of methodologies for evaluating security risks associated with modems and their use in an organization. This document also offers useful methods for creating a defense-in-depth architecture that protects the system components that use modems for connectivity. It is assumed that the reader of this document has a basic understanding of vulnerabilities associated with modem and modem communications, as this information is available from other sources.

Section 2 and 3 of the document discuss methods for assessing modem security, providing recommended resources for information and assessment tools and methods for identifying and analyzing modem connections. Section 4 provides options for implementing modem security according to the types of connections and/or devices being used. It also discusses methods such as authentication, logging, caller-ID filtering, and control system device security. Appendix A includes a list of resources used to create this document.

The methods presented in this document should be evaluated by each user for effectiveness within their operating environment. This analysis should include the capabilities and limitations of any hardware and/or software solution selected to implement these methods. This document does not cover the physical security aspects of modem security. Physical security should be driven by the control system and its components. If the physical security of the control system and its components has been addressed appropriately, then the modems will be a part of this physical security perimeter.

Securing WLANs Using 802.11i (draft)

This paper addresses design principles and best practices regarding the secure implementation and operation of Wireless LAN (WLAN) communication networks based on the IEEE 802.11 protocol. First, a general overview of WLAN technology and the 802.11 standard is provided. The subsequent sections describe the various initial and interim IEEE security standards leading to the 802.11i standard. An explanation of the 802.11i standard for securing WLAN networks is then presented, followed by principles for designing secure WLAN networks, and a list of specific security best practices that can be used as a guideline for organizations considering the deployment of a WLAN. Finally, a section on technical issues and special considerations for installations of WLAN networks in industrial environments is presented. A concluding section summarizes key points and is followed by a list of online technical references related to the topics presented.

Securing ZigBee Wireless Networks in Process Control System Environments (draft)

This paper addresses design principles and best practices regarding the secure implementation and operation of ZigBee wireless networks. ZigBee is a protocol specification and industry standard for a type of wireless communications technology generically known as Low-Rate Wireless Personal Area Networks (LR-WPAN). LR-WPAN technology is characterized by low-cost, low-power wireless devices that self-organize into a short-range wireless communication network to support relatively low throughput applications such as distributed sensing and monitoring. Networks can range from simple single-hop star topologies to more complex multi-hop mesh networks. The emergence of LR-WPAN technology and ZigBee standardization is appealing because of its potential for relatively fast, low cost, and simplified implementations compared to more traditional wired network installations used for industrial and process automation applications. The ZigBee specification provides a standardized set of protocols, services, and interfaces for vendors to create LR-WPAN hardware platforms and software applications that will enable customers to deploy complete, interoperable low-power mesh networking systems for monitoring and control.

The focus of this paper is on the secure deployment of ZigBee networks in industrial environments, such as manufacturing and process automation facilities. ZigBee is the name given to a specific protocol standard being developed by the ZigBee Alliance, the industry group overseeing its development and the process for certifying and branding compliant products. The term LR-WPAN, on the other hand, is a generic reference to the type of technology that is being standardized by groups such as the ZigBee Alliance. LR-WPAN is the term used by the IEEE, which has standardized the lowest layers of the technology but stopped short of developing the higher layers of the protocol stack needed to achieve fully functional and interoperable networks and applications. It should be noted that other industry groups are also engaged in the development of LR-WPAN standards, such as the ISASP100 and Wireless HART efforts.

This document will begin with a conceptual overview of LR-WPAN technology and the role that the ZigBee protocol plays in the development and standardization process. A section on the IEEE 802.15.4 specification upon which ZigBee is based is then presented, followed by a description of the ZigBee standard and its various components. A following section will describe ZigBee the security architecture, services, and features. Next, a section on secure LR-WPAN network design principles is presented, followed by a list of specific recommended security best practices that can be used as a guideline for organizations considering the deployment of ZigBee networks. Finally, a section on technical issues and special considerations for installations of LR-WPAN networks in industrial environments is presented. A concluding section summarizes key points and is followed by a list of technical references related to the topics presented in this document.

Using Operational Security (OPSEC) to Support a Cyber Security Culture in Control Systems Environments (draft)

Information infrastructures across many public and private domains share several common attributes regarding IT deployments and data communications. This is particularly true in the control systems domain. Many organizations use robust architectures to enhance business and reduce costs by increasing the integration of external, business, and control system networks. Data security is often deployed using specialized technologies and is supported by the creation of a cyber security ??culture?? that is based on policy, guidance, and operational requirements. By using methods of operational security (OPSEC), the security culture empowers management and users to maintain and enhance cyber security by instilling procedures and guidelines into the day-to-day operations.

However, the cyber security strategies required to protect the business domains and the associated security culture that is created to support the security programs may not be easily translated to the control system space. Factors such as operational isolation, legacy networking, and inflexible roles in job activities may not be conducive to creating environments that are rich with cyber security capability, functionality, or interest. As such, guidance is required to help organizations leverage operational security and establish effective, self-sustaining security cultures that will help protect information assets in the control systems architectures.

This document reviews several key operational cyber security elements that are important for control systems and industrial networks and how those elements can drive the creation of a cyber security-sensitive culture. In doing so, it provides guidance and direction for developing operational security strategies including:

• Creating cyber OPSEC plans for control systems
• Embedding cyber security into the operations life cycle
• Creating technical and non-technical security mitigation strategies.

An Undirected Attack Against Critical Infrastructure A Case Study for Improving Your Control System Security

Computer virus incidents cost companies billions of dollars every year. While antivirus technologies for detection and containment are attempting to keep pace, the threat is constantly evolving. The attack vector is no longer simply an infected executable on a floppy disk. Email, websites, macro-enabled documents, instant messages, peer-to-peer networks, cell phones, and other interconnected systems are all potential entry points onto our networks for a wide range of malware [1]. Our ability to successfully defend these entry points, as well as recover in the event of a given contamination, needs improvement. Such is the situation for the water treatment facility featured in this case study, where systems on its networks were repeatedly compromised by malware over the span of a couple days. Symptoms of this infection are first noted when network performance degrades significantly on several systems, but the actual compromise is not recognized until the Internet Service Provider (ISP) of the facility relays a message regarding a suspected worm outbreak emanating from the facility’s network. The offending systems are eventually identified, taken off-line, scanned, and disinfected. Unfortunately, the source carrier (a mobile laptop) of the worm is not identified and cleaned during the initial recovery process. Even though steps were being taken to address the vulnerability issues in the environment, the day after restoring operations, systems on the network are once again infected, further compounding the overall incident. Unable to effectively defend against and respond to the outbreak results in a loss of data, disruption in operation, and ultimately substantial financial impacts.

Attack Methodology Analysis: SQL Injection Attacks

Database applications have become a core component in control systems and their associated record keeping utilities. Traditional security models attempt to secure systems by isolating core software components and concentrating security efforts against threats specific to those computers or software components. Database security within control systems follows these models by using generally independent systems that rely on one another for proper functionality. The high level of reliance between the two systems creates an expanded threat surface.

To understand the scope of a threat surface, all segments of the control system, with an emphasis on entry points, must be examined. The communication link between data and decision layers is the primary attack surface for SQL injection. This paper facilitates understanding what SQL injection is and why it is a significant threat to control system environments.

Backdoors and Holes in Network Perimeters A Case Study for Improving Your Control System Security

The Supervisory Control and Data Acquisition (SCADA) system of a natural gas utility was compromised resulting in a reduction of operation. The breach was discovered when operator interfaces became unresponsive and the system was no longer acquiring data. As a result, the system was disconnected from the network and a combination of manual operation overrides and limited fail-over to a backup server went into effect until the environment could be restored. Technicians troubleshooting the incident identified the deletion of several core application files on the primary control server as the source of the problem.

Common Control System Vulnerability

The Control Systems Security Program and other programs within the Idaho National Laboratory have discovered a vulnerability common to control systems in all sectors that allows an attacker to penetrate most control systems, spoof the operator, and gain full control of targeted system elements. This vulnerability has been identified on several systems that have been evaluated at INL, and in each case a 100% success rate of completing the attack paths that lead to full system compromise was observed. Since these systems are employed in multiple critical infrastructure sectors, this vulnerability is deemed common to control systems in all sectors.

Modern control systems architectures can be considered analogous to today’s information networks, and as such are usually approached by attackers using a common attack methodology to penetrate deeper and deeper into the network. This approach often is composed of several phases, including gaining access to the control network, reconnaissance, profiling of vulnerabilities, launching attacks, escalating privilege, maintaining access, and obscuring or removing information that indicates that an intruder was on the system. With irrefutable proof that an external attack can lead to a compromise of a computing resource on the organization’s business local area network (LAN), access to the control network is usually considered the first phase in the attack plan. Once the attacker gains access to the control network through direct connections and/or the business LAN, the second phase of reconnaissance begins with traffic analysis within the control domain. Thus, the communications between the workstations and the field device controllers can be monitored and evaluated, allowing an attacker to capture, analyze, and evaluate the commands sent among the control equipment. Through manipulation of the communication protocols of control systems (a process generally referred to as “reverse engineering”), an attacker can then map out the control system processes and functions. With the detailed knowledge of how the control data functions, as well as what computers and devices communicate using this data, the attacker can use a well known Man-in-the-Middle attack to perform malicious operations virtually undetected.

The control systems assessment teams have used this method to gather enough information about the system to craft an attack that intercepts and changes the information flow between the end devices (controllers) and the human machine interface (HMI and/or workstation). Using this attack, the cyber assessment team has been able to demonstrate complete manipulation of devices in control systems while simultaneously modifying the data flowing back to the operator’s console to give false information of the state of the system (known as “spoofing”). This is a very effective technique for a control system attack because it allows the attacker to manipulate the system and the operator’s situational awareness of the perceived system status. The three main elements of this attack technique are: 1) network reconnaissance and data gathering, 2) reverse engineering, and 3) the Man-in-the-Middle attack.

DHS Bulletin: Securing Control Systems

Control Systems (CS) manage the nation’s Critical Infrastructure; therefore, it is paramount that secure systems be established. However, integrating security into control system environments is a much more inflexible process than in general IT networks. In lieu of this and the incredibly varied architecture of CS network architecture, control systems administrators and operators must carefully review the recommendations for securing control system networks before applying the changes. Testing and deployment of security configurations or updates should be performed on development, test, or backup systems and monitored carefully for impact before being put into practice on a production control system.

OPC Exposed

This report is the second of three white papers outlining the findings from a study on OPC security conducted by Byres Research, Digital Bond and the British Columbia Institute of Technology. The objective of this study was to create a series of simple, authoritative white papers that summarized current good practices for securing OPC client and server applications running on Windows-based hosts. The full study is divided into three Good Practice Guides for Securing OPC as follows:

• OPC Security White Paper #1 – Understanding OPC and How it is Used: An introduction to what OPC is, what are its basic components and how is it actually deployed in the real world.
• OPC Security White Paper #2 – OPC Exposed: What are the risks and vulnerabilities incurred in deploying OPC in a control environment?
• OPC Security White Paper #3 – Hardening Guidelines for OPC Hosts: How can a server or workstation running OPC be secured in a simple and effective manner?

All three white papers are intended to be read and understood by IT administrators and control systems technicians who have no formal background in either Windows programming or security analysis.

Recommended Practice Case Study: Cross-Site Scripting

This paper is intended to support and encourage application of best practices for control systems security. It describes the details of an information security attack, known as cross-site scripting, which could be used against control systems, and explains practices to mitigate this threat.

Cross-site scripting presents one entry point for attackers to access and manipulate control systems networks. It takes advantage of Web servers that return dynamically generated Web pages or allow users to post viewable content in order to execute arbitrary HTML and active content such as JavaScript, ActiveX, and VBScript on a remote machine browsing the site within the context of a client-server session. This potentially allows the attacker to redirect the Web page to a malicious location, hijack the client-server session, engage in network reconnaissance, and plant backdoor programs.

Security Implications of OPC, OLE, DCOM, and RPC in Control Systems

OPC is a collection of software programming standards and interfaces used in the process control industry. It is intended to provide open connectivity and vendor equipment interoperability. The use of OPC technology simplifies the development of control systems that integrate components from multiple vendors and support multiple control protocols. OPC-compliant products are available from most control system vendors, and are widely used in the process control industry.

OPC was originally known as OLE for Process Control; the first standards for OPC were based on underlying services in the Microsoft Windows computing environment. These underlying services (OLE [Object Linking and Embedding], DCOM [Distributed Component Object Model], and RPC [Remote Procedure Call]) have been the source of many severe security vulnerabilities. It is not feasible to automatically apply vendor patches and service packs to mitigate these vulnerabilities in a control systems environment. Control systems using the original OPC data access technology can thus inherit the vulnerabilities associated with these services.

Current OPC standardization efforts are moving away from the original focus on Microsoft protocols, with a distinct trend toward web-based protocols that are independent of any particular operating system. However, the installed base of OPC equipment consists mainly of legacy implementations of the OLE for Process Control protocols.

Understanding OPC and How it is Deployed

This report is the first of three white papers outlining the findings from a study on OPC security conducted by Byres Research, Digital Bond and the British Columbia Institute of Technology. The objective of this study was to create a series of simple, authoritative white papers that summarized current good practices for securing OPC client and server applications running on Windows-based hosts. The full study is divided into three Good Practice Guides for Securing OPC as follows:

• OPC Security White Paper #1 – Understanding OPC and How it is Used: An introduction to what OPC is, what are its basic components and how is it actually deployed in the real world.
• OPC Security White Paper #2 – OPC Exposed: What are the risks and vulnerabilities incurred in deploying OPC in a control environment?
• OPC Security White Paper #3 – Hardening Guidelines for OPC Hosts: How can a server or workstation running OPC be secured in a simple and effective manner?

All three white papers are intended to be read and understood by IT administrators and control systems technicians who have no formal background in either Windows programming or security analysis.