350084BUY SCADA CC2019 pc - PennWell Books

CYBERSECURITYFOR SCADA SYSTEMS

SECOND EDITION

350084BUY_SCADA_CC2019_pc.indd 3 18/12/2020 13:11:54

v

ContentsPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xixIntroduction: Industrial Automation in the Aftermath of 9/11 . . . . . . . . . . . . . xxi

Chapter 1The technological evolution of scada systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

The Early History of SCADA—Mainframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Minicomputers and Microprocessors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Central Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Distributed Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Client/Server Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Technological Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Ubiquitous Internet and IP Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Generalized Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapter 2Remote terminal units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Basic Features and Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Smart RTU Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Top-Down and Bottom-Up Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47The Emergence of PLCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Legacy Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Protocol Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54IP-Ready RTUs and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Chapter 3Telecommunications technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Voice-Grade (Analog) Telephony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Commercial Voice/Data Carriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Options for Wireless Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Digital Networking Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80TCP/IP Networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84The Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94


vi Cybersecurity for SCADA Systems

Chapter 4Supervisory control applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Operating System Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100SCADA System Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Program Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Standardized APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Chapter 5Operator interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Access-Control Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Standard System Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Site/Industry–Specific Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Historical Trending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Logs and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Chapter 6Conventional information technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Availability, Integrity, and Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Remote Access/Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172TCP/IP Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Firewalls & Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Wireless LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Authentication and Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Encryption and Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Chapter 7Identifying cybersecurity vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Threats and Threat Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Obvious Points of Attack and Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Chapter 8Malware, cyberattacks and hacking tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268WEB Server/SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Email and Web browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Chapter 9Physical security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Access tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287Illegal-entry Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Physical Isolation of Assets: Layers of Defense . . . . . . . . . . . . . . . . . . . . . . . . . . 289


Contents vii

Physical Protection of Materials and Information . . . . . . . . . . . . . . . . . . . . . . . 289Critical Ancillary Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291Remote and Field Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Chapter 10Operational security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Policies and Administrative Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Operational Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Recovery Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307Annual Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308Background Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Chapter 11Computer systems & Network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Chapter 12Electric utility industry–specific cybersecurity issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Substation Backdoors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366IP to the Substation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370TASE.2/ICCP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372UCA2 (IEC61850) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373DNP3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374NERC 1200/1300 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

Chapter 13Water/Wastewater industry–specific cybersecurity issues . . . . . . . . . . . . . . . . . . . . . . . . 377

Licensed Radio Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Nonsecure Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381PLC Equipment as RTUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382Supervisory and Local Control Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383Municipal LANs and WANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Control Interfaces to Plant Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Chapter 14Pipeline industry–specific cybersecurity issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

Radio Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391Smart RTUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393RTU Program Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Supervisory Control Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394IP along the Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395Web Browsing and Email Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396


viii Cybersecurity for SCADA Systems

Chapter 15The cyberthreat to scada systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

Chapter 16Commercial product vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

Appendix AU.S. Department of Energy’s “21 Steps to Improved SCADA Security” . . . . . . . . . . . . . . 409

Appendix BNERC CIP—Recommendations for Electric Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

Appendix CSecurity Recommendations of the Instruments, Systems, and Automation Society and the American Gas Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Recommendations of the AGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Appendix DIndustry and Government Security Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Appendix ESCADA System Security Assessment Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477


ix

