SP 800-82: Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems Security

From Cybersecurity Wiki
Jump to navigation Jump to search

Full Title of Reference

SP 800-82: Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems Security

Full Citation

Keith Stouffer, Joe Falco, Karen Kent, Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems Security: Recommendations of the National Institute of Standards and Technology, National Institute of Standards and Technology (2006). Web

BibTeX

Categorization

Key Words

Antivirus, Best Practices, DDoS Attack, Intelligence Infrastructure/Information Infrastructure, Malware, Patching, Risk Modeling, SCADA Systems, Worm

Synopsis

Executive Summary

This document provides guidance for establishing secure industrial control systems. These industrial control systems (ICS), which include supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and other smaller control system configurations such as skid-mounted Programmable Logic Controllers (PLC) are often found in the industrial control sectors. ICSs are typically used in industries such as electric, water, oil and gas, transportation, chemical, pharmaceutical, pulp and paper, food and beverage, and discrete manufacturing (e.g., automotive, aerospace, and durable goods.) SCADA systems are generally used to control dispersed assets using centralized data acquisition and supervisory control. DCSs are generally used to control production systems within a local area such as a factory using supervisory and regulatory control. PLCs are generally used for discrete control for specific applications and generally provide regulatory control. These control systems are critical to the operation of the U.S. critical infrastructures that are often highly interconnected and mutually dependent systems. It is important to note that approximately 90 percent of the nation's critical infrastructures are privately owned and operated. Federal agencies also operate many of the industrial processes mentioned above; other examples include air traffic control and materials handling (e.g., Postal Service mail handling.) The document provides an overview of these industrial control systems and typical system topologies, identifies typical threats and vulnerabilities to these systems, and provides recommended security countermeasures to mitigate the associated risks.

Initially, ICSs had little resemblance to traditional information technology (IT) systems in that ICSs were isolated systems running proprietary control protocols using specialized hardware and software. Widely available, low-cost Internet Protocol (IP) devices are now replacing proprietary solutions, which increases the possibility of cyber security vulnerabilities and incidents. As ICSs are adopting IT solutions to promote corporate connectivity and remote access capabilities, and are being designed and implemented using industry standard computers, operating systems (OS) and network protocols, they are starting to resemble IT systems. This integration supports new IT capabilities, but it provides significantly less isolation for ICSs from the outside world than predecessor systems, creating a greater need to secure these systems. While security solutions have been designed to deal with these security issues in typical IT systems, special precautions must be taken when introducing these same solutions to ICS environments. In some cases, new security solutions are needed that are tailored to the ICS environment.

Although some characteristics are similar, ICSs also have characteristics that differ from traditional information processing systems. Many of these differences stem from the fact that logic executing in ICS has a direct affect on the physical world. Some of these characteristics include significant risk to the health and safety of human lives and serious damage to the environment, as well as serious financial issues such as production losses, negative impact to a nation’s economy, and compromise of proprietary information. ICSs have unique performance and reliability requirements and often use operating systems and applications that may be considered unconventional to typical IT personnel. Furthermore, the goals of safety and efficiency sometimes conflict with security in the design and operation of control systems. Originally, ICS implementations were susceptible primarily to local threats because many of their components were in physically secured areas and the components were not connected to IT networks or systems. However, the trend toward integrating ICS systems with IT solutions provides significantly less isolation for ICSs from the outside world than predecessor systems, creating a greater need to secure these systems from remote, external threats. Also, the increasing use of wireless networking also places ICS implementations at greater risk from adversaries who are in relatively close physical proximity but do not have direct physical access to the equipment. Threats to control systems can come from numerous sources, including hostile governments, terrorist groups, disgruntled employees, malicious intruders, complexities, accidents, natural disasters as well as malicious or accidental actions by insiders. Protecting confidentiality is also an important concern.

Possible incidents an ICS may face include the following:

  • Blocked or delayed flow of information through ICS networks, which could disrupt ICS operation
  • Unauthorized changes to instructions, commands, or alarm thresholds, which could potentially damage, disable, or shut down equipment
  • Inaccurate information sent to system operators, either to disguise unauthorized changes, or to cause the operators to initiate inappropriate actions
  • ICS software or configuration settings modified, or ICS software infected with malware, which could have various negative effects
  • Interference with the operation of safety systems, which could endanger human life.

