final answer
Industrial Network
Security
Securing Critical Infrastructure
Networks for Smart Grid,
SCADA, and Other Industrial
Control Systems This page intentionally left blank Industrial Network
Security
Securing Critical Infrastructure
Networks for Smart Grid,
SCADA, and Other Industrial
Control Systems
Eric Knapp
Technical Editor
James Broad
AMSTERDAM • BOSTON • HEIDELBERG • LONDON NEW YORK • OXFORD • PARIS • SAN DIEGO SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO
Syngress is an imprint of Elsevier Acquiring Editor: Angelina WardDevelopment Editor: Matt CaterProject Manager: Jessica VaughanDesigner: Joanne Blank
Syngress is an imprint of Elsevier 225 Wyman Street, Waltham, MA 02451, USA
© 2011 Elsevier Inc. All rights reserved
No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions .
This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein).
NoticesKnowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods or professional practices may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information or methods described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility. To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein.
Library of Congress Cataloging-in-Publication DataKnapp, Eric. Industrial network security : securing critical infrastructure networks for Smart Grid, SCADA, and other industrial control systems / Eric Knapp. p. cm. Summary: “This book attempts to define an approach to industrial network security that considers the unique network, protocol and application characteristics of an industrial control system, while also taking into consideration a variety of common compliance controls”–Provided by publisher. Includes bibliographical references. ISBN 978-1-59749-645-2 (pbk.) 1. Process control–Security measures. 2. Computer security. I. Title. TS156.8.K58 2011 670.42'7–dc23 2011018442
British Library Cataloguing-in-Publication DataA catalogue record for this book is available from the British Library
ISBN: 978-1-59749-645-2
Printed in the United States of America
11 12 13 14 15 10 9 8 7 6 5 4 3 2 1
For information on all Syngress publications visit our website at www.syngress.com. v
Contents
About the Author
..................................................................................................... xiii
About the Technical Editor ...................................................................................... xv
Foreword ................................................................................................................ xvii
CHAPTER 1 Introduction ........................................................... 1
Book Overview and Key Learning Points ...................................... 1
Book Audience ................................................................................ 1
Diagrams and Figures ..................................................................... 2
The Smart Grid ............................................................................... 2
How This Book Is Organized .......................................................... 3
Chapter 2: About Industrial Networks
........................................ 3
Chapter 3: Introduction to Industrial Network Security ............. 4
Chapter 4: Industrial Network Protocols .................................... 4
Chapter 5: How Industrial Networks Operate ............................ 4
Chapter 6: Vulnerability and Risk Assessment ........................... 4
Chapter 7: Establishing Secure Enclaves ................................... 4
Chapter 8: Exception, Anomaly, and Threat Detection .............. 4
Chapter 9: Monitoring Enclaves ................................................. 5
Chapter 10: Standards and Regulations ...................................... 5
Chapter 11: Common Pitfalls and Mistakes ............................... 5
Conclusion ...................................................................................... 5
CHAPTER 2 About Industrial Networks ....................................... 7
Industrial Networks and Critical Infrastructure .............................. 7
Critical Infrastructure ................................................................. 8
Critical versus Noncritical Industrial Networks ....................... 11
Relevant Standards and Organizations ......................................... 12
Homeland Security Presidential DirectiveSeven/HSPD-7 ....... 12
NIST Special Publications (800 Series) ................................... 13
NERC CIP ................................................................................ 13
Nuclear Regulatory Commission .............................................. 13
Federal Information Security Management Act ....................... 15
Chemical Facility Anti-Terrorism Standards ............................ 16
ISA-99 ...................................................................................... 17
ISO 27002 ................................................................................. 18
Common Industrial Security Recommendations .......................... 18
Identification of Critical Systems ............................................. 18
Network Segmentation/Isolation of Systems ........................... 20 vi Contents
Defense in Depth ...................................................................... 23
Access Control .......................................................................... 24
The Use of Terminology Within This Book ................................. 25
Networks, Routable and Non-routable ..................................... 25
Assets, Critical Assets, Cyber Assets, and Critical
Cyber Assets ............................................................................. 25
Enclaves .................................................................................... 26
Electronic Security Perimeters ................................................. 27
Summary ....................................................................................... 28
Endnotes ....................................................................................... 28
CHAPTER 3 Introduction to Industrial Network Security ............ 31
The Importance of Securing Industrial Networks ......................... 31
The Impact of Industrial Network Incidents ................................. 34
Safety Controls ......................................................................... 34
Consequences of a Successful Cyber Incident ......................... 35
Examples of Industrial Network Incidents ................................... 36
Dissecting Stuxnet .................................................................... 38
Night Dragon ............................................................................ 41
APT and Cyber War ...................................................................... 41
The Advanced Persistent Threat ............................................... 43
Cyber War ................................................................................. 44
Emerging Trends in APT and Cyber War ................................. 45
Still to Come ............................................................................. 49
Defending Against APT ............................................................ 50
Responding to APT ................................................................... 50
Summary ....................................................................................... 52
Endnotes ....................................................................................... 53
CHAPTER 4 Industrial Network Protocols ................................. 55
Overview of Industrial Network Protocols ................................... 55
Modbus ......................................................................................... 56
What It Does ............................................................................. 56
How It Works ............................................................................ 57
Variants ..................................................................................... 58
Where It Is Used ....................................................................... 59
Security Concerns ..................................................................... 59
Security Recommendations ...................................................... 60
ICCP/TASE.2 ................................................................................ 61
What It Does ............................................................................. 62
How It Works ............................................................................ 62 vii Contents
Where It Is Used ....................................................................... 63
Security Concerns ..................................................................... 63
Security Improvements over Modbus ....................................... 64
Security Recommendations ...................................................... 65
DNP3 ............................................................................................ 66
What It Does ............................................................................. 66
How It Works ............................................................................ 67
Secure DNP3 ............................................................................ 69
Where It Is Used ....................................................................... 70
Security Concerns ..................................................................... 71
Security Recommendations ...................................................... 72
OLE for Process Control .............................................................. 73
What It Does ............................................................................. 73
How It Works ............................................................................ 74
OPC-UA and OPC-XI .............................................................. 75
Where It Is Used ....................................................................... 75
Security Concerns ..................................................................... 75
Security Recommendations ...................................................... 77
Other Industrial Network Protocols .............................................. 78
Ethernet/IP ................................................................................ 78
Profibus ..................................................................................... 79
EtherCAT .................................................................................. 80
Ethernet Powerlink ................................................................... 81
SERCOS III .............................................................................. 82
AMI and the Smart Grid ............................................................... 83
Security Concerns ..................................................................... 84
Security Recommendations ...................................................... 85
Summary ....................................................................................... 85
Endnotes ....................................................................................... 86
CHAPTER 5 How Industrial Networks Operate ........................... 89
Control System Assets .................................................................. 89
IEDs .......................................................................................... 89
RTUs ......................................................................................... 90
PLCs ......................................................................................... 90
HMIs ......................................................................................... 93
Supervisory Workstations ......................................................... 94
Data Historians ......................................................................... 94
Business Information Consoles and Dashboards ..................... 96
Other Assets .............................................................................. 96 viii Contents
Network Architectures .................................................................. 97
Topologies Used ....................................................................... 98
Control System Operations ......................................................... 100
Control Loops ......................................................................... 101
Control Processes ................................................................... 102
Feedback Loops ...................................................................... 103
Business Information Management ........................................ 104
Control Process Management ..................................................... 106
Smart Grid Operations ................................................................ 107
Summary ..................................................................................... 109
Endnotes ..................................................................................... 109
CHAPTER 6 Vulnerability and Risk Assessment ...................... 111
Basic Hacking Techniques .......................................................... 111
The Attack Process ................................................................. 112
Targeting an Industrial Network ............................................. 116
Threat Agents .......................................................................... 122
Accessing Industrial Networks ................................................... 123
The Business Network ............................................................ 124
The SCADA DMZ .................................................................. 126
The Control System ................................................................ 127
Common Vulnerabilities ......................................................... 127
The Smart Grid ....................................................................... 132
Determining Vulnerabilities ........................................................ 132
Why Vulnerability Assessment Is Important .......................... 133
Vulnerability Assessment in Industrial Networks ................... 137
Vulnerability Scanning for Configuration Assurance ............. 138
Where to Perform VA Scans ................................................... 139
Cyber Security Evaluation Tool .............................................. 140
Vulnerability Management ......................................................... 140
Patch Management ................................................................. 141
Configuration Management .................................................... 143
Device Removal and Quarantine ............................................ 144
Summary ..................................................................................... 144
Endnotes ..................................................................................... 145
CHAPTER 7 Establishing Secure Enclaves .............................. 147
Identifying Functional Groups .................................................... 148
Network Connectivity ............................................................. 149
Control Loops ......................................................................... 149
Supervisory Controls .............................................................. 150
Control Processes ................................................................... 151 ix Contents
Control Data Storage .............................................................. 152
Trading Communications ....................................................... 153
Remote Access ........................................................................ 154
Users and Roles ...................................................................... 155
Protocols ................................................................................. 156
Criticality ................................................................................ 156
Using Functional Groups to Identify Enclaves ....................... 159
Establishing Enclaves ................................................................. 161
Identifying Enclave Perimeters ............................................... 161
Network Alterations ................................................................ 164
Enclaves and Security Policy Development ........................... 164
Enclaves and Security Device Configurations ........................ 164
Securing Enclave Perimeters ...................................................... 166
Selecting Perimeter Security Devices ..................................... 166
Implementing Perimeter Security Devices ............................. 169
Intrusion Detection and Prevention (IDS/IPS)
Configuration Guidelines ........................................................ 172
Securing Enclave Interiors .......................................................... 181
Selecting Interior Security Systems ........................................ 183
Summary ..................................................................................... 185
Endnotes ..................................................................................... 186
CHAPTER 8 Exception, Anomaly, and Threat Detection ............ 189
Exception Reporting ................................................................... 190
Behavioral Anomaly Detection ................................................... 192
Measuring Baselines ............................................................... 192
Anomaly Detection ................................................................. 194
Behavioral Whitelisting .............................................................. 199
User Whitelists ....................................................................... 199
Asset Whitelists ...................................................................... 200
Application Behavior Whitelists ............................................. 202
Threat Detection ......................................................................... 205
Event Correlation .................................................................... 206
Correlating between IT and OT Systems ................................ 211
Summary ..................................................................................... 213
Endnotes ..................................................................................... 213
CHAPTER 9 Monitoring Enclaves ........................................... 215
Determining What to Monitor .................................................... 216
Security Events ....................................................................... 217
Assets ...................................................................................... 218 x Contents
Configurations ........................................................................ 220
Applications ............................................................................ 221
Networks ................................................................................. 222
User Identities and Authentication ......................................... 223
Additional Context .................................................................. 225
Behavior .................................................................................. 228
Successfully Monitoring Enclaves .............................................. 229
Log Collection ........................................................................ 229
Direct Monitoring ................................................................... 230
Inferred Monitoring ................................................................ 230
Information Collection and Management Tools
(Log Management Systems, SIEMs) ...................................... 233
Monitoring Across Secure Boundaries ................................... 236
Information Management ........................................................... 236
Queries .................................................................................... 237
Reports .................................................................................... 240
Alerts ....................................................................................... 241
Incident Investigation and Response ...................................... 241
Log Storage and Retention ......................................................... 242
Nonrepudiation ....................................................................... 242
Data Retention/Storage ........................................................... 242
Data Availability ..................................................................... 243
Summary ..................................................................................... 245
Endnotes ..................................................................................... 246
CHAPTER 10 Standards and Regulations .................................. 249
Common Standards and Regulations .......................................... 250
NERC CIP .............................................................................. 250
CFATS .................................................................................... 251
ISO/IEC 27002:2005 .............................................................. 252
NRC Regulation 5.71 ............................................................. 253
NIST SP 800-82 ..................................................................... 253
Mapping Industrial Network Security to Compliance ................ 254
Perimeter Security Controls ................................................... 255
Host Security Controls ........................................................... 255
Security Monitoring Controls ................................................. 279
Mapping Compliance Controls to Network Security
Functions ..................................................................................... 293
Common Criteria and FIPS Standards ........................................ 293
Common Criteria .................................................................... 293 xi Contents
FIPS 140-2 .............................................................................. 300
Summary ..................................................................................... 300
Endnotes ..................................................................................... 300
CHAPTER 11 Common Pitfalls and Mistakes ............................ 303
Complacency .............................................................................. 303
Vulnerability Assessments vs. Zero-Days .............................. 303
Real Security vs. Policy and Awareness ................................. 304
The Air Gap Myth ................................................................... 304
Misconfigurations ....................................................................... 305
Default Accounts and Passwords ............................................ 306
Lack of Outbound Security and Monitoring .......................... 306
The Executive Override .......................................................... 307
The Ronco Perimeter .............................................................. 307
Compliance vs. Security ............................................................. 308
Audit Fodder ........................................................................... 308
The “One Week Compliance Window”
....................................................... 310
Insufficiently Sized Security Controls .................................... 311
Summary ..................................................................................... 312
Endnotes ..................................................................................... 312
Glossary ................................................................................................................. 313
Appendix A ............................................................................................................ 323
Appendix B ............................................................................................................ 325
Appendix C ............................................................................................................ 329
Index ...................................................................................................................... 331 This page intentionally left blank xiii
About the Author
Eric D. Knapp is the Director of Critical Infrastructure Markets for NitroSecurity,
where he leads the identification, evaluation, and implementation of new security
technologies specific to the protection of critical infrastructure, Supervisory Control
And Data Acquisition (SCADA), and industrial control networks.
Eric has 20 years of experience in Information Technology, specializing in industrial
automation technologies, infrastructure security, and applied Ethernet protocols as
well as the design and implementation of Intrusion Prevention Systems and Security
Information and Event Management systems in both enterprise and industrial net -
works. In addition to his work in information security, Eric is an award-winning
author. He studied English and Writing at the University of New Hampshire and the
University of London and holds a degree in communications. This page intentionally left blank xv
About the Technical Editor
James Broad (CISSP, C|EH, C)PTS, Security , MBA) is the President and owner of
Cyber-Recon, LLC, where he and his team of consultants specialize in Information
Security, Information Assurance, and Certification and Accreditation and offer other
security consultancy services to corporate and government clients.
As a security professional with over 20 years of real-world IT experience, James
is an expert in many areas of IT security, specializing in security engineering, pen -
etration testing, and vulnerability analysis and research. He has provided security
services in the Nation’s most critical sectors including defense, law enforcement,
intelligence, finance, and healthcare.
James has a Master’s of Business Administration degree with specialization in
Information Technology (MBA/IT) from the Ken Blanchard College of Business,
Bachelor’s degrees in Computer Programming and Security Management from
Southwestern University and is currently a Doctoral Learner pursuing a PhD in
Information Security from Capella University. He is a member of ISSA and (ISC)
Temara. This page intentionally left blank xvii
Foreword
One of the most mysterious areas of information security is industrial system secu -
rity. No other area of information security contains that many myths, mistakes, mis -
conceptions and outright lies. Information available online, while voluminous, will
only lead information security professionals and industrial systems professionals to
more confusion and more misconceptions—which may result in not only costly, but
also life-threatening, mistakes.
What raises the mystery even higher is that the stakes in the area of industrial
security are extremely high. While the loss of trade secret information may kill a
business, the loss of electricity generating capability may kill not just one person,
but potentially thousands.
And finally the mystery is solved—with this well-researched book on industrial
system network security.
The book had a few parts of particular interest to me. I liked that the book covers
the “myth of an air gap”—now in the age of wireless, the air gap is not what it used
to be and should not be assumed to be “the absolute security.” I also liked that safety
versus security is covered: industrial engineers might know more about the former
while my InfoSec colleagues know more about the latter. Today’s interconnected
industrial systems absolutely need both! Finally, I also liked the book’s focus on risk
and impact, and not simply on following the regulatory minimum.
Both information security and industrial engineers, which are currently two
distinctly different tribes, would benefit from this book. And, hopefully Industrial
Network Security will bring the much needed union of both tribes, thus helping us
build a more secure business and industrial system.
—Dr. Anton A. Chuvakin
Security Warrior Consulting This page intentionally left blank 1
Introduction
1
CHAPTER
I N F O R M AT I O N I N T H I S C H A P T E R :
l Book Overview and Key Learning Points
l Book Audience
l Diagrams and Figures
l The Smart Grid
l How This Book Is Organized
BOOK OVERVIEW AND KEY LEARNING POINTS
This book attempts to define an approach to industrial network security that consid -
ers the unique network, protocol, and application characteristics of an industrial
control system , while also taking into consideration a variety of common compli -
ance controls.
Although many of the techniques described herein—and much of the general
guidance provided by regulatory standards organizations—are built upon common
enterprise security methods and reference readily available information security
tools, there is little information available about how to implement these methods.
This book attempts to rectify this by providing deployment and configuration guid -
ance where possible, and by identifying why security controls should be imple -
mented, where they should implemented, how they should be implemented, and
how they should be used.
BOOK AUDIENCE
To adequately discuss industrial network security, the basics of two very different
systems need to be understood: the Ethernet and Transmission Control Protocol/
Internet Protocol (TCP/IP) networking communications used ubiquitously in the
enterprise, and the SCADA and field bus protocols used to manage and/or operate
industrial automated systems.
As a result, this book possesses a bifurcated audience. For the plant operator
with an advanced electrical engineering degree and a decade of logic programming 2 CHAPTER 1 Introduction
for Modbus controllers, the basics of industrial network protocols in Chapter 4
have been presented within the context of security in an attempt to not only pro -
vide value to such a reader, but also to get that reader thinking about the subtle
implications of cyber security. For the information security analyst with a Certified
Information Systems Security Professional (CISSP) certification, basic information
security practices have been provided within the new context of an industrial con -
trol system.
There is an interesting dichotomy between the two that provides a further
challenge. Enterprise security typically strives to secure the users and hosts on a
network while at the same time enables the broad range of open communication
services required within modern business. Industrial control systems, on the other
hand, strive for the efficiency and reliability of a single, often fine-tuned system.
Only by giving the necessary consideration to both sides can the true objective be
achieved: a secure industrial network that supports reliable operation while also
providing business value to the larger enterprise.
To further complicate matters, there is a third audience: the compliance officer
who is mandated with meeting certain regulatory standards in order to survive an
audit with minimal penalties and/or fines. Compliance continues to drive information
security budgets, and therefore the broader scope of industrial networks must also be
narrowed on occasion to the energy industries, where (at least in the United States)
electrical energy, nuclear energy, oil, and gas are tightly regulated. Compliance
controls are discussed in this book solely within the context of implementing cyber
security controls. The recommendations given are intended to improve security and
should not be interpreted as advice concerning successful compliance management.
DIAGRAMS AND FIGURES
The network diagrams used throughout this book have been intentionally simplified
and have been designed to be as generic as possible while adequately represent -
ing industrial networks across a very wide range of industrial systems. As a result,
the diagrams will undoubtedly differ from real industrial network designs and may
exclude details specific to one particular industry while including details that are
specific to another. However, they will provide a high-level understanding of the
specific industrial network security controls being discussed.
THE SMART GRID
Although the smart grid is of major concern and interest, for the most part it is
treated as any other industrial network within this book, with specific considerations
being made only when necessary (such as when considering available attack vectors ).
As a result, there are many security considerations specific to the smart grid that are
unfortunately not included. This is partly to maintain focus on the more ubiquitous 3 How This Book Is Organized
ICS and SCADA security requirement, partly due to the relative immaturity of smart
grid security and partly due to the specialized and complex nature of these systems.
Although this means that specific measures for securing synchrophasers, meters, etc.
are not provided, the guidance and overall approach to security that is provided herein
is certainly applicable to smart grid networks. For more in-depth reading on smart
grid network security, consider Securing the Smart Grid: Next Generation Power
Grid Security by Tony Flick and Justin Morehouse (ISBN: 978-1-59749-570-7,
Syngress).
HOW THIS BOOK IS ORGANIZED
This book is divided into a total of eleven chapters, followed by three appendices
guiding the reader where to find additional information and resources about indus -
trial protocols, standards and regulations, and relevant NIST security guidelines.
An extensive glossary is also provided to accommodate the wealth of both infor -
mation security and industrial networking terms and acronyms used throughout
the book.
The chapters begin with an introduction to industrial networking, and what a
cyber attack against an industrial control systems might represent in terms of poten -
tial risks and consequences, followed by details of how industrial networks can be
assessed, secured, and monitored in order to obtain the strongest possible security,
and conclude with a detailed discussion of various compliance controls, and how
those specific controls map back to network security practices.
It is not necessary to read this book cover to cover, in order. The book is intended
to offer insight and recommendations that relate to both specific security goals as
well as the cyclical nature of the security process. That is, if faced with performing
a vulnerability assessment on an industrial control network, begin with Chapter 6;
every effort has been made to refer the reader to other relevant chapters where addi -
tional knowledge may be necessary.
Chapter 2: About Industrial Networks
In this chapter, there is a brief introduction to industrial networks as they relate to
“critical infrastructure ,” those infrastructures upon which our society, industry,
and way of life depend. The dependencies of critical infrastructures upon industrial
control systems lead naturally to a discussion of the many standards, regulations,
guidance documents, and policies that have been implemented globally to pro -
tect these systems. In addition, the chapter introduces the reader to the most basic
premises of industrial security.
Of particular note, Chapter 2 also discusses the use of terminology within the
book as it relates to the many applications of industrial networks (again, there is
also an extensive Glossary included to cover the abundance of new acronyms and
terms used in industrial control networks). 4 CHAPTER 1 Introduction
Chapter 3: Introduction to Industrial Network Security
Chapter 3 introduces industrial networks in terms of cyber security, by examining
the interrelations between “general” networking, industrial networking, and poten -
tially critical infrastructures. Chapter 3 covers the importance of securing industrial
networks, discusses the impact of a successful industrial attack, and provides exam -
ples of real incidents—including a discussion of the Advanced Persistent Threat
and the implications of cyber war.
Chapter 4: Industrial Network Protocols
This chapter focuses on industrial network protocols, including Modbus , DNP3,
OPC, ICCP , and others in both their native/original fieldbus form or in modern -
ized TCP/IP or real-time Ethernet implementations. The basics of protocol opera -
tion, frame format, and security considerations are provided for each, with security
recommendations being made where applicable.
Chapter 5: How Industrial Networks Operate
Industrial networks use specialized protocols because they perform functions that
are different than enterprise networks, with different requirements and different
security considerations. Chapter 5 discusses control system assets , network archi -
tectures, control system operations, and how control processes are managed, with
special emphasis on smart grid operations.
Chapter 6: Vulnerability and Risk Assessment
Strong security requires a proper assessment of vulnerabilities and risk, which
in turn requires that security analysts think like an attacker. Chapter 6 provides a
high-level overview of common attack methodologies, and how industrial networks
present a unique attack surface with common attack vectors to many critical areas.
Chapter 6 also discusses vulnerability assessment and patch management strategies.
Chapter 7: Establishing Secure Enclaves
A strong “defense in depth” strategy requires the isolation of functional groups into
securable “ .” Chapter 7 looks at how to separate functional groups and
where enclave boundaries should be implemented. Specifics are then provided on
how to secure both the perimeter and the interior of enclaves, including common
security products, methods, and policies that may be implemented.
Chapter 8: Exception, Anomaly, and Threat Detection
Awareness is the perquisite of action, according to the common definition of situ -
ational awareness . In this chapter, several contributing factors to obtaining situ -
ational awareness are discussed, including how to use anomaly detection, exception
reporting, and information correlation for the purposes of threat and risk detection. 5 Conclusion
Chapter 9: Monitoring Enclaves
Before situational awareness can be achieved, however, a necessary body of infor -
mation must be obtained. This chapter includes recommendations of what to moni -
tor, why, and how. Information management strategies—including log and event
collection, direct monitoring, and security information and event management
(SIEM )—are discussed, including guidance on data collection, retention, and
management.
Chapter 10: Standards and Regulations
There are many regulatory compliance standards applicable to industrial network
security, and most consist of a wide range of procedural controls that aren’t easily
resolved using information technology. There are common cyber security controls
(with often subtle but importance variations), however, which reinforce the recom -
mendations put forth in this book. Chapter 10 attempts to map those cyber security–
NERC CIP , CFATS ,
ISO /IEC 27002:2005, NRC RG 5.71, and NIST 800-82—to the security recom -
mendations made within this book, making it easier for security analysts to under -
stand the motivations of compliance officers, while compliance officers are able to
see the security concerns behind individual controls.
Chapter 11: Common Pitfalls and Mistakes
Industrial control systems are highly vulnerable, and often with high consequence.
In this chapter, some common pitfalls and mistakes are highlighted—including
errors of complacency, common misconfigurations, and deployment errors—as by
highlighting the pitfalls and mistakes, it is easier to avoid repeating those mistakes.
CONCLUSION
Writing this book has been an education, an experience, and a challenge. In the
months of research and writing, several historic moments have occurred concerning
Industrial Control Systems security, including the first ICS-targeted cyber weapon,
and one of the most sophisticated cyber attacks to date. The growing number of
attacks, new evidence of Advanced Persistent Threats, and a wave of new SCADA-
and ICS-specific vulnerabilities are just the tip of the proverbial iceberg.
Hopefully, this book will be both informative and enjoyable, and it will facili -
tate the increasingly urgent need to strengthen the security of our industrial net -
works and SCADA systems. Even though the attacks themselves will continue to
evolve, the methods provided herein should help to prepare against the inevitable
advancement of industrial network threat. This page intentionally left blank 7
About Industrial Networks
2
CHAPTER
I N F O R M AT I O N I N T H I S C H A P T E R :
l Industrial Networks and Critical Infrastructure
l Relevant Standards and Organizations
l Common Industrial Security Recommendations
l The Use of Terminology Within This Book
Before attempting to secure an industrial network, it is important to understand
what an industrial network really is. Because of the diversity of both the industrial
networks themselves as well as the markets that they serve, it can be confusing to
discuss them in general terms. In addition, the many regulatory agencies and com -
missions that have been formed to help secure different industrial networks for dif -
ferent markets each introduce their own specific nomenclatures and terminology.
Finally, the common misuse of terminology within the media further confuses the
issue of what an industrial network truly is.
INDUSTRIAL NETWORKS AND CRITICAL INFRASTRUCTURE
The world of industrial control systems, like many high-tech sectors, possesses its
own lexicon to describe the nuances of its industry. Unfortunately, the terms used
are also often interchanged and misunderstood. Industrial Control Systems are often
referred to in the media as “SCADA,” for example, which is both inaccurate and
misleading. An industrial network is most typically made up of several distinct areas,
which are simplified here as a business network or enterprise, business operations,
a supervisory network, and process and control networks (see Figure 2.1 ). SCADA,
or Supervisory Control and Data Acquisition , is just one specific piece of an
industrial network, separate from the control systems themselves, which should
be referred to as Industrial Control Systems (ICS), Distributed Control Systems
(DCS ), or Process Control Systems ( ). Each area has its own physical and log -
ical security considerations, and each has its own policies and concerns.
The book title “Industrial Network Security: Securing Critical Infrastructure
Networks for Smart Grid, SCADA, and Other Industrial Control Systems” was cho -
sen because this text discusses the security concerns of all the networks that make 8 CHAPTER 2 About Industrial Networks
up an industrial network, including the supervisory and distributed control systems,
primarily as they apply to critical infrastructure. The business Local Area Network
(LAN), the process control network, and whatever supervisory demilitarized zone
(DMZ) exists between them are all equally important. To be more specific, it dis -
cusses the cyber security of these networks. For the sake of clarity, it is assumed
that a strong security policy, security awareness, personnel, and physical security
practices are already in place, and these topics will not be addressed except for
where they might be used to strengthen specific areas of network security.
Critical Infrastructure
For the purposes of this book, the terms “Industrial Network” and “Critical
Infrastructure” are used in somewhat limited contexts. “Industrial Network” is refer -
ring to any network operating some sort of automated control system that commu -
nicates digitally over a network, and “Critical Infrastructure” is referring to critical
network infrastructure, including any network used in the direct operation of any
system upon which one of the defined “critical infrastructures” depends. Confusing?
It is, and this is perhaps one of the leading reasons that our critical infrastructures
FIGURE 2.1
Sample Industrial Automated Control System Network. 9 Industrial Networks and Critical Infrastructure
remain at risk today: many an ICS security seminar has digressed into an argument
over semantics, at the sake of any real discussion on network security practices.
Luckily, the two terms are closely related in that the defined critical infrastruc -
ture, meaning those systems listed in the Homeland Security Presidential Directive
Seven ( ), typically utilizes some sort of industrial control systems. In its own
words, “HSPD-7 establishes a national policy for Federal departments and agencies
to identify and prioritize [the] United States critical infrastructure and key resources
and to protect them from terrorist attacks.” HSPD-7 includes public safety, bulk elec -
tric energy, nuclear energy, chemical manufacturing, agricultural and pharmaceutical
manufacturing and distribution, and even aspects of banking and finance: basically,
anything whose disruption could impact a nation. 1 However, while some, such as glo -
bal banking and finance, are considered a part of our critical infrastructure, they do
not typically operate industrial control networks, and so are not addressed within this
book (although many of the security recommendations will still apply, at least at a
high level).
Utilities
Utilities—water, gas, oil, electricity, and communications—are critical infra -
structures that rely heavily on industrial networks and automated control systems.
Because the disruption of any of these systems could impact our society and our
safety, they are listed as critical by HSPD-7; because they use automated and distrib -
uted process control systems, they are clear examples of industrial networks. Of the
common utilities, electricity is often separated as requiring more extensive security.
In the United States and Canada, it is specifically regulated to standards of reliabil -
ity and cyber security. Oil and gas refining and distribution are systems that should
be treated as both a chemical/hazardous material and as a critical component of our
infrastructures. It is often regulated as a chemical facility because of these particular
qualities.
Nuclear Facilities
Nuclear facilities represent unique safety and security challenges due to their inher -
ent danger in the fueling and operation, as well as the national security implications
of the raw materials used. This makes nuclear facilities a prime target for cyber
attack, and it makes the consequences of a successful attack more severe. As such,
nuclear energy is heavily regulated in the United States by the Nuclear Regulatory
Commission (
in 1974 in an attempt to guarantee the safe operation of nuclear facilities and to
protect people and the environment. This includes regulating the use of nuclear
material including by-product, source, and special nuclear materials, as well as
nuclear power. 2
Bulk Electric
The ability to generate and distribute electricity in bulk is highly regulated.
Electrical energy generation and distribution is defined as a critical infrastructure 10 CHAPTER 2 About Industrial Networks
under HSPD-7, and is heavily regulated in North America by NERC —specifically
via the NERC Critical Infrastructure Protection (CIP) reliability standards—under
the authority of the Department of Energy, which is ultimately responsible for the
security of the production, manufacture, refining, distribution, and storage of oil,
gas, and non-nuclear power. 3
It’s important to note that energy generation and distribution are two distinct
industrial network environments, each with its own nuances and special security
requirements. Energy generation is primarily concerned with the safe manufacture of
a product (electricity), while energy distribution is concerned with the safe and bal -
anced distribution of that product. The two are also highly interconnected, obviously,
as generation facilities directly feed the power grid that distributes that energy; bulk
energy must be carefully measured and distributed upon production. For this same
reason, the trading and transfer of power between power companies is an important
facet of an electric utility’s operation.
The smart grid—an update to traditional electrical transmission and distribu -
tion systems to accommodate digital communications for metering and intelligent
delivery of electricity—is a unique facet of industrial networks that is specific to the
energy industry that raises many new security questions and concerns.
Although energy generation and distribution are not the only industrial systems
that need to be defended, they are often used as examples within this book. This is
because the North American Electric Reliability Corporation (NERC) has cre -
ated a reliability standard called “Critical Infrastructure Protection” and enforces
it heavily throughout the United States and Canada. Likewise, the NRC requires
and enforces the cyber security of nuclear power facilities. Ultimately, all other
industries rely upon energy to operate, and so the security of the energy infrastruc -
ture (and the development of the smart grid) impacts everything else, so that talk -
ing about securing industrial networks without talking about energy is practically
impossible.
Is bulk power more important than other industrial systems? That is a topic of
heavy debate. Within the context of this book, we assume that all control systems
are important, whether or not they generate or distribute energy, or whether they
are defined that way by HSPD-7 or any other directive. A speaker at the 2010 Black
Hat conference suggested that ICS security is overhyped, because these systems are
more likely to impact the production of cookies than they are to impact our national
infrastructure. 4 However, even the production of a snack food can impact many
lives: through the manipulation of its ingredients or through financial impact to the
producer and its workers, for example.
Chemical Facilities
Chemical manufacture and distribution represent specific challenges to securing an
industrial manufacturing network. Unlike the “utility” networks (electric, nuclear,
water, gas), chemical facilities need to secure their intellectual property as much
as they do their control systems and manufacturing operations. This is because the
product itself has a tangible value, both financially and as a weapon. For example, 11 Industrial Networks and Critical Infrastructure
the formula for a new pharmaceutical could be worth a large sum of money on the
black market. The disruption of the production of that pharmaceutical could be
used as a social attack against a country or nation, by impacting the ability to pro -
duce a specific vaccine or antibody. Likewise, the theft of hazardous chemicals can
be used directly as weapons or to fuel illegal chemical weapons research or manu -
facture. For this reason, chemical facilities need to also focus on securing the stor -
age and transportation of the end product.
Critical versus Noncritical Industrial Networks
The security practices recommended within this book aim for a very high standard,
and in fact go above and beyond what is recommended by many government and
regulatory groups. So which practices are really necessary, and which are exces -
sive? It depends upon the nature of the industrial system being protected. What
are the consequences of a cyber attack? The production of energy is much more
important in modern society than the production of a Frisbee. The proper manufac -
ture and distribution of electricity can directly impact our safety by providing heat
in winter or by powering our irrigation pumps during a drought. The proper manu -
facture and distribution of chemicals can mean the difference between the availabil -
ity of flu vaccines and pharmaceuticals and a direct health risk to the population.
Regardless of an ICS’s classification, however, most industrial control systems are
by their nature important, and any risk to their reliability holds industrial-scale con -
sequences. However, while not all manufacturing systems hold life-and-death conse -
quences, that doesn’t mean that they aren’t potential targets for a cyber attack. What
are the chances that an extremely sophisticated, targeted attack will actually occur?
The likelihood of an incident diminishes as the sophistication of the attack—and its
consequences—grow, as shown in Figure 2.2 . By implementing security practices to
address these uncommon and unlikely attacks, there is a greater possibility of avoid -
ing the devastating consequences that correspond to them.
Although the goal of this book is to secure any industrial network, it focuses
on Critical Infrastructure and electric energy in particular, and will reference vari -
ous standards, recommendations, and directives as appropriate. Regardless of the
nature of the control system that needs to be secured, it is important to understand
these directives, especially NERC CIP, Chemical Facility Anti-Terrorism Standards
(CFATS), Federal Information Security Management Act (FISMA), and the control
system security recommendations of National Institute of Standards and Technology
(NIST). Each has its own strengths and weaknesses, but all provide a good baseline
of best practices for industrial network security (each is explored in more detail in
Chapter 10, “Standards and Regulations”). Not surprisingly, the industrial networks
that control critical infrastructures demand the strongest controls and regulations
around security and reliability, and as such there are numerous organizations helping
to achieve just that. The Critical Infrastructure Protection Act of 2001 and HSPD-7
define what they are, while others—such as NERC CIP, CFATS, and various publi -
cations of NIST—help explain what to do. 12 CHAPTER 2 About Industrial Networks
RELEVANT STANDARDS AND ORGANIZATIONS
Many organizations are attempting to define methods of securing our industrial sys -
tems. Some are regional, some are national, and some are global. Some are public,
some are private. Some—like NERC CIP—carry heavy fines for non-compliance if
one falls under their jurisdiction. Others—such as CFATS—offer recommendations
for self-assessment and lack the ability to levy penalties for noncompliance.
Each standard is discussed briefly here and in more detail in Chapter 10,
“Standards and Regulations.” Although this book does not attempt to provide com -
pliance or audit guidelines, the various standards provide valuable insight into how
we should and should not be securing our industrial networks. When considered
as a whole, we see common requirement challenges and recommendations that can
and should be considered “best practices” for industrial network security.
Homeland Security Presidential DirectiveSeven/HSPD-7
The HSPD-7 attempts to distinguish the critical versus noncritical systems.
HSPD-7 does not include specific security recommendations, relying instead upon
other federal security recommendations such as those by the NIST on the security
of both enterprise and industrial networks, as well as the Homeland Security Risk-
Based Performance Standards used in securing chemical facilities.
Which regulations apply to your specific industrial network? Possibly several,
and possibly none. Although more information is provided in Chapter 10, “Standards
FIGURE 2.2
Likeliness versus Consequence of a Targeted Cyber Attack. 13 Relevant Standards and Organizations
and Regulations,” some of the more common regulations are summarized here in
order to help you determine which standards you should be striving to meet.
NIST Special Publications (800 Series)
NIST’s 800 series documents provide best practices and information of general
interest to information security. All 800 series documents concern information secu -
rity and should be used as references where applicable. Of particular relevance to
industrial network security is SP 800-53 (“Recommended Security Controls for
Federal Information Systems”), which defines many aspects of information secu -
rity procedures and technologies, and SP 800-82 (“Guide to Supervisory Control
and Data Acquisition [SCADA] and Industrial Control Systems Security”), which
discusses industrial control system security specifically. Although of the entire SP
800-53 is applicable to the protection of critical infrastructures, the technical aspects
defined under SP 800-53 as Access Control, Security Assessment and Authorization,
Configuration Management, Identification and Authentication, Risk Assessment,
System and Communications Protection, and System and Information Integrity are
directly applicable to industrial networks. 5
SP 800-82 (currently in draft) details control system architectures, proto -
cols, vulnerabilities, and security controls. Specific security recommendations of
SP 800-53 and SP 800-82 are addressed in more detail in Chapter 10, “Standards
and Regulations.”
-
cal infrastructure with the goal of ensuring the reliability of the bulk power system.
Compliance is mandatory for any power generation facility, and fines for noncom -
pliance can be steep. The CIP reliability standards consist of nine sections, each
with its own requirements and measures. They are Sabotage Reporting, Critical
Cyber Asset Identification, Security Management Controls, Personnel & Training,
Electronic Security Perimeter (s), Physical Security of Critical Cyber Assets,
Systems Security Management, Incident Reporting and Response Planning, and
Recovery Plans for Critical Cyber Assets.
Nuclear Regulatory Commission
The NRC is responsible for ensuring the safe use of radioactive materials for ben -
eficial civilian (nonmilitary) purposes by licensed nuclear facilities. Part of this
responsibility is the establishment of cyber security requirements and recommenda -
tions, which are defined primarily within two documents: Title 10 Code of Federal
Regulations (CFR), section 73.54 (10 CFR 73.54), and Office of Nuclear Regulatory
Research’s Regulatory Guide 5.71 (RG 5.71), which explains in detail the specific
cyber security requirements of 10 CFR 73.54. RG 5.71 provides recommendations 14 CHAPTER 2 About Industrial Networks
to nuclear agencies or “licensees” in how to secure their facilities against cyber
attack. These recommendations indicate that a licensee “shall protect digital compu -
ter and communication systems and networks associated with safety, security, emer -
gency preparedness, and any systems that support safety, security and emergency
preparedness”
integrity or confidentiality of data and/or software; deny access to systems, services,
and/or data; and prevent any activity that might adversely impact the operation of
systems, networks, and associated equipment. 7
To accomplish this, RG 5.71 makes recommendations in how to identify critical
digital assets , as well as how to implement a defense in depth strategy to mitigate
the adverse effects of a cyber attack against those critical assets, all to “ultimately
ensure that the functions of protected assets are not adversely impacted due to cyber
attacks.”
l Identification of Critical Digital Assets (C.3.1.3)
l Defense-in-Depth Protective Strategies (C.3.2)
l Security Defensive Architecture (C.3.2.1)
l Establishing Security Controls (C.3.3)
l Technical Controls (C.3.3.10), including
l Access Control (C.3.3.1.1)
l Audit and Accountability (C.3.3.1.2)
l System and Communications Protection (C.3.3.1.3)
l Identification and Authentication (C.3.3.1.4)
l System Hardening (C.3.3.1.5)
l Operational Controls (C3.3.2), including
l Media Protection (C.3.3.2.1)
l System and Information Integrity (C.3.3.2.3)
l Incident Response (C.3.3.2.6)
l Continuous Monitoring and Assessment (C.4.1)
l Vulnerability Scans and Assessments (C.4.1.3)
l Change Control (C.4.2)
l Configuration Management (C.3.3.2.9 and C.4.2.1)
In addition, Appendix B of RG 5.71 is exceptionally useful, as it provides in
depth detail on recommended security technical controls, of which the following
apply directly to network security: 10
l Access Controls (B.1), including
l Access Control Policy and Procedures (B.1.1)
l Account Management (B.1.2)
l Access Enforcement (B.1.3)
l Information Flow Enforcement (B.1.4)
l Separation of Functions (B.1.5) 15 Relevant Standards and Organizations
l Network Access Control (B.1.15)
l “Open/Insecure” Protocol Restrictions (B.1.16)
l Wireless Access Restrictions (B.1.17)
l Insecure and Rogue Connections (B.1.18)
l Proprietary Protocol Visibility (B.1.20)
l Audit and Accountability (B.2)
l Critical Digital Asset and Communications Protection (B.3), including
l Application Partitioning and Security Function Isolation (B.3.2)
l Transmission Integrity (B.3.6)
l Use of Cryptography (B.3.10)
l Session Authenticity (B.3.18)
l Confidentiality of Information at Rest (B.3.20)
l Identification and Authentication (B.4)
l Removal of Unnecessary Services and Programs (B.5.1)
l Host Intrusion Detection System (B.5.2)
For the most part, the NRC’s guidelines are consistent with NIST recommenda -
tions. The NRC classifies the criticality of an asset or system based on the risks to
operations and safety that could result from its compromise. A severity level (SL)
is assigned to a cyber asset or mechanism, and the recommendations for cyber
security vary based on the assigned SL. There are five SLs, Severity Level 0 to
Severity Level 4. One unique recommendation made by the NRC for the protection
of nuclear facilities is the use of unidirectional access to the most critical systems,
indicated by a severity level of 4—which may be accomplished using a data diode
or a physical air gap—represents one of the most stringent cyber security practices
recommended by any of the regulatory agencies mentioned within this book. The
specific recommendation to validate sessions and monitor access to proprietary pro -
tocols is also more stringent than the requirements of other regulations—both of
which are important considerations when attempting to secure industrial networks,
which often use proprietary protocols and/or specialized standard protocols that may
or may not include session authentication or validation. Unfortunately, RG 5.71 is
purely a recommendation for complying with the broader requirements provided in
10 CFR 73.54 and is not an enforceable standard at this time.
Federal Information Security Management Act
The FISMA may or may not apply to certain critical infrastructures, depending
upon their geographic location and/or their jurisdiction within the United States
federal government. However, the standards include valid and useful guidelines for
the security of critical environments, referring to and relying upon the NIST “800
series” Special Publication documents (especially SP 800-53 and SP 800-82). The
management controls of SP 800-53 are divided into 18 security categories: 11
l Access Control (AC)
l Awareness and Training (AT) 16 CHAPTER 2 About Industrial Networks
l Audit and Accountability (AU)
l Security Assessment and Authorization (CA)
l Configuration Management (CM)
l Contingency Planning (CP)
l Identification and Authentication (IA)
l Incident Response (IR)
l Maintenance (MA)
l Media Protection (MP)
l Physical and Environmental Protection (PE)
l Planning (PL)
l Personnel Security (PS)
l Risk Assessment (RA)
l System and Services Acquisition (SA)
l System and Communication Protection (SC)
l System and Information Integrity (SI)
l Program Management (PM)
While all of these controls relate to cyber security, the areas that relate most
directly to network security practices are Access Control (AC), Audit and Accountability
(AU), Configuration Management (CM), Identification and Authentication (IA),
Media Protection (MP), Risk Assessment (RA), System and Communication
Protection (SC), and System and Information Integrity (SI). 12
Chemical Facility Anti-Terrorism Standards
CFATS is a set of risk-based performance guidelines published by the Department of
Homeland Security. CFATS also consists of 18 Risk-based Performance Standards
(RBPS s), although these groups differ substantially from those defined by NIST: 13
l RBPS 1—Restrict Area Perimeter
l RBPS 2—Secure Site Assets
l RBPS 3—Screen and Control Access
l RBPS 4—Deter, Detect, and Delay
l RBPS 5—Shipping, Receipt, and Storage
l RBPS 6—Theft or Diversion
l RBPS 7—Sabotage
l RBPS 8—Cyber
l RBPS 9—Response
l RBPS 10—Monitoring
l RBPS 11—Training
l RBPS 12—Personnel Surety
l RBPS 13—Elevated Threats
l RBPS 14—Specific Threats, Vulnerabilities, or Risks
l RBPS 15—Reporting of Significant Security Incidents
l RBPS 16—Significant Security Incidents and Suspicious Activities 17 Relevant Standards and Organizations
l RBPS 17—Officials and Organization
l RBPS 18—Records
Of these, RBPS 6 (Theft or Diversion), 7 (Sabotage), 8 (Cyber), 14 (Specific
Threats, Vulnerabilities, or Risks), and 15 (Reporting of Significant Security
Incidents) concern cyber security, with RBPS 8 focusing solely on cyber security.
The CFATS RBPSs are not enforceable requirements at this time and are intended
as guidance for chemical facilities. 14
ISA-99
ISA standard 99 (ISA-99) is an industrial control security standard created by the
International Society of Automation (ISA) to protect SCADA and process control
systems. ISA-99 offers varying security recommendations based on the physi -
cal and logical location of the systems being protected as well as their importance
to the reliable operation of the system. In order to accomplish this, ISA-99 first
attempts to classify functional areas of an industrial system into specific security
levels and then provides recommendations for separating these areas into “
-
rity between zones.
Using the example of an industrial network as illustrated in Figure 2.1 , the most
public systems such as Internet or Internet-facing systems within the business LAN
would continue level 5, while the rest of the business LAN may map to level 4.
Supervisory networks (i.e., the SCADA DMZ network) would represent level 3,
and so on, with the actual “control system” (the SCADA networks, HMI sys -
tems, field devices, instrumentation and sensors) at level 0. This concept is very
illustrative of the functional isolation of services and the establishment of security
“enclaves” (see “Defense in Depth”).
ISA-99 organizes security recommendations into seven foundational requirements: 15
l FR1—Access Control (AC)
l FR2—Use Control (UC)
l FR3—Data Integrity (DI)
l FR4—Data Confidentiality (DC)
l FR5—Restrict Data Flow (RDF)
l FR6—Timely Response to an Event (TRE)
l FR7—Resource Availability (RA)
Each foundational requirement consists of multiple system requirements (SRs).
SRs that are especially useful to the protection of industrial networks (excluding
policy and procedural recommendations) include 16
l SR 1.1—IACS user identification and authentication
l SR 1.2—Account management
l SR 3.1—Communication integrity
l SR 3.2—Malicious code protection 18 CHAPTER 2 About Industrial Networks
l SR 3.3—Security functionality verification
l SR 3.4—Software and information integrity
l SR 4.3—Cryptographic key establishment and management
l SR 5.1—Information flow enforcement
l SR 5.2—Application partitioning
l SR 5.4—Boundary protection
l SR 7.1—Denial of service protection
l SR 7.2—Management of network resources
l SR 7.6—Network and security configuration settings
ISO 27002
ISO 27002 is a set of security recommendations published by the International
Standards Organization (ISO) and the International Electrotechnical Commission
(IEC), and may be referred to as ISO/IEC 27002 or ISO/IEC 27002:2005. ISO 27002
defines “Information technology—Security techniques—Code of practice for infor -
mation security management,” and is not specific to industrial network security. ISO
standards are widely used internationally and can be easily mapped to the recommen -
dations of NIST, NRC, NERC, and others, as they consist of functional guidelines
for risk assessment; security policy and management; governance; asset management;
personnel security; physical and environmental security; communications and opera -
tions management; access control; asset acquisition, development, and maintenance;
incident management; business continuity management; and compliance. 17
COMMON INDUSTRIAL SECURITY RECOMMENDATIONS
Many of the network security practices that are either required or recommended
by the aforementioned organizations are consistent between many or all of the
others. Although all recommendations should be considered, these common “best
practices” are extremely important and are the basis for many of the methods and
techniques discussed within this book. They consist of the following steps: (1) iden -
tifying what systems need to be protected, (2) separating the systems logically into
functional groups, (3) implementing a defense-in-depth strategy around each sys -
tem, and (4) controlling access into and between each group.
Identification of Critical Systems
The first step in securing any system is determining what needs to be protected, and
this is reflected heavily in NERC CIP, NRC 10 CFR 73.54, and ISA-99. Identifying
the assets that need to be secured, as well as identifying their individual importance
to the reliable operation of the overall process control system, is necessary for a
few primary reasons: it tells us what should be monitored, and how closely; it tells
us how to logically segment the network into high-level security enclaves; and it, 19 Common Industrial Security Recommendations
therefore, indicates where our point security devices (such as firewalls and intrusion
detection and prevention systems) should be placed. For North American electric
companies, it also satisfies a direct requirement of NERC CIP, and therefore can
help to minimize fines associated with noncompliance.
Identifying critical systems isn’t always easy, however. The first step is to build
a complete inventory of all connected devices. Each of these devices should be
evaluated independently. If it performs a critical function, it should be classified as
critical. If it does not, consider whether it could impact any other critical devices or
operations. Could it impact the network itself, preventing another device from inter -
acting with a critical system and therefore causing a failure? Finally, does it protect
a critical system in any way?
The NRC provides a logic map illustrating how to determine critical assets,
which is adapted to more generic asset identification in Figure 2.3 . This process
will help to separate devices into two categories:
l Critical Assets
l Noncritical Assets
However, in many larger operations this process may be over simplified. There
may be different levels of “criticality.” A general rule to follow once the basic sep -
aration of critical versus noncritical has been completed is as follows: are there
any critical assets that are not functionally related to other critical assets? If there
are, next ask if one function is more or less important than the other. Finally, if
there is both a functional separation and a difference in the criticality of the sys -
tem, consider adding a new logical “tier” to your network. Also remember that a
device could potentially be critical and also directly impact one or more other criti -
cal assets. Consider ranking the criticality of devices based on their total impact as
well. Each layer of a separation can then be used as a point of demarcation, provid -
ing additional layers of defense between each group.
FIGURE 2.3
NRC Process Diagram for Identifying Critical Cyber Assets. 18 20 CHAPTER 2 About Industrial Networks
Network Segmentation/Isolation of Systems
The separation of assets into functional groups allows specific services to be tightly
locked down and controlled, and is one of the easiest methods of reducing the attack
surface that is exposed to attackers. Simply by disallowing all unnecessary ports
and services, we also eliminate all of the vulnerabilities—known or unknown—that
could potentially allow an attacker to exploit those services.
For example, if five critical services are isolated within a single functional group
and separated from the rest of the network using a single firewall, it may be neces -
sary to allow several different traffic profiles through that firewall (see Figure 2.4 ).
If an attack is made using an exploit against web services over port 80, that attack
may compromise a variety of services including e-mail services, file transfers, and
patch/update services.
However, if each specific service is grouped functionally and separated from all
other services, as shown in Figure 2.5 —that is, all web servers are grouped together
in one group, all e-mail services in another group, etc.—the firewall can be config -
ured to disallow anything other than the desired service, preventing an e-mail server
from being exposed to a threat that exploits a weakness in HTTP.
In an industrial control system environment, this method of service segmen -
tation can be heavily utilized because there are many distinct functional groups
FIGURE 2.4
Placing All Services Behind a Common Defense Provides a Broader Attack Surface on
All Systems. 21 Common Industrial Security Recommendations
within an industrial network that should not be communicating at all outside of
established parameters. For example, protocols such as Modbus or DNP3 (discussed
in depth in Chapter 4, “Industrial Network Protocols”) are specific to SCADA and
ICS systems and should never be used within the business LAN and Internet serv -
ices such as HTTP, SMTP, FTP, and others should never be used within supervisory
or control network areas. In Figure 2.6 , it can be seen how this layered approach to
functional and topological isolation can greatly improve the defensive posture of
the network.
Note that within this book, these isolated functional groups or enclaves are often
depicted as being separated by a firewall. Although in many cases a separate fire
can vary and could include dedicated firewalls, intrusion detection and prevention
devices, application content filters, access control lists, and/or a variety of other
controls. In some cases, multiple enclaves can be supported using a single firewall
FIGURE 2.5
Separation into Functional Groups Reduces the Attack Surface to a Given System. 22 CHAPTER 2 About Industrial Networks
through the careful creation and management of policies that implicitly define
which servers can connect over a given protocol or port. This is covered in detail in
Chapter 7, “Establishing Secure Enclaves.”
CAUTION
Don’t forget to control communications in both directions through a firewall. Not all threats originate from outside. Open, outbound traffic policies can facilitate an insider attack, enable the internal spread of malware, enable outbound command and control capabilities, or allow for data leakage or information theft. 23 Common Industrial Security Recommendations
Defense in Depth
All standards organizations, regulations, and recommendations indicate that a
defense-in-depth strategy should be implemented. Although the definitions of
“defense in depth” vary somewhat, the philosophy of a layered or tiered defensive
strategy is considered a best practice. Figure 2.7 illustrates a common defense-
in-depth model, mapping logical defensive levels to common security tools and
techniques.
Interestingly, because of the segregated nature of most industrial systems,
the term “defense in depth” can and should be applied in more than one context,
including
l The layers of the Open Systems Interconnection (OSI) model, from physical
(Layer 1) to Application (Layer 7).
l Physical or Topological layers consisting of subnetworks and/or functional groups.
l Policy layers, consisting of users, roles, and privileges.
l Multiple layers of defense devices at any given demarcation point (such as
implementing a firewall and an IDS or IPS ).
FIGURE 2.7
Defense in Depth with Corresponding Protective Measures. 24 CHAPTER 2 About Industrial Networks
Access Control
Access control is one of the most difficult yet important aspects of cyber security.
By locking down services to specific users or groups of users, it becomes more dif -
ficult for an attacker to identify and exploit systems. The further we can lock down
access, the more difficult an attack becomes. Although many proven technologies
exist to enforce access control—from network access control ( ), authentica -
tion services, and others—the successful implementation of access control is dif -
ficult because of the complexity of managing users and their roles and mapping
that to the specific devices and services that relate specifically to an employee’s
operational responsibilities. As shown in Table 2.1 , the strength of access controls
increases as a user’s identity is treated with the additional context of that user’s
roles and responsibilities within a functional group.
Again, the more layers of complexity applied to the rules of user authentication
and access, the more difficult it will be to gain unauthorized access. Some examples
of advanced access control include the following:
l Only allow a user to log in to an HMI if the user has successfully badged into
the control room (user credentials combined with physical access controls)
l Only allow a user to operate a given control from a specific controller (user cre -
dentials limited within a security enclave)
l Only allow a user to authenticate during that user’s shift (user credentials com -
bined with personnel management)
TIP
Authentication based on a combination of multiple and unrelated identifiers provides the strongest access control, for example, the use of both a digital and a physical key, such as a password and a biometric scanner.
Table 2.1 Adding Context to User Authentication to Strengthen Access Control
Good Better Best
User accounts are classified by authority level User accounts are classified by functional role User accounts are classified by functional role and authority
Assets are classified in conjunction with user authority level
Assets are classified in conjunction with function or operational role
Assets are classified in conjunction with function and user authority
Operational controls can be accessed by any device based on user authority
Operational controls can be accessed by only those devices that are within a functional group
Operational controls can only be accessed by devices within a functional group by a user with appropriate authority 25 The Use of Terminology Within This Book
THE USE OF TERMINOLOGY WITHIN THIS BOOK
Terminology specific to these various organizations and requirements will be used
throughout this book. Although they may originate in a compliance mandate such
as NERC CIP, they are used in the more open context of security best practices
unless otherwise specified. Some terms that will be used extensively are routable
and non-routable networks, assets (including cyber assets, critical assets, and criti -
cal cyber assets), enclaves, and electronic security perimeters or ESPs .
Networks, Routable and Non-routable
Although many think of a “network” as a Transmission Control Protocol/Internet
Protocol (TCP/IP) network running on Ethernet, that assumption cannot be made
when talking about industrial network security. Because many areas of industrial
networks are connected using serial or bus networks, which operate via specific
protocols, we need to expand our definition to include these areas of the industrial
control systems. To make it easier to discern between the two network types, and
to align with NERC CIP terminology, the terms “routable” and “non-routable” are
used. A routable network typically means Ethernet and TCP/IP, although other routa -
ble protocols such as AppleTalk, DECnet, Novell IPX, and other legacy network -
ing protocols certainly apply. “Routable” networks also include routable variants of
SCADA and ICS protocols that have been modified to operate over TCP/IP, such as
Modbus/TCP or ICCP over TCP/IP.
A “non-routable” network refers to those serial, bus, and point-to-point com -
munication links that utilize Modbus/RTU , point-to-point ICCP, fieldbus, and other
networks. They are still networks: they interconnect devices and provide a commu -
nication path between digital devices, and in many cases are designed for remote
command and control.
Routable and non-routable networks generally interconnect at the demarcation
between the control systems and the SCADA or supervisory networks, although
in some cases (depending upon the specific industrial network protocols used) the
two networks overlap. This is illustrated in Figure 2.8 and is discussed in more
depth in Chapter 4, “Industrial Network Protocols,” and Chapter 5, “How Industrial
Networks Operate.”
are often computers, but also include network switches and routers, firewalls, print -
ers, alarm systems, Human–Machine Interfaces (HMIs), Programmable Logic
Controllers ( ( ), and the various relays,
actuators, sensors, and other devices that make up a typical control loop. As of ver -
sion 3, NERC CIP defines a “cyber asset” as any device connected via a routable
protocol, which limits the role of a cyber asset to those devices communicating on a 26 CHAPTER 2 About Industrial Networks
routable LAN. 19 A “critical cyber asset,” again as defined by NERC, is a cyber asset
whose operation can impact the bulk energy system. 20
In this book the broader definition of “asset” is used, in order to extend (as
much as possible) cyber security to the non-routable devices such as PLCs and
RTUs, which have been proven to be both targetable and vulnerable to cyber
attack during the 2010 outbreak of Stuxnet (see “examples of Industrial Network
Incidents” in Chapter 3, “Introduction to Industrial Network Security.”
-
lar to the functional “zone and conduit” model supported by ISA-99, 21 that is, the
devices, applications, and users that should be interacting with each other legiti -
mately in order to function, as illustrated in Figure 2.9 . One example is a control
loop: an HMI interfaces with a PLC which interacts with sensors, motors, valves,
etc. to perform a specific control function. The “enclave” here includes all devices
within the control loop including the PLC and HMI, and ideally the authorized
users allowed to use the HMI. Nothing outside of this group should be interacting
with anything inside of this group.
FIGURE 2.8
Routable and Non-routable Areas within an Industrial Control System. 27 The Use of Terminology Within This Book
Enclaves are an important aspect of security as they define acceptable versus
unacceptable behaviors. However, because a single asset can exist in multiple logi -
cal enclaves, the mapping and management of enclaves can become confusing. The
concept of enclaves is expanded later in Chapter 7 “Establishing Secure Enclaves”;
for now it’s enough to understand the term and how it will be used.
Electronic Security Perimeters
The outermost boundary of any closed group of assets (i.e., an “enclave”) is called
the perimeter. Again, this supports NERC CIP terminology, where “Electronic
FIGURE 2.9
Basic Security Enclaves, Separating Both Logical and Physical Functional Groups.
NOTE
In the context of this book, an enclave is not (necessarily) a physical grouping of devices: it is a logical delineation of asset communication. 28 CHAPTER 2 About Industrial Networks
Security Perimeter” or “ESP” refers to the boundary between secure and nonse -
cure enclaves. 22 The perimeter itself is nothing more than the logical “dotted line”
around an enclave that separates the closed group of assets within its boundaries
from the rest of the network. “Perimeter defenses” are the security defenses estab -
lished to police the entry into the enclave, and typically consist of a firewall and/or
an Intrusion Prevention System (IPS).
A Note on Perimeterless Security
There is much debate about the ESP within the context of NERC and much dis -
cussion about a shift toward “perimeterless” security. In a perimeterless approach,
there is no strict demarcation where all of our security products are concentrated.
The goal is to move away from the “hard outer shell” with “soft gooey center”
security practices that NERC’s mandate of an ESP unintentionally promotes.
Although future changes to NERC CIP may alter the terminology around establish -
ing perimeter defenses, it will remain important to establish and enforce bounda -
ries. This will be discussed further in Chapter 7, “Establishing Secure Enclaves.”
Understanding the basic nature of industrial networks, and examining the many reg -
ulations and recommendations put forth by NERC, NIST, NRC, ISA, the ISO/IEC,
and other organizations is the foundation of industrial network security. By evaluat -
ing an industrial network, identifying and isolating its systems into functional groups
or enclaves, and applying a structured methodology of defense in depth and strong
access control, the security of the network as a whole will be greatly improved.
ENDNOTES
3. Department of Homeland Security, Homeland security presidential directive/HSPD-7.
Roles and responsibilities of sector-specific federal agencies (18)(d). http://www.dhs
.gov/xabout/laws/gc_1214597989952.shtm ., September 2008 (cited: November 1, 2010).
4. J. Arlen, SCADA and ICS for security experts: how to avoid cyberdouchery. in: Proc.
2010 BlackHat Technical Conference, July 2010.
1. Department of Homeland Security, Homeland security presidential directive 7: critical
infrastructure identification, prioritization, and protection. http://www.dhs.gov/xabout/
laws/gc_1214597989952.shtm ., September, 2008 (cited: November 1, 2010).
2. U.S. Nuclear Regulatory Commission, The NRC: who we are and what we do. http://
www.nrc.gov/about-nrc.html . (cited: November 1, 2010).
5. National Institute of Standards and Technology, Special Publication 800-53 Revision 3.
Recommended Security Controls for Federal Information Systems and Organizations,
August 2009, Computer Security Division, Information Technology Laboratory, National
Institute of Standards and Technology, Gaithersburg, MD 20899-8930. 29 Endnotes
22. North American Electric Corporation, Standard CIP–002–3, Cyber Security, Critical
Cyber Asset Identification, North American Electric Corporation (NERC), Princeton, NJ,
December 16, 2009.
19. North American Electric Corporation, Standard CIP–002–3, Cyber Security, Critical
Cyber Asset Identification, North American Electric Corporation (NERC), Princeton, NJ,
December 16, 2009.
20. Ibid.
6. U.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide)
Cyber Security Programs for Nuclear Facilities, January 2010, U.S. Nuclear Regulatory
Commission, Washington, DC.
7. Ibid.
8. Ibid.
9. Ibid.
10. Ibid.
11. National Institute of Standards and Technology, Special Publication 800-53 Revision 3.
Recommended Security Controls for Federal Information Systems and Organizations,
August 2009, Computer Security Division, Information Technology Laboratory, National
Institute of Standards and Technology, Gaithersburg, MD.
12. Ibid.
13. Department of Homeland Security, Risk-based performance standards guidance; chemi -
cal facility anti-terrorism standards, Department of Homeland Security, Office of
Infrastructure Protection, Infrastructure Security Compliance Division, Washington, DC,
May 2009.
14. Ibid.
15. ANSI/ISA-TR99.00.01-2007, Security technologies for industrial automation and control
systems, 2007, International Society of Automation (ISA), Research Triangle Park, NC.
16. Ibid.
17. International Standards Organization, ISO/IEC 27002:2005. Information Technology—
Security Techniques—Code of Practice for Information Security Management, ISO/IEC,
Geneva, Switzerland, 2005.
21. ANSI/ISA-TR99.00.01-2007, Security technologies for industrial automation and control
systems, 2007, International Society of Automation (ISA), Research Triangle Park, NC.
18. U.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide)
Cyber Security Programs for Nuclear Facilities, U.S. Nuclear Regulatory Commission,
Washington, DC, January 2010. This page intentionally left blank 31
Introduction to Industrial
Network Security
3
CHAPTER
I N F O R M AT I O N I N T H I S C H A P T E R :
l The Importance of Securing Industrial Networks
l The Impact of Industrial Network Incidents
l Examples of Industrial Network Incidents
l APT and Cyber War
Securing an industrial network, although similar in many ways to standard enter -
prise information security, presents several unique challenges. Because industrial
systems are built for reliability and longevity, the systems and networks used are
easily outpaced by the tools employed by an attacker. An industrial control system
may be expected to operate without pause for months or even years, and the overall
life expectancy may be measured in decades. Attackers, on the contrary, have easy
access to new exploits and can employ them at any time. Security considerations
and practices have also lagged, largely for the same reason: the systems used pre -
date modern network infrastructures, and so they have always been secured physi -
cally rather than digitally.
Because of the importance of industrial networks and the potentially devastat -
ing consequences of an attack, new security methods need to be adopted. As can be
seen in real-life examples of industrial cyber sabotage (see the section “Examples
of Industrial Network Incidents”), our industrial networks are being targeted.
Furthermore, they are the target of a new threat profile that utilizes more sophisti -
cated and targeted attacks than ever before.
THE IMPORTANCE OF SECURING INDUSTRIAL NETWORKS
The need to improve the security of industrial networks cannot be overstated. Many
industrial systems are built using legacy devices, in some cases running legacy pro -
tocols that have evolved to operate in routable networks. Before the proliferation
of Internet connectivity, web-based applications, and real-time business information
systems, energy systems were built for reliability. Physical security was always a
concern, but information security was not a concern, because the control systems
were air-gapped—that is, physically separated with no common system (electronic
or otherwise) crossing that gap, as illustrated in Figure 3.1 . 32 CHAPTER 3 Introduction to Industrial Network Security
Ideally, the air gap would still exist, and it would still apply to digital commu -
nication, but in reality it does not. As the business operations of industrial networks
evolved, the need for real-time information sharing evolved as well. Because the
information required originated from across the air gap, a means to bypass the
gap needed to be found. Typically, a firewall would be used, blocking all traffic
except what was absolutely necessary in order to improve the efficiency of business
operations.
The problem is that—regardless of how justified or well intended the action—
the air gap no longer exists, as seen in Figure 3.2 . There is now a path into critical
systems, and any path that exists can be found and exploited.
Security consultants at Red Tiger Security presented research in 2010 that
clearly indicates the current state of security in industrial networks. Penetration
tests were performed on approximately 100 North American electric power genera -
tion facilities, resulting in more than 38,000 security warning and vulnerabilities. 1
Red Tiger was then contracted by the Department of Homeland Security (DHS) to
analyze the data in search of trends that could be used to help identify common
attack vectors and, ultimately, to help improve the security of these critical systems
against cyber attack.
FIGURE 3.1
Air Gap Separation. 33 The Importance of Securing Industrial Networks
The results were presented at the 2010 BlackHat conference and implied a
security climate that was lagging behind other industries. The average number of
days between the time when the vulnerability was disclosed publicly and the time
when the vulnerability was discovered in a control system was 331 days: almost an
entire year. Worse still, there were cases of vulnerabilities that were over 1100 days
old, nearly 3 years past their respective “zero-day.”
allow hackers’ and cyber criminals’ entry into our control networks. A vulnerabil -
ity that has been disclosed for almost a year has almost certainly been made read -
ily available within open source penetration testing utilities such as Metasploit and
Backtrack, making exploitation of those vulnerabilities fairly easy and available to
a wide audience.
It should not be a surprise that there are well-known vulnerabilities within control
systems. Control systems are by design very difficult to patch. By intentionally limit -
ing (or even better, eliminating) access to outside networks and the Internet, simply
obtaining patches can be difficult. Because reliability is paramount, actually applying
patches once they are obtained can also be difficult and restricted to planned mainte -
nance windows. The result is that there are almost always going to be unpatched vul -
nerabilities, although reducing the window from an average of 331 days to a weekly
or even monthly maintenance window would be a huge improvement.
FIGURE 3.2
The Reality of the Air Gap. 34 CHAPTER 3 Introduction to Industrial Network Security
THE IMPACT OF INDUSTRIAL NETWORK INCIDENTS
Industrial networks are responsible for process and manufacturing operations of
almost every scale, and as a result the successful penetration of a control system
network can be used to directly impact those processes. Consequences could poten -
tially range from relatively benign disruptions, such as the disruption of the opera -
tion (taking a facility offline), the alteration of an operational process (changing the
formula of a chemical process or recipe), all the way to deliberate acts of sabotage
that are intended to cause harm. For example, manipulating the feedback loop of
certain processes could cause pressure within a boiler to build beyond safe operat -
ing parameters, as shown in Figure 3.3 . Cyber sabotage could result in injury or
loss of life, including the loss of critical services (blackouts, unavailability of vac -
cines, etc.) or even catastrophic explosions.
Safety Controls
To avoid catastrophic failures, most industrial networks employ automated safety
systems. However, many of these safety controls employ the same messaging and
control protocols used by the industrial control network’s operational processes, and
in some cases, such as certain fieldbus implementations, the safety systems are sup -
ported directly within the same communications protocols as the operational con -
trols, on the same physical media (see Chapter 4, “Industrial Network Protocols,” for
details and security concerns of industrial control protocols).
FIGURE 3.3
Disruption of a Control Process Can Cause Catastrophic Failure(s). 35 The Impact of Industrial Network Incidents
Although safety systems are extremely important, they have also been used to
downplay the need for heightened security of industrial networks. However, research
has shown that real consequences can occur in modeled systems. Simulations per -
formed by the Sandia National Laboratories showed that simple Man-in-the-Middle
(MITM) attacks could be used to change values in a control system and that a
modest-scale attack on a larger bulk electric system using targeted malware (in this
scenario, targeting specific control system front end processors) was able to cause
significant loss of generation. 3
The European research team VIKING (Vital Infrastructure, Networks,
Information and Control Systems Management) is currently investigating threats of
a different sort. The Automatic Generation Control (AGC) of electric utilities oper -
ates in an entirely closed loop—that is, the control process completes entirely within
the logic of the SCADA system, without human intervention or control. Rather than
breaching a control system through the manipulation of an HMI, VIKING’s research
attempts to investigate whether the manipulation of input data could alter the normal
control loop functions, ultimately causing a disturbance. 4
TIP
When establishing a cyber security plan, think of security and safety as two entirely sepa - rate entities. Do not assume that security leads to safety or that safety leads to security. If an automated safety control is compromised by a cyber attack (or otherwise disrupted), the necessity of having a strong digital defense against the manipulation of operations becomes even more important. Likewise, a successful safety policy should not rely on the security of the networks used. By planning for both safety and security controls that oper - ate independently of one another, both systems will be inherently more reliable.
Consequences of a Successful Cyber Incident
A successful cyber attack on a control system can either
l delay, block, or alter the intended process, that is, alter the amount of energy
produced at an electric generation facility.
l delay, block, or alter information related to a process, thereby preventing a bulk
energy provider from obtaining production metrics that are used in energy trad -
ing or other business operations.
The end result could be penalties for regulatory non-compliance or the finan -
cial impact of lost production hours due to misinformation or denial of service. An
incident could impact the control system in almost any way, from taking a facility
offline, disabling or altering safeguards, and even causing life-threatening incidents
within the plant—up to and including the release or theft of hazardous materials
or direct threats to national security. 5 The possible damages resulting from a cyber
incident vary depending upon the type of incident, as shown in Table 3.1 . 36 CHAPTER 3 Introduction to Industrial Network Security
EXAMPLES OF INDUSTRIAL NETWORK INCIDENTS
Over the past decade, there have been numerous incidents, outages, and other fail -
ures that have been identified as the result of a cyber incident. In 2000, a disgrun -
tled man in Australia who was rejected for a government job was accused of using a
radio transmitter to alter electronic data within a sewerage pumping station, causing
the release of over two hundred thousand gallons of raw sewage into nearby rivers. 6
In 2007, there was the Aurora Project: a controlled experiment by the Idaho
National Laboratories (INL), which successfully demonstrated that a controller
could be destroyed via a cyber attack. The vulnerability allowed hackers—which
in this case were white-hat security researchers at the INL—to successfully open
Table 3.1 The Potential Impact of Successful Cyber Attacks
Incident Type Potential Impact
Change in a system, operating system, or application configuration Introduction of command and control channels into otherwise secure system
Suppression of alarms and reports to hide malicious activity
Alteration of expected behavior to produce unwanted and unpredictable results
Change in programmable logic in PLCs, RTUs, or other controllers Damage to equipment and/or facilities
Malfunction of the process (shutdown)
Disabling control over a process
Misinformation reported to operators Causing inappropriate actions in response to misinformation that could result in a change in programmable logic
Hiding or obfuscating malicious activity, including the incident itself or injected code (i.e., a rootkit)
Tampering with safety systems or other controls Preventing expected operations, fail safes, and other safeguards with potentially damaging consequences
Malicious software (malware) infection May initiate additional incident scenarios
May impact production, or force assets to be taken offline for forensic analysis, cleaning, and/or replacement
May open assets up to further attacks, information theft, alteration, or infection
Information theft Sensitive information such as a recipe or chemical formula are stolen
Information alteration Sensitive information such as a recipe or chemical formula is altered in order to adversely affect the manufactured product 37 Examples of Industrial Network Incidents
and close breakers on a diesel generator out of synch, causing an explosive failure.
In September 2007, CNN reported on the experiment, bringing the security of our
power infrastructure into the popular media. 7
The Aurora vulnerability remains a concern today. Although the North American
Electric Reliability Corporation (NERC) first issued an alert on Aurora a few months
before CNN’s report in June 2007, it has since provided additional alerts, as recent
as an October 2010 alert that provides clear mitigation strategies for dealing with the
vulnerability. 8
In 2008, the agent.btz worm began infecting U.S. military machines and was
reportedly carried into CENTCOM’s classified network on a USB thumb drive
later that year. Although the CENTCOM breach, reported by CBS’ 60 Minutes in
November 2009, was widely publicized, the specifics are difficult to ascertain and
the damages and intentions remain highly speculative. 9
Not to be confused with the Aurora Project is another recent attack called
Operation Aurora that hit Google and others in late 2009 and put the spotlight on the
sophisticated new arsenal of cyber war. Operation Aurora used a zero-day exploit
in Internet Explorer to deliver a payload designed to exfiltrate protected intellec -
tual property. Operation Aurora changed the threat landscape from denial of service
attacks and malware designed to damage or disable networks to targeted attacks
designed to operate without disruption, to remain stealthy, and to steal informa -
tion undetected. Aurora consisted of multiple individual pieces of malware, which
combined to establish a hidden presence on a host and then communicate over a
sophisticated command and control (C2) channel that employed a custom, encrypted
protocol that mimicked common HTTPS traffic on port 443 encrypted via Secure
Sockets Layer (SSL). 10 Although CENTCOM and Operation Aurora did not tar -
get industrial networks specifically, they exemplifed the evolving nature of threats.
In other words, Aurora demonstrated the existence of the “Advanced Persistent
Threats” ( ), just as a more recent worm demonstrated the existence of targeted
cyber weapons and the machinations of cyber war.
This later worm, of course, is Stuxnet: the new weapon of cyber war, which
began to infect industrial control systems in 2010. Any speculation over the possi -
bility of a targeted cyber attack against an industrial network has been overruled by
this extremely complex and intelligent collection of malware. Stuxnet is a tactical
nuclear missile in the cyber war, and it was not a shot across the bow: it hit its mark
and left behind the proof that extremely complex and sophisticated attacks can and
do target industrial networks. The worst-case scenario has now been realized: indus -
trial vulnerabilities have been targeted and exploited by an APT.
Although Stuxnet was first encountered in June 2009, widespread discussions
about it did not occur until the summer of 2010, after an Industrial Control Systems
Cyber Emergency Response Team (ICS-CERT) advisory was issued. 11 Stuxnet
uses four zero-days in total to infect and spread, looking for SIMATIC WinCC and
PCS 7 programs from Siemens, and then using default SQL account credentials to
infect connected Programmable Logic Controllers (PLCs) by injecting a rootkit via
the Siemens fieldbus protocol, Profibus . Stuxnet then looks for automation devices 38 CHAPTER 3 Introduction to Industrial Network Security
using a frequency converter that controls the speed of a motor. If it sees a controller
operating within a range of 800–1200 Hz, it attempts to sabotage the operation. 12
Although little was known at first, Siemens effectively responded to the issue,
quickly issuing a security advisory, as well as a tool for the detection and removal
of Stuxnet. Stuxnet drew the attention of the mass media through the fall of 2010
for being the first threat of its kind—a sophisticated and blended threat that actively
targets SCADA systems—and it immediately raised the industry’s awareness of
advanced threats, and illustrated exactly why industrial networks need to dramati -
cally improve their security measures.
Dissecting Stuxnet
Stuxnet is very complex, as can be seen in Figure 3.4 . It was used to deliver a pay -
load targeting a specific control system. It is the first industrial control system root -
kit. It can self-update even when cut off from C2 (which is necessary should it find
its way into a truly air-gapped system). It is able to inject code into the ladder logic
of PLCs, and at that point alter the operations of the PLC as well as hide itself by
reporting false information back to the HMI. It adapts to its environment. It uses
system-level, hard-coded authentication credentials that were not publicly disclosed.
It signed itself with legitimate certificates manufactured using stolen keys. There is
no doubt about it at this time: Stuxnet is an advanced new weapon in the cyber war.
Set SA CL
Error
Equal
Chec k CFG
Regk ey NTVDM Trace = 19790509
CFG OK
Date OK
Vista or higher XP or less
Not set Pastdeadline Date < 06/24/2012
Chec k OS
Set DA CL
Create global mute x
Create .pnf &.cfg files
Date < 06/24/2012
Files OK Decr ypt & load self from disk. Call expor t 6 – get version
Compare r unning version number andversion on disk
Decr ypt resource 201 & 242 & wr ite to disk
Set file times
Create rootkit ser vice regk eys
Exit
Injectin Step7 &call e xpor t 32
Create global mute xes
Inject in ser vices , call expor t 32 Inject in Step7 & call e xpor t 32
Mrxnet sys Mrxcls sys
oem 7a.pnf
Version OK
Rootkit files
Infects remov able drives
Hidesmaliciousfiles
InfectsStep7projects
FIGURE 3.4
Stuxnet’s Infection Processes. 13
Courtesy of Symantec. 39 Examples of Industrial Network Incidents
What It Does
The full extent of what Stuxnet is capable of doing is not known at the time of this
writing. What we do know is that Stuxnet does the following: 14
l Infects Windows systems using a variety of zero-day exploits and stolen certifi -
cates, and installing a Windows rootkit on compatible machines.
l Attempts to bypass behavior-blocking and host intrusion protection based tech -
nologies that monitor LoadLibrary calls by using special processes to load any
required DLLs, including injection into preexisting trusted processes.
l Typically infects by injecting the entire DLL into another process and only
exports additional DLLs as needed.
l Checks to make sure that its host is running a compatible version of Windows,
whether or not it is already infected, and checks for installed Anti-Virus before
attempting to inject its initial payload.
l Spreads laterally through infected networks, using removable media, network
connections, and/or Step7 project files.
l Looks for target industrial systems (Siemens WinCC SCADA). When found, it
uses hard-coded SQL authentication within the system to inject code into the
database, infecting the system in order to gain access to target PLCs.
l Injects code blocks into the target PLCs that can interrupt processes, inject traf -
fic on to the Profibus, and modify the PLC output bits, effectively establishing
itself as a hidden rootkit that can inject commands to the target PLCs.
l Uses infected PLCs to watch for specific behaviors by monitoring Profibus
(The industrial network protocol used by Siemens. See Chapter 4, “Industrial
Network Protocols,” for more information on Profibus).
l If certain frequency controller settings are found, Stuxnet will throttle the fre -
quency settings from 1410 to 2 Hz, in a cycle.
l It includes the capabilities to remove itself from incompatible systems, lie dor -
mant, reinfect cleaned systems, and communicate peer to peer in order to self-
update within infected networks.
What we do not know at this point is what the full extent of damage could be
from the malicious code that is inserted within the PLC. Subtle changes in set
points over time could go unnoticed that could cause failures down the line, use
the PLC logic to extrude additional details of the control system (such as command
lists), or just about anything. Because Stuxnet has exhibited the capability to hide
itself and lie dormant, the end goal is still a mystery.
Lessons Learned
Because Stuxnet is such a sophisticated piece of malware, there is a lot that we
can learn from dissecting it and analyzing its behavior. How did we detect Stuxnet?
Largely because it was so widespread. Had it been deployed more tactically, it
might have gone unnoticed: altering PLC logic and then removing itself from the
WinCC hosts that were used to inject those PLCs. How will we detect the next
one? The truth is that we may not, and the reason is simple: our “barrier-based” 40 CHAPTER 3 Introduction to Industrial Network Security
methodologies do not work against cyber attacks that are this well researched and
funded. They are delivered via zero-days, which means we do not detect them
until they have been deployed, and they infect areas of the control system that are
difficult to monitor.
So what do we do? We learn from Stuxnet and change our perception and atti -
tude toward industrial network security (see Table 3.2 ). We adopt a new “need to
know” mentality of control system communication. If something is not explicitly
defined, approved, and allowed to communicate, it is denied. This requires under -
standing how control system communications work, establishing that “need to
know” in the form of well-defined security enclaves, establishing policies and base -
lines around those enclaves that can be interpreted by automated security software,
and whitelisting everything.
It can be seen in Table 3.2 that additional security measures need to be con -
sidered in order to address new “Stuxnet-class” threats that go beyond the require -
ments of compliance mandates and current best-practice recommendations. New
measures include Layer 7 application session monitoring to discover zero-day
threats and to detect covert malware communications. They also include more
clearly defined security policies to be used in the adoption of policy-based user,
application, and network whitelisting to control behavior in and between enclaves
(see Chapter 7, “Establishing Secure Enclaves”).
Table 3.2 Lessons Learned from Stuxnet
Previous Beliefs Lessons Learned from Stuxnet
Control systems can be effectively isolated from other networks, eliminating risk of a cyber incident
Control systems are still subject to human nature: a strong perimeter defense can be bypassed by a curious operator, a USB drive, and poor security awareness
PLCs and RTUs that do not run modern operating systems lack the necessary attack surface to make them vulnerable
PLCs can and have been targeted and infected by malware
Highly specialized devices benefit from “security through obscurity.” Because industrial control systems are not readily available, it is impossible to effectively engineer an attack against them
The motivation, intent, and resources are all available to successfully engineer a highly specialized attack against an industrial control system
Firewalls and Intrusion Detection and Prevention system (IDS/IPS) are sufficient to protect a control system network from attack
The use of multiple zero-day vulnerabilities to deploy a targeted attack indicates that “blacklist ” point defenses, which compare traffic to definitions that indicate “bad” code are no longer sufficient, and “whitelist” defenses should be considered as a catchall defense against unknown exploits 41 APT and Cyber War
TIP
Before Stuxnet, the axiom “to stop a hacker, you need to think like a hacker” was often used, meaning that in order to successfully defend against a cyber attack you need to think in terms of someone trying to penetrate your network. This philosophy still has merit, the only difference being that now the “hacker” can be thought of as having a much greater knowledge of control systems, as well as significantly more resources and motivation. In the post-Stuxnet world, imagine that you are building a digital bunker in the cyber war, rather than simply defending a network, and aim for the best possible defenses against the worst possible attack.
Night Dragon
In February 2011, McAfee announced the discovery of a series of coordinated
attacks against oil, energy, and petrochemical companies. The attacks, which origi -
nated primarily in China, were believed to have originated in 2009, operating con -
tinuously and covertly for the purpose of information extraction, 15 as is indicative
of an APT.
Night Dragon is further evidence of how an outside attacker can (and will) infil -
trate critical systems. Although the attack did not result in sabotage, as was the case
with Stuxnet, it did involve the theft of sensitive information. The intended use of
this information is unknown at this time. The information that was stolen could be
used for almost anything, and for a variety of motives. It began with SQL injec -
tions against corporate web servers, which were then used to access intranet serv -
ers. Using standard tools, attackers gained additional usernames and passwords to
enable further infiltration to internal desktop PCs and servers. Night Dragon estab -
lished command and control servers as well as Remote Administration Toolkits
(RATs), primarily to extract e-mail archives from executive accounts. 16 Although
it is important to note that the industrial control systems of the target companies
were not affected, important information could have been obtained regarding the
design and operation of those systems, which could be used in a later, more tar -
geted attack. As with any APT, Night Dragon is surrounded with uncertainty and
supposition. After all, APT is an act of cyber espionage: one that may or may not
develop into a more targeted cyber war.
APT AND CYBER WAR
The terms APT and cyber war are often used interchangeably, and they can be
related, but they differ enough in their intent to justify distinct classifications of
modern, sophisticated network threats.
Although both are of concern to industrial networks, it is important to under -
stand their differences and intentions, so that they can be better addressed. It is also
important to understand that both are types of threat behaviors that consist of vari -
ous exploits and are not specific exploits or pieces of malware themselves. That is, 42 CHAPTER 3 Introduction to Industrial Network Security
“APT” classifies a group of exploits (delivery) to infect a network with malicious
code (the payload) that is designed to accomplish a specific goal (information theft).
Cyber war similarly classifies a threat that can include distinct delivery mechanisms
to deliver payloads of various intents. 17 Although both can utilize similar techniques,
exploits, and even common code, the differences between APT and cyber war at a
higher level distinguish one from another, as can be seen in Table 3.3 .
Just as APT and cyber war differ in intent, they can also differ in their targets,
as seen in Table 3.4 . Again, the methods used to steal intellectual property for profit
Table 3.3 Distinctions between APT and Cyber War
APT Qualities Cyber War Qualities
Often uses simple exploits for initial infection Uses more sophisticated vectors for initial infection
Designed to avoid detection over long periods of time Designed to avoid detection over long periods of time
Designed to communicate information back to the attacker using covert command and control (C2)
Designed to operate in isolation, not dependent upon remote command and control (C2)
Mechanisms for persistent operation even if detected Mechanisms for persistent operation or reinfection if detected
Not intended to impact or disrupt network operations Possible intentions include network disruption
Table 3.4 Information Targets of APT and Cyber War
APT Targets Cyber War Targets
Intellectual Property
Application code Certificates and authority
Application design Control protocols
Protocols Functional diagrams
Patents PCS command codes
Industrial Designs
Product schematics Control system designs and schematics
Engineering designs and drawings Safety controls
Research PCS weaknesses
Chemicals and Formulas
Pharmaceutical formulas Pharmaceutical formulas
Chemical equations Pharmaceutical safety and allergy information
Chemical compounds Chemical hazards and controls 43 APT and Cyber War
and the methods used to steal intellectual property to sabotage an industrial sys -
tem can be the same. However, by determining the target of attack, insight into
the nature of the attack can be inferred. The difference is a subtle one and is made
here in an attempt to highlight the level of severity and sophistication that should
be considered when securing industrial networks. That is, blended attacks designed
to be persistent and undetected represent the APT, while these same blended and
stealthy attacks can be weaponized and used for cyber sabotage. APT can be used
to obtain information that is later used to construct new zero-day exploits. APT can
also be used to obtain information necessary to design a targeted payload—such as
the one used by Stuxnet—that can be delivered using those exploits. In other words,
the methods, intentions, and impact of cyber war should be treated as even more
sophisticated than the APT.
The Advanced Persistent Threat
The Advanced Persistent Threat, or APT, has earned broad media attention in recent
years. The Aurora Project and Stuxnet’s high publicity increased awareness of new
threat behaviors both within and outside of the information security communities:
Incident researchers such as Exida ( ), Lofty Perch (
), and Red Tiger Security ( )
specialize in the incident response of APT; organizations such as RISI (Repository
of Industrial Security Incidents; http://www.securityincidents.org ) have been devel -
oped to catalogue incident behavior; and regulatory and CERT organizations have
issued warnings for APTs, including an NERC alert issued by the North American
Electric Reliability Corporation for both Aurora and Stuxnet, requiring direct action
from its member electric utilities, with clear penalties for noncompliance. 18
With all of this attention, a lot has been determined about how APTs func -
tion. One differentiator of an APT is a shift from broad, untargeted attacks to more
directed attacks that focus on determining specifics about its target network. APTs
spread and learn, and exfiltrate information through covert communications chan -
nels. Often, APT relies upon outside C2, although in some cases such as Stuxnet,
APT threats are capable of operating in isolation. 19
Another differentiator of APT from normal malware or hack attempts is an
attempt to remain hidden and to proliferate within a network, leading to the persist -
ence of the threat. This typically includes a tiered infection model, where increas -
ingly sophisticated methods of covert communication are established. The most
basic will operate in an attempt to obtain information from the target, whereas
one or more increasingly sophisticated mechanisms will remain dormant. This
tiered model increases the persistence of the threat, where the more difficult to
detect infections only awaken after the removal of the initial APT. In this way,
“cleaned” machines can remain infected. This is one reason why it is important
to thoroughly investigate an APT before attempting disinfection, as the initially
detected threat may be easier to deal with, while higher-level programs remain
dormant. 20 44 CHAPTER 3 Introduction to Industrial Network Security
The end result of APT’s relentless, layered approach is the deliberate exfiltration
of data. Proprietary information can achieve anything from increased competitive -
ness in manufacturing and design (making the data valuable on the black market),
to direct financial benefit achieved through the theft of financial resources and
records. Highly classified information may also be valuable for the development of
further, more sophisticated APTs, or even weaponized threats for use in cyber sabo -
tage and cyber warfare.
Common APT Methods
The methods used by APT are diverse. Within industrial networks, incident data has
been analyzed, and specific attacker profiles have been identified. The attacks them -
selves tend to be fairly straightforward, using Open Source Intelligence (OSINT) to
facilitate social engineering, targeted spear phishing (customized e-mails designed
to trick readers into clicking on a link, opening an attachment, or otherwise trig -
gering malware), malicious attachments, removable media such as USB drives,
and malicious websites as initial infection vectors. 21 APT payloads (the malware
itself) range from freely available kits such as Webattacker and torrents, to com -
mercial malware such as Zeus (ZBOT), Ghostnet (Ghostrat), Mumba (Zeus v3),
and Mariposa. Malware delivery is typically obfuscated to avoid detection by Anti-
Virus and other detection mechanisms. 22
Once a network is infected, APT strives to operate covertly and may attempt
to deactivate or circumvent Anti-Malware software, establish backdoor channels,
or open holes in firewalls. 23 Stuxnet, for example, attempts to avoid discovery by
bypassing host intrusion detection and also by removing itself from systems that are
incompatible with its payload. 24
Because the techniques used are for the most part common infection vectors and
known malware, what is so “advanced” about the APT? One area where APT is
often very sophisticated is in the knowledge of its target—known information about
the target and the people associated with that target. For example, highly effective
spear phishing may utilize knowledge of the target corporation’s organization struc -
ture (e.g., a mass e-mail that masquerades as a legitimate e-mail from an executive
within the company), or of the local habits of employees (e.g., a mass e-mail prom -
ising discounted lunch coupons from a local eatery). 25
Cyber War
Unlike APT, where the initial infections are typically from focused yet simple
exploits such as spear phishing (the “advanced” moniker comes from the behav -
ior of the threat after infection), the threats associated with cyber war trend toward
more sophisticated delivery mechanisms and payloads. 26 Stuxnet utilized multi -
ple zero-day exploits for infection, for example. The development of one zero-day
requires resources: the financial resources to purchase commercial malware or the
intellectual resources with which to develop new malware. Stuxnet raised a high 45 APT and Cyber War
degree of speculation about its source and its intent at least partly due to the level
of resources required to deliver the worm through so many zero-days. Stuxnet
also used “insider intelligence” to focus on its target control system, which again
implied that the creators of Stuxnet had significant resources: they either had access
to an industrial control system with which to develop and test their malware, or
they had enough knowledge about how such a control system was built that they
were able to develop it in a simulated environment.
That is, the developers of Stuxnet could have used stolen intellectual property—
which is the primary target of the Advanced Persistent Threat—to develop a more
weaponized piece of malware . In other words, APT is a logical precursor to cyber
war. In the case of Stuxnet, it is pure speculation: at the time of this writing, the
creators of Stuxnet are unknown, as is their intent.
Two important inferences can be made by comparing APT and cyber war -
fare. The first is that cyber warfare is higher in sophistication and in consequence,
mostly due to available resources of the attacker and the ultimate goal of destruc -
tion versus profit. The second is that in many industrial networks, there is less
profit available to a cyber attacker than from others. If the industrial network you
are defending is largely responsible for commercial manufacturing, signs of an APT
are likely evidence of attempts at intellectual theft. If the industrial network you are
defending is critical and could potentially impact lives, signs of an APT could mean
something larger, and extra caution should be taken when investigating and mitigat -
ing these attacks.
Emerging Trends in APT and Cyber War
Through the analysis of known cyber incidents, several trends can be determined in
how APT and cyber attacks are being performed. These include, but are not limited
to, a shift in the initial infection vectors and the qualities of the malware used, its
behavior, and how it infects and spreads.
Although threats have been trending “up the stack” for some time, where
exploits are moving away from network-layer and protocol-layer vulnerabilities
and more toward application-specific exploits, even more recent trends show signs
that these applications are shifting away from the exploitation of Microsoft soft -
ware products toward the almost ubiquitously deployed Adobe Portable Document
Format (PDF) and its associated software products.
Web-based applications are also used heavily both for infections and for C2.
The use of social networks such as Twitter, Facebook, Google groups, and other
cloud services is ideal for both because they are widely used, highly accessible, and
difficult to monitor. Many companies actually embrace social networking for mar -
keting and sales purposes, often to the extent that these services are allowed open
access through corporate firewalls.
The malware itself, of course, is also evolving. There is growing evidence
among incident responders and forensics teams of deterministic malware and even 46 CHAPTER 3 Introduction to Industrial Network Security
the emergence of mutating bots. Stuxnet, again, is a good example: it contains
robust logic and will operate differently depending upon its environment. It will
spread, attempt to inject PLC code, communicate via C2, lie dormant, or awaken
depending upon changes to its environment.
Evolving Vulnerabilities: The Adobe Exploits
Adobe Postscript Document Format (PDF) exploits are an example of the shifting
attack paradigm from lower-level protocol and OS exploits to the manipulation of
application contents. At a very high level, the exploits utilize PDFs’ ability to call
and execute code to execute malicious code: either by calling a malicious website
or by injecting the code directly within the PDF file. It works like this:
l An e-mail contains a compelling message, a properly targeted spear-phishing
message. There is a .pdf attachment.
l This PDF uses a feature, specified in the PDF format, known as a “Launch
action.” Security researcher Didier Stevens successfully demonstrated that
Launch actions can be exploited and can be used to run an executable embedded
within the PDF file itself. 27
l The malicious PDF also contains an embedded file named Discount_at_Pizza_
Barn_Today_Only.pdf, which has been compressed inside the PDF file. This
attachment is actually an executable file, and if the PDF is opened and the
attachment is run, it will execute.
l The PDF uses the JavaScript function exportDataObject to save a copy of the
attachment to the user’s PC.
l When this PDF is opened in Adobe Reader (JavaScript must be enabled), the
exportDataObject function causes a dialog box to be displayed asking the user
to “Specify a file to extract to.” The default file is the name of the attachment,
Discount_at_Pizza_Barn_Today_Only.pdf. The exploit requires that the users’
naïveté and/or their confusion will cause them to save the file.
l Once the exportDataOject function has completed, the Launch action is run.
The Launch action is used to execute the Windows command interpreter (cmd
.exe), which searches for the previously saved executable attachment Discount_
at_Pizza_Barn_Today_Only.pdf and attempts to execute it.
l A dialogue box will warn users that the command will run only if the user clicks
“Open.”
28
Although it does require user interaction, PDF files are extremely common, and
when combined with a quality spear-phishing attempt, this attack can be very
effective.
Another researcher chose to infect the benign PDF with another /Launch hack
that redirected a user to a website, but noted that it could have just as easily been an
exploit pack and/or embedded Trojan binary. The dialogue box used to warn users
can also be modified, increasing the likeliness that even a normally cautious user
will execute the file. 29 47 APT and Cyber War
Antisocial Networks: A New Playground for Malware
Social networking sites are increasingly popular, and they represent a serious risk
against industrial networks. How can something as benign as Facebook or Twitter
be a threat to an industrial network? By design, social networking sites make it easy
to find and communicate with people, and people are subject to social engineering
exploitation just as networks are subject to protocol and application exploits.
At the most basic level, they are a source of gathering personal information
and end user’s trust that can be exploited either directly or indirectly. At a more
sophisticated level, social networks can be used actively by malware as a C2 chan -
nel. Fake accounts posing as “trusted” coworkers can lead to even more information
sharing, or to trick the user into clicking on a link that will take them to a malicious
website that will infect the user’s laptop with malware. That malware could mine
even further information, or it could be walked into a “secure” facility to impact an
industrial network directly.
Although no direct evidence links the rise in web-based malware and social
networking adoption, the correlation is strong enough that any good security
plan should accommodate social networking, especially in industrial networks.
According to Cisco, “Companies in the Pharmaceutical and Chemical vertical were
the most at risk for web-based malware encounters, experiencing a heightened risk
rating of 543 percent in 2Q10, up from 400 percent in 1Q10. Other higher risk ver -
ticals in 2Q10 included Energy, Oil, and Gas (446 percent), Education (157 per -
cent), Government (148 percent), and Transportation and Shipping (146 percent).”
by more sophisticated attackers to formulate targeted spear-phishing campaigns,
such as the “pizza delivery” exercise. Through no direct fault of the social network
operators (most have adequate privacy controls in place), users may post personal
information about where they work, what their shift is, who their boss is, and other
details that can be used to engineer a social exploitation. Spear phishing is already a
proven tactic; combined with the additional trust associated with social networking
communities, it is easier and even more effective.
TIP
Security awareness training is an important part of building a strong security plan, but it can also be used to assess current defenses. Conduct this simple experiment to both increase awareness of spear phishing and gauge the effectiveness of existing network security and monitoring capabilities:
1. Create a website using a free hosting service that displays a security awareness banner.
2. For this exercise, create a Gmail account using the name (modified if necessary) of a group manager, HR director, or the CEO of your company (again, disclosing this activ - ity to that individual in advance and obtaining necessary permissions). Assume the role of an attacker, with no inside knowledge of the company: look for executives who are quoted in press releases, or listed on other public documents. Alternately, use the Social Engineering Toolkit (SET), a tool designed to “perform advanced attacks against
the human element,” to perform a more thorough social engineering penetration test. 31 48 CHAPTER 3 Introduction to Industrial Network Security
3. Again, play the part of the attacker and use either SET or outside means such as Jigsaw.com or other business intelligence websites to build a list of e-mail addresses within the company. 4. Send an e-mail to the group from the fake “executive” account, informing recipients to please read the attached article in preparation for an upcoming meeting. 5. Perform the same experiment on a different group, using an e-mail address originating from a peer (again, obtain necessary permissions). This time, attempt to locate a pizza
restaurant local to your corporate offices, using Google map searches or similar means, and send an e-mail with a link to an online coupon for buy-one-get-one-free pizza.
Track your results to see how many people clicked through to the offered URL. Did anyone validate the “from” in the e-mail, reply to it, or question it in any way? Did anyone outside of the target group click through, indicating a forwarded e-mail? Finally, with the security monitoring tools that are currently in place, is it possible to effectively track the activity? Is it possible to determine who clicked through (without looking at web logs)? Is it possible to detect abnormal patterns or behaviors that could be used to generate signatures, and detect similar phishing in the future?
The best defense against a social attack continues to be security awareness and
situational awareness: the first helps prevent a socially engineered attack from suc -
ceeding by establishing best-practice behaviors among personnel; the second helps
to detect if and when a successful breach has occurred, where it originated, and
where it may have spread to—in order to mitigate the damage and correct any gaps
in security awareness and training.
CAUTION
Always inform appropriate personnel of any security awareness exercise to avoid unintended consequences and/or legal liability, and NEVER perform experiments of this kind using real malware. Even if performed as an exercise, the collection of actual personal or corporate
information could violate your employment policy or even state, local, or federal privacy laws.
Finally, social networks can also be used as a C2 channel between deployed
malware and a remote server. One case of Twitter being used to deliver commands
to a bot is the @upd4t3 channel, first detected in 2009, that uses standard 140-
character tweets to link to base64-encoded URLs that deliver infosteeler bots. 32
This use of social networking is difficult to detect, as it is not feasible to scour
these sites individually for such activity and there is no known way to detect what
the C2 commands may look like or where they might be found. In the case of
@upd4t3, application session analysis on social networking traffic could detect the
base64 encoding once a session was initiated. The easiest way to block this type
of activity, of course, is to block access to social networking sites completely from
inside industrial networks. However, the wide adoption of these sites within the
enterprise (for legitimate sales, marketing, and even business intelligence purposes)
makes it highly likely that any threat originating from or directly exploiting social
networks can and will compromise the business enterprise. 49 APT and Cyber War
Cannibalistic Mutant Underground Malware
More serious than the 1984 New World Pictures film about cannibalistic human -
oid underground dwellers, the newest breed of malware is a real threat. It is mal -
ware with a mind: using conditional logic to direct activity based on its surrounding
until it finds itself in the perfect conditions in which it will best accomplish its goal
(spread, stay hidden, deploy a weapon, etc.). Again, Stuxnet’s goal was to find a par -
ticular industrial process control system: it spread widely through all types of net -
works, and only took secondary infection measures when the target environment
(SIMATIC) was found. Then, it again checked for particular PLC models and ver -
sions, and if found it injected process code into the PLC; if not, it lay dormant.
Malware mutations are also already in use. At a basic level, Stuxnet will update
itself in the wild (even without a C2 connection), through peer-to-peer checks with
others of its kind: if a newer version of Stuxnet bumps into an older version, it
updates the older version, allowing the infection pool to evolve and upgrade in the
wild. 33
Further mutation behavior involves self-destruction of certain code blocks with
self-updates of others, effectively morphing the malware and making it more tar -
geted as well as more difficult to detect. Mutation logic could include checking for
the presence of other well-known malware and adjusting its own profile to utilize
similar ports and services, knowing that this new profile will go undetected. In
other words, malware is getting smarter and it is harder to detect.
Still to Come
Infection mechanisms, attack vectors, and malware payloads continue to evolve.
We can expect to see greater sophistication of the individual exploits and bots, as
well as more sophisticated blends of these components. Because advanced mal -
ware is expensive to develop (or acquire), however, it is reasonable to expect new
variations or evolutions of existing threats in the short term, rather than additional
“Stuxnet-level” revolutions. Understanding how existing exploits might be fuzzed
or enhanced to avoid detection can help plan a strong defense strategy.
What we can assume is that threats will continue to grow in size, sophistica -
tion, and complexity. 34 We can also assume that new zero-day vulnerabilities will
be used for one or more stages of an attack (infection, propagation, and execution).
Also assume that attacks will become more focused, attempting to avoid detection
through minimized exposure. Stuxnet spreads easily through many systems and only
fully activates within certain environments; if a similar attack were less promiscuous
and more tactically inserted into the target environment, it would be much more dif -
ficult to detect.
In early 2011, additional vulnerabilities and exploits that specifically target
SCADA systems have been developed and released publically, including the broadly
publicized exploits developed by two separate researchers in Italy and Russia. The
“Luigi Vulnerabilities,” identified by Italian researcher Luigi Auriemma included
34 total vulnerabilities against systems from Siemens, Iconics, 7-Technologies, and 50 CHAPTER 3 Introduction to Industrial Network Security
DATAC. 35 Additional vulnerabilities and exploit code, including nine zero-days,
was released by the Russian firm Gleg as part of the Agora exploit pack for the
CANVAS toolkit. 36
Luckily, many tools are already available to defend against these sophisticated
attacks, and the results can be very positive when they are used appropriately in a
blended, sophisticated defense based upon “Advanced Persistent Diligence.”
that are recommended herein are aimed high, and this is because the threat environ -
ment in industrial networks has already shifted to these types of APTs, if not out -
right cyber war. These recommendations are built around the concept of “Advanced
Persistent Diligence” and a much higher than normal level of situational awareness.
This is because APT is evolving specifically to avoid detection by known security
measures. 38
Advanced Persistent Diligence requires a strong Defense-in-Depth approach,
both in order to reduce the available attack surface exposed to an attacker, and in
order to provide a broader perspective of threat activity for use in incident analy -
sis, investigation, and response. That is, because APT is evolving to avoid detection
even through advanced event analysis, it is necessary to examine more data about
network activity and behavior from more contexts within the network. 39
More traditional security recommendations are not enough, because the active
network defense systems such as firewalls, UTMs, and IPS are no longer capable
of blocking the same threats that carry with them the highest consequences. APT
threats can easily slide through these legacy cyber defenses.
Having situational awareness of what is attempting to connect to the system, as
well as what is going on within the system is the only way to start to regain control
of the system. This includes information about systems and assets, network commu -
nication flows and behavior patterns, organizational groups, user roles, and policies.
Ideally, this level analysis will be automated and will provide an active feedback
loop in order to allow IT and OT security professionals to successfully mitigate a
detected APT.
Responding to APT
Ironically, the last thing that you should do upon detecting an APT is to clean the
system of infected malware. This is because, as mentioned under section “Advanced
Persistent Threats,” there may be subsequent levels of infection that exist, dormant,
that will be activated as a result. Instead, a thorough investigation should be per -
formed, with the same sophistication as the APT itself.
First, logically isolate the infected host so that it can no longer cause any harm.
Allow the APT to communicate over established C2 channels, but isolate the host 51 APT and Cyber War
from the rest of your network, and remove all access between that host and any
sensitive or protected information. Collect as much forensic detail as possible in the
form of system logs, captured network traffic, and supplement where possible with
memory analysis data. By effectively sandboxing the infected system, important
information can be gathered that can result in the successful removal of an APT.
In summary, when you suspect that you are dealing with an APT, approach the
situation with diligence and perform a thorough investigation:
l Always monitor everything: collect baseline data, configurations, and firmware
for comparison.
l Analyze available logs to help identify scope, infected hosts, propagation vec -
tors, etc.
l Sandbox and investigate infected systems.
l Analyze memory to find memory-resident rootkits and other threats living in
user memory.
l Reverse engineer-detected malware to determine full scope and to identify addi -
tional attack vectors and possible prorogation.
l Retain all information for disclosure to authorities.
NOTE
Information collected from an infected and sandboxed host may prove valuable to legal authorities, and depending upon the nature of your industrial network you may be required to report this information to a governing body.
Depending on the severity of the APT, a “bare metal reload” may be necessary,
where a device is completely erased and reduced to a bare, inoperable state. The
host’s hardware must then be reimaged completely. For this reason, clean versions
of operating systems and/or asset firmware should be kept in a safe, clean envi -
ronment. This can be accomplished using secure virtual backup environments, or
via secure storage on trusted removable media that can then be stored in a locked
cabinet.
Free tools such as Mandiant’s Memoryze, shown in Figure 3.5 , can help you to
perform a deep forensic analysis on infected systems. This can help to determine
how deeply infected a system might be, by detecting memory-resident rootkits.
Memoryze and other forensics tools are available at http://www.mandiant.com .
TIP
If you think you have an APT, you should know that there are security firms that are experienced in investigating and cleaning APT. Many such firms further specialize in industrial control networks. These firms can help you deal with infection as well as provide an expert interface between your organization and any governing authorities that may be involved. 52 CHAPTER 3 Introduction to Industrial Network Security
SUMMARY
Industrial networks are important and vulnerable, and there are potentially devas -
tating consequences of a cyber incident. Examples of real cyber incidents—from
CENTCOM to Aurora to Stuxnet—have grown progressively more severe over
time, highlighting the evolving nature of threats against industrial systems. The
attacks are evolving into APTs, and the intentions are evolving from information
theft to industrial sabotage and the disruption of critical infrastructures.
Securing industrial networks requires a reassessment of our security prac -
tices, realigning them to a better understanding of how industrial protocols and
networks operate (see Chapter 4, “Industrial Network Protocols,” and Chapter 5
“How Industrial Networks Operate”), as well as a better understanding of the
vulnerabilities and threats that exist (see Chapter 6, “Vulnerability and Risk
Assessment”).
FIGURE 3.5
Mandiant’s Memoryze: A Memory Forensic Package. 40 53 Endnotes
ENDNOTES
1. J. Pollet, Red Tiger, Electricity for free? The dirty underbelly of SCADA and smart
meters, in: Proc. 2010 BlackHat Technical Conference, Las Vegas, NV, July 2010.
2. Ibid.
3. M.J. McDonald, G.N. Conrad, T.C. Service, R.H. Cassidy, SANDIA Report SAND2008-
5954, Cyber Effects Analysis Using VCSE Promoting Control System Reliability, Sandia
National Laboratories Albuquerque, New Mexico and Livermore, California, September 2008.
6. T. Smith, The Register. Hacker jailed for revenge sewage attacks. ,http://www.theregister
.co.uk/2001/10/31/hacker_jailed_for_revenge_sewage/ ., October 31, 2001 (cited:
November 3, 2010).
7. J. Meserve, CNN.com. Sources: Staged cyber attack reveals vulnerability in power grid.
,http://articles.cnn.com/2007-09-26/us/power.at.risk_1_generator-cyber-attack-electric-
infrastructure ., September 26, 2007 (cited: November 3, 2010).
8. North American Reliability Corporation, Press Release: NERC Issues AURORA Alert to
Industry, October 14, 2010.
9. CBS News, Cyber war: sabotaging the system. ,http://www.cbsnews.com/stories/2009/
11/06/60minutes/main5555565.shtml ., November 8, 2009 (cited: November 3, 2010).
10. McAfee Threat Center, Operation Aurora. ,http://www.mcafee.com/us/threat_center/
operation_aurora.html . (cited: November 4, 2010).
4. A. Giani, S. Sastry, K.H. Johansson, H.Sandberg, The VIKING Project: An Initiative
on Resilient Control of Power Networks, Department of Electrical Engineering and
Computer Sciences, University of California at Berkeley, and School of Electrical
Engineering, Royal Institute of Technology (KTH), Berkeley, CA, 2009.
5. K. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology,
Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems
(ICS) Security, Computer Security Division, Information Technology Laboratory,
National Institute of Standards and Technology Gaithersburg, MD and Intelligent
Systems Division, Manufacturing Engineering Laboratory, National Institute of
Standards and Technology Gaithersburg, MD, September 2008.
11. Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), ICSA-10-
238-01—STUXNET MALWARE MITIGATION, Department of Homeland Security,
US-CERT, Washington, DC, August 26, 2010.
12. E. Chien, Symantec. Stuxnet: a breakthrough. ,http://www.symantec.com/connect/blogs/
stuxnet-breakthrough ., November 2010 (cited: November 16, 2010).
14. N. Falliere, L.O Murchu, E. Chien, Symantec. W32.Stuxnet Dossier, Version 1.1,
October 2010.
15. Global Energy Cyberattacks: “Night Dragon,” McAfee Foundstone Professional Services
and McAfee Labs, Santa Clara, CA, February 10, 2011.
16. Ibid.
17. J. Pollet, Red Tiger, Understanding the advanced persistent threat, in: Proc. 2010 SANS
European SCADA and Process Control Security Summit, Stockholm, Sweden, October 2010.
18. North American Reliability Corporation, NERC Releases Alert on Malware Targeting
SCADA Systems, September 14, 2010.
13. N. Falliere, L.O. Murchu, E. Chien, Symantec, W32.Stuxnet Dossier, Version 1.3,
October 2010.
19. J. Pollet, Red Tiger, Understanding the advanced persistent threat, in: Proc. 2010 SANS
European SCADA and Process Control Security Summit, Stockholm, Sweden, October 2010. 54 CHAPTER 3 Introduction to Industrial Network Security
22. Ibid.
23. Ibid.
24. N. Falliere, L.O. Murchu, E. Chien, Symantec. W32.Stuxnet Dossier, Version 1.1,
October 2010.
25. J. Pollet, Red Tiger, Understanding the advanced persistent threat, in: Proc. 2010 SANS
European SCADA and Process Control Security Summit, Stockholm, Sweden, October 2010.
26. Ibid.
38. Ibid.
39. US Department of Homeland Security, US-CERT, Recommended Practice: Improving
Industrial Control Systems Cybersecurity with Defense-In-Depth Strategies, Washington,
DC, October 2009.
32. J. Nazario, Arbor networks. Twitter-based Botnet Command Channel. ,http://asert.
arbornetworks.com/2009/08/twitter-based-botnet-command-channel ., August 13, 2009
(cited: November 4, 2010).
33. J. Pollet, Red Tiger, Understanding the advanced persistent threat, in: Proc. 2010 SANS
European SCADA and Process Control Security Summit, Stockholm, Sweden, October 2010.
34. Ibid.
35. D. Peterson, Italian researcher publishes 34 ICS vulnerabilities. Digital Bond. ,http://
www.digitalbond.com/2011/03/21/italian-researcher-publishes-34-ics-vulnerabilities/ .,
March 21, 2011 (cited: April 4, 2011).
36. D. Peterson, Friday News and Notes. ,http://www.digitalbond.com/2011/03/25/friday-
news-and-notes-127 ., March 25, 2011 (cited: April 4, 2011).
37. Ibid.
27. D. Stevens, Escape from PDF. ,http://blog.didierstevens.com/2010/03/29/escape-from-
pdf ., March 2010 (cited: November 4, 2010).
28. M86 Security Labs, PDF “Launch” Feature Used to Install Zeus. ,http://www.m86security
.com/labs/traceitem.asp?article 1301 ., April 14, 2010 (cited: November 4, 2010).
29. J. Conway, Sudosecure.net. Worm-Able PDF Clarification. ,http://www.sudosecure.net/
archives/644 ., April 4, 2010 (cited: November 4, 2010).
30. Cisco Systems, 2Q10 Global Threat Report, 2010.
31. Social Engineering Framework, Computer based social engineering tools: Social
Engineer Toolkit (SET). ,http://www.social-engineer.org ..
40. Screenshot, Mandiant’s Memoryze memory analysis software. ,http://www.mandiant
.com . (cited: October 26, 2010).
21. J. Pollet, Red Tiger, Understanding the advanced persistent threat, in: Proc. 2010 SANS
European SCADA and Process Control Security Summit, Stockholm, Sweden, October 2010.
20. K. Harms, Mandiant, Keynote on advanced persistent threat, in: Proc. 2010 SCADA
Security Scientific Symposium (S4), Miami, FL, January 2010. 55
Industrial Network Protocols
4
CHAPTER
I N F O R M AT I O N I N T H I S C H A P T E R :
l Overview of Industrial Network Protocols
l Modbus
l ICCP/TASE.2
l DNP3
l OLE for Process Control
l Other Industrial Network Protocols
l AMI and the Smart Grid
Understanding how industrial networks operate requires a basic understanding of
the underlying communications protocols that are used, where they are used, and
why. There are many highly specialized protocols used for industrial automation
and control, most of which are designed for efficiency and reliability to support
the economic and operational requirements of large distributed control systems.
Similarly, most industrial protocols are designed for real-time operation to support
precision operations.
Unfortunately, this means that most industrial protocols forgo any feature
or function that is not absolutely necessary, for the sake of efficiency. Even more
unfortunate is that this often includes security features such as authentication and
encryption, both of which require additional overhead. To further complicate mat -
ters, many of these protocols have been modified to run over Ethernet and Internet
Protocol (IP) networks in order to meet the evolving needs of business, potentially
exposing these vulnerable protocols to attack.
OVERVIEW OF INDUSTRIAL NETWORK PROTOCOLS
Industrial Network Protocols are often referred to generically as SCADA and/or
fieldbus protocols. SCADA protocols are primarily used for the communication of
supervisory systems, whereas fieldbus protocols are used for the communication of
industrial, automated control systems (ICS or IACS). However, most of the proto -
cols discussed have the ability to perform both functions, and so will be referred to
here more generically as Industrial Network Protocols. 56 CHAPTER 4 Industrial Network Protocols
Industrial Network Protocols are real-time communications protocols, devel -
oped to interconnect the systems, interfaces, and instruments that make up an
industrial control system. Most were designed initially to communicate serially
over RS-232, RS-485, or other serial connections but have since evolved to operate
over Ethernet networks using routable protocols such as TCP/IP.
Four common industrial network protocols will be discussed in some depth, oth -
ers will be touched upon more briefly, and many will not be covered here: there
are literally dozens of industrial protocols, developed by specific manufacturers for
specific purposes. Modicon Communication Bus (Modbus), Inter Control Center
Protocol (ICCP, also known as TASE.2 or Telecontrol Application Service
Element-2 ), Distributed Network Protocol (DNP3), and Object Linking and
Embedding for Process Control (OPC) have been selected for more in-depth discus -
sion because they are all widely deployed and they represent several unique quali -
ties that are important to understand within the context of security. These unique
qualities include the following:
l Each is used in different (though sometimes overlapping) areas within an indus -
trial network.
l Each provides different methods of verifying data integrity and/or security.
l The specialized requirements of industrial protocols (e.g., real-time, synchro -
nous communication) often make them highly susceptible to disruption.
By understanding the basic principles of how to secure these protocols, it should
be possible to assess the risks of other industrial network protocols that are not cov -
ered here directly.
MODBUS
Modbus is the oldest and perhaps the most widely deployed industrial control com -
munications protocol. It was designed in 1979 by Modicon (now part of Schneider
Electric) that invented the first Programmable Logic Controller (PLC). Modbus has
been widely adopted as a de facto standard and has been enhanced over the years
into several distinct variants.
Modbus’ success stems from its relative ease of use: it communicates raw mes -
sages without restrictions of authentication or excessive overhead. It is also an open
standard, is freely distributed, and is widely supported by members of the Modbus
Organization, which still operates today.
What It Does
Modbus is an application layer messaging protocol, meaning that it operates at
layer 7 of the OSI model. It allows for efficient communications between intercon -
nected assets based on a request/reply methodology. It can be used by extremely
simple devices such as sensors or motors to communicate with a more com -
plex computer, which can read measurements and perform analysis and control. 57 Modbus
To support a communications protocol on a simple device requires that the message
generation, transmission, and receipt all require very little processing overhead.
This same quality also makes Modbus suitable for use by PLCs and RTUs to com -
municate supervisory data to a SCADA system.
Because Modbus is a layer 7 protocol, it can operate independently of under -
lying network protocols, and it has allowed Modbus to be easily adapted to both
serial and routable network architectures.
How It Works
Modbus is a request/response protocol using only three distinct Protocol Data Units
(PDUs): Modbus Request, Modbus Response, and Modbus Exception Response, as
illustrated in Figure 4.1 .1
Each device communicating via Modbus must be assigned a unique address. A
command is addressed to a specific Modbus address, and while other devices may
receive the message, only the addressed device will respond.
A session begins with the transmission of an initial Function Code and a Data
Request within a Request PDU. The receiving device responds in one of two ways.
If there are no errors, it will respond with a Function Code and Data Response within
a Response PDU. If there are errors, the device will respond with an Exception
Function Code and Exception Code within a Modbus Exception Response.
Function Codes and Data Requests can be used to perform a wide range of com -
mands. Some examples of Modbus commands include the following:
l Control an I/O interface.
l Read from an I/O interface.
FIGURE 4.1
Modbus Protocol Operation. 58 CHAPTER 4 Industrial Network Protocols
l Read the value of a register.
l Write a value to a register (i.e., change the value in a register).
Variants
The popularity of Modbus has led to the development of several variations to suit
particular needs. These include Modbus RTU and Modbus ASCII , which support
binary and ASCII transmissions over serial buses, respectively. Modbus TCP is a
variant of Modbus developed to operate on modern networks using the IP. Modbus
Plus is a variant designed to extend the reach of Modbus via interconnected busses. 2
Modbus RTU and Modbus ASCII
These similar variants of Modbus are used in serial communications, and they are
the simplest of the variants. Modbus RTU ( ) uses binary data represen -
tation, whereas Modbus ASCII ( ) uses ASCII characters to represent
data. Each uses a simple message format carried within a PDU, consisting of an
address, function code, a payload of data, and a checksum, to ensure the message
was received correctly.
Modbus TCP
Modbus TCP uses Transmission Control Protocol/Internet Protocol (TCP/IP) to
transport Modbus commands and messages over modern routable networks. Early
implementations of Modbus TCP abandoned the Modbus checksum, relying on the
FIGURE 4.2
Modbus Frame (Modbus RTU).
FIGURE 4.3
Modbus Frame (Modbus ASCII). 59 Modbus
checksum of the underlying TCP/IP protocol, whereas most current Modbus TCP
implementations include the original Modbus checksum within the TCP/IP pay -
load, as shown in Figure 4.4 .
Modbus Plus or Modbus
Modbus Plus is proprietary to Modicon, which sends embedded Modbus messages
over an RS-485 communication link. Modbus Plus supports some interesting fea -
tures, including Modbus bridging to allow multiple buses to interconnect, extending
the number of supported nodes indefinitely.
Where It Is Used
Modbus is typically deployed between PLCs and HMIs, or between a Master
PLC and slave devices such as PLCs, HMIs, Drivers, Sensors, I/O devices, etc., as
shown in Figure 4.5 . Typically up to 247 devices are supported in a single, non -
bridged bus.
A common deployment uses Modbus on TCP/IP within a SCADA DMZ or
Supervisory LAN, where master HMIs provide a central management capability to
a number of Master PLCs, each of which may connect serially over a bus topology
to a number of PLCs and/or HMIs, responsible for a distinct control loop.
Security Concerns
Modbus represents several security concerns:
l Lack of authentication. Modbus sessions only require the use of a valid Modbus
address and valid function code. One can be easily guessed or spammed,
whereas the other is easily obtainable information.
l Lack of encryption. Commands and addresses are transmitted in clear text and
can therefore be easily captured and spoofed due to the lack of encryption.
FIGURE 4.4
Modbus Frame (Modbus TCP). 60 CHAPTER 4 Industrial Network Protocols
l Lack of message checksum (Modbus TCP only). A spoofed command is even
easier over some implementations of Modbus TCP, as the checksum is gener -
ated at the transmission layer, not the application layer.
l Lack of broadcast suppression (serial Modbus variants only). All serially con -
nected devices will receive all messages, meaning a broadcast of unknown
addresses can be used for effective denial of service (DoS) to a chain of serially
connected devices.
l Programmability. By far, the most dangerous quality of Modbus—which is shared
with many industrial protocols—is that it is intentionally designed to program
controllers, and could be used to inject malicious logic into an RTU or PLC.
Security Recommendations
Modbus, like many industrial control protocols, should only be used to communi -
cate between sets of known devices, using expected function codes, and as such it is
easily monitored by establishing clear enclaves and by baselining acceptable behav -
ior. For more information about creating whitelists , this topic is discussed in detail
in Chapter 8, “Exception, Anomaly, and Threat Detection.” 61 ICCP/TASE.2
Some specific examples of Modbus messages that should be of concern include
the following:
l Modbus TCP packets that are of wrong size or length.
l Function codes that force slave devices into a “listen only” mode.
l Function codes that restart communications.
l Function codes that clear, erase, or reset diagnostic information such as counters
and diagnostic registers.
l Function codes that request information about Modbus servers, PLC configura -
tions, or other need-to-know information.
l Traffic on TCP port 502 that is not Modbus or is using Modbus over malformed
protocol(s).
l Any message within an Exception PDU (i.e., any Exception Code).
l Modbus traffic from a server to many slaves (i.e., a potential DoS).
l Modbus requests for lists of defined points and their values (i.e., a configuration
scan).
l Commands to list all available function codes (i.e., a function scan).
A SCADA Intrusion Detection System ( ) or SCADA Intrusion
Prevention System ( ) can be easily configured to monitor for these
activities using Modbus signatures such as those developed and distributed by Digital
Bond. In more critical areas, an application-aware firewall, industrial protocol filter, or
Application Data Monitor may be required to validate Modbus sessions and ensure
that Modbus has not been “hijacked” and used for covert communication, command,
and control (i.e., the underlying TCP/IP session on port 502 has not been altered to
hide additional communications channels within otherwise normal-looking Modbus
traffic). This is discussed in detail in Chapter 7, “Establishing Secure Enclaves.”
The Inter Control Center Protocol (also known as TASE.2 or IEC60870-6, but more
commonly referred to as ICCP) is a protocol designed for communication between
control center s within the energy industry. Unlike Modbus, which was designed
for serial command requests, ICCP was designed for bidirectional Wide Area
Network (WAN) communication between a utility control center and other control
centers, power plants, substations, and even other utilities. 62 CHAPTER 4 Industrial Network Protocols
Because many custom and proprietary protocols are used by asset vendors, a
common protocol was needed to allow for reliable and standardized data exchange
between control centers—especially between control centers that are operated
by different owners, produce different products, or perform different operations.
Basically, standardization became necessary to support the unique business and
operational requirements of industry, especially the electrical utilities that require
careful load balancing within a bulk system operated by many disparate facilities.
For example, in North America, the division of utilities among several responsible
regional entities requires a means of sharing information between utilities as well as
the regional entity. Similarly, national and global energy markets require real-time
information exchange for load distribution and trading that spans the boundaries of
individual utilities.
A working group was formed in 1991 to develop and test a standardized pro -
tocol and to submit the specification to the IEC. The initial protocol was called
ELCOM-90, or Telecontrol Application Service Element-1 ( ). TASE.1
evolved into TASE.2, which is the most commonly used form of ICCP. 3
What It Does
ICCP is used to perform a number of communication functions between control
centers, including the following:
l Establishing a connection.
l Accessing information (read requests).
l Information transmission (such as e-mail messages or energy market information).
l Notifications of changes, alarms, or other exception conditions.
l Configuration of remote devices.
l Control of remote devices.
l Control of operating programs.
How It Works
The ICCP protocol defines communication between two control centers using a
client/server model. One control center (the server) contains application data and
defined functions. Another control center (the client) issues requests to read from
the server, and the server responds. Communications over ICCP occur using a com -
mon format in order to ensure interoperability.
ICCP support is typically either integrated directly into a control system, pro -
vided via a gateway product, or provided as software running on Windows or Unix
that can then be installed to perform gateway functions.
Although ICCP is primarily a unidirectional client/server protocol, most modern
implementations support both functions, allowing a single ICCP device to function
as both a client and a server, and thus supporting bidirectional communication (of a
sort) over a single connection.
Although ICCP can operate over essentially any network protocol, including
TCP/IP, it is commonly implemented using ISO transport on top of TCP port 102, as 63 ICCP/TASE.2
defined in RFC 1006. ICCP is effectively a point-to-point protocol due to the use of
a “bilateral table” that explicitly defines an agreement between two control centers
connected with an ICCP link, as shown in Figure 4.6 . The bilateral table is essen -
tially an access control list that identifies which data elements a client can access.
The permissions defined within the bilateral tables in the server and the client are the
authoritative control over what is accessible to each control center. In addition, the
entries in the bilateral tables must match on both the client and the server, ensur -
ing that the permissions are agreed upon by both centers (remembering that ICCP
is used to interconnect to other organizations in addition to internal WAN links to
substations). 4
Where It Is Used
ICCP is widely used between control system enclaves and between distinct control
centers, as shown in Figure 4.7 , for example, between two electric utilities, between
two control systems within a single electric utility, between a main control center
and a number of substations, etc.
Security Concerns
Like Modbus, ICCP represents several security concerns. ICCP is susceptible to
spoofing, session hijacking, and any number of attacks made possible because of:
l Lack of authentication and encryption. ICCP does not mandate authentication
or encryption, most often deferring these services to lower protocol layers.
Although Secure ICCP does exist, it is not ubiquitously deployed.
FIGURE 4.6
ICCP Protocol Operation. 64 CHAPTER 4 Industrial Network Protocols
l Explicitly defined trust relationships. The exploitation of bilateral tables could
directly compromise security of ICCP servers and clients.
l Accessibility. ICCP is a Wide Area Protocol making it highly accessible and
susceptible to many attacks including DoS attacks.
The limited security mechanisms within ICCP are configured on the ICCP
Master station , meaning that the successful breach of the Master through a Man-
in-the-Middle (MITM) or other attack opens the entire communication session up
to manipulation.
Security Improvements over Modbus
ICCP offers several improvements over more basic fieldbus protocols such as
Modbus, including the following:
l ICCP’s use of bilateral tables provides basic control over the communication
path by explicitly defining which ICCP clients and servers can communicate.
l A secure version of ICCP exists that incorporates digital certificate authentica -
tion and encryption.
FIGURE 4.7
Typical ICCP Use within the Industrial Network Architecture. 65 ICCP/TASE.2
Security Recommendations
Secure ICCP variants should be used wherever possible. There are several known
vulnerabilities with ICCP that are reported by ICS-CERT. Because there are known
exploits in the wild and ICCP is a WAN protocol, proper penetration testing and
patching of ICCP servers and clients is recommended.
Extreme care should be taken in the definition of the bilateral table. The bilat -
eral table is the primary enforcement of policy and permissions between control
centers and malicious commands issued via ICCP could directly alter or otherwise
impact control center operations.
In addition, ICCP clients and servers should be isolated into a unique enclave
consisting only of authorized client/server pairs (multiple enclaves can be defined
for devices communicating to multiple clients), and the enclave(s) should be thor -
oughly secured using standard defense-in-depth practices, including a firewall and/
or IDS system that enforces strict control over the type, source, and destination of
traffic over the ICCP link.
Many malicious behaviors can be detected through monitoring the ICCP link,
including the following:
l Intruders gaining unauthorized access to the control center network, via over -
looked access points such as dial-up connections to partner or vendor networks.
l Insider threats, including unauthorized information access and transmission,
alteration of secure configurations, or other malicious actions can be the result of
a physical security breach within a control center, or of a disgruntled employee.
l A DoS attack resulting from repeated information requests (“spamming”) that
utilize the server’s available resources and prevent legitimate operation of the
ICCP link.
l Malware infecting the ICCP server or other devices could be used to exfiltrate
sensitive information for purposes of sabotage (e.g., theft of command function
codes), financial disruption (e.g., alteration of energy metrics used in trading),
or various other malicious intents.
l Interception and modification of ICCP messages (i.e., MITM) attacks.
Monitoring of ICCP protocol functions can also detect suspicious or malicious
behavior, such as
l Function “read” codes that could be used to exfiltrate protected information.
l Function “write” codes that could be used to manipulate client or server operations.
l Traffic on TCP port 102 that is not ICCP.
l ICCP traffic that is not sourced by and destined to defined ICCP servers or clients.
A SCADA-IDS or SCADA-IPS can be easily configured to monitor for these
activities. Digital Bond, a security research team funded by the Department of
Energy, has Snort compatible IDS signatures and preprocessors to detect a variety
of ICCP-related security events. Again, in more critical areas, an application-aware
firewall, industrial protocol filter, or Application Data Monitor may be required to 66 CHAPTER 4 Industrial Network Protocols
validate ICCP sessions and ensure that ICCP or the underlying RFC-1006 connection
have not been “hijacked” and that messages have not been manipulated or falsified.
CAUTION
Any SCADA-IPS devices should be configured with caution and should only alert on events, rather than block them (i.e., operate in IDS mode rather than active IPS mode), as a false positive that blocks an ICCP command could cause an unintentional failure within the control system.
DNP3
DNP3 began as a serial protocol designed for use between master control stations
and slave devices or “ IED s
within a control station. Like most control system protocols, DNP3 was extended to
work over IP, encapsulated in TCP or UDP packets, in order to make remote RTU
communications more easily accessible over modern networks.
One distinction of DNP3 is that it is very reliable, while remaining efficient and
well suited for real-time data transfer. It also utilizes several standardized data for -
mats and supports time-stamped (and time-synchronized) data, making real-time
transmissions more efficient and thus even more reliable. Another reason that DNP3
is considered highly reliable is due to the frequent use of CRC checks—a single
DNP3 frame can include up to 17 CRCs: one in the header and one per data block
within the payload (see the section “How it Works”). There are also optional link-
layer acknowledgments for further reliability assurance, and—of particular note—
Because all of this
is done within the link-layer frame, it means that additional network-layer checks
may also apply if DNP3 is encapsulated for transport over Ethernet.
Unlike Modbus and ICCP, DNP3 is both bidirectional (supporting communica -
tions from both Master to Slave and from Slave to Master) and supports exception-
based reporting. It is therefore possible for a DNP3 outstation to initiate an
unsolicited response, in order to notify the Master of an event outside of the normal
polling interval (such as an alarm condition).
What It Does
Like the other ICS protocols that have been discussed, DNP3 is primarily used to
send and receive messages between control system devices—only in the case of
DNP3, it also does it with a high degree of reliability. Assuming that the various
CRCs are all valid, the data payload is then processed. Again, the payload is very
flexible and can be used to simply transfer informational readings, or it can be used
to send control functions, or even direct binary or analog data for direct interac -
tion with devices such as Remote Terminal Units (RTUs), as well as other analog
devices such as IEDs. 67 DNP3
As mentioned previously, both the link-layer frame (or LPDU) header and the
data payload contain CRCs, and the data payload actually contains a pair of CRC
octets for every 16 data octets. This provides an exceptional degree of assurance that
any communication errors will be detected. If any errors are detected, DNP3 will
retransmit the errored frames. In addition to frame integrity, there are also physical
layer integrity issues, and it remains possible that a correctly formed and transmitted
frame will not arrive at its destination. To overcome this risk, DNP3 uses an addi -
tional link layer confirmation. When link layer confirmation is enabled, the DNP3
transmitter (source) of the frame requests that the receiver (destination) confirms the
successful receipt of the frame. If a requested confirmation is not received, the link
layer will retransmit the frame. This confirmation is optional because although it
increases reliability, it adds overhead that directly impacts the efficiency of the pro -
tocol. In real-time environments, this added overhead may not be appropriate. 5
Once a successful and (if requested) confirmed frame arrives, the frame is proc -
essed. Each frame consists of a multipart header and a data payload. The header is
significant as it contains a well-defined function code, which can tell the recipient
whether it should confirm, read, write, select a specific point, operate a point (initi -
ate a change to a point), directly operate a point (both selecting and changing a
point in one command), or directly operate a point without acknowledgment. 6
These functions are especially powerful when considering that the data pay -
load of the DNP3 frame supports analog data, binary data, files, counters, and other
types of data objects. At a high level, DNP3 supports two kinds of data, referred
to as class 0 or static data (data that represents a static value or point reading) and
event data (data that represents a change, some sort of activity, or an alarm condi -
tion). Event data is rated by priority from class 1 (highest) to class 3 (lowest). The
differentiation of static and event data, as well as the classification of event data
allows DNP3 to operate more efficiently by allowing higher-priority information to
be polled more frequently, for example, or to enable or disable unsolicited responses
by data type. The data itself can be binary, analog input or output, or a specific
control output. 7
How It Works
DNP3 provides a method to identify the remote device’s parameters and then use
message buffers corresponding to event data classes 1 through 3 in order to identify
incoming messages and compare them to known point data. In this way, the master
device is only required to retrieve new information resulting from a point change or
change event.
Initial communications are typically a class 0 request from the Master to an
Outstation, used to read all point values into the Master database. Subsequent com -
munications will typically either be direct poll requests for a specific data class from
the Master; unsolicited responses for a specific data class from an outstation; con -
trol or configuration requests from the Master to an RTU, and subsequent periodic
class 0 polls. When a change occurs on an outstation, a flag is set to the appropriate 68 CHAPTER 4 Industrial Network Protocols
data class. The Master station is then able to poll only those outstations where there
is new information to be reported.
This is a huge departure from constant data polling that can result in improved
responsiveness and much more efficient data exchange. The departure from a real-
time polling mechanism does require time synchronization, however, because the
time between a change event and a successful poll/request sequence is variable.
Therefore, all responses are time-stamped, so that the events between polls can be
reconstructed in the correct order.
Communication is initiated by the Master to the Slave, or in the case of unso -
licited responses (alarms) from the slave to the master, as shown in Figure 4.8 .
FIGURE 4.8
DNP3 Protocol Operation. 69 DNP3
Because DNP3 operates bidirectionally and supports unsolicited responses, as
shown in Figure 4.9 , each frame requires both a source address and a destination
address so that the recipient device knows which messages to process, and so that
it knows which device to return responses to. Although the addition of a source
address (remember that in the other purely Master/ Slave protocols, there is no need
for a source address as the originating device is always the master) does add some
overhead, it does so for the sake of dramatically increased scalability and functional -
ity; as many as 65,520 individual addresses are available within DNP3, and any one
of them can initiate communications. An address equals one device (every DNP3
device requires a unique address), although there are reserved DNP3 addresses,
including one for broadcast messages (which will be received and processed by all
connected DNP3 devices). 8
Secure DNP3
Secure DNP3 is a DNP3 variant that adds authentication to the response/request
process, as shown in Figure 4.10 . Authentication is issued as a challenge by the
receiving device. A challenge condition occurs upon session initiation (when a mas -
ter station initiates a DNP3 session with an outstation), after a preset period of time
(the default is 20 minutes), or upon a critical request (it is possible to know which
requests are critical because the data types and functions of DNP3 are well defined)
such as writes, selects, operates, direct operates, starts, stops and restarts, etc. 9
Authentication occurs using a unique session key, which is hashed together with
message data from the sender and from the challenger. The result is an authentica -
tion method that at once verifies authority (checksum against the secret key), integ -
rity (checksum against the sending payload), and pairing (checksum against the
challenge message). In this way, it is very difficult to perform data manipulation or
code injection, or to spoof or otherwise hijack the protocol. 10
The DNP3 layer 2 frame provides the source, destination, control, and payload,
and can operate over a variety of application layers including TCP/IP (typically
FIGURE 4.9
DNP3 Protocol Operation: Unsolicited Responses Allow Remote Alarm Generation. 70 CHAPTER 4 Industrial Network Protocols
using TCP port 20000 or UDP port 20000). The function codes are resident within
the CNTRL bytes in the DNP3 frame header, as shown in Figure 4.11 .
Where It Is Used
As shown in Figure 4.12 , DNP3 is primarily used between a master control station
and an RTU in a remote station, over almost any medium including wireless, radio,
and dial-up. However, DNP3 is also widely used between RTUs and IEDs. As such
it competes directly with the Modbus protocols within several areas of the control
system.
Unlike Modbus, however, DNP3 is well suited for hierarchical and aggregated
point-to-multipoint topologies in addition to the linear point-to-point and serial
point-to-multipoint topologies that are supported by Modbus. 11
FIGURE 4.10
Message Confirmation and Secure DNP3 Authentication Operation. 71 DNP3
Security Concerns
While much attention is given to the integrity of the data frame, there is no authen -
tication or encryption inherent within DNP3 (although there is within Secure
DNP3). Because of the well-defined nature of DNP3 function codes and data types,
it then becomes relatively easy to manipulate a DNP3 session.
Also, while DNP3 does include security measures, the added complexity of
the protocol increases the chances of vulnerability. As of this writing, there
are several known vulnerabilities with DNP3 that are reported by ICS-CERT.
Because there are known exploits in the wild and DNP3 is a heavily deployed
protocol, proper penetration testing and patching of DNP3 interconnections is
recommended.
FIGURE 4.11
DNP3 Protocol Framing. 72 CHAPTER 4 Industrial Network Protocols
Some examples of realistic hacks against DNP3 include the use of MITM
attacks to capture addresses, which can then be used to manipulate the system.
Examples include the following:
l Turning off unsolicited reporting to stifle alarms. 12
l Spoofing unsolicited responses to the Master to falsify events and trick an oper -
ator into taking inappropriate actions.
l Performing a DoS attack through the injection of broadcasts, creating storm
behavior within the full extent of the DNP3 system.
l Manipulating the time synchronization data, resulting in synchronization loss
and subsequent communication errors.
l Manipulating or eliminating confirmation messages forcing a state of continu -
ous retransmission.
l Issuing unauthorized stops, restarts, or other functions that could disrupt
operations.
Security Recommendations
Because a secure implementation of DNP3 exists, the primary recommendation is
to implement only Secure DNP3. However, it may not always be possible due to
varying vendor support and other factors. In these cases, secure use of the transport
layer protocol is advised, such as the use of Transport Layer Security (TLS). In other
words, treat your encapsulated DNP3 traffic as highly sensitive information and use
every TCP/IP security best practice to protect it.
FIGURE 4.12
Typical DNP3 Use within the Industrial Network Architecture. 73 OLE for Process Control
As always, DNP3 masters and outstations should be isolated into a unique
enclave consisting only of authorized devices (multiple enclaves can be defined for
devices communicating to multiple clients, or for hierarchical Master/Slave pairs),
and the enclave(s) should be thoroughly secured using standard defense-in-depth
practices, including a firewall and/or IDS system that enforces strict control over
the type, source, and destination of traffic over the DNP3 link.
Many threats can be detected through monitoring the DNP3 session, and look -
ing for specific function codes and behaviors, including the following:
l Use of any non-DNP3 communication on a DNP3 Port (TCP and UDP Port
20000).
l Use of configuration function code 23 (Disable Unsolicited Responses).
l Use of control function codes 4, 5, or 6 (Operate, Direct Operate, and Direct
Operate without Acknowledgment).
l Use of application control function 18 (Stop Application).
l Multiple, unsolicited responses over time (Response Storm).
l Any unauthorized attempt to perform an action requiring authentication.
l Any authentication failures.
l Any DNP3 communication sourced from or destined to a device that is not
explicitly identified as a DNP3 master or slave device.
As with other industrial protocols, SCADA-IDS or SCADA-IPS can be easily
configured to monitor for these activities, while an application-aware firewall or
Application Data Monitor may be required to validate DNP3 sessions.
CAUTION
Any SCADA-IPS devices should be configured with caution, and should only alert on events, rather than block them (i.e., operate in IDS mode rather than active IPS mode), as a false positive that blocks a valid DNP3 function code could cause an unintentional failure within the control system.
OLE FOR PROCESS CONTROL
OPC is not an industrial network protocol, but rather an operational framework
for the communication of Windows-based process control systems using Microsoft’s
Object Linking and Embedding (OLE) protocol, which itself heavily utilizes addi -
tional communications protocols such as Remote Procedure Call (RPC). That is,
OPC is a suite of protocols that collectively enable process control systems to com -
municate using some of the underlying networking capabilities of Windows.
What It Does
OPC differs from the other fieldbus protocols discussed in this chapter in that
its primary function is to interconnect other distributed control systems with
Windows hosts, typically connected via an Ethernet TCP/IP network. OPC is 74 CHAPTER 4 Industrial Network Protocols
an implementation of OLE for Process Control Systems. Originally OPC was
Distributed Component Object Model (DCOM) based, and many OPC systems
in use today use DCOM, although OPC has more recently been updated to use an
object-oriented protocol called OPC-Unified Architecture (OPC-UA). 13
OPC provides a common communications interface between diverse industrial
control systems and products by leveraging Microsoft’s DCOM communications
API, reducing the need for device-specific drivers. In place of specific communi -
cations drivers for each device, simple device drivers could be written to interface
with OPC. The use of OPC therefore minimized driver development and allowed
for better optimization of core OPC interfaces. 14
OPC’s strengths and weaknesses come from its foundation, which is based upon
Microsoft’s OLE protocol. OLE is used extensively in Office document generation
and is used to embed a common data set in both a Word file and an Excel spread -
sheet, for example. This not only allows OPC-connected devices to communicate
and interact with minimal operator feedback (as in the case of the Office docu -
ments) but also presents significant security challenges. 15
How It Works
OPC works in a client/server manner, where a client application calls a local process,
but instead of executing the process using local code, the process is executed on a
remote server. The remote process is linked to the client application and is responsi -
ble for providing the necessary parameters and functions to the server, over an RPC.
In other words, the stub process is linked to the client, but when a function is
performed, the process is performed remotely, on the server. The server RPC func -
tions then transmit the requested data back to the client computer. Finally, the client
process receives the data over the network, provides it to the requesting application,
and closes the session, as shown in Figure 4.13 .
FIGURE 4.13
Typical OPC Protocol Operation. 75 OLE for Process Control
In Windows systems, the requesting application typically loads RPC libraries at
run-time, using a Windows dynamic link library (DLL). 16
OPC is more complex than previous client/server industrial network protocols
because of this interaction with the calling application and the underlying DCOM
architecture. It interacts with various aspects of the host operating system, tying it
closely to other host processes and exposing the protocol to a very broad attack
surface. OPC also inherently supports remote operations (ROPs) that allow OPC to
perform common control system functions. 17
OPC-UA and OPC-XI
The OPC-UA and the OPC Express Interface (XI) are newer variations of OPC that
break away from OPC Classic’s dependence upon OLE. OPC-UA and OPC-XI
preserve the functionality of earlier OPC implementations, while introducing new
capabilities including stronger authentication services, encryption, and new trans -
port mechanisms, including SOAP over HTTPS, and binary encoding to improve
performance over XML, which has relatively high overhead. 18
OPC-UA and OPC-XI represent strong improvements over legacy OPC imple -
mentations in terms of security. However, legacy OPC systems remain heavily
deployed.
Where It Is Used
OPC is primarily a SCADA protocol, and it is used within many areas of indus -
trial networks, including data transfer to data historians, data collection within
HMIs, and other supervisory controls, as shown in Figure 4.14 . OPC is a Windows
interconnection, and so all communications occur either between Windows-based
devices, or via OPC gateways that translate the RPC to the native fieldbus format.
Unfortunately, OPC is also widely used within an industrial system’s business net -
work, including connections to corporate intranets, and even the Internet. 19 Because
of the common use of OLE, RPC, and DCOM protocols within OPC, this opens the
SCADA environment to a very broad attack surface.
Typically, OPC will be used “upstream” of fieldbus protocols, acting as a gate -
way between these protocols and Windows-based computing networks.
Security Concerns
OPC’s use of DCOM and RPC makes it highly vulnerable to attack, as it is subject
to the same vulnerabilities as the more ubiquitously used OLE. In addition, OPC is
rooted in the Windows operating system (OS) and is therefore susceptible to attack
through exploitation of any vulnerability inherent to the OS. 20
OPC and related control system vulnerabilities are available only to authorized
members of ICS-CERT; however, many OLE and RPC vulnerabilities exist and are
well known. Because of the difficulties involved in patching production systems 76 CHAPTER 4 Industrial Network Protocols
within an industrial network (see Chapter 6, “Vulnerability and Risk Assessment”),
many of these vulnerabilities are still in place, even if there is an available patch
from Microsoft.
Also, because OPC is supported on Windows, many basic host security con -
cerns apply. Many OPC hosts utilize weak authentication, and passwords are often
weak when authentication is enforced. Many systems support additional Windows
services that are irrelevant to SCADA systems, resulting in unnecessary processes,
which often correspond to open ports. These issues open the OPC system up to a
broader attack surface. Inadequate or nonexistent logging exacerbates this by provid -
ing insufficient forensic detail should a breach occur, as Windows 2000/XP auditing
settings do not record DCOM connection requests by default. 21
In other words, unlike the simple and single-purpose protocols discussed until
now, OPC must be treated as a larger system, according to modern OS and network
security practices. Given OPC’s reliance on Microsoft authentication mechanisms,
weak passwords are among the most critical vulnerabilities that can undermine
the security of an OPC server. Inadequate logging is also a primary concern, as
by default, Windows 2000/XP auditing settings do not record DCOM connection
requests, SMB log-ins, or attempts to access system objects. 22
Other security concerns of OPC include the following:
l Legacy authentication services. Because systems within industrial networks
are difficult to upgrade (due to limited maintenance windows, interpretability
FIGURE 4.14
Typical OPC Use within the Industrial Network Architecture. 77 OLE for Process Control
concerns, and other factors), insecure authentication mechanisms remain in use.
For example, Windows 2000 LanMan (LM) and NT LanMan (NTLM) authentica -
tion mechanisms are still used by default in many systems. These and other legacy
authentication mechanisms may be vulnerable and susceptible to exploitation. 23
l RPC vulnerabilities. Because OPC uses RPC, it is susceptible to all RPC-related
vulnerabilities, including several vulnerabilities that are exposed prior to authen -
tication. Exploitation of underlying RPC vulnerabilities could result in arbitrary
code execution, or DoS. 24
l Unnecessary ports and services. OPC supports other network protocols
other than TCP/IP, including NetBIOS Extended User Interface (NetBEUI),
Connection Oriented NetBIOS over InterNetwork packet Exchange (IPX), and
Hyper Text Transport Protocol (HTTP) Internet services. 25
l OPC Server Integrity. It is possible to create a rogue OPC server and to use that
server for disruption of service, DoS, information theft through bus snooping, or
the injection of malicious code. 26
Security Recommendations
OPC-UA or OPC-XI should be used where possible.
Regardless of the OPC variation used (Classic, UA, or XI), all unnecessary ports
and services should be removed or disabled from the OPC server. This includes any
and all irrelevant applications, and all unused network protocols. All unused services
may introduce vulnerabilities to the system that could result in a compromise of the
Windows host, and therefore the OPC network. 27
OPC servers should be isolated into a unique enclave consisting only of author -
ized devices, and the enclave(s) should be thoroughly secured using standard defense-
in-depth practices, including a firewall and/or IDS/IPS system that enforces strict
control over the type, source, and destination of traffic to and from the OPC enclave.
Because OPC is primarily used in a supervisory capacity, IPS can be considered
in place of IDS, understanding that an IPS may block SCADA traffic and result in a
lack of visibility into control system operations. If information loss will be damag -
ing to the control process or detrimental to business operations, use only IDS.
Many threats can be detected through monitoring OPC networks and/or OPC
servers (server activity can be monitored through the collection and analysis of
Windows logs), and looking for specific behaviors, including the following:
l The use of non-OPC ports and services initiated from the OPC server.
l The presence of known OPC (including underlying OLE RPC and DCOM)
exploits.
l OPC services originating from unknown OPC servers (indicating the presence
of a rogue server).
l Failed authentication attempts or other authentication anomalies on the OPC
server.
l Successful authentication attempts on the OPC server from unknown or unau -
thorized users. 78 CHAPTER 4 Industrial Network Protocols
Most commercially available IDS and IPS devices support a wide range of detec -
tion signatures for OLE and RPC and therefore can also detect many of the underly -
ing vulnerabilities of OPC. Similarly, most open-source and commercial log analysis
and threat detection tools are capable of collecting and assessing Windows logs.
TIP
OPC-UA and OPC-XI, as well as certain OPC Classic vulnerabilities, may require the use of a SCADA-IDS or SCADA-IPS rather than an enterprise IDS or IPS. Enterprise devices typi - cally detect exploits via inspection of OLE, RPC, and DCOM and may not be able to detect all threats targeting OPC. In some cases, enterprise IDS and IPS devices may be adapted to detect a wider range of OPC threats, using Snort ® compatible preprocessors and detec - tion signatures available from Digital Bond.
OTHER INDUSTRIAL NETWORK PROTOCOLS
There are dozens of industrial protocols—more than can be covered in even cursory
detail within this book. Several warrant mention, as they introduce new concepts
and/or concerns regarding industrial network security. These include Ethernet/IP ,
Profibus, EtherCAT, Ethernet Powerlink, and SERCOS III .
Ethernet/IP
Ethernet/IP uses standard Ethernet frames (ethertype 0x80E1) in conjunction with the
Common Industrial Protocol (CIP) suite to communicate with nodes. Communication
is typically client/server, although an “implicit” mode is supported to handle real-time
requirements. Implicit mode uses connectionless transport—specifically the User
Datagram Protocol (UDP) and multicast transmissions—to minimize latency and jitter.
NOTE
The “IP” in Ethernet/IP derives from “Industrial Protocol” and not “Internet Protocol,” because of the use of the Common Industrial Protocol (CIP). Similarly, the acronym “CIP” meaning “Common Industrial Protocol” should not be confused with “Critical Infrastructure Protection” of NERC CIP.
The CIP uses object models to define the various qualities of a device. There are
three types of objects: Required Objects, which define attributes such as device iden -
tifiers, routing identifiers, and other attributes of a device such as the manufacturer,
serial number, date of manufacture, etc.; Application Objects, which define input and
output profiles for devices; and Vendor-specific Objects, which enable vendors to
add proprietary objects to a device. Objects (other than vendor-specific objects) are
standardized by device type and function, to facilitate interoperability: if one brand 79 Other Industrial Network Protocols
of pump is exchanged for another brand, for example, the application objects will
remain compatible, eliminating the need to build custom drivers. The wide adop -
tion and standardization of CIP has resulted in an extensive library of device models,
which can facilitate interoperability but can also aid in control network scanning and
enumeration (see Chapter 6, “Vulnerability and Risk Assessment”).
While the Required Objects provide a common and complete set of identifying
values, the Application Objects contain a common and complete suite of services
for control, configuration, and data collection that includes both implicit (control)
and explicit (information) messaging. 28
Security Concerns
Ethernet/IP is a real-time Ethernet protocol, and as such it is susceptible to any
of the vulnerabilities of Ethernet. Ethernet/IP over UDP is transaction-less and
so there is no inherent network-layer mechanism for reliability, ordering, or data
integrity checks. The CIP also introduces some specific security concerns, due to its
well-defined object model.
The following concerns are specific to Ethernet/IP:
l The CIP does not define any explicit or implicit mechanisms for security.
l The use of common Required Objects for device identification can facilitate
device identification and enumeration, facilitating an attack.
l The use of common Application Objects for device information exchange and
control can enable broader industrial attacks, able to manipulate a broad range
of industrial devices.
l Ethernet/IP’s use of UDP and Multicast traffic—both of which lack transmis -
sion control—for real-time transmissions facilitate the injection of spoofed traf -
fic or (in the case of multicast traffic) the manipulation of the transmission path
using injected IGMP controls.
Security Recommendations
Because Ethernet/IP is a real-time Ethernet protocol using UDP and IGMP, it is nec -
essary to provide Ethernet and IP-based security at the perimeter of any Ethernet/IP
network. It is also recommended that passive network monitoring be used to ensure
the integrity of the Ethernet/IP network, ensuring that the Ethernet/IP protocol is
only being used by explicitly identified devices and that no Ethernet/IP traffic is
originating from an unauthorized, outside source. This can be accomplished using a
SCADA-IDS/IPS or other network monitoring device capable of detecting and inter -
preting the Ethernet/IP protocol.
Profibus
Profibus (Process fieldbus) is a fieldbus protocol that was originally developed in the
late 1980s in Germany by the Central Association for the Electrical Industry. Several
specialized variants of Profibus exist, including Profibus-DP (Decentralized Periphery)
and Profibus-PA (Process Automation). The standardized variant is Profibus-DP, which 80 CHAPTER 4 Industrial Network Protocols
itself has three common variants: Profibus DP-V0, DP-V1, and DP-V2, each of which
represents a minor evolution of capabilities within the protocol. There are also three
profiles for Profibus communication: asynchronous, synchronous, and via Ethernet
using ethertype 0x8892. Profibus over Ethernet is also called Profinet .29
Profibus is a Master/ Slave protocol that supports multiple master nodes through
the use of token sharing: when a master has control of the token, it can commu -
nicate with its slaves (each slave is configured to respond to a single master). In
Profibus DP-V2, slaves can initiate communications to the master or to other slaves
under certain conditions. Typically, a master Profibus node is a PLC or RTU, and a
slave is sensor, motor, or some other control system device.
Security Concerns
Profibus lacks authentication inherent to many of its functions, allowing a spoofed
node to impersonate a master node, which in turn provides control over all con -
figured slaves. A compromised master node or a spoofed master node could also
be used to capture the token, inject false tokens, or otherwise disrupt the protocol
functions, causing a DoS. A rogue master node could alter clock synchronization to
slave devices, snoop query responses (across all masters), or even inject code into a
slave node.
Profibus over Ethernet (Profinet) is a real-time Ethernet protocol, and as such it
is susceptible to any of the vulnerabilities of Ethernet. When used over the IP, it is
also susceptible to any vulnerabilities of IP.
NOTE
Stuxnet (see Chapter 3, “Introduction to Industrial Network Security”) is an example of Profibus exploitation. Stuxnet compromised PLCs (master Profibus nodes), which were then used to monitor the Profibus and look for specific behaviors associated with fre - quency controllers. Once the sought-after conditions were detected, Stuxnet then issued commands to the relevant slave nodes to sabotage the process.
Security Recommendations
As with many fieldbus protocols, the inherent lack of authentication and vulnerabil -
ity of the protocol requires strong isolation of the bus. If Profinet is used, it should
be controlled and used only over authenticated and encrypted networks. Monitoring
of Ethernet networks for unauthorized or suspicious use of Profinet should be
implemented as well, and firewalls and IPS devices should be configured to explic -
itly deny Profinet outside of well-defined areas.
EtherCAT
EtherCAT is another real-time Ethernet fieldbus protocol, which uses a defined
Ethernet ethertype (0x88A4) to transport control systems communications over
standard Ethernet networks. To maximize the efficiency of distributed process data
communications (which requires only a few bytes per cycle) over Ethernet frames 81 Other Industrial Network Protocols
(which vary in size from 46 to 1500 bytes of payload), EtherCAT communicates
large amounts of distributed process data with just one Ethernet frame, so that typi -
cally only one or two Ethernet frames are required for a complete cycle. Slaves pass
the frame(s) to other slaves in sequence, appending its appropriate response, until
the last slave returns the completed response frame back. 30
Security Concerns
EtherCAT is a real-time Ethernet protocol, and as such it is susceptible to any of
the vulnerabilities of Ethernet. EtherCAT over UDP is transaction-less and so there
is no inherent network-layer mechanism for reliability, ordering or data integrity
checks.
As with many real-time Ethernet protocols, EtherCAT is sensitive and highly
susceptible to DoS attacks. EtherCAT is easily disrupted via the insertion of rogue
Ethernet frames into the network to interfere with time synchronization and is sub -
ject to spoofing and MITM attacks due to the lack of bus authentication, requiring
the separation of EtherCAT from other Ethernet systems.
Security Recommendations
Because EtherCAT is a real-time Ethernet protocol, it is necessary to provide
Ethernet-based security at the perimeter of any EtherCAT network. It is also rec -
ommended that passive network monitoring be used to ensure the integrity of the
EtherCAT network, ensuring that the EtherCAT protocol is only being used by
explicitly identified devices and that no EtherCAT traffic is originating from an
unauthorized, outside source. This can be accomplished using a SCADA-IDS/IPS or
other network monitoring device capable of detecting and interpreting the EtherCAT
protocol. A network monitoring product or probe can also be used to detect Ethernet
packets using EtherCAT’s specific ethertype.
Ethernet Powerlink
Ethernet Powerlink uses Fast Ethernet as the basis for real-time transmission
of industrial control messages. A master node is used to initiate and synchronize
cyclic polling of slave devices, by transmitting a master “Start of Cycle” frame that
provides a basis for the network synchronization. The master then polls each sta -
tion; slaves can only respond if they receive a poll request frame, ensuring that all
Master/ Slave communications occur in sequence. Slave responses are broadcast,
eliminating source address resolution. Because collisions are avoided solely via the
carefully controlled request/response cycles, Ethernet Powerlink is best used homo -
geneously: the introduction of other Ethernet-based systems could disrupt synchro -
nization and cause a failure. 31
Ethernet Powerlink is often used in conjunction with CANopen, an applica -
tion layer protocol based on CAN (Controller Area Network). CANopen enables
the communication between devices of different manufacturers, and the protocol
stacks are widely available including open-source distribution for both Windows 82 CHAPTER 4 Industrial Network Protocols
and Linux platforms. The open nature of CANopen makes Ethernet Powerlink/
CANopen a desirable combination for industrial networks requiring inexpensive
solutions in Linux environments. 32
Security Concerns
Ethernet Powerlink is a real-time Ethernet protocol, and as such it is susceptible to
any of the vulnerabilities of Ethernet. Ethernet Powerlink is designed for use over
all IPs, including TCP, UDP, and HTTP, and it is therefore also susceptible to any
corresponding IP vulnerabilities.
As with many real-time Ethernet protocols, Ethernet Powerlink is sensitive and
highly susceptible to DoS attacks. Ethernet Powerlink is easily disrupted via the
insertion of rogue Ethernet frames into the network, requiring the separation of
Ethernet Powerlink from other Ethernet systems. The protocol itself is sensitive and
highly susceptible to DoS attacks.
Security Recommendations
Because sensitivity of the cyclic polling mechanism requires separation from other
non–Powerlink Ethernet services, Ethernet Powerlink implementations will most
likely have a clear demarcation from other networks. This demarcation can be lev -
eraged to further isolate the industrial protocol, through the establishment of strong
perimeter defenses at these boundaries.
SERCOS III
SERCOS (Serial Real-time Communications System) is a fieldbus specialized for
digital motion control. SERCOS III is a real-time Ethernet communication protocol
specifically designed for serial communications between PLCs and IEDs, operating
at high speeds within closed loops. 33
SERCOS III is a Master/ Slave protocol that operates cyclically, using a mecha -
nism in which a single Master Synchronization Telegram is used to communicate
to slaves, and the slave nodes are given a predetermined time (again synchronized
by the master node) during which they can place their data on the bus. All messages
for all nodes are packaged into a Master Data Telegram, and each node knows which
portion of the MDT it should read based upon a predetermined byte allocation. 34
An interesting addition to SERCOS III is that, although SERCOS dedicates
the use of the bus for synchronized real-time traffic during normal cycles, it allows
unallocated time within a cycle to be freed up for other network protocols such as
IP. This “IP Channel” allows the use of broader network applications from the same
device—for example, a web-based management interface that would be accessible
to business networks. 35
Security Concerns
SERCOS III is a real-time Ethernet protocol, and as such it is susceptible to any
of the vulnerabilities of Ethernet. SERCOS III introduces new security concerns
through the option to support embedded, open TCP/IP communications. With this
option enabled, a compromised RTU or PLC using SERCOS III could be used to 83 AMI and the Smart Grid
launch an in-bound attack into other corporate communications systems, including
SCADA and business networks.
Security Recommendations
SERCOS III should be isolated to control loops that require the protocol, and the
use of IP channels should be seriously considered and avoided where possible. If IP
channels are used, the extent and reach of the IP channel should be enclosed within
an explicitly defined enclave consisting of the SERCOS III master node and only
those TCP/IP network devices that are absolutely required.
AMI AND THE SMART GRID
The smart grid is a term encompassing many aspects of modern power transmis -
sion. Although smart grid technology might seem irrelevant to many industrial net -
work systems outside of the energy industry, it is discussed briefly here because of
its broad reach and vulnerable attack surface. The smart grid is a widely distributed
communication network that touches both energy production and transmission sys -
tems and many end user networks. Therefore, the smart grid represents an easily
accessible network that contains many vectors to many possible targets; once com -
promised, an attacker could use the network to attack the power utility’s network,
or to attack the networks of connected home and/or business networks.
The term “smart grid” is widely used and generally refers to a new generation
of energy distribution built around an Advanced Metering Infrastructure (AMI).
AMI promises many new features designed to increase the efficiency and reduce the
costs of energy distribution. Common AMI features include Remote Meter Reading;
Remote Billing; Demand/Response Energy Delivery; Remote Connect/Disconnect;
and Remote Payment and Prepayment. 36
At a high level, the smart grid requires coordination among the following
systems:
l Bulk Generation Systems
l Transmission Systems
l Distribution Systems
l Customer Information and Management Systems
l Usage and Meter Management Systems
l Billing Systems
l Interconnected network systems, including Neighborhood Area Networks (often
using wireless mesh technologies); Metropolitan Area Networks (MANs); Home
Area Networks (HANs); and Business Area Networks (BANs)
-
connecting power suppliers to power consumers (see Figure 4.15 ). It is made of
highly diverse systems, using diverse protocols and network topologies. Smart
grids even introduce new protocols. To support home- and business-based service 84 CHAPTER 4 Industrial Network Protocols
portals, Smart Metering introduces HAN and BAN protocols, such as Zigbee and
HomePNA, as well as power line protocols such as IEC 61334, Control Network
Power Line (PL) Channel Specification, and Broadband over Powerline (BPL).
Although the data link and application protocols are too numerous to discuss
in detail, it is widely accepted that TCP/IP will be leveraged for network-layer
communications. 37
Although these specific protocols will not be discussed within this book, it is
important to recognize that the disparate nature of these systems requires that sev -
eral distinct operational models and several distinct network architectures combine
to form a single end-to-end communications path, as illustrated in Figure 4.15 . This
means that while many distinct smart grid protocols may be used, the smart grid as
a whole should be considered as a single, highly accessible communications net -
work that is highly interconnected.
Security Concerns
The security concerns of smart grid are numerous. AMI represents an extremely
large network that touches many private networks and is designed for command
and control in order to support remote disconnect, demand/response billing, and
other features. 38 Combined with a lack of industry-accepted security standards, the
smart grid represents significant risk to connected systems that are not adequately
isolated. Specific security concerns include the following:
l Smart meters are highly accessible and therefore require board- and chip-level
security in addition to network security.
l Smart grid protocols vary widely in their inherent security and vulnerabilities.
l Neighborhood, home, and business LANs can be used both as an ingress to the
AMI, and as a target from the AMI.
FIGURE 4.15
Smart Grid Operational Areas and Protocols. 85 Summary
l Smart grids are ultimately interconnected with critical power generation and
distribution systems.
l Smart grids represent a target to private hackers (for financial gain or service
theft) as well as to more sophisticated and serious attackers (for sociopolitical
gain or cyber warfare).
Security Recommendations
The best recommendation for smart grid security at this point is for electric utilities
to carefully assess smart grid deployments and to perform risk and threat analysis
early in the planning stages, and for the end users who are connected to the smart
grid to perform a similar assessment of the system as a potential threat vector into
the business (or home) network.
Again, clear delineation, separation of services, and the establishment of strong
defense in depth at the perimeters will help to minimize any threat associated with
the smart grid. For the smart grid operators, this could represent a challenge (espe -
cially in terms of security monitoring) due to the broad scale of smart grid deploy -
ments, which could contain hundreds of thousands or even millions of intelligent
nodes. Therefore, it may be necessary to carve smart grid deployments into multiple,
smaller and more manageable security enclaves.
SUMMARY
Industrial networks use a variety of specialized “fieldbus” protocols to accomplish
specific tasks, often with careful attention to synchronization and real-time opera -
tion. Each protocol has varying degrees of inherent security and reliability, and these
qualities should be considered when attempting to secure these protocols. However,
because industrial network protocols, in general, lack sufficient authentication or
encryption, all are susceptible to cyber attack using relatively simple MITM attacks,
which can be used to disrupt normal protocol operations or potentially to alter or
otherwise manipulate protocol messages to steal information, commit fraud, or
potentially cause a failure of the control process itself.
By understanding each protocol and isolating each into its own carefully
defined security enclave, these protocols can be reasonably secured (see Chapter 7,
“Establishing Secure Enclaves”). Because each protocol has specific uses within a
control system, the creation of enclaves based purely on physical devices is possi -
ble and relatively simple. However, as industrial network protocols are used more
widely over Ethernet and/or TCP/IP, the creation of clean enclave boundaries
becomes more difficult, as boundaries begin to overlap. For this reason, the use of
“business” network protocols to transport fieldbus protocols should be avoided
unless absolutely necessary, and be especially scrutinized and tested where they are
necessary. 86 CHAPTER 4 Industrial Network Protocols
ENDNOTES
11. The DNP Users Group, DNP3 Primer, Revision A. ,http://www.dnp.org/About/
DNP3%20Primer%20Rev%20A.pdf ., March, 2005 (cited: November 24, 2010).
5. The DNP Users Group, DNP3 Primer, Revision A. ,http://www.dnp.org/About/
DNP3%20Primer%20Rev%20A.pdf ., March 2005 (cited: November 24, 2010).
6. G.R. Clarke, Deon Reynders Practical Modern SCADA Protocols: DNP3, 60870.5 and
Related Systems, Newnes, Oxford, UK and Burlington MA, 2004.
7. The DNP Users Group, DNP3 Primer, Revision A. ,http://www.dnp.org/About/
DNP3%20Primer%20Rev%20A.pdf ., March 2005 (cited: November 24, 2010).
4. Ibid.
2. Ibid.
1. The Modbus Organization, Modbus Application Protocol Specification V1.1b. ,http://
www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf ., December 2006
(cited: November 24, 2010).
3. J.T. Michalski, A. Lanzone, J. Trent, S. Smith, SANDIA Report SAND2007-3345: Secure
ICCP Integration Considerations and Recommendations, Sandia National Laboratories,
Albuquerque, New Mexico and Livermore, California, June 2007.
8. Ibid.
9. Digitalbond SCADAPEDIA, Secure DNP3. ,http://www.digitalbond.com/wiki/index.
php/Secure_DNP3 ., August 2008 (cited: November 24, 2010).
10. Ibid.
12. A.B.M. Omar Faruk, Testing & Exploring Vulnerabilities of the Applications Implementing
DNP3 Protocol, KTH Electrical Engineering, Stockholm, Sweden, June 2008.
13. The OPC Foundation OPC Task Force, OPC Overview Version 1.0. ,http://www
.opcfoundation.org/Archive/c218e7b5-4e00-4f95-82ba-7da07eb17883/General/OPC%20
Overview%201.00.pdf ., October 27, 1998 (cited: November 24, 2010).
14. Ibid.
15. Digital Bond, British Columbia Institute of Technology, and Byres Research. OPC
Security White Paper #2: OPC Exposed (Version 1-3c), Byres Research, Lantzville, BC
and Sunrise, FL, November 13, 2007.
16. Microsoft Corporation, RPC Protocol Operation. ,http://msdn.microsoft.com/en-us/
library/ms818824.aspx . (cited: November 4, 2010).
17. European Organization for Nuclear Research (CERN), A Brief Introduction to OPC™
,http://itcofe.web.cern.ch/itcofe/Services/OPC/GeneralInformation/
Specifications/RelatedDocuments/DASummary/DataAccessOvw.html ., November 11,
2000 (cited: November 29, 2010).
18. Digital Bond, British Columbia Institute of Technology, and Byres Research, OPC Security
White Paper #1 Understanding OPC and How It Is Deployed (Version 1-3b), Byres
Research, Lantzville, BC and Sunrise, FL, July 27, 2007.
19. Ibid.
20. Digital Bond, British Columbia Institute of Technology, and Byres Research. OPC
Security White Paper #2: OPC Exposed (Version 1-3c), Byres Research, Lantzville, BC
and Sunrise, FL, November 13, 2007.
21. Ibid.
22. Ibid.
23. Ibid. 87 Endnotes
24. Ibid.
25. Ibid.
26. Ibid.
27. Ibid.
36. UCA ® International Users Group, AMI-SEC Task Force, AMI System Security
Requirements, UCA, Raleigh, NC, December 17, 2008.
37. National Institute of Standards and Technology, NIST Special Publication 1108: NIST
Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0,
February 2010.
31. P. Doyle, Introduction to Real-Time Ethernet II. The Extension: A Technical Supplement
to Control Network, vol. 5, Issue 4, Contemporary Control Systems, Inc., Downers
Grove, IL, July 2004.
32. Ethernet POWERLINK Standardization Group, CANopen. ,http://www.ethernet-power -
link.org/index.php?id 39., 2009 (cited: November 24, 2010).
33. SERCOS International, Technology: Introduction to SERCOS interface. ,http://www
.sercos.com/technology/index.htm ., 2010 (cited: November 24, 2010).
34. SERCOS International, Technology: Cyclic Operation. ,http://www.sercos.com/technology/
cyclic_operation.htm ., 2010 (cited: November 24, 2010).
35. SERCOS International, Technology: Service & IP Channels. ,http://www.sercos.com/
technology/service_ip_channels.htm ., 2010 (cited: November 24, 2010).
29. V.M. Igure, Security assessment of SCADA protocols: a taxonomy based methodology
for the identification of security vulnerabilities in SCADA protocols, VDM Verlag Dr.
Müller Aktiengesellschaft & Co. KG, 2008.
30. The EtherCAT Technology Group, Technical introduction and overview: EtherCAT—
,http://www.ethercat.org/en/technology.html#5 ., May 10, 2010
(cited: November 24, 2010).
28. ODVA, CIP Technology Overview. ,http://www.odva.org/Home/ODVATECHNOLOGIES/
CIP/CIPTechnologyOverview/tabid/68/Default.aspx ., 2010 (cited: November 24,
2010), Saarbrücken, Germany.
38. UCA ® International Users Group, AMI-SEC Task Force, AMI system security require -
ments, UCA, Raleigh, NC, December 17, 2008. This page intentionally left blank 89
How Industrial Networks
Operate
5
CHAPTER
I N F O R M AT I O N I N T H I S C H A P T E R :
l Control System Assets
l Network Architectures
l Control System Operations
l Control Process Management
l Smart Grid Operations
In addition to understanding how industrial network protocols operate, it is neces -
sary to understand how commonly used devices interact within an industrial net -
work. For operators of industrial control systems, this information may seem overly
basic. However, it is important to remember that how control systems are connected
and how they should be connected are not always the same, and so by taking a short
step back to the basics we can quickly assess whether there are any basic security
flaws in an industrial network design. This requires an understanding of the specific
assets, architectures, and operations of a typical industrial network.
CONTROL SYSTEM ASSETS
The first step is to understand the devices used within industrial networks and the
roles that they play. These devices, which are discussed in this chapter, include
operational devices such as sensors, motors, gauges, and other intelligent electronic
device s; Remote Terminal Units (RTUs) and/or Programmable Logic Controllers
(PLCs); Human Machine Interface (HMI) Control System Assets; Supervisory
Management Workstations; Data Historians; and Business Information Consoles or
Dashboards.
IEDs
An intelligent electronic device (IED) is any device commonly used within a con -
trol system—such as a sensor, actuator, motor, transformers, circuit breakers, and
pumps—that is equipped with a small microprocessor that enables it to communicate
digitally. These devices communicate almost exclusively using fieldbus protocols, 90 CHAPTER 5 How Industrial Networks Operate
operating as slave nodes, and are controlled via an upstream RTU or PLC. As with
all technology, IEDs are growing more and more sophisticated over time, and an IED
may perform other tasks, blurring the line between device types. However, to simplify
things for the purposes of this book, an IED can be considered to support a specific
function (i.e., a motor can spin at different frequencies) within the control system,
typically within a specific control loop, whereas RTUs and PLCs are designed for
general use (i.e., they can be programmed to control the speed of a motor, to engage a
lock, to activate a pump, etc.).
RTUs
A Remote Terminal Unit (RTU) typically resides in a substation or other remote
location. RTUs monitor field parameters and transmit that data back to a central
monitoring station—typically either a Master Terminal Unit (MTU), or a centrally
located PLC, or directly to an HMI system. RTUs, therefore, include remote com -
munications capabilities, consisting of a modem, cellular data connection, radio, or
other wide area communication capability. They will typically use industrial net -
work protocols such as DNP3 to communicate between master and remote units,
and either DNP3 or Modbus, Profibus or some other common fieldbus protocol to
communicate with IEDs (see Chapter 4, “Industrial Network Protocols”).
RTUs and PLCs continue to overlap in capability and functionality, with many
RTUs integrating programmable logic and control functions, to the point where an
RTU can be thought of as a remote PLC.
PLCs
A programmable logic controller (PLC) is a specialized computer used to automate
functions within industrial networks. Unlike desktop computers, PLCs are typically
materially hardened (making them suitable for deployment on a production floor)
and may be specialized for specific industrial uses with multiple specialized inputs
and outputs. PLCs also differ from desktop computers in that they do not typically
use a commercially available operating system (OS); instead they rely on blocks
of logic code that allow the PLC to function automatically to specific inputs (e.g.,
from sensors) with as little overhead as possible. PLCs were originally designed
to replace relays, and very simple PLCs may be referred to as programmable logic
relays (PLRs).
PLCs typically control real-time processes, and so they are designed for sim -
ple efficiency. For example, in plastic manufacturing, a catalyst may need to be
injected into a vat when the temperature reaches a very specific value; if processing
overhead or other latency introduces delay in the execution of the PLC’s logic, it
would be very difficult to precisely time the injections, which could result in quality
issues. For this reason, the logic used on PLCs is typically very simple and usually
based on ladder logic (although almost any programming language could theoreti -
cally be supported).
Again, as technology evolves, the line blurs between RTU, PLC, and IED, as
can be seen in Emerson Process Management’s ROC800L liquid hydrocarbon 91 Control System Assets
remote controller shown in Figure 5.1. This device performs measurement, diag -
nostics, and remote control in a single device that supports several programmable
languages.
Ladder Logic
PLCs often use “ladder logic,” a simplistic programming language that is
well suited for industrial applications. Ladder logic is based on relay-based
logic and can be thought of as a set of connections between inputs (contacts)
and outputs (coils). Ladder logic follows a relay function diagram, as shown in
Figure 5.2. A path is traced on the left side, across “rungs” consisting of various
inputs. If an input relay is “true” the path continues, and if it is “false” it does not.
If the path to the right side completes (there is a complete “true” path across the
ladder), the ladder is complete and the output coil will be set to “true” or “ener -
gized.” If no path can be traced, then the output remains “false,” and the relay
remains “de-energized.” 1
The PLC applies this ladder logic by looking at inputs from digital or analog
devices such as sensors that are connected to the outside world and comparing them
to set points. PLCs can use a variety of digital and analog communications meth -
ods, but typically use a fieldbus protocol such as Modbus or Profibus (see Chapter 4,
“Industrial Network Protocols”). If a set point is satisfied, the input is considered
“true,” and if it is not it is considered “false.” Processes defined by ladder logic can
be simple or very complex. For example, an “or” condition can allow the rung to
complete based on an alternate input condition, as shown in Figure 5.3.
FIGURE 5.1
Emerson Process Management’s ROC800L Liquid Hydrocarbon Remote Controller.
Photo courtesy of Emerson Process Management. 92 CHAPTER 5 How Industrial Networks Operate
FIGURE 5.2
Example of Simple Ladder Logic, with Both Complete and Incomplete Conditions.
FIGURE 5.3
Example of Simple Ladder Logic, Containing an “or” Condition. 93 Control System Assets
When an output is finally reached it becomes “true,” and the PLC activates the
output. This allows the PLC to automate a function (e.g., turning a pump on or off)
based on set point parameters (e.g., high and low water levels within a tank). 2
Ladder logic is created using a software application on a PC and then is pro -
grammed onto a PLC by connecting that PC and transferring the ladder logic code
onto the PLC. This PC can be a dedicated system or it can be a function of an HMI
system. Internal relays may also be used within a PLC—these relays, unlike input
relays, do not use inputs from outside but can be used by the ladder logic to lock
an input on (true) or off (false) depending upon other conditions of the program.
Finally, PLCs can use counters and timers, allowing PLCs to act in defined cycles
or pulses, as well as storage. 3
Sometimes PLCs use “Step Logic,” which differs from ladder logic in that each
step is tested in isolation and progresses to the next step only upon completion,
whereas in ladder logic every step is tested in each scan. Again, almost any pro-
gramming language could be supported on a modern PLC. However, the end goal is
ultimately to automate the relay functions common in industrial systems by check -
ing inputs, applying logic (the program), and adjusting outputs as appropriate, 4 as
shown in Figure 5.4.
HMIs
Human machine interfaces (HMIs) are used as an operator control panel to PLCs,
RTUs, and in some cases directly to IEDs. HMIs replace manually activated
switches, dials, and other controls with graphical representations of the control proc -
ess and digital controls to influence that process. HMIs allow operators to start and
stop cycles, adjust set points, and perform other functions required to adjust and
interact with a control process. Because the HMI is software based, they replace
physical wires and controls with software parameters, allowing them to be adapted
and adjusted very easily.
FIGURE 5.4
PLC Operational Flow Diagram. 94 CHAPTER 5 How Industrial Networks Operate
HMIs are modern software applications running on modern operating systems,
and as such they are capable of performing many functions. They act as a bridge
between the human operator and the complex logic of one or more PLCs, allowing
the operator to function on the process rather than on the underlying logic that per -
forms the function and to control many functions across distributed and potentially
complex processes from a centralized location. To accomplish this, the user interface
will graphically represent the process being controlled, including sensor values and
other measurements, and visible representation of output states (which motors are
on, which pumps are activated, etc.).
Humans interact with the HMI through a computer console, and as such must
authenticate to the HMI system using password protection. Because HMIs provide
supervisory data (visual representation of a control process’s current state and val -
ues) as well as control (i.e., set point changes), user access may lock out specific
functions to specific users. The security of the industrial process therefore relies
heavily on access control and host security of the HMI.
The HMI, in turn, interacts with one or more PLCs and/or RTUs, typically using
industrial protocols such as OLE for Process Control (OPC) or fieldbus protocols
such as Modbus (see Chapter 4, “Industrial Network Protocols”).
Supervisory Workstations
A supervisory workstation collects information from assets used within a control
system and presents that information for supervisory purposes. Unlike an HMI, a
supervisory workstation is primarily read-only; that is, there is no control element
to interact directly with the control process, only the presentation of information
about that process.
Typically, a supervisory workstation will consist of either an HMI system (with
read-only or supervisory access restrictions) or a Data Historian—a device specifically
designed to collect a running audit trail of control system operational data. Supervisory
workstations can reside within the Supervisory Control and Data Acquisition demili -
tarized zone (SCADA DMZ) or within the business network—up to and including
Internet-facing web portals, Intranets, etc. (see “Control Processes” on page 102).
CAUTION
When placing a supervisory workstation or any other service outside of its intended security enclave, the overall security of that enclave is weakened. For example, by placing a SCADA supervisory console in the business network, the console can be more easily accessed by an attacker and then utilized to communicate back into the SCADA DMZ. This is covered in detail in Chapter 7, “Establishing Secure Enclaves”.
Data Historians
A Data Historian is a specialized software system that collects point values and other
information from industrial devices and stores them in a purpose-built database. 95 Control System Assets
Most industrial asset vendors—including ABB, Arreva, Emerson, GE, Invensys,
Rockwell, Siemens, and others—provide their own proprietary Data Historian sys -
tems. In addition, there are third-party industrial Data Historian vendors, such as
Canary Labs ( www.canarylabs.com ), Modiüs ( www.modius.com ), and OSIsoft
(www.osisoft.com ), which interoperate with third-party assets and even integrate
with third-party Data Historians in order to provide a common, centralized platform
for data historization and analysis.
Data points that are historized and stored within a Data Historian are referred
to as “tags” and can represent almost anything—the current frequency of a motor
or turbine, the rate of airflow through an heating, ventilation, and air-conditioning
(HVAC) system, the total volume in a mixing tank, the specific volumes of injected
chemical catalysts in a tank, etc. Tags can even represent human-generated values,
such as production targets and acceptable loss margins.
Because the information stored within a Data Historian is used by both industrial
operations and business management, Data Historians are often replicated across an
industrial network. This can represent a security risk, as a Data Historian in a less
secure zone (i.e., the business network) could be used as a vector into more secure
zones (i.e., the SCADA DMZ). As such, Data Historians should be isolated, secured
within their own enclaves, and should be patched regularly to minimize vulnerability.
NOTE
The information collected by a Data Historian is stored centrally within a database. Depending upon the Data Historian used, this could be a commercial Relational Database Management System (RDBMS), specialized columnar or time-series database system, or some other proprietary data storage system. The type of database used is important for several reasons. First, the Data Historian will typically be responsible for collecting information from thousands or even millions of devices. Especially in larger networks, the capabilities of the database in terms of data collection performance can impact the Data Historian’s ability to collect operational information in real time. Second, and more importantly within the context of this book, is that commercial RDBMSs may present spe - cific vulnerabilities to cyber attack. The Data Historian and any auxiliary system (database server, network storage, etc.) should be included in any vulnerability assessment, and care should be taken to isolate and secure these systems along with the Data Historian server.
At the time of this writing, OSIsoft holds a dominant position in the Historian
market, with 65% market penetration in global industrial automated systems. 5 The
OSIsoft PI System integrates with many IT and OT systems including other Data
Historians, and as such is a premium target for attack. Again, applying the lat-
est updates and patches can minimize vulnerabilities, while properly isolating and
securing PI within its own enclave can minimize accessibility. For more informa -
tion about the role of Data Historians within control system operations, see “Control
Processes: Feedback Loops” and “Control Processes: Business Information
Management” later in the chapter. 96 CHAPTER 5 How Industrial Networks Operate
Business Information Consoles and Dashboards
Business Information Consoles are extensions of supervisor workstations designed to
deliver business intelligence information to upper management. They typically consist
of read-only representations of the same data obtained from HMI or Data Historian
systems. In some cases, a Business Information Console is a physical console: a com -
puter display connected to an HMI or Historian within the SCADA DMZ, but physi -
cally located elsewhere (such as an executive office or trading floor). In these cases,
the physical display is remotely connected using a remote display or secure remote
Keyboard Video Mouse (KVM) switching system. Business information may also
be obtained by replicating HMI or Data Historian systems within the business net -
work or by publishing exported information from these systems using an intermediary
system, for example, exporting Data Historian information to a spreadsheet and then
publishing that spreadsheet to a corporate information portal or intranet. Depending
upon the sophistication of the Data Historian, this publishing model may be stream -
lined and automated. In any case, any published data should be access controlled,
and any open communication path from SCADA systems to more openly accessible
workstations or portals should be very carefully controlled, isolated, and monitored.
Other Assets
There are many other assets that may be connected to an industrial network other
than PLCs, RTUs, HMIs, Historians, and various workstations. Devices such as
printers and print servers may be connected to corporate networks, or they may
connect directly to a control loop. Physical access control systems such as badge
scanners and biometric readers may be used, and these devices may be networked
(probably over Transmission Control Protocol/Internet Protocol [TCP/IP]).
Although this book does not attempt to cover every aspect of every device that
may be present within an industrial network, it is important to recognize that every
device has a potential impact to security and should be assessed if:
1. It is connected to a network of any kind (including wireless networks originat -
ing from the device itself, as with some printers).
2. It is capable of transporting data or files, such as removable media (mobile
devices).
Even the most harmless seeming devices should be assessed. Check the docu-
mentation of devices to make sure that they do not have wireless capabilities, and
if they do, secure or disable those features. Many commercially produced devices
contain multipurpose microprocessors, which may contain radio or Wi-Fi anten-
nae receivers or transmitters even if the device is not intended for wireless commu -
nication. This is because it is sometimes more cost-effective to use a commercial,
off-the-shelf (COTS) microprocessor with unneeded capabilities; those capabilities
may never be enabled by the manufacturer, but if the hardware exists it can be used
as an attack vector by hackers. 6 97 Network Architectures
NETWORK ARCHITECTURES
As with all networks, industrial networks vary considerably. However, because
many common functions within industrial systems vary widely—from automation
systems, to supervisory and control systems, to business systems—there are natu -
ral demarcations within the network where these systems intersect. Table 5.1 indi -
cates some of the major difference between these functional groups. The primary
requirement of an industrial automation system is real-time operation and reliability,
while the primary requirement of a business network might be high bandwidth and
low operation costs. These requirements drive the use of real-time fieldbus protocols
within control system processes and control loops, while business networks utilize
fast, low-cost Ethernet networks and TCP/IP. SCADA systems sit between these two
very different networks. In many ways, SCADA systems share the requirements of
the control system itself—they need to be able to operate in real time, for example.
However, they must also communicate with business systems over TCP/IP.
For this reason, a DMZ is recommended for supervisory systems. The SCADA
DMZ sits between the operational and automation systems that they are supervising
and controlling, and the business networks and business information systems. The
DMZ is protected from both directions, using a firewall, intrusion detection and/or
protection system, a data diode, or other perimeter defensive mechanism to prevent
unauthorized traffic from crossing into or out of the DMZ. Logically, this creates
three network areas: business, supervisory, and operations, as illustrated in Figure 5.5 .
Table 5.1 Differences in Industrial Network Architectures by Function
Function Industrial Automation SCADA Enterprise
Real-time operation Critical High Best effort
Reliability requirements Critical High Best effort
Bandwidth requirements Low Low High
Protocols used Fieldbus Fieldbus, TCP/IP TCP/IP
FIGURE 5.5
Functional Demarcation of Industrial Networks. 98 CHAPTER 5 How Industrial Networks Operate
The operational and automation systems contain PLCs, RTUs, and IEDs, as
well as HMI systems. The SCADA DMZ will also contain HMI systems, as well as
Data Historians, MTUs (connecting to remote facilities), and Inter Control Center
Protocol (ICCP) clients and servers for communicating with peer systems (see
Chapter 4, “Industrial Network Protocols”). Business networks contain common
computing and business systems, as well as supervisory workstations and replicated
Data Historians.
Topologies Used
Industrial networks are typically very distributed and vary considerably in all
aspects, including the link layer and network protocols used, as well as the topol -
ogy. In the business networks, however, Ethernet and TCP/IP networks are ubiq -
uitous, using a variety of star, tree, and even full-mesh topologies. The ubiquity of
Ethernet and TCP/IP make it the “glue” that connects other SCADA and industrial
control systems together. SCADA and industrial control system networks may uti -
lize bus, ring, star, and tree topologies depending upon the specific type of control
process that is in operation and the specific protocols that are used. For example,
an automated control process to sanitize water may use a bus topology with the
Modbus protocol, while another control process may use Profibus in a ring topology
to control pumping or filtration systems (see Figure 5.6 for examples of topology
use within and across an industrial network). The SCADA DMZ must communicate
to both sides: on one side a number of industrial network protocols and on the other
corporate Ethernet TCP/IP networks. As such, the SCADA DMZ will require proto -
col gateways to translate between the two environments (see Chapter 4, “Industrial
Network Protocols”). These gateways can be standalone network devices, or they
may be a built-in function of MTUs, HMIs, PLCs, or other industrial assets.
The specific topology used has little impact on the security of any particular net -
work. More important is the boundary of a network area (which will help to deter -
mine how an attacker can migrate between systems) and the protocol(s) used within
a network area (which will help to determine how a specific network area may
be vulnerable). Although these areas are shown at a very high level in Figure 5.5 ,
each network area that can be differentiated from its neighbors—ICCP intercon -
nects versus OPC SCADA systems versus different control groups using DNP3,
Modbus, etc.—can and should be isolated behind a secure periphery (see Chapter 7,
“Establishing Secure Enclaves”).
Special Topology Considerations
One area that deserves special consideration is the smart grid. As mentioned in
Chapter 4, “Industrial Network Protocols,” the smart grid is an extensive network
providing advanced metering and communications capabilities to power distribu -
tion, and as such it is at once specific to the energy industry and yet also a concern 99 Network Architectures
for any other industrial network that may connect to the smart grid as a client of the
energy industry.
As with all networks, the “smart grid” also varies widely by deployment, and the
topologies and protocols used will vary accordingly. However, there is one primary
quality that is consistent across any smart grid deployment, and that is its scale and
accessibility. As a distribution system designed to deliver power ubiquitously to resi-
dences, offices, storefronts, and all aspects of urban infrastructure, even small smart
grid deployments create large numbers of nodes and network interconnections, often
in hundreds of thousands or even in millions. The scale of a smart grid requires the
use of some mechanism to “tier” or hierarchically distribute the nodes.
Represented in terms of an addressable attack surface, smart grids provide broad
and easy access to a network that ultimately interconnects to our energy transmis-
sion and distribution infrastructure, as well as to many interconnected homes and
businesses. In Figure 5.7, the attack surface is illustrated as being exponentially
larger as we radiate outward from core energy generation through to the outer
reaches of the smart grid.
FIGURE 5.6
Common Topologies in Industrial Networks. 100 CHAPTER 5 How Industrial Networks Operate
Scalability also plays a role in the development of smart grid devices, putting
significant cost pressure on the end-node devices (Smart Meters). Any device
deployed at such a large-scale needs to be as efficient to build, deploy, and operate
as possible. Because of the costs and complexity of providing security assurance
and testing in the various supply, design, and manufacturing stages of Smart Meter
development, this business driver is a real concern. As pressures force costs down,
there is an increased chance that some physical or network-based vulnerability will
find its way into production, and therefore into one of the most easily reachable net -
works ever built.
CONTROL SYSTEM OPERATIONS
All of the industrial network protocols, devices, and topologies discussed up to
this point are used to create and automate some industrial operations: refining oil,
manufacturing a consumer product, filtering water, generating electricity, synthesiz -
ing and combining chemicals, etc. A typical industrial operation consists of several
layers of programmed logic designed to manipulate mechanical controls in order
to automate the operation. Each specific function is automated by a control loop,
while multiple control loops may be combined or stacked together to automate
larger processes.
FIGURE 5.7
The Smart Grid Attack Surface Relative to Other Network Areas. 101 Control System Operations
Control Loops
Industrial networks are made up of many specific automated processes, called con -
trol loops. The term “loop” derives from the ladder logic that is widely used in
these systems: a controller device such as a PLC is programmed with specific logic;
the PLC then cycles through its various inputs, applying the logic to adjust outputs
or controls, in order to perform a specific function. This cycle or “loop” automates
that function.
In a closed loop, the output of the process affects the inputs, fully automating
the process. For example, a water heater is programmed to heat water to 90°C. An
electric heater coil is then engaged to heat the water, and the water temperature is
measured and fed back into the process; when 90°C is reached, the heater will turn
off inputs from outside of the specific process. In an open loop, the output of the
process does not affect the inputs, such as when the coil of a water heater is manu -
ally engaged, independent of the current water temperature. In other words, closed
loops provide automated control whereas open loops provide manual control.
Control loops can be very simple, checking a single input, as illustrated in
Figures 5.8 and 5.9 . For example, a simple loop in an automated lighting process
might check a single input (e.g., a light sensor to measure ambient light) and adjust
a single output (e.g., the dimmer switch on a lamp). Very complex loops might use
FIGURE 5.8
A Simplified Control Loop in the ON State, Showing the Applied Ladder Logic. 102 CHAPTER 5 How Industrial Networks Operate
multiple inputs (e.g., pressure, volume, flow, and temperature sensors) and adjust
multiple outputs (e.g., valves, pumps, heaters) to perform a function that is inher -
ently more complex—in this case, maintaining a constant pressure in a dynamic
fluid system.
Multiple control loops may be required to perform even more complex control
processes. They may be controlled by a central HMI, or they may themselves be
part of a larger control loop, acting as inputs or outputs into another level of logic,
controlled by a master or central PLC.
Control Processes
A “control process” is a general term used to define larger automated processes
within an industrial operation. Many control processes may be required to manu -
facture a product or to generate electricity, and each control process may consist of
one or many control loops. For example, one process might be to inject an ingredi -
ent into a mixer, and that process may consist of a control loop that opens a valve
in response to volume measurements within the mixer, temperature, and other
FIGURE 5.9
A Simplified Control Loop in the OFF State, Showing the Applied Ladder Logic. 103 Control System Operations
conditions. Several such processes can automate the correct timing and combina -
tion of several ingredients, which in turn complete a larger process (to make a bat -
ter). The mixed batter might then be transported to other entirely separate control
processes for baking, packaging, and labeling.
Each process is typically managed using an HMI, which is used to interact with
that process. Typically, an HMI will provide relevant readings from one or more
control loops, requiring communication to all daughter systems, typically PLCs or
RTUs. Some HMIs may include readouts of sensors and other feedback mecha -
nisms, as well as the activity of the PLCs, while others may issue direct control
operations and provide controls to adjust the set points of the ongoing control
process.
Again, an HMI may control a process consisting of many control loops; there -
fore, the HMI’s network connectivity is typically heterogeneous: connecting over
routable protocols (TCP/IP) as well as specialized SCADA and fieldbus protocols
and other industrial network protocols to the various PLCs and RTUs that make up
the individual loops. Because of this, HMIs are a common attack vector between
the routable SCADA and business networks.
Feedback Loops
Every automated process relies on some degree of feedback both within a control
loop and between a control loop or process and a human operator. Feedback is gen -
erally provided directly from the HMI used to control a specific process, as seen in
Figure 5.10. Feedback may also be centralized across multiple processes, through
the collection, analysis, and display of information from many systems. For exam -
ple, a refinery may have several crude oil tanks, each used in a replicated control
process. Information from each process can be collected and analyzed together to
determine production averages, overages, and variations.
FIGURE 5.10
An HMI Displaying Current Operational Parameters. 104 CHAPTER 5 How Industrial Networks Operate
The centralized information management of an industrial control system is typi -
cally performed by one or more Data Historian systems. The process of removing
data from the real-time environment of an industrial automation process and storing
it over time is called “historizing” the data. Once historized, the information can
be heavily analyzed, either directly from within the Data Historian or by using an
external analysis tool such as a spreadsheet.
Specific control system elements may use their own Data Historian system
to historize data locally. For example, an ABB 800xA control system may use
the 800xA Information Management Historian, while an Emerson Ovation con -
trol system may use the Ovation Process Historian. The need for a common Data
Historian that historizes all data across systems derives from the heterogeneous
nature of many industrial operations, where different processes may utilize assets
manufactured by different vendors, yet all processes need to be evaluated holisti -
cally in order to manage and fine-tune overall operations. In addition, there may be
value in collecting information from other devices and systems within the industrial
network, such as IT systems, HVAC systems, and Physical Security and Access
Control systems. The shift from process-specific data historization to operation-
wide business intelligence has led to the development of specialized features and
functionality within Data Historians.
Business Information Management
Operational monitoring and analysis provides valuable information that can be used
by business managers to fine-tune operations, improve efficiencies, minimize costs,
and maximize profits. As such, there is a need for replication of the operational
process data into the business network.
Supervisory data can be accessed using an HMI or a Data Historian, each of
which presents its own security challenges. HMIs provide supervisory and control
capabilities, meaning that an HMI user with the correct privileges can adjust parame -
ters of control process (see “Control Process Management” on page 106). By placing
an HMI outside of the SCADA DMZ, any firewalls, IDS/IPS, and other security
monitoring devices that are in place will need to be configured to allow the com -
munication of the HMI into and out of the SCADA DMZ, effectively reducing the
strength of the security perimeter between the SCADA and business networks to user
authentication only. That is, if a user account is compromised on the outside HMI
system, it can be used to directly manipulate control process(es), without further vali -
dation from perimeter security devices.
The use of a Data Historian for business intelligence management presents a sim -
ilar concern: the security perimeter must be configured to allow the communication
between the Data Historian in the Business network and the various systems within
the SCADA DMZ that need to be monitored. Unlike an HMI, a replicated Data
Historian does not explicitly allow control of the process. Instead, the Data Historian
provides a visual dashboard that can be configured to mimic the informational 105 Control System Operations
qualities and graphical representation of an HMI so that information about a process
can be viewed in a familiar format.
TIP
Because the replication of Data Historian systems into the business network is for information purposes only, these systems can be effectively connected to the SCADA DMZ using a unidirectional gateway or data diode (see Chapter 7, “Establishing Secure Enclaves”). This preserves the security perimeter between business and supervisory net - works, by allowing only outbound data communications. However, data outbound (from the SCADA DMZ to the business network) should still be secured using one or more secu - rity devices such as a firewall, IDS/IPS, or application monitor.
Data is collected by a Data Historian through a variety of methods including
direct communication via industrial network protocols such as Modbus, Profibus,
DNP3, and OPC (see Chapter 4, “Industrial Network Protocols”); via direct inser -
tions in the Data Historian’s database using Object Linking and Embedding Database
(OLEDB), Open Database Connectivity (ODBC), Java Database Connectivity
(JDBC), etc.; or using standard data exchange protocols such as the Simple Network
Management Protocol (SNMP) and Syslog. Most Data Historians support multiple
methods of data collection to support a variety of industrial applications. Once the
information has been collected, it is stored within a database schema along with rel -
evant metadata that helps to apply additional context to the data, such as batch num -
bers, shifts, or virtually anything (depending upon the Data Historian’s available
features and functionality).
Data Historian systems also provide access to historized data, typically through
the same supported