FiguresFig. 1–1. Simplified component diagram of a SCADA system . . . . . . . . . . . . . . . . . . 2Fig. 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). . . . . . . . . . . 4Fig. 1–3. Example tabular operator display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Fig. 1–4. Example semi-graphic operator display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Fig. 1–5. Centralized, redundant SCADA system architecture . . . . . . . . . . . . . . . . 11Fig. 1–6. Distributed SCADA system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Fig. 1–7. Client/server SCADA system architecture. . . . . . . . . . . . . . . . . . . . . . . . . . 15Fig. 1–8. Virtualized SCADA system implementations . . . . . . . . . . . . . . . . . . . . . . . 16Fig. 1–9. SCADA as a service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Fig. 1–10. SCADA without a SCADA system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Fig. 1–11. Generalized Information Flow within a Generic SCADA System . . . . 21Fig. 2–1. Typical MTU console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Fig. 2–2. RTU contact output (control) types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Fig. 2–3. Evolution of smart RTU technology and capabilities . . . . . . . . . . . . . . . . 30Fig. 2–4. RTU hierarchy using master and slave protocol combination . . . . . . . . 33Fig. 2–5. Typical RTU multiline LCD and keypad . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Fig. 2–6. Example host definition of downloaded calculation functions . . . . . . . . 38Fig. 2–7. Supervisory control of local regulatory control panels . . . . . . . . . . . . . . . 39Fig. 2–8. Basic SCADA system and DCS architectures . . . . . . . . . . . . . . . . . . . . . . . 40Fig. 2–9. IEC 61131 PLC/RTU configuration alternatives. . . . . . . . . . . . . . . . . . . . . 42Fig. 2–10. Categories of typical RTU protocol message types . . . . . . . . . . . . . . . . . 51Fig. 2–11. Simple RTU serial protocol architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 55Fig. 2–12. Network-based serial protocol architecture . . . . . . . . . . . . . . . . . . . . . . . 56Fig. 2–13. Ethernet cable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Fig. 3–1. SCADA host with multiple master radios on separate frequencies . . . . 66Fig. 3–2. Typical microwave-based private telephone system . . . . . . . . . . . . . . . . . 68Fig. 3–3. Use of packet switching networks for SCADA communications . . . . . . 71Fig. 3–4. Connection-oriented telephone circuits. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Fig. 3–5. Using digital telephone circuits to bridge LANs . . . . . . . . . . . . . . . . . . . . . 73Fig. 3–6. Frame relay and FRADs used to replace analog leased lines . . . . . . . . . . 75Fig. 3–7. Spectral energy (frequency) distribution of spread-spectrum radio . . . 77Fig. 3–8. Cellular data communications architecture . . . . . . . . . . . . . . . . . . . . . . . . . 79Fig. 3–9. Frame-relay DLCI-to-IP-address mapping in routers . . . . . . . . . . . . . . . . 81Fig. 3–10. FDDI counter-rotating ring design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83


x Cybersecurity for SCADA Systems

Fig. 3–11. Typical corporate IP network architecture . . . . . . . . . . . . . . . . . . . . . . . . 86Fig. 3–12. Some of the basic protocols in the IP suite . . . . . . . . . . . . . . . . . . . . . . . . 89Fig. 3–13. Site-to-site and remote-access VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Fig. 4–1. Software layers comprising a typical SCADA system host . . . . . . . . . . . 100Fig. 4–2. Evolution of SCADA software with commercial software . . . . . . . . . . . 101Fig. 4–3. SCADA system user account management utility . . . . . . . . . . . . . . . . . . 107Fig. 4–4. SCADA configuration utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Fig. 4–5. Database point and calculated point creation utility . . . . . . . . . . . . . . . . 111Fig. 4–6. Creating the tag database using a spreadsheet utility. . . . . . . . . . . . . . . . 112Fig. 4–7. Graphical display editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Fig. 4–8. Application program interacting with HMI