Major security objectives for an ICS implementation often include the following:

  • Restricting logical access to the ICS network and network activity. This includes using a demilitarized zone (DMZ) network architecture with firewalls to prevent network traffic from passing directly between the corporate and ICS networks, and having separate authentication mechanisms and credentials for users of the corporate and ICS networks. The ICS should also use a network topology that has multiple layers, with the most critical communications occurring in the most secure and reliable layer.
  • Restricting physical access to the ICS network and devices. Unauthorized physical access to components could cause serious disruption of the ICS’s functionality. A combination of physical access controls should be used, such as locks, card readers, and/or guards.
  • Protecting individual ICS components from exploitation. This includes deploying security patches in as expeditious a manner as possible, after testing them under field conditions; disabling all unused ports and services; restricting ICS user privileges to only those that are required for each person’s role; tracking and monitoring audit trails; and using security controls such as antivirus software and file integrity checking software where technically feasible to prevent, deter, detect, and mitigate malware.
  • Maintaining functionality during adverse conditions. This involves designing the ICS so that each critical component has a redundant counterpart. Additionally, if a component fails, it should fail in a manner that does not generate unnecessary traffic on the ICS, or does not cause another problem elsewhere, such as a cascading event.

To properly address security in an ICS, it is essential for a cross-functional cyber security team to share their varied domain knowledge and experience to evaluate and mitigate risk in the ICS. The cyber security team should consist of a member of the organization’s IT staff, a control engineer, network and system security expertise, a member of the management staff, and a member of the physical security department at a minimum. For continuity and completeness, the cyber security team should consult with the control system vendor as well. The cyber security team should report directly to site management or the company’s CIO/CSO, who in turn, accepts complete responsibility and accountability for the cyber security of the corporate and ICS networks. An effective cyber security program for an ICS should apply a strategy known as “defense-in-depth”. This strategy means that security mechanisms are layered such that the impact of a failure in any one mechanism is minimized. In a typical ICS this means a defense-in-depth strategy that includes:

  • Developing security policies, procedures, and educational material that apply specifically to the ICS.
  • Considering ICS security policies and procedures based on the Homeland Security Advisory System Threat Level, deploying increasingly heightened security postures as the Threat Level increases.
  • Addressing security throughout the lifecycle of the ICS from architecture to procurement to installation to maintenance to decommissioning.
  • Implementing a network topology for the ICS that has multiple layers, with the most critical communications occurring in the most secure and reliable layer.
  • Providing logical separation between the corporate and ICS networks (e.g., stateful inspection firewall(s) between the two networks).
  • Employing a DMZ network architecture (i.e., prevent direct traffic between the corporate and ICS networks).
  • Ensuring that critical components are redundant and are on redundant networks.
  • Designing critical systems for graceful degradation (fault tolerant) to prevent catastrophic cascading events. In addition, design systems to fail securely.
  • Disabling unused ports and services on ICS devices after testing to assure this will not impact ICS operation.
  • Restricting physical access to the ICS network and devices.
  • Restricting ICS user privileges to only those that are required to perform each person’s job (i.e., establishing role-based access control and configuring each role based on the principle of least privilege).
  • Considering the use of separate authentication mechanisms and credentials for users of the ICS network and the corporate network (i.e., ICS network accounts do not use corporate network user accounts).
  • Using modern technology, such as smart cards for Personal Identity Verification (PIV).
  • Implementing security controls such as antivirus software and file integrity checking software, where technically feasible, to prevent, deter, detect, and mitigate the introduction, exposure, and propagation of malicious software to, within, and from the ICS.
  • Applying security techniques such as encryption to ICS data storage and communications.
  • Expeditiously deploying security patches after testing all patches under field conditions on a test system if possible, before installation on the ICS.
  • Tracking and monitoring audit trails on critical areas of the ICS.

NIST has initiated a high-priority project1 in cooperation with the public and private sector ICS community to develop specific guidance on the application of the security controls in NIST SP 800-53 Recommended Security Controls for Federal Information Systems to ICSs. Since the project is still ongoing, the resulting guidance could not be included in the current release of this document or NIST SP 800-53, but will appear in future releases. Section 6 of this document summarizes the management, operational, and technical controls identified in NIST SP 800-53 and provides initial guidance on how these security controls apply to ICSs. Initial ICS specific recommendations and guidance, if available, is provided in an outlined box for each section. In addition, Appendix C provides an overview of the many activities currently ongoing among Federal organizations, standards organizations, industry groups, and automation system vendors to make available “best practices” in the area of ICS security.

Additional Notes and Highlights

Expertise required: Technology - Moderate

Appendix A provides a list of acronyms and abbreviations used in this document.

Appendix B provides a glossary of terms used in this document.

Retrieved from "http://cyber.harvard.edu/cybersecurity/?title=SP_800-82:_Guide_to_Supervisory_Control_and_Data_Acquisition_(SCADA)_and_Industrial_Control_Systems_Security&oldid=5109"