Full Chapter Cybersecurity For Scada Systems 2Nd Edition William T Shaw PDF
Full Chapter Cybersecurity For Scada Systems 2Nd Edition William T Shaw PDF
https://textbookfull.com/product/handbook-of-scada-control-
systems-security-second-edition-brodsky/
https://textbookfull.com/product/business-ethics-ninth-edition-
william-h-shaw/
https://textbookfull.com/product/moral-issues-in-business-
william-h-shaw/
https://textbookfull.com/product/canine-and-feline-behavior-for-
veterinary-technicians-and-nurses-2nd-edition-shaw/
American Politics Today (Sixth Edition) William T.
Bianco
https://textbookfull.com/product/american-politics-today-sixth-
edition-william-t-bianco/
https://textbookfull.com/product/hacking-exposed-industrial-
control-systems-ics-and-scada-security-secrets-and-solutions-
first-1st-edition-clint-bodungen/
https://textbookfull.com/product/bernard-shaw-on-religion-the-
critical-shaw-shaw/
https://textbookfull.com/product/american-politics-today-
essentials-sixth-edition-william-t-bianco/
https://textbookfull.com/product/financial-cybersecurity-risk-
management-leadership-perspectives-and-guidance-for-systems-and-
institutions-paul-rohmeyer/
Cybersecurity for SCADA Systems
CYBERSECURITY
FOR SCADA SYSTEMS
SECOND EDITION
Disclaimer
The recommendations, advice, descriptions, and the methods in this book are
presented solely for educational purposes. The author and publisher assume no
liability whatsoever for any loss or damage that results from the use of any of the
material in this book. Use of the material in this book is solely at the risk of the user.
Copyright © 2020 by
PennWell Books, LLC
10050 E 52nd Street
Tulsa, OK 74146
866-777-1814
[email protected]
www.pennwellbooks.com
Publisher: Matthew Dresher
Cover images: © iStock / Getty Images Plus - MF3d
© iStock / Getty Images Plus - TheYok
© Pipeline Knowledge, LLC
Library of Congress Cataloging-in-Publication Data
Names: Shaw, William T., author.
Title: Cybersecurity for industrial scada systems / William T. Shaw.
Description: Second edition. | Tulsa, OK, USA : PennWell Books, LLC, [2020]
| Includes bibliographical references and index. | Summary:
“Cybersecurity for SCADA Systems provides a high-level overview of SCADA
technology, with an explanation of each market segment. Readers will
understand the vital issues, and learn strategies for decreasing or
eliminating system vulnerabilities”— Provided by publisher.
Identifiers: LCCN 2020044734 (print) | LCCN 2020044735 (ebook) | ISBN
9781593705060 (hardback) | ISBN 9781593705053 (epub)
Subjects: LCSH: Supervisory control systems. | Automatic data collection
systems. | Data protection. | Computer security.
Classification: LCC TJ222 .S53 2020 (print) | LCC TJ222 (ebook) |
DDC 620/.46028558—dc23
LC record available at https://lccn.loc.gov/2020044734
LC ebook record available at https://lccn.loc.gov/2020044735
All rights reserved. No part of this book may be reproduced, stored in a retrieval
system, or transcribed in any form or by any means, electronic or mechanical, including
photocopying and recording, without the prior written permission of the publisher.
1 2 3 4 5 23 22 21 20 19
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Introduction: Industrial Automation in the Aftermath of 9/11 . . . . . . . . . . . . . xxi
Chapter 1
The technological evolution of scada systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
The Early History of SCADA—Mainframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Minicomputers and Microprocessors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Central Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Distributed Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Client/Server Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Technological Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Ubiquitous Internet and IP Networkingg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Generalized Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapter 2
Remote terminal units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Basic Features and Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Smart RTU Technologyy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Top-Down and Bottom-Up Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
The Emergence of PLCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Legacy Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Protocol Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
IP-Ready RTUs and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Chapter 3
Telecommunications technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Voice-Grade (Analog) Telephonyy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Commercial Voice/Data Carriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Options for Wireless Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Digital Networking Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
TCP/IP Networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
The Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
v
vi Cybersecurity for SCADA Systems
Chapter 4
Supervisory control applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Operating System Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
SCADA System Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Program Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Standardized APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Chapter 5
Operator interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Access-Control Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Standard System Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Site/Industry–Specific Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Historical Trendingg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Logs and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Chapter 6
Conventional information technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Availability, Integrity, and Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Remote Access/Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
TCP/IP Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Firewalls & Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Wireless LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Authentication and Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Encryption and Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Chapter 7
Identifying cybersecurity vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Threats and Threat Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Obvious Points of Attack and Vulnerabilityy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Chapter 8
Malware, cyberattacks and hacking tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
WEB Server/SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Email and Web browsingg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Chapter 9
Physical security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Access tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Illegal-entry Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Physical Isolation of Assets: Layers of Defense . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Contents vii
Chapter 10
Operational security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Policies and Administrative Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Operational Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Trainingg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Recovery Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Annual Review w ...................................................... 308
Background Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Chapter 11
Computer systems & Network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Chapter 12
Electric utility industry–specific cybersecurity issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Substation Backdoors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
IP to the Substation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
TASE.2/ICCP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
UCA2 (IEC61850) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
DNP3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
NERC 1200/1300 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Chapter 13
Water/Wastewater industry–specific cybersecurity issues . . . . . . . . . . . . . . . . . . . . . . . . 377
Licensed Radio Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Nonsecure Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
PLC Equipment as RTUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Supervisory and Local Control Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Municipal LANs and WANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Control Interfaces to Plant Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Chapter 14
Pipeline industry–specific cybersecurity issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Radio Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Smart RTUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
RTU Program Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Supervisory Control Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
IP along the Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Web Browsing and Email Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
viii Cybersecurity for SCADA Systems
Chapter 15
The cyberthreat to scada systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Chapter 16
Commercial product vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Appendix A
U.S. Department of Energy’s “21 Steps to Improved SCADA Security” . . . . . . . . . . . . . . 409
Appendix B
NERC CIP—Recommendations for Electric Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Appendix C
Security Recommendations of the Instruments, Systems, and Automation Society
and the American Gas Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Recommendations of the AGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Appendix D
Industry and Government Security Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Appendix E
SCADA System Security Assessment Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Figures
Fig. 1–1. Simplified component diagram of a SCADA system . . . . . . . . . . . . . . . . . . 2
Fig. 1–2. Example bit-oriented message format (starting and ending portions only,
owing to actual large number of bits required in a full-length message). . . . . . . . . . . 4
Fig. 1–3. Example tabular operator display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Fig. 1–4. Example semi-graphic operator displayy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Fig. 1–5. Centralized, redundant SCADA system architecture . . . . . . . . . . . . . . . . 11
Fig. 1–6. Distributed SCADA system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Fig. 1–7. Client/server SCADA system architecture. . . . . . . . . . . . . . . . . . . . . . . . . . 15
Fig. 1–8. Virtualized SCADA system implementations . . . . . . . . . . . . . . . . . . . . . . . 16
Fig. 1–9. SCADA as a service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Fig. 1–10. SCADA without a SCADA system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Fig. 1–11. Generalized Information Flow within a Generic SCADA System . . . . 21
Fig. 2–1. Typical MTU console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Fig. 2–2. RTU contact output (control) types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Fig. 2–3. Evolution of smart RTU technology and capabilities . . . . . . . . . . . . . . . . 30
Fig. 2–4. RTU hierarchy using master and slave protocol combination . . . . . . . . 33
Fig. 2–5. Typical RTU multiline LCD and keypad . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Fig. 2–6. Example host definition of downloaded calculation functions . . . . . . . . 38
Fig. 2–7. Supervisory control of local regulatory control panels . . . . . . . . . . . . . . . 39
Fig. 2–8. Basic SCADA system and DCS architectures . . . . . . . . . . . . . . . . . . . . . . . 40
Fig. 2–9. IEC 61131 PLC/RTU configuration alternatives. . . . . . . . . . . . . . . . . . . . . 42
Fig. 2–10. Categories of typical RTU protocol message types . . . . . . . . . . . . . . . . . 51
Fig. 2–11. Simple RTU serial protocol architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Fig. 2–12. Network-based serial protocol architecture . . . . . . . . . . . . . . . . . . . . . . . 56
Fig. 2–13. Ethernet cable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Fig. 3–1. SCADA host with multiple master radios on separate frequencies . . . . 66
Fig. 3–2. Typical microwave-based private telephone system . . . . . . . . . . . . . . . . . 68
Fig. 3–3. Use of packet switching networks for SCADA communications . . . . . . 71
Fig. 3–4. Connection-oriented telephone circuits. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Fig. 3–5. Using digital telephone circuits to bridge LANs . . . . . . . . . . . . . . . . . . . . . 73
Fig. 3–6. Frame relay and FRADs used to replace analog leased lines . . . . . . . . . . 75
Fig. 3–7. Spectral energy (frequency) distribution of spread-spectrum radio . . . 77
Fig. 3–8. Cellular data communications architecture . . . . . . . . . . . . . . . . . . . . . . . . . 79
Fig. 3–9. Frame-relay DLCI-to-IP-address mapping in routers . . . . . . . . . . . . . . . . 81
Fig. 3–10. FDDI counter-rotating ring design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
ix
x Cybersecurity for SCADA Systems
xv
Preface
I n the 1960s, when the first computer-based supervisory control and data acqui-
sition systems (SCADA) were being developed, there was no cultural concept of
needing to provide any particular protective measures to keep such systems safe
from intentional attacks. After all, why would someone want to disrupt the opera-
tion of such systems? The world was a different place, and the computer expertise to
work on, or with, such systems was a rare commodity. The only protective consid-
erations built into those systems were ones instituted in order to minimize or elim-
inate the impact of user errors. Not so today. Computers have become commodity
appliances, and computer expertise far more commonplace. In addition, there are
people that have technical expertise and, for a variety of reasons, choose to use it
to inflict damage. Or worse still, there are those who wish to use such expertise to
cause serious harm to the United States government and citizens. The Internet,
a world-spanning communications technology that should be a positive force to
unite cultures and peoples, is also being used as a means to reach into our computer
systems by such people. Much of our critical industrial infrastructure is managed
and controlled by SCADA systems, and thus it is now essential that we place pro-
tective measures into and around these systems. This book is intended to provide
a general background of SCADA system technology, cybersecurity concepts and
technologies, and how the two can be brought together to safeguard our infra-
structure and computer automation systems. In this second revision of the book,
I have included a great deal more information about implementing cybersecurity
protections and about technical countermeasures. This revision also takes advan-
tage of the evolved industry-specific cybersecurity standards that have emerged
since the initial printing, especially in the electric power and oil-and-gas pipeline
industry sectors. There have also been many technological changes in commu-
nications and networking and other areas of computer science since the original
publication. I have tried to capture applicable changes in this revision.
xvii
Acknowledgements
T he author would like to acknowledge all of the people that assisted in the writ-
ing of this book and, in particular, my wonderful and understanding wife, who
put up with the long nights and weekends spent writing, editing, and proofing this
manuscript. I would also like to thank the people at PennWell, who encouraged
me to update this book and who helped in editing it into a suitable, professional-
looking document.
xix
Introduction
Industrial Automation
in the Aftermath of 9/11
W ithout the events of September 11, 2001, there might not have been a need for
this book, or at least for such a book this soon. Up until the events of that day,
the people and government of the United States held the belief that we were iso-
lated and insulated from the foreign governments and “true believers” that might
wish us harm. It is true that for many years we had been witnessing a growing prob-
lem of computer hackingg and the regular introduction of computer worms, viruses,
and other forms of malware over the Internet. But these activities were not per-
ceived as serious, intentional attacks on our country or infrastructure. After 9/11,
everything changed. We now know that there are people and groups that will spend
the time and money to create havoc and terror in order to advance their political,
social, or religious agendas. In response to the events of 9/11, the Department of
Homeland Security (DHS) was formed and given the responsibility for protect-
ing us from these people and organizations. One of the results of the work being
done by the DHS was the recognition that the vast majority of our industrial and
manufacturing facilities, technological infrastructure, transportation systems, and
energy infrastructure are run and controlled by computer-based systems—and
that these systems (mainly SCADA and DCS/PLC systems) were not designed with
any intrinsic protective mechanisms. This is not to say that such systems were/are
fragile or even readily accessible to an attacker. The vendors of these systems have
generally designed them to be robust and capable of continued operation even with
some level of component failures or damage. This was essential because of the criti-
cal or essential nature of the processes being controlled by such systems.
Designers of computer-based automation and control systems have always
known that computers, and electronic devices in general, can and will fail. Thus,
system designs have long accounted for this possibility through redundancy
schemes and architectures that permitted “graceful
“ degradation.” In the early years
of computer-based automation systems, these systems were typically employed in
a “stand alone” configuration without any communications with, or interfaces to,
other computer systems. The only way that a remote cyberattacker/hacker could
access such systems would have been if a dial-in telephone circuit had been sup-
plied with the system, for the purpose of providing remote support by the system
vendor. But, as computer and networking technology became pervasive and ubiq-
uitous in all aspects of modern business enterprises, these automation systems
started to be interfaced with corporate networks, business systems, and eventually,
even to the Internet itself. This evolutionary process has provided cyberattackers
with much greater access to these critical automation systems.
xxi
xxii Cybersecurity for SCADA Systems
Since this book’s initial publication, we have become aware that hostile nation-
states are actively supporting and funding hacking activities in order to steal our
intellectual property and trade secrets, disrupt our elections, gain access to our
bank accounts and credit cards, and generally establish remote access into business
and governmental computer systems (including those of the military). Since the
initial publication of this book, there have been numerous documented instances,
around the globe, of cyberattacks on power grids, industrial facilities, water distri-
bution systems, and communication systems. So, providing adequate and effective
cybersecurity for our SCADA systems is even more important than ever.
The world of computer-based automation systems can be divided into two
broad classes: those systems used with processes that are spread over a large geo-
graphical area (and thus require the use of wide-area communications technology)
and those systems that manage processes that are geographically constrained (and
thus can use local-area communications technology). The first type of system is
called a Supervisory Control And Data Acquisition system (SCADA) and is used
in applications such as gas and liquid pipelines, electric power transmission and
distribution, and water distribution systems. The second type of system is called
a Distributed Control System (DCS) and is used in plant automation applications
such as refining, steel production, paper and pulp, food and beverage, bulk and fine
chemicals, etc. A variation of this second type of system is based on Programmable
Logic Controller (PLC) technology. Almost every high-volume manufacturing
facility is automated using PLC control system technology. The DHS has initially
focused its efforts on cybersecurity for SCADA systems, and therefore SCADA
system cybersecurity will be the focus of this book, although many of the issues
and principles will be directly relevant and applicable to DCS systems as well.
1
The technological evolution
of scada systems
To provide real-time data updates from the field, a SCADA system needs
remote sensory and communications capabilities. Electronic devices called RTUs
are located at each point where measurements are to be taken or where process
equipment is to be controlled. The central computer continuously, cyclically polls
the field-based RTUs to fetch their current measurement values and status indi-
cations. Polling is the process of sending a message to an RTU, to elicit a response
message containing updated values, and repeating that operation with subsequent
Chapter 1 The technological evolution of scada systems 3
RTUs, until all have been processed. Then, that sequence is repeated over and
over, endlessly, presumably providing the SCADA operational personnel with a
near-real-time view of the process being supervised and controlled. In the earliest
SCADA systems, RTUs were essentially nothing more than remotely located I/O
equipment that could read and transmit inputs and receive commands to generate
outputs. That remained the case in the electric power transmission industry well
into the 1990s. Other industry segments made strides in enhancing and utilizing
the intelligence and capabilities of their RTU devices starting in the 1970s.
The RTUs designed in the 1960s, some of which remain in use today, were very
simple electronic devices with a severely limited set of hardwired functions. They
were ‘digital’ from the standpoint of being built from discrete logic gates (and, or,
xor, nor, latch, not, flip-flops, etc.) but they contained no microprocessor or stored
program logic. Normally, RTUs are equipped with input/output (I/O) hardware cir-
cuitry that enables the measurement of electrical signals generated by devices that
produce voltages or currents in proportion to a physical process parameter such as
pressure, flow rate, level, or temperature. (The term transmitterr is often used for the
device that produces an electrical signal proportional to the value of a physical prop-
erty.) RTUs are also able to generate control outputs, either as voltage or current
signals, or in the form of switch/contact closures. Output control signals are initi-
ated or adjusted by the RTU upon receipt of a command from the central computer,
usually initiated by a human operator. In order for the RTUs and the central host
computer to exchange data and control commands, there needs to be a communica-
tions system to allow messages to be sent/received over large distances, as well as an
agreed-on message format and predefined set of messages and responses.
SCADA system designers in the 1960s had to use the currently available long-
distance telecommunications technologies of the time, and that meant either the
telephone company (“Ma Bell”) technology or licensed radio technology. Frequently,
the RTU equipment (and the process being monitored and controlled) was located
in remote areas where no telephone service was available and possibly too great a
distance from the SCADA operations/control center to reliably employ radio com-
munications. In those instances, the process owner (e.g., a pipeline company or an
electric utility) would build their own telephone system, using the same equipment
that the telephone company would have employed (microwave relay towers, signal
multiplexers, etc.).
Analog telephone and analog radio technologies were designed for voice
(sound) communications. Thus, SCADA systems required the use of MODEMs to
turn computer and RTU electrical signals into sounds. In the late 1960s, MODEM
technology was restricted to very low data transmission rates, typically 110–
300 bits per second. The RTUs in the 1960s were electronic, and constructed with
digital components, but not computer-based, so they had to be hardwired to sup-
port a simple set of messages for exchanging data with the central host computer.
Further, since most communications would take place at 1200 bits per second
(bps) or less, keeping messages short was essential. The set of messages that could
4 Cybersecurity for SCADA Systems
be sent to the RTUs and the set of messages that the RTUs could generate together
define a communications protocol. In the 1960s, vendors of SCADA systems had
to design and build their own RTUs and thus also defined their own (proprietary)
communications protocol(s). In certain industries today (primarily the electric
utilities), there are still RTUs utilizing some of these old, obsolete protocols—often
referred to as legacy protocols.
In the 1960s, the universal asynchronous receiver transmitter (UART) chip had
not yet been invented, and microprocessors were just beginning to be invented, so
it was up to each vendor to decide the format of their protocol messages (i.e., how
many bits in a message). To simplify the electronic design of the RTUs, most ven-
dors elected to send all available numeric (analog) or binary (status) data in sin-
gle, long, many-bit messages (fig. 1–2). This would mean messages of 74, 96, 123,
or some other extended number of bits. In essence, a response to a polling mes-
sage from the SCADA host was the transmission of the current values of all of the
inputs (analog and status/digital), sent as one long message. These early protocols
have very few message types and variations (all of which were built into the RTU
hardware), and data values were either single bit or an 8 bit binary integer.
Fig. 1–2. Example bit-oriented message format (starting and ending portions only,
owing to actual large number of bits required in a full-length message)
These bit-orientedd protocols fell out of favor with the invention of the UART
chip (and microprocessors), but as previously mentioned, some of these legacy
bit-oriented protocols remain in limited use today. These types of protocols usually
require the use of specially designed interfaces that can receive and generate the
necessary long-bit-sequences. Specially programmed single-board computers are
often used for this task. Most ‘serial’ RTU protocols still used today are based on
constructing the messages using some integral number of 8 bit octets/bytes which
are suitable for asynchronous serial transmission via UART circuits. Although they
normally don’t come as a standard interface anymore, computers today can still be
equipped with RS-232 serial ports (called ‘COM:’ ports in the Windows® operating
or designated as “ttyS0, ttyS1, etc.” in a Linux operating system all of which employ
UART circuitry to make them function. Protocols based on messages that use an
integral number of octets are generally called character-oriented protocols. You
will also occasionally hear these two different types of protocols referred to as syn-
chronous and asynchronous protocols, but this is not technically accurate. In fact,
Chapter 1 The technological evolution of scada systems 5
both are asynchronous (meaning the time between messages is highly variable and
so you can’t predict when the next one will arrive), but one uses message frames
that are an even multiple of octets (8 bits) and the other some vendor-defined
frame consisting of a large number of bits (usually several dozens). The differ-
ences between these two categories of protocols will be discussed in more detail
in a later chapter. Just understand that character-oriented serial protocols can be
sent and received with conventional ‘COM:’ (RS-232) serial ports whereas the bit-
oriented (long frame) protocols require specialized hardware for transmission and
reception. It was common to use external hardware (a single-board computer) to
receive these bit-oriented messages and then break them into octet multiples and
send each octet as a separate character into a standard ‘COM:’ port or a standard
“tty#” port. And the process was reversed for transmitted messages.
A SCADA system is used to fetch and present current data values to a human
operator. The time required to refresh the measurement data in a SCADA system
that represent the current state of the remote process, through the polling of RTUs,
depends on several factors:
• The bit rate (110, 300, or 1,200 bps) of the polling communication
circuit(s)
• The number of RTUs sharing a given communications circuit
• The length (in bits) and number of messages exchanged in the polling
process
• The number of communication circuits being used sequentially or
concurrently
• The time delay characteristics (latency) of the communication circuits
This is for polling over low-bandwidth serial communication circuits. If
high-bandwidth (a.k.a. broadband) communications are being used to communi-
cate with field sites, then the most important factor is the last one in the list above.
The protocol used by a SCADA host to communicate with its RTUs can be
designed to permit multiple RTUs to share a common communication circuit,
much like a party-line telephone circuit (if you’re old enough to remember what
those were). This means that the protocol incorporates some mechanism (usually
an RTU identification number [ID] in the message) that allows a given RTU to iden-
tify which messages are intended for that RTU and to ignore messages addressed
to other RTUs on a shared circuit. Placing multiple RTUs on communication cir-
cuits reduces the required number of such circuits, but it can lengthen the time
required to poll all RTUs for their current data values. Most SCADA systems that
support multiple polling circuits are designed to poll RTUs on all of these circuits
concurrently. Thus, if there are x circuits, the SCADA host can be polling x RTUs
concurrently (i.e., one on each circuit).
In some industries, the process dynamics are such that a human operator (or
supervisory application program) monitoring and controlling the process through
a SCADA system needs to have fresh measurements more frequently than with
Another random document with
no related content on Scribd:
climate, upon an equal soil, freely pasture his herds and flocks where
he pleases, and love his neighbor better than himself.
OUR FARMERS.
The test of profitable farming is the state of the account at the end
of the year. Under free trade the evidence multiplies that the English
farmer comes to the end of the year with no surplus, often in debt,
bare and discontented. Their laborers rarely know the luxury of
meat, not over sixteen ounces per week,[87] and never expect to own a
rood of the soil.
But under the protective policy the American farmer holds and
cultivates his own land, has a surplus at the end of the year for
permanent investments or improvements, and educates and brings
up his sons and daughters with the advantages and comforts of good
society. There are more American houses with carpets than in any
other country of the world. I believe it will not be disputed that the
down-trodden tillers of the soil in Great Britain are not well fed; that
they are coarsely underclad, and that for lack of common-school
culture they would hardly be regarded as fit associates here for
Americans who drive their teams afield, or for the young men who
start in life as laborers upon farms. The claim that free trade is the
true policy of the American farmer would seem to be, therefore, a
very courageous falsehood.
It is an unfortunate tendency of the age that nearly one-half of the
population of the globe is concentrated in cities, often badly
governed, and sharply exposed to extravagance, pauperism,
immorality, and all the crimes and vices which overtake mankind
reared in hot-beds. I would neither undervalue the men of brilliant
parts, nor blot out the material splendor of cities, but regret to see
the rural districts depopulated for their unhealthy aggrandizement.
Free trade builds up a few of these custom-house cities, where gain
from foreign trade is the chief object sought, where mechanics,
greater in numbers than any other class, often hang their heads,
though Crœsus rolls in Pactolian wealth, and Shylock wins his pound
of flesh; but protection assembles artisans and skilled workmen in
tidy villages and towns, details many squadrons of industry to other
and distant localities, puts idle and playful waterfalls at work, opens,
builds up, and illumines, as with an electric light, the whole interior
of the country; and the farmer of Texas or of New England, of Iowa
or of Wisconsin, is benefited by such reinforcements of consumers,
whether they are by his side or across the river, at Atlanta or South
Bend, at Paterson or at Providence. The farmers own and occupy
more than nineteen-twentieths of our whole territory, and their
interest is in harmony with the even-handed growth and prosperity
of the whole country.
There is not a State whose interests would not be jeopardized by
free trade, and I should like to dwell upon the salient facts as to
Missouri, Kansas, Indiana, Alabama, Illinois, and many other States,
but I shall only refer to one. The State of Texas, surpassing empires
in its vast domains, doubling its population within a decade, and
expending over twenty million dollars within a year in the
construction of additional railroads, with a promised expenditure
within the next fifteen months of over twenty-seven millions more,
has sent to market as raw material the past year 12,262,052 pounds
of hides, 20,671,639 pounds of wool, and 1,260,247 bales of cotton.
Her mineral resources, though known to be immense, are as yet
untouched. Her bullocks, in countless herds on their way to market,
annually crowd and crop the prairies from Denver to Chicago. But
now possessed of a liberal system of railroads, how long will the
dashing spirit of the Lone Star State—where precious memories still
survive of Austin, of Houston, of Rusk, and of Schleicher—be content
to send off unmanufactured her immense bulk of precious raw
materials, which should be doubled in value at home, and by the
same process largely multiply her population? With half as many in
number now as had the original thirteen, and soon to pass our
largest States, wanting indefinite quantities of future manufactures
at home, Texas should also prepare to supply the opening trade with
Mexico, in all of its magnitude and variety, and far more worthy of
ambition than in the golden days of Montezuma.
No State can run and maintain railroads unless the way-stations,
active and growing settlements and towns, are numerous enough to
offer a large, constant, and increasing support. The through business
of long lines of railroads is of great importance to the termini, and
gives the roads some prestige, but the prosperity and dividends
mainly accrue from the local business of thrifty towns on the line of
the roads. It is these, especially manufacturing towns, which make
freight both ways, to and from, that free trade must ever fail to do,
and while through freights, owing to inevitable competition, pay little
or no profit, the local freights sustain the roads, and are and must be
the basis of their chief future value. Without this efficient local
support, cheap and rapid long transportation would be wholly
impracticable.
The Southern States, in the production of cotton, have possibly
already reached the maximum quantity that can be cultivated with
greatest profit, unless the demand of the world expands. A short crop
now often brings producers a larger sum than a full crop. The
amount of the surplus sent abroad determines the price of the whole
crop. Production appears likely soon to outrun the demand. Texas
alone has latent power to overstock the world. Is it not time,
therefore, to curtail the crop, or to stop any large increase of it, while
sure to obtain as much or more for it, and to turn unfruitful capital
and labor into other and more profitable channels of industry? The
untrodden fields, where capital and labor wait to be organized for the
development of Southern manufactures and mining, offer unrivaled
temptations to leaders among men in search of legitimate wealth.
The same facts are almost equally applicable to general
agriculture, but more particularly to the great grain-growing regions
of the West. A great harvest frequently tends to render the labor of
the whole year almost profitless, whenever foreign countries are
blessed with comparatively an equal abundance. The export of corn
last year in October was 8,535,067 bushels, valued at $4,604,840,
but the export of only 4,974,661 bushels this year brings $3,605,813.
An equal difference appears in the increased value of exports of flour.
A much larger share of crops must be consumed nearer home, if any
sure and regular market is to be permanently secured. The foreign
demand, fitful and uncertain as it is, rarely exceeds one-twentieth of
even the present home requirements, and the losses from long
transportation, incident to products of great bulk, can never be
successfully avoided except by an adequate home demand.
Farmers do not look for a market for grain among farmers, but
solely among non-producing consumers, and these it is greatly to
their interest to multiply rather than to diminish by forcing them to
join in producing or doubling crops for which there may be an
insufficient demand. Every ship-load of wheat sent abroad tends to
bring down foreign prices; and such far-off markets should be sought
only when the surplus at home is excessive or when foreign prices
are extraordinarily remunerative.
The wheat regions of the West, superb as they undoubtedly are, it
is to be feared, have too little staying character to be prodigally
squandered, and their natural fertility noticeably vanishes in the rear
unless retained by costly fertilizers almost as rapidly as new fields
open in front. Some of the Middle States as well as the New England,
though seeking fertilizers far and near, already look to the West for
much of their corn and bread; and there is written all over Eastern
fields, as Western visitors may read, the old epitaph, “As we are now
so you may be.” It will take time for this threatened decadence, but
not long in the life of nations. The wheat crop runs away from the
Atlantic coast to the Pacific, and sinks in other localities as it looms
up in Minnesota, Nebraska, and Dakota. Six years of cropping in
California, it is said, reduces the yield per acre nearly one-half.
There was in 1880 devoted to wheat culture over thirty-five million
acres, or nearly double the acreage of 1875. In twenty-five years a
hundred million people will more than overtake any present or
prospective surplus, and we may yet need all of our present
magnificent wheat fields to give bread to our own people. Certainly
we need not be in haste to slaughter and utterly exhaust the native
fertility of our fields on the cheap terms now presented.
England, with all her faults, is great, but unfortunately has not
room to support her greatness, and must have cheap food and be
able to offer better wages or part with great numbers of her people. I
most sincerely hope her statesmen—and she is never without those
of eminence—will prove equal to their great trust and to any crisis;
but we cannot surrender the welfare of our Republic to any foreign
empire. Free trade may or may not be England’s necessity. Certainly
it is not our necessity; and it has not reached, and never will reach,
the altitude of a science. An impost on corn there, it is clear, would
now produce an exodus of her laboring population that would soon
leave the banner of Victoria waving over a second-rate power.
Among the nations of the world the high position of the United
States was never more universally and cordially admitted. Our rights
are everywhere promptly conceded, and we ask nothing more. It is
an age of industry, and we can only succeed by doing our best. Our
citizens under a protective tariff are exceptionally prosperous and
happy, and not strangers to noble deeds nor to private virtues. A
popular government based on universal suffrage will be best and
most certainly perpetuated by the elevation of laboring men through
the more liberal rewards of diversified employments, which give
scope to all grades of genius and intelligence and tend to secure to
posterity the blessings of universal education and the better hope of
personal independence.
Speech of Hon. J. D. Cameron, of Penna.