via SCADA library functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Fig. 4–9. OPC client/server architecture and data-exchange alternatives . . . . . . 122Fig. 4–10. Using a SQL-compliant database server to exchange SCADA data. . . . 124Fig. 5–1. Example SCADA system control room console design . . . . . . . . . . . . . 130Fig. 5–2. Typical RTU polling and communications diagnostic display. . . . . . . . 133Fig. 5–3. SNMP-based RTU polling and communications diagnostic display . . . .134Fig. 5–4. SCADA system operational status display . . . . . . . . . . . . . . . . . . . . . . . . . 135Fig. 5–5. RTU current value display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Fig. 5–6. Point group display (bar graph mode). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Fig. 5–7. Web-page operational display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Fig. 5–8. Geographic layout operational display . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Fig. 5–9. Process-flow operational graphical display . . . . . . . . . . . . . . . . . . . . . . . . 143Fig. 5–10. Display hierarchy and inter-display navigation . . . . . . . . . . . . . . . . . . . . 145Fig. 5–11. GIS example SCADA display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Fig. 5–12. Alarm limit checking on a typical analog input point . . . . . . . . . . . . . . 149Fig. 5–13. Typical current-alarm summary display window. . . . . . . . . . . . . . . . . . 151Fig. 5–14. Using symbols or code letters to indicate measurement conditions . . . . 154Fig. 5–15. Control-point tagging display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Fig. 5–16. Mechanical strip-chart pen recorder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Fig. 5–17. Data storage hierarchy for historical trending. . . . . . . . . . . . . . . . . . . . . 159Fig. 5–18. Example historical trending display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Fig. 5–19. A typical SCADA system event log query . . . . . . . . . . . . . . . . . . . . . . . . 165Fig. 5–20. Example of a spreadsheet report for a water utility . . . . . . . . . . . . . . . . 167Fig. 5–21. Microsoft Windows Task Scheduler Utility. . . . . . . . . . . . . . . . . . . . . . . 168Fig. 6–1. Communication interconnections to a SCADA system . . . . . . . . . . . . . 173Fig. 6–2. Attacking and utilizing a legacy serial communication circuit . . . . . . . 175


Figures xi

Fig. 6–3. Attacking a SCADA system that is using IP-to-the-Field . . . . . . . . . . . . 176Fig. 6–4. The OSI seven-layer model and IP equivalent-function layers . . . . . . . 179Fig. 6–5. Performing NAT in a gateway computer . . . . . . . . . . . . . . . . . . . . . . . . . . 183Fig. 6–6. IP and TCP (or UDP) datagram header information . . . . . . . . . . . . . . . . 185Fig. 6–7. IP datagram fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Fig. 6–8. The internal structure of the IPv4 datagram header. . . . . . . . . . . . . . . . . 187Fig. 6–9. The Zenmap network scanning tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Fig. 6–10. IP routing between PC network interfaces . . . . . . . . . . . . . . . . . . . . . . . 192Fig. 6–11. Accidental bridging of LANs via dual-home connections . . . . . . . . . . 193Fig. 6–12. Ethernet frame structure and contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Fig. 6–13. Switched Ethernet LAN elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Fig. 6–14. Creating a broadcast storm in an Ethernet LAN . . . . . . . . . . . . . . . . . . 199Fig. 6–15. Using RSTP to re-establish LAN communications . . . . . . . . . . . . . . . . 199Fig. 6–16. Tagged frames with different priority values . . . . . . . . . . . . . . . . . . . . . . 201Fig. 6–17. Tagged and un-tagged Ethernet frames . . . . . . . . . . . . . . . . . . . . . . . . . . 202Fig. 6–18. Setting up a SPAN port on a switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Fig. 6–19. IEEE 802.1x port-based NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Fig. 6–20. Using Syslog protocol to send logs to a SIEM . . . . . . . . . . . . . . . . . . . . . 205Fig. 6–21. Using Wi-Fi at SCADA field sites for local communications . . . . . . . 207Fig. 6–22. Cyber security measures if Wi-Fi must be used . . . . . . . . . . . . . . . . . . . 208Fig. 6–23. Remote and local user access to a computer/system . . . . . . . . . . . . . . . 209Fig. 6–24. Strong authentication options and technologies . . . . . . . . . . . . . . . . . . 211Fig. 6–25. Encryption and decryption of a document . . . . . . . . . . . . . . . . . . . . . . . 215Fig. 6–26. Using stream cipher to protect transmitted information . . . . . . . . . . . 216Fig. 6–27. Key size increases time required to break . . . . . . . . . . . . . . . . . . . . . . . . 217Fig. 6–28. Public and private key generation and exchange . . . . . . . . . . . . . . . . . . 217Fig. 6–29. Public-private key encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Fig. 6–30. MS Windows Encrypted File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Fig. 6–31. Hash algorithm generating a message digest value . . . . . . . . . . . . . . . . 221Fig. 6–32. Example of a public key (Base 64 encoded) . . . . . . . . . . . . . . . . . . . . . . . 222Fig. 6–33. Example of an X.509 digital certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Fig. 6–34. Creating zones and network segmentation with firewalls . . . . . . . . . . 226Fig. 6–35. Conceptual design of a media scanning 'kiosk' . . . . . . . . . . . . . . . . . . . . 227Fig. 7–1. Taxonomy of potential threat sources to a SCADA system . . . . . . . . . . 229Fig. 7–2. Example of a spear phishing email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Fig. 7–3. Typical attack pathways for cyberattack . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Fig. 7–4. Classes of security and types of countermeasures . . . . . . . . . . . . . . . . . . 240


