Guide to industrial control systems (ics) security
Preview:
Citation preview
- 1. Special Publication 800-82 Guide to Industrial Control
Systems (ICS) Security Supervisory Control and Data Acquisition
(SCADA) systems, Distributed Control Systems (DCS), and other
control system configurations such as Programmable Logic
Controllers (PLC) Recommendations of the National Institute of
Standards and Technology KeithStouffer JoeFalco KarenScarfone
- 2. NIST Special Publication 800-82 Guide to Industrial Control
Systems (ICS) Security Supervisory Control and Data Acquisition
(SCADA) systems, Distributed Control Systems (DCS), and other
control system configurations such as Programmable Logic
Controllers (PLC) Recommendations of the National Institute of
Standards and Technology Computer Security Division Information
Technology Laboratory National Institute of Standards and
Technology Gaithersburg, MD 20899-8930 Intelligent Systems Division
Engineering Laboratory National Institute of Standards and
Technology Gaithersburg, MD 20899-8930 June 2011 U.S. Department of
Commerce Gary Locke, Secretary National Institute of Standards and
Technology Patrick Gallagher, Director C O M P U T E R S E C U R I
T Y
- 3. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Reports
on Computer Systems Technology The Information Technology
Laboratory (ITL) at the National Institute of Standards and
Technology (NIST) promotes the U.S. economy and public welfare by
providing technical leadership for the nations measurement and
standards infrastructure. ITL develops tests, test methods,
reference data, proof of concept implementations, and technical
analysis to advance the development and productive use of
information technology. ITLs responsibilities include the
development of technical, physical, administrative, and management
standards and guidelines for the cost-effective security and
privacy of sensitive unclassified information in Federal computer
systems. This Special Publication 800-series reports on ITLs
research, guidance, and outreach efforts in computer security and
its collaborative activities with industry, government, and
academic organizations. Certain commercial entities, equipment, or
materials may be identified in this document in order to describe
an experimental procedure or concept adequately. Such
identification is not intended to imply recommendation or
endorsement by the National Institute of Standards and Technology,
nor is it intended to imply that the entities, materials, or
equipment are necessarily the best available for the purpose.
National Institute of Standards and Technology Special Publication
800-82 Natl. Inst. Stand. Technol. Spec. Publ. 800-82, 155 pages
(June 2011) iii
- 4. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY iv
Acknowledgments The authors, Keith Stouffer, Joe Falco, and Karen
Scarfone of the National Institute of Standards and Technology
(NIST), wish to thank their colleagues who reviewed drafts of this
document and contributed to its technical content. The authors
would particularly like to acknowledge Tim Grance, Ron Ross, Stu
Katzke, and Freemon Johnson of NIST for their keen and insightful
assistance throughout the development of the document. The authors
also gratefully acknowledge and appreciate the many contributions
from the public and private sectors whose thoughtful and
constructive comments improved the quality and usefulness of this
publication. The authors would particularly like to thank the
members of ISA99. The authors would also like to thank the UK
National Centre for the Protection of National Infrastructure
(CPNI)) for allowing portions of the Good Practice Guide on
Firewall Deployment for SCADA and Process Control Network to be
used in this document as well as ISA for allowing portions of the
ANSI/ISA99 Standards to be used in this document.
- 5. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Table of
Contents Executive
Summary..............................................................................................................ES-1
1. Introduction
......................................................................................................................1-1
1.1
Authority...................................................................................................................1-1
1.2 Purpose and Scope
.................................................................................................1-1
1.3
Audience..................................................................................................................1-1
1.4 Document
Structure.................................................................................................1-2
2. Overview of Industrial Control
Systems........................................................................2-1
2.1 Overview of SCADA, DCS, and PLCs
.....................................................................2-1
2.2 ICS Operation
..........................................................................................................2-2
2.3 Key ICS Components
..............................................................................................2-3
2.3.1 Control
Components.....................................................................................2-4
2.3.2 Network
Components...................................................................................2-5
2.4 SCADA
Systems......................................................................................................2-6
2.5 Distributed Control Systems
..................................................................................2-10
2.6 Programmable Logic Controllers
...........................................................................2-12
2.7 Industrial Sectors and Their Interdependencies
....................................................2-13 3. ICS
Characteristics, Threats and Vulnerabilities
..........................................................3-1 3.1
Comparing ICS and IT Systems
..............................................................................3-1
3.2
Threats.....................................................................................................................3-5
3.3 Potential ICS
Vulnerabilities.....................................................................................3-6
3.3.1 Policy and Procedure
Vulnerabilities............................................................3-7
3.3.2 Platform
Vulnerabilities.................................................................................3-8
3.3.3 Network
Vulnerabilities...............................................................................3-12
3.4 Risk
Factors...........................................................................................................3-14
3.4.1 Standardized Protocols and
Technologies.................................................3-15
3.4.2 Increased Connectivity
...............................................................................3-15
3.4.3 Insecure and Rogue Connections
..............................................................3-16
3.4.4 Public
Information.......................................................................................3-16
3.5 Possible Incident
Scenarios...................................................................................3-17
3.6 Sources of Incidents
..............................................................................................3-18
3.7 Documented Incidents
...........................................................................................3-19
4. ICS Security Program Development and
Deployment..................................................4-1 4.1
Business Case for
Security......................................................................................4-1
4.1.1
Benefits.........................................................................................................4-1
4.1.2 Potential
Consequences...............................................................................4-2
4.1.3 Key Components of the Business
Case.......................................................4-3
4.1.4 Resources for Building Business Case
........................................................4-4 4.1.5
Presenting the Business Case to
Leadership...............................................4-4 4.2
Developing a Comprehensive Security Program
.....................................................4-4 4.2.1
Senior Management
Buy-in..........................................................................4-5
4.2.2 Build and Train a Cross-Functional Team
....................................................4-5 4.2.3
Define Charter and
Scope............................................................................4-6
4.2.4 Define ICS Specific Security Policies and
Procedures.................................4-6 4.2.5 Define and
Inventory ICS Systems and Networks
Assets............................4-6 v
- 6. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 4.2.6
Perform Risk and Vulnerability
Assessment.................................................4-7
4.2.7 Define the Mitigation Controls
......................................................................4-8
4.2.8 Provide Training and Raise Security Awareness
.........................................4-9 5. Network
Architecture.......................................................................................................5-1
5.1
Firewalls...................................................................................................................5-1
5.2 Logically Separated Control
Network.......................................................................5-3
5.3 Network Segregation
...............................................................................................5-3
5.3.1 Dual-Homed Computer/Dual Network Interface Cards
(NIC).......................5-3 5.3.2 Firewall between Corporate
Network and Control Network..........................5-4 5.3.3
Firewall and Router between Corporate Network and Control
Network.......5-6 5.3.4 Firewall with DMZ between Corporate Network
and Control Network..........5-7 5.3.5 Paired Firewalls between
Corporate Network and Control Network ............5-9 5.3.6 Network
Segregation
Summary..................................................................5-10
5.4 Recommended Defense-in-Depth Architecture
.....................................................5-10 5.5
General Firewall Policies for ICS
...........................................................................5-11
5.6 Recommended Firewall Rules for Specific
Services..............................................5-13 5.6.1
Domain Name System
(DNS).....................................................................5-14
5.6.2 Hypertext Transfer Protocol
(HTTP)...........................................................5-14
5.6.3 FTP and Trivial File Transfer Protocol (TFTP)
...........................................5-14 5.6.4
Telnet..........................................................................................................5-14
5.6.5 Simple Mail Transfer Protocol (SMTP)
.......................................................5-14 5.6.6
Simple Network Management Protocol (SNMP)
........................................5-15 5.6.7 Distributed
Component Object Model (DCOM)
..........................................5-15 5.6.8 SCADA and
Industrial
Protocols.................................................................5-15
5.7 Network Address Translation (NAT)
......................................................................5-15
5.8 Specific ICS Firewall
Issues...................................................................................5-16
5.8.1 Data
Historians...........................................................................................5-16
5.8.2 Remote Support
Access.............................................................................5-16
5.8.3 Multicast Traffic
..........................................................................................5-17
5.9 Single Points of
Failure..........................................................................................5-17
5.10 Redundancy and Fault
Tolerance..........................................................................5-18
5.11 Preventing Man-in-the-Middle Attacks
...................................................................5-18
6. ICS Security Controls
......................................................................................................6-1
6.1 Management
Controls..............................................................................................6-1
6.1.1 Security Assessment and
Authorization.......................................................6-2
6.1.2
Planning........................................................................................................6-2
6.1.3 Risk
Assessment..........................................................................................6-3
6.1.4 System and Services Acquisition
.................................................................6-5
6.1.5 Program
Management..................................................................................6-6
6.2 Operational
Controls................................................................................................6-6
6.2.1 Personnel Security
.......................................................................................6-7
6.2.2 Physical and Environmental
Protection........................................................6-7
6.2.3 Contingency
Planning.................................................................................6-11
6.2.4 Configuration Management
........................................................................6-13
6.2.5
Maintenance...............................................................................................6-14
6.2.6 System and Information
Integrity................................................................6-14
6.2.7 Media
Protection.........................................................................................6-18
6.2.8 Incident
Response......................................................................................6-18
6.2.9 Awareness and
Training.............................................................................6-21
vi
- 7. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 6.3
Technical Controls
.................................................................................................6-22
6.3.1 Identification and
Authentication.................................................................6-22
6.3.2 Access Control
...........................................................................................6-27
6.3.3 Audit and Accountability
.............................................................................6-31
6.3.4 System and Communications
Protection....................................................6-32
List of Appendices Appendix A Acronyms and Abbreviations
.......................................................................A-1
Appendix B Glossary of
Terms..........................................................................................B-1
Appendix C Current Activities in Industrial Control System Security
...........................C-1 Appendix D Emerging Security
Capabilities
....................................................................D-1
Appendix E Industrial Control Systems in the FISMA
Paradigm.................................... E-1 Appendix F
References
......................................................................................................
F-1 List of Figures Figure 2-1. ICS
Operation.........................................................................................................2-3
Figure 2-2. SCADA System General
Layout.............................................................................2-7
Figure 2-3. Basic SCADA Communication
Topologies.............................................................2-8
Figure 2-4. Large SCADA Communication Topology
...............................................................2-8
Figure 2-5. SCADA System Implementation Example (Distribution
Monitoring and Control)...2-9 Figure 2-6. SCADA System
Implementation Example (Rail Monitoring and
Control).............2-10 Figure 2-7. DCS Implementation Example
.............................................................................2-11
Figure 2-8. PLC Control System Implementation Example
....................................................2-12 Figure
3-1. Industrial Security Incidents by Year
....................................................................3-19
Figure 5-1. Firewall between Corporate Network and Control
Network....................................5-4 Figure 5-2. Firewall
and Router between Corporate Network and Control
Network.................5-6 Figure 5-3. Firewall with DMZ between
Corporate Network and Control Network....................5-7 Figure
5-4. Paired Firewalls between Corporate Network and Control
Network.......................5-9 Figure 5-5. CSSP Recommended
Defense-In-Depth
Architecture.........................................5-11 Figure
E-1. Risk Management Framework
..............................................................................
E-3 vii
- 8. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY viii List
of Tables Table 3-1. Summary of IT System and ICS Differences
...........................................................3-3
Table 3-2. Adversarial Threats to
ICS.......................................................................................3-5
Table 3-3. Policy and Procedure Vulnerabilities
.......................................................................3-7
Table 3-4. Platform Configuration
Vulnerabilities......................................................................3-8
Table 3-5. Platform Hardware Vulnerabilities
.........................................................................3-10
Table 3-6. Platform Software
Vulnerabilities...........................................................................3-10
Table 3-7. Platform Malware Protection Vulnerabilities
..........................................................3-11
Table 3-8. Network Configuration
Vulnerabilities....................................................................3-12
Table 3-9. Network Hardware
Vulnerabilities..........................................................................3-13
Table 3-10. Network Perimeter
Vulnerabilities........................................................................3-13
Table 3-11. Network Monitoring and Logging
Vulnerabilities..................................................3-14
Table 3-12. Communication Vulnerabilities
............................................................................3-14
Table 3-13. Wireless Connection Vulnerabilities
....................................................................3-14
Table 4-1. Suggested Actions for ICS Vulnerability
Assessments............................................4-8 Table
E-1. Possible Definitions for ICS Impact Levels Based on
ISA99.................................. E-5 Table E-2. Possible
Definitions for ICS Impact Levels Based on Product Produced,
Industry and Security
Concerns......................................................................................................
E-5
- 9. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Executive
Summary This document provides guidance for establishing secure
industrial control systems (ICS). These ICS, which include
supervisory control and data acquisition (SCADA) systems,
distributed control systems (DCS), and other control system
configurations such as skid-mounted Programmable Logic Controllers
(PLC) are often found in the industrial control sectors. ICS are
typically used in industries such as electric, water and
wastewater, oil and natural 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. DCS 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
vital 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 ICS mentioned above; other
examples include air traffic control and materials handling (e.g.,
Postal Service mail handling.) This document provides an overview
of these ICS and typical system topologies, identifies typical
threats and vulnerabilities to these systems, and provides
recommended security countermeasures to mitigate the associated
risks. Initially, ICS had little resemblance to traditional
information technology (IT) systems in that ICS 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 ICS are adopting IT solutions to promote corporate
business systems 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 ICS
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, ICS 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 nations economy, and compromise of proprietary
information. ICS 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
networks provides significantly less isolation for ICS 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 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.
ICS security objectives typically follow the priority of
availability, integrity and confidentiality, in that order. 1
- 10. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 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 damage, disable, or shut down equipment,
create environmental impacts, and/or endanger human life Inaccurate
information sent to system operators, either to disguise
unauthorized changes, or to cause the operators to initiate
inappropriate actions, which could have various negative effects
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 should 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 ICSs 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
persons 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 other networks, or does not cause
another problem elsewhere, such as a cascading event. Restoring
system after an incident. Incidents are inevitable and an incident
response plan is essential. A major characteristic of a good
security program is how quickly a system can be recovered after an
incident has occurred. 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 to the ICS. The cyber security team should consist of
a member of the organizations IT staff, control engineer, control
system operator, network and system security expert, 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 and/or
system integrator as well. The cyber security team should report
directly to site management (e.g., facility superintendent) or the
companys CIO/CSO, who in turn, accepts complete responsibility and
accountability for the cyber security of the ICS. An effective
cyber security program for an ICS should apply a strategy known as
defense-in-depth, layering security mechanisms such that the impact
of a failure in any one mechanism is minimized. 2
- 11. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY In a
typical ICS this means a defense-in-depth strategy that includes:
Developing security policies, procedures, training 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
design 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 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. 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 persons 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 intrusion detection software, 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
and/or cryptographic hashes to ICS data storage and communications
where determined appropriate. 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. 3
- 12. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 4 NIST
has created the Industrial Control System Security 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 and Organizations to ICS. While most
controls in Appendix F of NIST SP 800-53 are applicable to ICS as
written, several controls did require ICS-specific interpretation
and/or augmentation by adding one or more of the following to the
control: ICS Supplemental Guidance provides organizations with
additional information on the application of the security controls
and control enhancements in Appendix F of NIST SP 800- 53 to ICS
and the environments in which these specialized systems operate.
The Supplemental Guidance also provides information as to why a
particular security control or control enhancement may not be
applicable in some ICS environments and may be a candidate for
tailoring (i.e., the application of scoping guidance and/or
compensating controls). ICS Supplemental Guidance does not replace
the original Supplemental Guidance in Appendix F of NIST SP 800-53.
ICS Enhancements (one or more) that provide enhancement
augmentations to the original control that may be required for some
ICS ICS Enhancement Supplemental Guidance that provides guidance on
how the control enhancement applies, or does not apply, in ICS
environments. This ICS-specific guidance is included in NIST SP
800-53, Revision 3, Appendix I: Industrial Control Systems Security
Controls, Enhancements, and Supplemental Guidance. Section 6 of
this document also provides initial guidance on how 800-53 security
controls apply to ICS. Initial recommendations and guidance, if
available, are provided in an outlined box for each section. NIST
is planning a December 2011 update to NIST SP 800-53 (NIST SP
800-53, Revision 4), including an update of current security
controls, control enhancements, supplemental guidance, as well as
tailoring and supplementation guidance, in the area of industrial
control systems. Additionally, Appendix C of this document provides
an overview of the many activities currently ongoing among Federal
organizations, standards organizations, industry groups, and
automation system vendors to make available recommended practices
in the area of ICS security. The most successful method for
securing an ICS is to gather industry recommended practices and
engage in a proactive, collaborative effort between management, the
controls engineer and operator, the IT organization, and a trusted
automation advisor. This team should draw upon the wealth of
information available from ongoing federal government, industry
groups, vendor and standards organizational activities listed in
Appendix C. 1 The Industrial Control System Security Project Web
site is located at: http://csrc.nist.gov/groups/SMA/fisma/ics/
- 13. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 1.
Introduction 1.1 Authority The National Institute of Standards and
Technology (NIST) developed this document in furtherance of its
statutory responsibilities under the Federal Information Security
Management Act (FISMA) of 2002, Public Law 107-347 and Homeland
Security Presidential Directive 7 (HSPD-7) of 2003. NIST is
responsible for developing standards and guidelines, including
minimum requirements, for providing adequate information security
for all agency operations and assets, but such standards and
guidelines shall not apply to national security systems. This
guideline is consistent with the requirements of the Office of
Management and Budget (OMB) Circular A-130, Section 8b(3), Securing
Agency Information Systems, as analyzed in A-130, Appendix IV:
Analysis of Key Sections. Supplemental information is provided in
A-130, Appendix III. This guideline has been prepared for use by
Federal agencies. It may be used by nongovernmental organizations
on a voluntary basis and is not subject to copyright, though
attribution is desired. Nothing in this document should be taken to
contradict standards and guidelines made mandatory and binding on
Federal agencies by the Secretary of Commerce under statutory
authority, nor should these guidelines be interpreted as altering
or superseding the existing authorities of the Secretary of
Commerce, Director of the OMB, or any other Federal official. 1.2
Purpose and Scope The purpose of this document is to provide
guidance for securing industrial control systems (ICS), including
supervisory control and data acquisition (SCADA) systems,
distributed control systems (DCS), and other systems performing
control functions. The document provides an overview of ICS and
typical system topologies, identifies typical threats and
vulnerabilities to these systems, and provides recommended security
countermeasures to mitigate the associated risks. Because there are
many different types of ICS with varying levels of potential risk
and impact, the document provides a list of many different methods
and techniques for securing ICS. The document should not be used
purely as a checklist to secure a specific system. Readers are
encouraged to perform a risk-based assessment on their systems and
to tailor the recommended guidelines and solutions to meet their
specific security, business and operational requirements. The scope
of this document includes ICS that are typically used in the
electric, water and wastewater, oil and natural gas, chemical,
pharmaceutical, pulp and paper, food and beverage, and discrete
manufacturing (automotive, aerospace, and durable goods)
industries. 1.3 Audience This document covers details specific to
ICS. The document is technical in nature; however, it provides the
necessary background to understand the topics that are discussed.
The intended audience is varied and includes the following: Control
engineers, integrators, and architects who design or implement
secure ICS System administrators, engineers, and other information
technology (IT) professionals who administer, patch, or secure ICS
1-1
- 14. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 1-2
Security consultants who perform security assessments and
penetration testing of ICS Managers who are responsible for ICS
Senior management who are trying to understand implications and
consequences as they justify and apply an ICS cyber security
program to help mitigate impacts to business functionality
Researchers and analysts who are trying to understand the unique
security needs of ICS Vendors that are developing products that
will be deployed as part of an ICS Readers of this document are
assumed to be familiar with general computer security concepts,
communication protocols such as those used in networking and with
using Web-based methods for retrieving information. 1.4 Document
Structure The remainder of this guide is divided into the following
major sections: Section 2 provides an overview of SCADA and other
ICS as well as their importance as a rationale for the need for
security. Section 3 provides a discussion of differences between
ICS and IT systems, as well as threats, vulnerabilities and
incidents. Section 4 provides an overview of the development and
deployment of an ICS security program to mitigate the risk of the
vulnerabilities identified in Section 3. Section 5 provides
recommendations for integrating security into network architectures
typically found in ICS, with an emphasis on network segregation
practices. Section 6 provides a summary of the management,
operational, and technical controls identified in NIST Special
Publication 800-53, Recommended Security Controls for Federal
Information Systems and Organizations, and provides initial
guidance on how these security controls apply to ICS. The guide
also contains several appendices with supporting material, as
follows: Appendix A provides a list of acronyms and abbreviations
used in this document. Appendix B provides a glossary of terms used
in this document. Appendix C provides a list and short description
of some of the current activities in ICS security. Appendix D
provides a list of some emerging security capabilities being
developed for ICS. Appendix E provides an overview of the FISMA
implementation project and supporting documents, and the relevancy
of FISMA to ICS. Appendix F provides a list of references used in
the development of this document.
- 15. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 2.
Overview of Industrial Control Systems Industrial control system
(ICS) is a general term that encompasses several types of control
systems, including supervisory control and data acquisition (SCADA)
systems, distributed control systems (DCS), and other control
system configurations such as skid-mounted Programmable Logic
Controllers (PLC) often found in the industrial sectors and
critical infrastructures. ICS are typically used in industries such
as electrical, water and wastewater, oil and natural gas, chemical,
transportation, pharmaceutical, pulp and paper, food and beverage,
and discrete manufacturing (e.g., automotive, aerospace, and
durable goods.) 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.) This section provides an
overview of SCADA, DCS, and PLC systems, including typical
architectures and components. Several diagrams are presented to
depict the network connections and components typically found on
each system to facilitate the understanding of these systems. Keep
in mind that actual implementations of ICS may be hybrids that blur
the line between DCS and SCADA systems by incorporating attributes
of both. Please note that the diagrams in this section do not
represent a secure ICS. Architecture security and security controls
are discussed in Section 5 and Section 6 of this document
respectively. 2.1 Overview of SCADA, DCS, and PLCs SCADA systems
are highly distributed systems used to control geographically
dispersed assets, often scattered over thousands of square
kilometers, where centralized data acquisition and control are
critical to system operation. They are used in distribution systems
such as water distribution and wastewater collection systems, oil
and natural gas pipelines, electrical power grids, and railway
transportation systems. A SCADA control center performs centralized
monitoring and control for field sites over long- distance
communications networks, including monitoring alarms and processing
status data. Based on information received from remote stations,
automated or operator-driven supervisory commands can be pushed to
remote station control devices, which are often referred to as
field devices. Field devices control local operations such as
opening and closing valves and breakers, collecting data from
sensor systems, and monitoring the local environment for alarm
conditions. DCS are used to control industrial processes such as
electric power generation, oil refineries, water and wastewater
treatment, and chemical, food, and automotive production. DCS are
integrated as a control architecture containing a supervisory level
of control overseeing multiple, integrated sub-systems that are
responsible for controlling the details of a localized process.
Product and process control are usually achieved by deploying feed
back or feed forward control loops whereby key product and/or
process conditions are automatically maintained around a desired
set point. To accomplish the desired product and/or process
tolerance around a specified set point, specific PLCs are employed
in the field and proportional, integral, and/or derivative settings
on the PLC are tuned to provide the desired tolerance as well as
the rate of self-correction during process upsets. DCS are used
extensively in process-based industries. PLCs are computer-based
solid-state devices that control industrial equipment and
processes. While PLCs are control system components used throughout
SCADA and DCS systems, they are often the primary components in
smaller control system configurations used to provide operational
control of discrete processes such as automobile assembly lines and
power plant soot blower controls. PLCs are used extensively in
almost all industrial processes. 2-1
- 16. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY The
process-based manufacturing industries typically utilize two main
processes [1]: Continuous Manufacturing Processes. These processes
run continuously, often with transitions to make different grades
of a product. Typical continuous manufacturing processes include
fuel or steam flow in a power plant, petroleum in a refinery, and
distillation in a chemical plant. Batch Manufacturing Processes.
These processes have distinct processing steps, conducted on a
quantity of material. There is a distinct start and end step to a
batch process with the possibility of brief steady state operations
during intermediate steps. Typical batch manufacturing processes
include food manufacturing. The discrete-based manufacturing
industries typically conduct a series of steps on a single device
to create the end product. Electronic and mechanical parts assembly
and parts machining are typical examples of this type of industry.
Both process-based and discrete-based industries utilize the same
types of control systems, sensors, and networks. Some facilities
are a hybrid of discrete and process-based manufacturing. While
control systems used in distribution and manufacturing industries
are very similar in operation, they are different in some aspects.
One of the primary differences is that DCS or PLC-controlled sub-
systems are usually located within a more confined factory or
plant-centric area, when compared to geographically dispersed SCADA
field sites. DCS and PLC communications are usually performed using
local area network (LAN) technologies that are typically more
reliable and high speed compared to the long-distance communication
systems used by SCADA systems. In fact, SCADA systems are
specifically designed to handle long-distance communication
challenges such as delays and data loss posed by the various
communication media used. DCS and PLC systems usually employ
greater degrees of closed loop control than SCADA systems because
the control of industrial processes is typically more complicated
than the supervisory control of distribution processes. These
differences can be considered subtle for the scope of this
document, which focuses on the integration of IT security into
these systems. Throughout the remainder of this document, SCADA
systems, DCS and PLC systems will be referred to as ICS unless a
specific reference is made to one (e.g., field device used in a
SCADA system). 2.2 ICS Operation The basic operation of an ICS is
shown in Figure 2-1 [2]. Key components include the following:
Control Loop. A control loop consists of sensors for measurement,
controller hardware such as PLCs, actuators such as control valves,
breakers, switches and motors, and the communication of variables.
Controlled variables are transmitted to the controller from the
sensors. The controller interprets the signals and generates
corresponding manipulated variables, based on set points, which it
transmits to the actuators. Process changes from disturbances
result in new sensor signals, identifying the state of the process,
to again be transmitted to the controller. Human-Machine Interface
(HMI). Operators and engineers use HMIs to monitor and configure
set points, control algorithms, and adjust and establish parameters
in the controller. The HMI also displays process status information
and historical information. Remote Diagnostics and Maintenance
Utilities. Diagnostics and maintenance utilities are used to
prevent, identify and recover from abnormal operation or failures.
2-2
- 17. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY A
typical ICS contains a proliferation of control loops, HMIs, and
remote diagnostics and maintenance tools built using an array of
network protocols on layered network architectures. Sometimes these
control loops are nested and/or cascading whereby the set point for
one loop is based on the process variable determined by another
loop. Supervisory-level loops and lower-level loops operate
continuously over the duration of a process with cycle times
ranging on the order of milliseconds to minutes. Figure 2-1. ICS
Operation 2.3 Key ICS Components To support subsequent discussions,
this section defines key ICS components that are used in control
and networking. Some of these components can be described
generically for use in SCADA systems, DCS and PLCs, while others
are unique to one. The Glossary of Terms in Appendix B contains a
more detailed listing of control and networking components.
Additionally, Figure 2-5 and Figure 2-6 in Section 2.4 show SCADA
implementation examples, Figure 2-7 in Section 2.5 shows a DCS
implementation example and Figure 2-8 in Section 2.6 shows a PLC
system implementation example that incorporates these components.
2-3
- 18. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 2.3.1
Control Components The following is a list of the major control
components of an ICS: Control Server. The control server hosts the
DCS or PLC supervisory control software that communicates with
lower-level control devices. The control server accesses
subordinate control modules over an ICS network. SCADA Server or
Master Terminal Unit (MTU). The SCADA Server is the device that
acts as the master in a SCADA system. Remote terminal units and PLC
devices (as described below) located at remote field sites usually
act as slaves. Remote Terminal Unit (RTU). The RTU, also called a
remote telemetry unit, is a special purpose data acquisition and
control unit designed to support SCADA remote stations. RTUs are
field devices often equipped with wireless radio interfaces to
support remote situations where wire-based communications are
unavailable. Sometimes PLCs are implemented as field devices to
serve as RTUs; in this case, the PLC is often referred to as an
RTU. Programmable Logic Controller (PLC). The PLC is a small
industrial computer originally designed to perform the logic
functions executed by electrical hardware (relays, switches, and
mechanical timer/counters). PLCs have evolved into controllers with
the capability of controlling complex processes, and they are used
substantially in SCADA systems and DCS. Other controllers used at
the field level are process controllers and RTUs; they provide the
same control as PLCs but are designed for specific control
applications. In SCADA environments, PLCs are often used as field
devices because they are more economical, versatile, flexible, and
configurable than special-purpose RTUs. Intelligent Electronic
Devices (IED). An IED is a smart sensor/actuator containing the
intelligence required to acquire data, communicate to other
devices, and perform local processing and control. An IED could
combine an analog input sensor, analog output, low-level control
capabilities, a communication system, and program memory in one
device. The use of IEDs in SCADA and DCS systems allows for
automatic control at the local level. Human-Machine Interface
(HMI). The HMI is software and hardware that allows human operators
to monitor the state of a process under control, modify control
settings to change the control objective, and manually override
automatic control operations in the event of an emergency. The HMI
also allows a control engineer or operator to configure set points
or control algorithms and parameters in the controller. The HMI
also displays process status information, historical information,
reports, and other information to operators, administrators,
managers, business partners, and other authorized users. The
location, platform, and interface may vary a great deal. For
example, an HMI could be a dedicated platform in the control
center, a laptop on a wireless LAN, or a browser on any system
connected to the Internet. Data Historian. The data historian is a
centralized database for logging all process information within an
ICS. Information stored in this database can be accessed to support
various analyses, from statistical process control to enterprise
level planning. Input/Output (IO) Server. The IO server is a
control component responsible for collecting, buffering and
providing access to process information from control sub-components
such as PLCs, RTUs and IEDs. An IO server can reside on the control
server or on a separate computer platform. IO servers are also used
for interfacing third-party control components, such as an HMI and
a control server. 2-4
- 19. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 2.3.2
Network Components There are different network characteristics for
each layer within a control system hierarchy. Network topologies
across different ICS implementations vary with modern systems using
Internet-based IT and enterprise integration strategies. Control
networks have merged with corporate networks to allow control
engineers to monitor and control systems from outside of the
control system network. The connection may also allow
enterprise-level decision-makers to obtain access to process data.
The following is a list of the major components of an ICS network,
regardless of the network topologies in use: Fieldbus Network. The
fieldbus network links sensors and other devices to a PLC or other
controller. Use of fieldbus technologies eliminates the need for
point-to-point wiring between the controller and each device. The
devices communicate with the fieldbus controller using a variety of
protocols. The messages sent between the sensors and the controller
uniquely identify each of the sensors. Control Network. The control
network connects the supervisory control level to lower-level
control modules. Communications Routers. A router is a
communications device that transfers messages between two networks.
Common uses for routers include connecting a LAN to a WAN, and
connecting MTUs and RTUs to a long-distance network medium for
SCADA communication. Firewall. A firewall protects devices on a
network by monitoring and controlling communication packets using
predefined filtering policies. Firewalls are also useful in
managing ICS network segregation strategies. Modems. A modem is a
device used to convert between serial digital data and a signal
suitable for transmission over a telephone line to allow devices to
communicate. Modems are often used in SCADA systems to enable
long-distance serial communications between MTUs and remote field
devices. They are also used in SCADA systems, DCS and PLCs for
gaining remote access for operational and maintenance functions
such as entering commands or modifying parameters, and diagnostic
purposes. Remote Access Points. Remote access points are distinct
devices, areas and locations of a control network for remotely
configuring control systems and accessing process data. Examples
include using a personal digital assistant (PDA) to access data
over a LAN through a wireless access point, and using a laptop and
modem connection to remotely access an ICS system. 2-5
- 20. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 2.4
SCADA Systems SCADA systems are used to control dispersed assets
where centralized data acquisition is as important as control [3]
[4]. These systems are used in distribution systems such as water
distribution and wastewater collection systems, oil and natural gas
pipelines, electrical utility transmission and distribution
systems, and rail and other public transportation systems. SCADA
systems integrate data acquisition systems with data transmission
systems and HMI software to provide a centralized monitoring and
control system for numerous process inputs and outputs. SCADA
systems are designed to collect field information, transfer it to a
central computer facility, and display the information to the
operator graphically or textually, thereby allowing the operator to
monitor or control an entire system from a central location in real
time. Based on the sophistication and setup of the individual
system, control of any individual system, operation, or task can be
automatic, or it can be performed by operator commands. SCADA
systems consist of both hardware and software. Typical hardware
includes an MTU placed at a control center, communications
equipment (e.g., radio, telephone line, cable, or satellite), and
one or more geographically distributed field sites consisting of
either an RTU or a PLC, which controls actuators and/or monitors
sensors. The MTU stores and processes the information from RTU
inputs and outputs, while the RTU or PLC controls the local
process. The communications hardware allows the transfer of
information and data back and forth between the MTU and the RTUs or
PLCs. The software is programmed to tell the system what and when
to monitor, what parameter ranges are acceptable, and what response
to initiate when parameters change outside acceptable values. An
IED, such as a protective relay, may communicate directly to the
SCADA Server, or a local RTU may poll the IEDs to collect the data
and pass it to the SCADA Server. IEDs provide a direct interface to
control and monitor equipment and sensors. IEDs may be directly
polled and controlled by the SCADA Server and in most cases have
local programming that allows for the IED to act without direct
instructions from the SCADA control center. SCADA systems are
usually designed to be fault-tolerant systems with significant
redundancy built into the system architecture. Figure 2-2 shows the
components and general configuration of a SCADA system. The control
center houses a SCADA Server (MTU) and the communications routers.
Other control center components include the HMI, engineering
workstations, and the data historian, which are all connected by a
LAN. The control center collects and logs information gathered by
the field sites, displays information to the HMI, and may generate
actions based upon detected events. The control center is also
responsible for centralized alarming, trend analyses, and
reporting. The field site performs local control of actuators and
monitors sensors. Field sites are often equipped with a remote
access capability to allow field operators to perform remote
diagnostics and repairs usually over a separate dial up modem or
WAN connection. Standard and proprietary communication protocols
running over serial communications are used to transport
information between the control center and field sites using
telemetry techniques such as telephone line, cable, fiber, and
radio frequency such as broadcast, microwave and satellite. MTU-RTU
communication architectures vary among implementations. The various
architectures used, including point-to-point, series, series-star,
and multi-drop [5], are shown in Figure 2-3. Point-to-point is
functionally the simplest type; however, it is expensive because of
the individual channels needed for each connection. In a series
configuration, the number of channels used is reduced; however,
channel sharing has an impact on the efficiency and complexity of
SCADA operations. Similarly, the series-star and multi-drop
configurations use of one channel per device results in decreased
efficiency and increased system complexity. 2-6
- 21. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Figure
2-2. SCADA System General Layout The four basic architectures shown
in Figure 2-3 can be further augmented using dedicated
communication devices to manage communication exchange as well as
message switching and buffering. Large SCADA systems, containing
hundreds of RTUs, often employ sub-MTUs to alleviate the burden on
the primary MTU. This type of topology is shown in Figure 2-4.
Figure 2-5 shows an example of a SCADA system implementation. This
particular SCADA system consists of a primary control center and
three field sites. A second backup control center provides
redundancy in the event of a primary control center malfunction.
Point-to-point connections are used for all control center to field
site communications, with two connections using radio telemetry.
The third field site is local to the control center and uses the
wide area network (WAN) for communications. A regional control
center resides above the primary control center for a higher level
of supervisory control. The corporate network has access to all
control centers through the WAN, and field sites can be accessed
remotely for troubleshooting and maintenance operations. The
primary control center polls field devices for data at defined
intervals (e.g., 5 seconds, 60 seconds) and can send new set points
to a field device as required. In addition to polling and issuing
high-level commands, the SCADA server also watches for priority
interrupts coming from field site alarm systems. 2-7
- 22. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Figure
2-3. Basic SCADA Communication Topologies Figure 2-4. Large SCADA
Communication Topology 2-8
- 23. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Figure
2-5. SCADA System Implementation Example (Distribution Monitoring
and Control) Figure 2-6 shows an example implementation for rail
monitoring and control. This example includes a rail control center
that houses the SCADA system and three sections of a rail system.
The SCADA system polls the rail sections for information such as
the status of the trains, signal systems, traction electrification
systems, and ticket vending machines. This information is also fed
to operator consoles at the HMI station within the rail control
center. The SCADA system also monitors operator inputs at the rail
control center and disperses high-level operator commands to the
rail section components. In addition, the SCADA system monitors
conditions at the individual rail sections and issues commands
based on these conditions (e.g., shut down a train to prevent it
from entering an area that has been determined to be flooded or
occupied by another train based on condition monitoring). 2-9
- 24. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Figure
2-6. SCADA System Implementation Example (Rail Monitoring and
Control) 2.5 Distributed Control Systems DCS are used to control
production systems within the same geographic location for
industries such as oil refineries, water and wastewater treatment,
electric power generation plants, chemical manufacturing plants,
and pharmaceutical processing facilities. These systems are usually
process control or discrete part control systems. A DCS uses a
centralized supervisory control loop to mediate a group of
localized controllers that share the overall tasks of carrying out
an entire production process [6]. By modularizing the production
system, a DCS reduces the impact of a single fault on the overall
system. In many modern systems, the DCS is interfaced with the
corporate network to give business operations a view of production.
An example implementation showing the components and general
configuration of a DCS is depicted in Figure 2-7. This DCS
encompasses an entire facility from the bottom-level production
processes up to the corporate or enterprise layer. In this example,
a supervisory controller (control server) communicates to its
subordinates via a control network. The supervisor sends set points
to and requests data from the distributed field controllers. The
distributed controllers control their process actuators based on
control server commands and sensor feedback from process sensors.
2-10
- 25. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Figure
2-7 gives examples of low-level controllers found on a DCS system.
The field control devices shown include a PLC, a process
controller, a single loop controller, and a machine controller. The
single loop controller interfaces sensors and actuators using
point-to-point wiring, while the other three field devices
incorporate fieldbus networks to interface with process sensors and
actuators. Fieldbus networks eliminate the need for point-to-point
wiring between a controller and individual field sensors and
actuators. Additionally, a fieldbus allows greater functionality
beyond control, including field device diagnostics, and can
accomplish control algorithms within the fieldbus, thereby avoiding
signal routing back to the PLC for every control operation.
Standard industrial communication protocols designed by industry
groups such as Modbus and Fieldbus [7] are often used on control
networks and fieldbus networks. In addition to the
supervisory-level and field-level control loops, intermediate
levels of control may also exist. For example, in the case of a DCS
controlling a discrete part manufacturing facility, there could be
an intermediate level supervisor for each cell within the plant.
This supervisor would encompass a manufacturing cell containing a
machine controller that processes a part and a robot controller
that handles raw stock and final products. There could be several
of these cells that manage field-level controllers under the main
DCS supervisory control loop. Figure 2-7. DCS Implementation
Example 2-11
- 26. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 2.6
Programmable Logic Controllers PLCs are used in both SCADA and DCS
systems as the control components of an overall hierarchical system
to provide local management of processes through feedback control
as described in the sections above. In the case of SCADA systems,
they provide the same functionality of RTUs. When used in DCS, PLCs
are implemented as local controllers within a supervisory control
scheme. PLCs are also implemented as the primary components in
smaller control system configurations. PLCs have a user-
programmable memory for storing instructions for the purpose of
implementing specific functions such as I/O control, logic, timing,
counting, three mode proportional-integral-derivative (PID)
control, communication, arithmetic, and data and file processing.
Figure 2-8 shows control of a manufacturing process being performed
by a PLC over a fieldbus network. The PLC is accessible via a
programming interface located on an engineering workstation, and
data is stored in a data historian, all connected on a LAN. Figure
2-8. PLC Control System Implementation Example 2-12
- 27. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 2-13 2.7
Industrial Sectors and Their Interdependencies Both the electrical
power transmission and distribution grid industries use
geographically distributed SCADA control technology to operate
highly interconnected and dynamic systems consisting of thousands
of public and private utilities and rural cooperatives for
supplying electricity to end users. SCADA systems monitor and
control electricity distribution by collecting data from and
issuing commands to geographically remote field control stations
from a centralized location. SCADA systems are also used to monitor
and control water, oil and natural gas distribution, including
pipelines, ships, trucks, and rail systems, as well as wastewater
collection systems. SCADA systems and DCS are often networked
together. This is the case for electric power control centers and
electric power generation facilities. Although the electric power
generation facility operation is controlled by a DCS, the DCS must
communicate with the SCADA system to coordinate production output
with transmission and distribution demands. The U.S. critical
infrastructure is often referred to as a system of systems because
of the interdependencies that exist between its various industrial
sectors as well as interconnections between business partners [8]
[9]. Critical infrastructures are highly interconnected and
mutually dependent in complex ways, both physically and through a
host of information and communications technologies. An incident in
one infrastructure can directly and indirectly affect other
infrastructures through cascading and escalating failures. Electric
power is often thought to be one of the most prevalent sources of
disruptions of interdependent critical infrastructures. As an
example, a cascading failure can be initiated by a disruption of
the microwave communications network used for an electric power
transmission SCADA system. The lack of monitoring and control
capabilities could cause a large generating unit to be taken
offline, an event that would lead to loss of power at a
transmission substation. This loss could cause a major imbalance,
triggering a cascading failure across the power grid. This could
result in large area blackouts that could potentially affect oil
and natural gas production, refinery operations, water treatment
systems, wastewater collection systems, and pipeline transport
systems that rely on the grid for electric power.
- 28. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY 3. ICS
Characteristics, Threats and Vulnerabilities Most ICS in use today
were developed years ago, long before public and private networks,
desktop computing, or the Internet were a common part of business
operations. These systems were designed to meet performance,
reliability, safety, and flexibility requirements. In most cases
they were physically isolated from outside networks and based on
proprietary hardware, software, and communication protocols that
included basic error detection and correction capabilities, but
lacked the secure communication capabilities required in todays
interconnected systems. While there was concern for Reliability,
Maintainability, and Availability (RMA) when addressing statistical
performance and failure, the need for cyber security measures
within these systems was not anticipated. At the time, security for
ICS meant physically securing access to the network and the
consoles that controlled the systems. ICS development paralleled
the evolution of microprocessor, personal computer, and networking
technologies during the 1980s and 1990s, and Internet-based
technologies started making their way into ICS designs in the late
1990s. These changes to ICS exposed them to new types of threats
and significantly increased the likelihood that ICS could be
compromised. This section describes the unique security
characteristics of ICS, the vulnerabilities in ICS implementations,
and the threats and incidents that ICS may face. Section 3.7
presents several examples of actual ICS cyber security incidents.
3.1 Comparing ICS and IT Systems Initially, ICS had little
resemblance to IT systems in that ICS 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 ICS
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 ICS 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. ICS have many characteristics
that differ from traditional IT systems, including different risks
and priorities. Some of these include significant risk to the
health and safety of human lives, serious damage to the
environment, and financial issues such as production losses, and
negative impact to a nations economy. ICS have different
performance and reliability requirements and use operating systems
and applications that may be considered unconventional to typical
IT support personnel. Furthermore, the goals of safety and
efficiency can sometimes conflict with security in the design and
operation of control systems (e.g., requiring password
authentication and authorization should not hamper or interfere
with emergency actions for ICS.) The following lists some special
considerations when considering security for ICS: Performance
Requirements. ICS are generally time-critical, with the criterion
for acceptable levels of delay and jitter dictated by the
individual installation. Some systems require deterministic
responses. High throughput is typically not essential to ICS. In
contrast, IT systems typically require high throughput, and they
can typically withstand some level of delay and jitter Availability
Requirements. Many ICS processes are continuous in nature.
Unexpected outages of systems that control industrial processes are
not acceptable. Outages often must be planned and scheduled
days/weeks in advance. Exhaustive pre-deployment testing is
essential to ensure high 3-1
- 29. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY
availability for the ICS. In addition to unexpected outages, many
control systems cannot be easily stopped and started without
affecting production. In some cases, the products being produced or
equipment being used is more important than the information being
relayed. Therefore, the use of typical IT strategies such as
rebooting a component, are usually not acceptable solutions due to
the adverse impact on the requirements for high availability,
reliability and maintainability of the ICS. Some ICS employ
redundant components, often running in parallel, to provide
continuity when primary components are unavailable. Risk Management
Requirements. In a typical IT system, data confidentiality and
integrity are typically the primary concerns. For an ICS, human
safety and fault tolerance to prevent loss of life or endangerment
of public health or confidence, regulatory compliance, loss of
equipment, loss of intellectual property, or lost or damaged
products are the primary concerns. The personnel responsible for
operating, securing, and maintaining ICS must understand the
important link between safety and security. Architecture Security
Focus. In a typical IT system, the primary focus of security is
protecting the operation of IT assets, whether centralized or
distributed, and the information stored on or transmitted among
these assets. In some architectures, information stored and
processed centrally is more critical and is afforded more
protection. For ICS, edge clients (e.g., PLC, operator station, DCS
controller) need to be carefully protected because they are
directly responsible for controlling the end processes. The
protection of the central server is still very important in an ICS,
because the central server could possibly adversely impact every
edge device. Physical Interaction. In a typical IT system, there is
not physical interaction with the environment. ICS can have very
complex interactions with physical processes and consequences in
the ICS domain that can manifest in physical events. All security
functions integrated into the ICS must be tested (e.g., off-line on
a comparable ICS) to prove that they do not compromise normal ICS
functionality. Time-Critical Responses. In a typical IT system,
access control can be implemented without significant regard for
data flow. For some ICS, automated response time or system response
to human interaction is very critical. For example, requiring
password authentication and authorization on an HMI must not hamper
or interfere with emergency actions for ICS. Information flow must
not be interrupted or compromised. Access to these systems should
be restricted by rigorous physical security controls. System
Operation. ICS operating systems (OS) and applications may not
tolerate typical IT security practices. Legacy systems are
especially vulnerable to resource unavailability and timing
disruptions. Control networks are often more complex and require a
different level of expertise (e.g., control networks are typically
managed by control engineers, not IT personnel). Software and
hardware are more difficult to upgrade in an operational control
system network. Many systems may not have desired features
including encryption capabilities, error logging, and password
protection. Resource Constraints. ICS and their real time OSs are
often resource-constrained systems that usually do not include
typical IT security capabilities. There may not be computing
resources available on ICS components to retrofit these systems
with current security capabilities. Additionally, in some
instances, third-party security solutions are not allowed due to
ICS vendor license and service agreements, and loss of service
support can occur if third party applications are installed without
vendor acknowledgement or approval. Communications. Communication
protocols and media used by ICS environments for field device
control and intra-processor communication are typically different
from the generic IT environment, and may be proprietary. 3-2
- 30. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Change
Management. Change management is paramount to maintaining the
integrity of both IT and control systems. Unpatched software
represents one of the greatest vulnerabilities to a system.
Software updates on IT systems, including security patches, are
typically applied in a timely fashion based on appropriate security
policy and procedures. In addition, these procedures are often
automated using server-based tools. Software updates on ICS cannot
always be implemented on a timely basis because these updates need
to be thoroughly tested by the vendor of the industrial control
application and the end user of the application before being
implemented and ICS outages often must be planned and scheduled
days/weeks in advance. The ICS may also require revalidation as
part of the update process. Another issue is that many ICS utilize
older versions of operating systems that are no longer supported by
the vendor. Consequently, available patches may not be applicable.
Change management is also applicable to hardware and firmware. The
change management process, when applied to ICS, requires careful
assessment by ICS experts (e.g., control engineers) working in
conjunction with security and IT personnel. Managed Support.
Typical IT systems allow for diversified support styles, perhaps
supporting disparate but interconnected technology architectures.
For ICS, service support is usually via a single vendor, which may
not have a diversified and interoperable support solution from
another vendor. Component Lifetime. Typical IT components have a
lifetime on the order of 3 to 5 years, with brevity due to the
quick evolution of technology. For ICS where technology has been
developed in many cases for very specific use and implementation,
the lifetime of the deployed technology is often in the order of 15
to 20 years and sometimes longer. Access to Components. Typical IT
components are usually local and easy to access, while ICS
components can be isolated, remote, and require extensive physical
effort to gain access to them. Table 3-1 summarizes some of the
typical differences between IT systems and ICS. Table 3-1. Summary
of IT System and ICS Differences Category Information Technology
System Industrial Control System Performance Requirements
Non-real-time Response must be consistent High throughput is
demanded High delay and jitter may be acceptable Real-time Response
is time-critical Modest throughput is acceptable High delay and/or
jitter is not acceptable Availability Requirements Responses such
as rebooting are acceptable Availability deficiencies can often be
tolerated, depending on the systems operational requirements
Responses such as rebooting may not be acceptable because of
process availability requirements Availability requirements may
necessitate redundant systems Outages must be planned and scheduled
days/weeks in advance High availability requires exhaustive pre-
deployment testing 3-3
- 31. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Category
Information Technology System Industrial Control System Risk
Management Requirements Data confidentiality and integrity is
paramount Fault tolerance is less important momentary downtime is
not a major risk Major risk impact is delay of business operations
Human safety is paramount, followed by protection of the process
Fault tolerance is essential, even momentary downtime may not be
acceptable Major risk impacts are regulatory non- compliance,
environmental impacts, loss of life, equipment, or production
Architecture Security Focus Primary focus is protecting the IT
assets, and the information stored on or transmitted among these
assets. Central server may require more protection Primary goal is
to protect edge clients (e.g., field devices such as process
controllers) Protection of central server is also important
Unintended Consequences Security solutions are designed around
typical IT systems Security tools must be tested (e.g., off-line on
a comparable ICS) to ensure that they do not compromise normal ICS
operation Time-Critical Interaction Less critical emergency
interaction Tightly restricted access control can be implemented to
the degree necessary for security Response to human and other
emergency interaction is critical Access to ICS should be strictly
controlled, but should not hamper or interfere with human-machine
interaction System Operation Systems are designed for use with
typical operating systems Upgrades are straightforward with the
availability of automated deployment tools Differing and possibly
proprietary operating systems, often without security capabilities
built in Software changes must be carefully made, usually by
software vendors, because of the specialized control algorithms and
perhaps modified hardware and software involved Resource
Constraints Systems are specified with enough resources to support
the addition of third- party applications such as security
solutions Systems are designed to support the intended industrial
process and may not have enough memory and computing resources to
support the addition of security capabilities Communications
Standard communications protocols Primarily wired networks with
some localized wireless capabilities Typical IT networking
practices Many proprietary and standard communication protocols
Several types of communications media used including dedicated wire
and wireless (radio and satellite) Networks are complex and
sometimes require the expertise of control engineers Change
Management Software changes are applied in a timely fashion in the
presence of good security policy and procedures. The procedures are
often automated. Software changes must be thoroughly tested and
deployed incrementally throughout a system to ensure that the
integrity of the control system is maintained. ICS outages often
must be planned and scheduled days/weeks in advance. ICS may use
OSs that are no longer supported Managed Support Allow for
diversified support styles Service support is usually via a single
vendor Component Lifetime Lifetime on the order of 3-5 years
Lifetime on the order of 15-20 years Access to Components
Components are usually local and easy to access Components can be
isolated, remote, and require extensive physical effort to gain
access to them 3-4
- 32. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY
Available computing resources for ICS (including central processing
unit [CPU] time and memory) tend to be very limited because these
systems were designed to maximize control system resources, with
little to no extra capacity for third-party cyber security
solutions. Additionally, in some instances, third-party security
solutions are not allowed due to vendor license and service
agreements, and loss of service support can occur if third party
applications are installed. Another important consideration is that
IT cyber security and control systems expertise is typically not
found within the same group of personnel. In summary, the
operational and risk differences between ICS and IT systems create
the need for increased sophistication in applying cyber security
and operational strategies. A cross-functional team of control
engineers, control system operators and IT security professionals
needs to work closely to understand the possible implications of
the installation, operation, and maintenance of security solutions
in conjunction with control system operation. IT professionals
working with ICS need to understand the reliability impacts of
information security technologies before deployment. Some of the
OSs and applications running on ICS may not operate correctly with
commercial-off-the-shelf (COTS) IT cyber security solutions because
of specialized ICS environment architectures. 3.2 Threats Threats
to control systems can come from numerous sources, including
adversarial sources such as hostile governments, terrorist groups,
industrial spies, disgruntled employees, malicious intruders, and
natural sources such as from system complexities, human errors and
accidents, equipment failures and natural disasters. To protect
against adversarial threats (as well as known natural threats), it
is necessary to create a defense-in-depth strategy for the ICS.
Table 3-2 lists possible threats to ICS. Please note this list is
in alphabetical order and not by greatest threat. Table 3-2.
Adversarial Threats to ICS Threat Agent Description Attackers
Attackers break into networks for the thrill of the challenge or
for bragging rights in the attacker community. While remote
cracking once required a fair amount of skill or computer
knowledge, attackers can now download attack scripts and protocols
from the Internet and launch them against victim sites. Thus, while
attack tools have become more sophisticated, they have also become
easier to use. Many attackers do not have the requisite expertise
to threaten difficult targets such as critical U.S. networks.
Nevertheless, the worldwide population of attackers poses a
relatively high threat of an isolated or brief disruption causing
serious damage. Bot-network operators Bot-network operators are
attackers; however, instead of breaking into systems for the
challenge or bragging rights, they take over multiple systems to
coordinate attacks and to distribute phishing schemes, spam, and
malware attacks. The services of compromised systems and networks
are sometimes made available on underground markets (e.g.,
purchasing a denial of service attack or the use of servers to
relay spam or phishing attacks). Criminal groups Criminal groups
seek to attack systems for monetary gain. Specifically, organized
crime groups are using spam, phishing, and spyware/malware to
commit identity theft and online fraud. International corporate
spies and organized crime organizations also pose a threat to the
U.S. through their ability to conduct industrial espionage and
large-scale monetary theft and to hire or develop attacker talent.
Some criminal groups may try to extort money from an organization
by threatening a cyber attack. 3-5
- 33. GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY Threat
Agent Description Foreign intelligence services Foreign
intelligence services use cyber tools as part of their information
gathering and espionage activities. In addition, several nations
are aggressively working to develop information warfare doctrines,
programs, and capabilities. Such capabilities enable a single
entity to have a significant and serious impact by disrupting the
supply, communications, and economic infrastructures that support
military power impacts that could affect the daily lives of U.S.
citizens. Insiders The disgruntled insider is a principal source of
computer crime. Insiders may not need a great deal of knowledge
about computer intrusions because their knowledge of a target
system often allows them to gain unrestricted access to cause
damage to the system or to steal system data. The insider threat
also includes outsourcing vendors as well as employees who
accidentally introduce malware into systems. Insiders may be
employees, contractors, or business partners. Inadequate policies,
procedures, and testing can, and have led to ICS impacts. Impacts
have ranged from trivial to significant damage to the ICS and field
devices. Unintentional impacts from insiders are some of the
highest probability occurrences. Phishers Phishers are individuals
or small groups that execute phishing schemes in an attempt to
steal identities or information for monetary gain. Phishers may
also use spam and spyware/malware to accomplish their objectives.
Spammers Spammers are individuals or organizations that distribute
unsolicited e-mail with hidden or false information to sell
products, conduct phishing schemes, distribute spyware/malware, or
attack organizations (e.g., DoS). Spyware/malware authors
Individuals or organizations with malicious intent carry out
attacks against users by producing and distributing spyware and
malware. Several destructive computer viruses and worms have harmed
files and hard drives, including the Melissa Macro Virus, the
Explore.Zip worm, the CIH (Chernobyl) Virus, Nimda, Code Red,
Slammer, and Blaster. Terrorists Terrorists seek to destroy,
incapacitate, or exploit critical infrastructures to threaten
national security, cause mass casualties, weaken the U.S. economy,
and damage public morale and confidence. Terrorists may use
phishing schemes or spyware/malware to generate funds or gather
sensitive information. Terrorists may attack one target to divert
attention or resources from other targets. Industrial spies
Industrial espionage seeks to acquire intellectual property and
know-how by clandestine methods Source: Government Accountability
Office (GAO), Department of Homeland Securitys (DHSs) Role in
Critical Infrastructure Protection (CIP) Cybersecurity, GAO-05-434
(Washington, D.C.: May, 2005). 3.3 Potential ICS Vulnerabilities
This section lists vulnerabilities that may be found in typical
ICS. The order of these vulnerabilities does not necessarily
reflect any priority in terms of likelihood of occurrence or
severity of impact. The vulnerabilities are grouped into Policy and
Procedure, Platform, and Network categories to assist in
determining optimal mitigation strategies. Any given ICS will
usually exhibit a subset of these vulnerabilities, but may also
contain additional vulnerabilities unique to the particular ICS
implementation that do not appear in this listing. Specific
information on ICS vulnerabilities can be researched at the United
States Computer Emergency Readiness Team (US-CERT) Control Systems
Web site.2 When studying possible security vulnerabilities, it is
easy to becom