xii Cybersecurity for SCADA Systems

Fig. 7–5. US-CERT/CISA monthly vulnerability updates . . . . . . . . . . . . . . . . . . . . 245Fig. 7–6. The MITRE Corporation’s ATT&CK™ Database . . . . . . . . . . . . . . . . . . . 246Fig. 7–7. The MITRE Corporation’s IACS ATT&CK™ database . . . . . . . . . . . . . . 247Fig. 8–1. The Metasploit framework with Armitage. . . . . . . . . . . . . . . . . . . . . . . . . 254Fig. 8–2. Sample exploits from the Metasploit framework . . . . . . . . . . . . . . . . . . . 255Fig. 8–3. Using Metasploit to inject a VNC into a target computer . . . . . . . . . . . 256Fig. 8–4. Kali Linux distribution with pen-testing tools . . . . . . . . . . . . . . . . . . . . . 257Fig. 8–5. Buffer overflow attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Fig. 8–6. Stack smashing in an x86 CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Fig. 8–7. Relational database tampering via SQL injection . . . . . . . . . . . . . . . . . . . 272Fig. 9–1. Gates and fencing to control vehicle and personnel access . . . . . . . . . . 281Fig. 9–2. Physical security layers for added security . . . . . . . . . . . . . . . . . . . . . . . . . 282Fig. 9–3. Various forms of high-security key/lock systems . . . . . . . . . . . . . . . . . . . 283Fig. 9–4. Typical electronic access-control door . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Fig. 9–5. Electronic, automated access-control

and intrusion-detection system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Fig. 9–6. Tamper-indicating/detection mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 287Fig. 9–7. Physical protection of roof areas with radio equipment . . . . . . . . . . . . . 292Fig. 9–8. Physical protection of network cabling and components . . . . . . . . . . . . 293Fig. 9–9. Power supply: typical configuration

and equipment interconnections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Fig. 11–1. Unified Threat Management appliance . . . . . . . . . . . . . . . . . . . . . . . . . . 314Fig. 11–2. Application proxy firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315Fig. 11–3. Packet-inspection firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Fig. 11–4. Tracking TCP state for each session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Fig. 11–5. Ethernet switch with packet filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318Fig. 11–6. Transparent firewall operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321Fig. 11–7. Industrial protocol-aware firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323Fig. 11–8. Industrial protocol detailed filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324Fig. 11–9. Cross-network vulnerabilities with IP to the field . . . . . . . . . . . . . . . . . 325Fig. 11–10. NIDS components and structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326Fig. 11–11. Using network taps for message collection . . . . . . . . . . . . . . . . . . . . . . 328Fig. 11–12. Network intrusion detection and prevention system . . . . . . . . . . . . . 329Fig. 11–13. Host-based intrusion detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332Fig. 11–14. SNMP Client and Agent communications . . . . . . . . . . . . . . . . . . . . . . 334Fig. 11–15. SNMP client software (network monitor) from SolarWinds™. . . . . . 336Fig. 11–16. Simplified block-diagram of a SIEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339Fig. 11–17. SNTP server on the LAN, with GPS time source . . . . . . . . . . . . . . . . 342


Figures xiii

Fig. 11–18. Using a data diode to forward data safely . . . . . . . . . . . . . . . . . . . . . . . 344Fig. 11–19. Establishing a DMZ to isolate the SCADA system . . . . . . . . . . . . . . . 345Fig. 11–20. Setting port security on a Cisco switch port . . . . . . . . . . . . . . . . . . . . . 346Fig. 11–21. Using IEEE 802.1x port-based NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Fig. 11–22. Using Syslog messages to monitor network elements . . . . . . . . . . . . 349Fig. 11–23. Blocking unnecessary ports in Windows . . . . . . . . . . . . . . . . . . . . . . . . 352Fig. 11–24. Windows local security policy setting groups . . . . . . . . . . . . . . . . . . . 353Fig. 11–25. Windows security policy templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Fig. 11–26. Possible incorrect placement of NIDS sensor when VPN is used . . . .356Fig. 11–27. Accessing VLANs using pre-tagged frames . . . . . . . . . . . . . . . . . . . . . 357Fig. 11–28. The “hosts” and “lmhosts” files in Windows . . . . . . . . . . . . . . . . . . . . . 359Fig. 11–29. Using a KVM to support multi-computer access. . . . . . . . . . . . . . . . . 361Fig. 12–1. Generalized block diagram of an electric utility SCADA system . . . . 365Fig. 12–2. Electrical transmission substation circa 1990 . . . . . . . . . . . . . . . . . . . . . 367Fig. 12–3. Substation information consolidation (substation automation) . . . . . 370Fig. 12–4. IP networking to the substation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371Fig. 13–1. SCADA system block diagram for the water/wastewater industry . . . .378Fig. 13–2. Using portable equipment to hijack a remote site . . . . . . . . . . . . . . . . . 381Fig. 13–3. Evolution of PLC programming and configuration downloading . . . 383Fig. 13–4. Using serial link cryptographic transceivers . . . . . . . . . . . . . . . . . . . . . . 385Fig. 13–5. Example MAN shared by a municipal utility SCADA system. . . . . . . 387Fig. 14–1. Generalized architecture of a pipeline SCADA system . . . . . . . . . . . . 390Fig. 14–2. Evolution of pipeline communications technologies . . . . . . . . . . . . . . 392Fig. 15–1. Cyber event categorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399Fig. 16–1. The CVE database Web site based on MITRE data . . . . . . . . . . . . . . . . 404Fig. 16–2. CVE vulnerability listing for Windows XP. . . . . . . . . . . . . . . . . . . . . . . . 405Fig. 16–3. Microsoft security bulletin Web site—example bulletin. . . . . . . . . . . . 405Fig. 16–4. The CVE Details Web page for Enterprise Linux vulnerabilities . . . . 406Fig. 16–5. NIST National Vulnerability Database (NVD) . . . . . . . . . . . . . . . . . . . . 407Fig. 16–6. Cisco’s product support site for CVE assessment & support . . . . . . . 408


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-oriented 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,



service provider sets up a system and provides each participating utility a Web-based portal that provides them with displays of their own information (but isolates them from the information of others.) The SCADA vendor provides the equipment to the utilities and assists them with the initial configuration and installation of RTUs and workstations and setting up of their basic displays, alarms, and control screens. Each field site needs to have power and network connectivity, which can be arranged through local telecommunication providers. In some instances, the communications may be via cellular connectivity or possibly even via satellite link. The point is that by sharing the cost of running and maintaining a SCADA system among a fair number of utilities, this can be profitable for the SCADA service provider and cost-effective for the various utilities. This is a form of SaaS (SCADA as a Service).

Fig. 1–9. SCADA as a service

These days, there is a lot of noise made about the evolving and emerging Industrial Internet of Things (IIoT) and how it will impact automation technologies (of which SCADA is a principle one). A lot of the IIoT discussion revolves around embedding intelligence into the lowest levels of automation, which for SCADA


Chapter 2 Remote terminal units 39

Regulatory and sequence controlIn the pipeline and water/wastewater industries, the RTUs installed in the field

were often located at physical locations around the process where there was a need for some level of local regulatory control and sequence logic. Basic SCADA sys-tems are supervisory control systems, meaning that the decisions to take a control action are made at the host level and then dispatched to the RTU to execute. This is fine as long as the communications bandwidth is sufficient and reliable. If gas pressure needs to be controlled at a delivery point and the target pressure needs to be adjustable based on conditions, then control adjustments to the pressure- regulating valve may need to be made every second or faster. With the low-baud-rate serial communication schemes used by most SCADA systems (not to mention channel sharing across multiple RTUs), it is typically not possible to read the gas pressure, send it to the host, make a control adjustment calculation in the host, and send a control output command to the RTU all within a second. In the past, in order to provide local regulation for such applications, it was typical to have some form of instrumentation and control panel at the site, to perform the regulatory control, and the RTU would merely interface with this panel via analog, pulse, and contact I/O points (fig. 2–7), typically to provide a reading of the measurements and to make setpoint adjustments to the instrument performing the PID control.

Fig. 2–7. Supervisory control of local regulatory control panels

In the 1980s, microprocessor-based RTUs had become reasonably powerful, and at the same time, a revolution was taking place in the process control indus-try. Traditional analog instrumentation and control panels were being replaced with computer-based technology. Specifically, the distributed control system (DCS) had been introduced and, for reasons both financial and technical, was



local network. (If it is across a LAN, then the IP datagrams themselves are carried as data in the link layer protocol of the LAN [such as an Ethernet frame].)

One feature that these two transport protocols add is the idea of ports. Computers on an IP network have unique (IP) addresses (and in fact that can have more than just one), but there can be many different programs concurrently run-ning on a computer and attempting communication with other programs running on other computers. Port numbers (a 16 bit integer value) were created to uniquely identify each communicating program. (Just like a street address for a building can include a specific apartment number so that the letter gets to the right person at the address, an IP address gets more specific with the addition of a port number, so that messages get to the right program.) There are over 65,000 possible port numbers as they are represented by a 16 bit integer (0 to 216-1). Unlike IP addresses, we have not run out of those numbers. For common applications (services) that are found on most computers, a standardized set of so-called well-known port numbers have been assigned (port numbers between 1 to 1023). Returning to the postal service metaphor for the moment, a port number is like specifying the specific person at an address to whom the letter should be delivered. A well-known port number is equivalent to using an addressee such as “Accounting Department” or “Human Resources” in place of a specific person’s name. Since most companies have such departments, you can get your mail delivered, even if you don’t know a specific name of a person in that department. Using a well-known port number is how you get connected to a computer’s email server, Web server and most other common services. Unfortunately, because they are well-known, hackers can attack these ports and attempt to exploit identified vulnerabilities in these system-level services.

IP addresses (until IPv6) were just a 32 bit binary number. (That number is usually broken into four octets with each octet written as a decimal number sep-arated by periods: e.g., 128.156.12.33.) The number actually has two parts: a net-work ID and then a unique computer/host ID within that network. You can think of this like having an area code and phone number. Other people may have the same phone number as you, as long as they have a different area code. The people who initially cooked up the Internet couldn’t envision there ever being more than 232—1 computers connected on a single network worldwide. They were so very wrong. We ran out of unique IP addresses a few years ago, and there have been sev-eral temporary workarounds employed to keep things going. In IPv6, the address is a 128 bit binary number (and that should last us a while). When an IP message (actually called a datagram) arrives at a computer, the message headers contain the IP address and port number of both the destination computer/program and the sender computer/program. (Actually, it may arrive as multiple pieces called fragments if the original datagram was large, and each fragment will have that same delivery information.) This information is like the return address on a letter, the original purpose of which was so that you could send a return message using that address/port information. Today, that sender information might also be used to decide if the message should be accepted or discarded (that is called packet filtering,


Chapter 4 Supervisory control applications 109

Utility Type Description/Use Usage Frequency

Computations and calculations

Define, modify, and delete calculated values, adjust calculation parameters, assign re-calculation intervals

Frequently during initial system commissioning and then again when system expansions or changes are made. Otherwise not used.

Logging Assign alarms and events to logging, remove from logging, print logs, purge logs, assign printing and archive directory to logs, define log retention intervals, define operator and other user actions to be logged, define other activities to be logged, remove activities from logging

Frequently during initial system commissioning and then again when system expansions or changes are made. Some functions may be used on a regular basis for system administration purposes

Data exchange Set up values and status and controls to be exchanged, assign placement and scaling of values in exchange messages, add or remove points, controls, and functions offered to the exchange partner

Frequently during initial inter-system link commis-sioning and testing and then again when system expansions or changes are made. Otherwise not used.

Redundancy synchronization

Establish the trigger events for fail over to backup, establish schedule for data update of backup computer, enable or disable fail over function, enable or disable data synchronization functions

Used during the initial commissioning and testing of the system. Not normally used thereafter.

The SCADA functions of a SCADA system product normally provide for a wide range of operational configuration flexibility, since a given vendor’s SCADA product needs to be able to accommodate a wide range of application and indus-try variations. Many of the SCADA utilities exist for the purpose of setting up customer- specific and industry/application-specific configuration tables that direct the actions of the generic SCADA software modules (fig. 4–4). For example, the number of polling channels, the number of RTUs per channel, baud rate per channel, and protocol to be used on each channel are all customer-specific config-uration parameters that would need to be defined in order for the SCADA system to perform its RTU polling duties. For a SCADA system of any reasonable size there is a massive amount of information that must be defined to make the system work. A single analog input can require a dozen or more parameters to be set, and a SCADA system might have many thousands of analog inputs. Everything from giving inputs names and descriptions to defining how they are to be displayed and even how they are to be historically trended must be defined.

Configuration activities go well beyond merely setting up the polling channels. It is necessary to describe each and every input and output that the SCADA system is to process for every one of the RTUs. The description for each I/O signal (point) includes assigning a tag name to the signal, defining what type of signal it is, provid-ing all of the processing and alarm-checking information necessary to manipulate the point, defining the frequency at which the point is to be processed, the actions to



business applications, but these systems are not directly involved in monitoring and controlling the distributed process via the SCADA system. Of course, there are also small SCADA systems that consist of a desktop PC, a printer, and a master radio, all sitting on a desk in the corner. Pipeline and electric transmission utilities tend to have the big, fancy control rooms. Small water utilities and rural electric cooperatives (RECs) tend to have the desktop SCADA systems.

Fig. 5–1. Example SCADA system control room console design

The purpose of all this equipment is to give operational personnel a real-time view of the state of the process they are monitoring and to provide them with a means for initiating control actions and responding to alarms and events, when-ever necessary. Obviously, we don’t want unauthorized (or untrained) personnel walking into the control room and touching the operator consoles and potentially sending commands out to operate field equipment. So that only authorized per-sonnel have access to the system functions, physical isolation and physical pro-tection of the equipment is common, particularly for the control room (because as we have mentioned, the operator consoles may have no protection other than physical protection because they are always operational and don’t require a login or password). As was previously noted, SCADA systems include some type of access-control mechanism for non-operational personnel, whether it is just the user account/password scheme of the underlying operating system or that plus additional SCADA access controls as well. In the vast majority of cases, this is an ID/password scheme, whereby either each user or each category of user is issued a unique ID/password pair that enables (and disables) the functions and features authorized for this user or category of user. The problem with such protective measures is that people don’t change or properly protect their passwords, they


229

7Identifying cybersecurity vulnerabilities

Threats and Threat Agents

When discussing the possibility of a hacker, a malware infection, or a terrorist attack on a SCADA system, we are really referring to the probability (or

likelihood) of an attack occurring and the consequences resulting were it to be successful. An attacker, regardless of type and motivation, will be looking for the weaknesses in your defenses and will attempt to exploit those weaknesses ( vulnerabilities) to carry out an attack. It is important to take reasonable actions to protect your systems, particularly if a successful attack upon them could cause loss of life, injury, or substantial damage, not to mention any additional financial impact. But what is the probability of an attack and the possibility that it could succeed, and who are the potential attackers?

Fig. 7–1. Taxonomy of potential threat sources to a SCADA system


Documents

350084BUY SCADA CC2019 pc - PennWell Books