Industrial Cybersecurity: Efficiently monitor the cybersecurity posture of your ICS environment

BIRMINGHAM—MUMBAI

Industrial Cybersecurity Second Edition

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Vijin Boricha

Publishing Product Manager: Preet Ahuja

Senior Editor: Rahul D'souza

Content Development Editor: Romy Dias

Technical Editor: Nithik Cheruvakodan

Copy Editor: Safis Editing

Project Coordinator: Shagun Saini

Proofreader: Safis Editing

Indexer: Rekha Nair

Production Designer: Alishon Mendonca

First published: October 2017

Second edition: September 2021

Production reference: 1010921

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN: 978-1-80020-209-2

www.packt.com

Contributors

About the author

Pascal Ackerman is a seasoned industrial security professional with a degree in electrical engineering and over 20 years of experience in industrial network design and support, information and network security, risk assessments, pentesting, threat hunting, and forensics. After almost two decades of hands-on, in-the-field, and consulting experience, he joined ThreatGEN in 2019 and is currently employed as managing director of threat services and research. His passion lies in analyzing new and existing threats to ICS environments and he fights cyber adversaries both from his home base and while traveling the world with his family as a digital nomad.

Pascal wrote the previous edition of this book and has been a reviewer and technical consultant of many security books.

I want to thank my wonderful wife and loving daughters, for helping, supporting, and encouraging me throughout the process of writing this book.

Additionally, I'd like to thank the ICS security community for helping me during the many hours of research. Many of you have helped me, directly or indirectly, by pointing me in the right direction, writing an article or related book, or just being there for me when I needed to bounce ideas off you.

About the reviewers

Syed M. Belal is a cybersecurity director, principal consultant, and strategist with over 14 years of experience in information technology (IT), operational technology (OT), and industrial control systems (ICS) applications with a focus on networking and cybersecurity. Currently, as the director of OT Cybersecurity Consulting, he is responsible for its strategy and growth globally. He helps critical infrastructures protect assets from internal and external threats and align strategy by designing successful and cost-effective solutions.

He holds a BS in electrical engineering and an MBA in business strategy. He holds a multitude of industry certifications, including CISSP, CISA, and CISM.

First, thanks to the Almighty for His guidance. I'd like to thank my wife, Rabea, and our three children, Zaeem, Zaafirah, and Zakariyya, for their daily support and patience. To my parents, relatives, friends, and colleagues, thank you for guiding and supporting me. I'd also like to thank Packt Publishing for the opportunity to review this wonderful book.

As the technical lead for ManTech International Corp., Ron Nemes is responsible for leading all technical and operational aspects of delivering ICS cybersecurity assessment and consulting solutions to multiple clients. He performs ICS critical infrastructure risk assessments around the world across various functions, including power and building automation. A seasoned cybersecurity professional, he is an expert in bridging business and technical needs to achieve client success. He brings extensive experience in designing, implementing, and assessing network infrastructure and security for the Department of Defense, civilian, and commercial environments. He also holds the CISSP, GICSP, GPEN, and GRID certifications.

Table of Contents

Preface

Section 1: ICS Cybersecurity Fundamentals

Chapter 1: Introduction and Recap of First Edition

Industrial Cybersecurity – second edition

Recap of the first edition

What is an ICS?

ICS functions

ICS architecture

The Purdue model for ICSes

IT and OT convergence and the associated benefits and risks

Example attack on the Slumbertown papermill

The comprehensive risk management process

The DiD model

ICS security program development

Takeaway from the first edition

Summary

Chapter 2: A Modern Look at the Industrial Control System Architecture

Why proper architecture matters

Industrial control system architecture overview

The Enterprise Zone

The Industrial Demilitarized Zone

The Industrial Zone

The hardware that's used to build the ICS environment

ICS environment and architecture management

Summary

Chapter 3: The Industrial Demilitarized Zone

The IDMZ

Fundamental concept

IDMZ design process

Design changes due to an expanding ICS environment

What makes up an IDMZ design?

The Enterprise Zone

IDMZ firewalls

IDMZ switches

IDMZ broker services

The Industrial Zone – Level 3 Site Operations

Example IDMZ broker-service solutions

Summary

Chapter 4: Designing the ICS Architecture with Security in Mind

Typical industrial network architecture designs

Evolution from standalone islands of automation

Designing for security

Network architecture with security in mind

Security monitoring

Network choke points

Logging and alerting

Summary

Section 2: Industrial Cybersecurity – Security Monitoring

Chapter 5: Introduction to Security Monitoring

Security incidents

Passive security monitoring

Active security monitoring

Threat-hunting exercises

Security monitoring data collection methods

Network packet capturing

Event logs

Putting it all together – introducing SIEM systems

Summary

Chapter 6: Passive Security Monitoring

Technical requirements

Passive security monitoring explained

Network packet sniffing

Collection and correlation of event logs

Host-based agents

Security Information and Event Management – SIEM

What is a SIEM solution?

How does a SIEM solution work?

Common passive security monitoring tools

NSM

IDS

Event log collection and correlation

Setting up and configuring Security Onion

Exercise 1 – Setting up and configuring Security Onion

Deploying the Security Onion VM

Configuring Security Onion

Deploying Wazuh agents

Exercise 2 – Setting up and a configuring a pfSense firewall

Deploying a pfSense VM

Configuring pfSense

Exercise 3 – Setting up, configuring, and using Forescout's eyeInsight (formerly known as SilentDefense)

Deploying the SilentDefense sensor and Command Center VMs

Configuration of the SilentDefense setup

Example usages of the SilentDefense setup

Summary

Chapter 7: Active Security Monitoring

Technical requirements

Understanding active security monitoring

Network scanning

Endpoint inspection with host-based agents

Manual endpoint inspection/verification

Exercise 1 – Scanning network-connected devices

Dangers of scanning in the ICS environment

Nmap

Assets scan

Interrogating Windows machines

Exploring Modbus

Getting EtherNet/IP information

Scanning Siemens S7 (iso-tsap)

Manual vulnerability verification

Scanning for vulnerabilities

Exercise 2 – Manually inspecting an industrial computer

Pulling Windows-based host information

Configured users

Summary

Chapter 8: Industrial Threat Intelligence

Technical requirements

Threat intelligence explained

Using threat information in industrial environments

Acquiring threat information

Your own incidents and threat hunting efforts

Vendor reports

Your own honeypots

Peers and sharing communities

External/third-party free and paid-for feeds

Creating threat intelligence data out of threat information

Exercise – Adding an AlienVault OTX threat feed to Security Onion

Summary

Chapter 9: Visualizing, Correlating, and Alerting

Technical requirements

Holistic cybersecurity monitoring

Network traffic monitoring

Network intrusion monitoring

Host-based security monitoring

Exercise 1 – Using Wazuh to add Sysmon logging

Exercise 2 – Using Wazuh to add PowerShell Script Block Logging

Exercise 3 – Adding a Snort IDS to pfSense

Exercise 4 – Sending SilentDefense alerts to Security Onion syslog

Exercise 5 – Creating a pfSense firewall event dashboard in Kibana

Exercise 6 – Creating a breach detection dashboard in Kibana

NIDS alerts

Zeek notices

Zeek Intel logs

Suspicious process and file creation

Suspicious PowerShell commands

Suspicious egress connections

Suspicious ingress connections

Failed user login attempts

New user creation and changes to user accounts

Downloaded files

SilentDefense alerts

Finishing up the dashboard

Summary

Section 3: Industrial Cybersecurity – Threat Hunting

Chapter 10: Threat Hunting

What is threat hunting?

Threat hunting in ICS environments

What is needed to perform threat hunting exercises?

Network traffic logs

Endpoint OS and application event logs

Making modifications to PLC, HMI, and other control systems and equipment

Tracking new and changed devices on the (industrial) network

Network services event logs

SIEM

Network packet captures

Research, lookups, and comparison resources

Threat hunting is about uncovering threats

Correlating events and alerts for threat hunting purposes

Summary

Chapter 11: Threat Hunt Scenario 1 – Malware Beaconing

Forming the malware beaconing threat hunting hypothesis

Detection of beaconing behavior in the ICS environment

Malware beaconing explained

Data exfiltration

Legitimate application beaconing

Using Security Onion to detect beaconing behavior

Using RITA to detect beaconing behavior

Investigating/forensics of suspicious endpoints

Finding the suspicious computer

Find the beaconing process – netstat

Upload executable to VirusTotal

Rudimentary inspection of the suspicious executable – malware analysis 101

Using indicators of compromise to uncover additional suspect systems

Discovered IOCs so far

Searching for network-specific indicators of compromise

Searching for host-based indicators of compromise

Summary

Chapter 12: Threat Hunt Scenario 2 – Finding Malware and Unwanted Applications

Technical requirements

Forming the malicious or unwanted applications threat hunting hypothesis

Detection of malicious or unwanted applications in the ICS environment

Comparing system snapshots to find artifacts

Looking for application errors to find artifacts

Looking for malicious network traffic to find artifacts

Comparing port scans to find artifacts

Inventorying currently running processes in the ICS environment

Inventorying startup processes in the ICS environment

Investigation and forensics of suspicious endpoints

Securely extracting the suspicious executables

Using discovered indicators of compromise to search the environment for additional suspect systems

Using YARA to find malicious executables

Using file strings as an indicator of compromise

Summary

Chapter 13: Threat Hunt Scenario 3 – Suspicious External Connections

Forming the suspicious external connections threat hunting hypothesis

Ingress network connections

Mayhem from the internet

Attacks originating from the enterprise network

Summary

Section 4: Industrial Cybersecurity – Security Assessments and Intel

Chapter 14: Different Types of Cybersecurity Assessments

Understanding the types of cybersecurity assessments

Risk assessments

Asset identification

System characterization

Vulnerability identification

Threat modeling

Risk calculation

Mitigation prioritization and planning

Red team exercises

How do red team exercises differ from penetration tests?

Blue team exercises

Penetration testing

How do ICS/OT security assessments differ from IT?

Summary

Chapter 15: Industrial Control System Risk Assessments

Chapter 16: Red Team/Blue Team Exercises

Red Team versus Blue Team versus pentesting

Penetration-testing objective – get to the objective at any cost

Red Team exercise objective – emulate real-world adversary TTPs

Blue Team objective – detect and respond to security incidents as quickly as possible

Red Team/Blue Team example exercise, attacking Company Z

Red Team strategy

Blue Team preparation

The attack

Summary

Chapter 17: Penetration Testing ICS Environments

Practical view of penetration testing

Why ICS environments are easy targets for attackers

Typical risks to an ICS environment

Modeling pentests around the ICS Kill Chain

The Cyber Kill Chain explained

The Intrusion Kill Chain

The ICS Cyber Kill Chain

Pentest methodology based on the ICS Kill Chain

Pentesting results allow us to prioritize cybersecurity efforts

Pentesting industrial environments requires caution

Creating an approximation of the industrial environment

Exercise – performing an ICS-centric penetration test

Preparation work

Setting up the test environment

Pentest engagement step 1 – attacking the enterprise environment

Pentest engagement step 2 – pivoting into the industrial environment

Pentest engagement step 3 – attacking the industrial environment

Testing Level 3 Site Operations

Testing the lower layers

Pentest engagement step 4 – reaching the objective of the attack

Summary

Section 5: Industrial Cybersecurity – Incident Response for the ICS Environment

Chapter 18: Incident Response for the ICS Environment

What is an incident?

What is incident response?

Incident response processes

Incident response preparation process

Incident handling process

Incident response procedures

Incident response preparation process

Incident handling process

Example incident report form

Summary

Chapter 19: Lab Setup

Discussing the lab architecture

The lab hardware

The lab software

Details about the enterprise environment lab setup

ENT-DC

ENT-SQL and ENT-IIS

ENT-Clients

Active Directory/Windows domain setup

Details about the industrial environment – lab setup

Servers

Workstations

HMIs

PLCs and automation equipment

Active Directory/Windows domain setup

How to simulate (Chinese) attackers

Discussing the role of lab firewalls

How to install the malware for the lab environment

Configuring packet capturing for passive security tools

Summary

Why subscribe?

Other Books You May Enjoy

Preface

By applying a variety of tools, techniques, and technologies, in this book, we will visualize and track security posture and identify threats in an Industrial Control System (ICS) environment. Industrial Cybersecurity, Second Edition looks at implementing a comprehensive and solid security program for the ICS environment and should be read by those who are new to industrial security or are extending their industrial security posture.

With IT industries expanding to the cloud, cyberattacks have increased significantly. Understanding your control system’s vulnerabilities and learning techniques to defend critical infrastructure systems from cyber threats is becoming increasingly important.

You will begin this book by looking at how to design for security and exploring how to create an architecture that allows all the tools, techniques, and activities discussed in the book to be implemented effectively and easily. You will also learn about activities, tools, procedures, and concepts around the monitoring, tracking, and trending (visualizing) of ICS cybersecurity risks, as well as learning about the overall security program and posture/hygiene. You will also be introduced to threat hunting principles, tools, techniques, and methodology. Toward the end of the book, you will work with incident response and incident recovery tools, techniques, activities, and procedures as they relate to the ICS environment.

By the end of the book, you will be adept at industrial cybersecurity monitoring, assessments, incident response activities, and threat hunting.

Who this book is for

If you are an ICS security professional or are ICS cybersecurity-curious and want to ensure a robust ICS environment for your (critical infrastructure) systems, or if you want to extend/improve/monitor/validate your ICS cybersecurity posture, then this book is for you. Information Technology as well as Operational Technology (IT/OT) professionals interested in getting into the ICS cybersecurity monitoring domain or who are looking for additional/supporting learning material for a variety of industry-leading cybersecurity certifications will also find this book useful.

What this book covers

Chapter 1, Introduction and Recap of the First Edition, will be a recap of the first edition of this book. We will set the stage for the rest of the book and cover important concepts, tools, and techniques so that you can follow along with this second edition of the book.

Chapter 2, A Modern Look at the Industrial Control System Architecture, takes an overview of ICS security, explaining how I implement plant-wide architectures with some years of experience under my belt. The chapter will cover new concepts, techniques, and best practice recommendations

Chapter 3, The Industrial Demilitarized Zone, is where I will discuss an updated IDMZ design that is the result of years of refinement, updating and adjusting the design to business needs, and revising and updating industry best practice recommendations.

Chapter 4, Designing the ICS Architecture with Security in Mind, is where I will outline key concepts, techniques, tools, and methodologies around designing for security. How to architect a network so that it allows the easy implementation of security techniques, tools, and concepts will be discussed in the rest of the book.

Chapter 5, Introduction to Security Monitoring, is where we will discuss the ins and outs of cybersecurity monitoring as it pertains to the ICS environment. I will present the three main types of cybersecurity monitoring, passive, active, and threat hunting, which are explained in detail throughout the rest of the book.

Chapter 6, Passive Security Monitoring, is where we will look at the tools, techniques, activities, and procedures involved in passively monitoring industrial cybersecurity posture.

Chapter 7, Active Security Monitoring, looks at tools, techniques, activities, and procedures involved in actively monitoring industrial cybersecurity posture.

Chapter 8, Industrial Threat Intelligence, looks at tools, techniques, and activities that help to add threat intelligence to our security monitoring activities. Threat intelligence will be explained and common techniques and tools to acquire and assemble intelligence will be discussed.

Chapter 9, Visualizing, Correlating, and Alerting, explores how to combine all the gathered information and data, discussed in the previous chapters, into an interactive visualization, correlation, and alerting dashboard, built around the immensely popular ELK (Elasticsearch, Kibana, Logstash) stack, which is part of the Security Onion appliance.

Chapter 10, Threat Hunting, is a general introduction to threat hunting principles, tools, techniques, and methodology. This chapter will revisit Security Onion and how to use it for threat hunting exercises.

Chapter 11, Threat Hunt Scenario 1 – Malware Beaconing, presents the first threat hunt use case, where we suspect malware beaconing or data is being exfiltrated from our systems, and so we will use logs, events, data, and other information to prove the hunch and show the what, where, how, and who behind the attack.

Chapter 12, Threat Hunt Scenario 2 – Finding Malware and Unwanted Applications, presents the second threat hunt use case, built around the assumption that there is executable code running on assets on the ICS network that is performing malicious actions (malware) or is just using up (wasting) resources. These would be Potentially Unwanted Programs (PUPs), such as spyware, bitcoin miners, and so on.

Chapter 13, Threat Hunt Scenario 3 – Suspicious External Connections, presents a third threat hunt use case: we suspect that external entities are connecting to our systems. We will use logs, events, data, and other information to prove the hunch and show the what, where, how, and who behind things.

Chapter 14, Different Types of Cybersecurity Assessments, outlines the types of security assessments that exist to help you assess the risk to an ICS environment.

Chapter 15, Industrial Control System Risk Assessments, will detail the tools, techniques, methodologies, and activities used in performing risk assessments for an ICS environment. You will get hands-on experience with the most common tools and software used during assessment activities.

Chapter 16, Red Team/Blue Team Exercises, will detail the tools, techniques, methodologies, and activities used in performing red team and blue team exercises in an ICS environment. You will get hands-on experience with the most common tools and software used during assessment activities.

Chapter 17, Penetration Testing ICS Environments, will detail the tools, techniques, methodologies, and activities used in performing penetration testing activities in an ICS environment. You will get hands-on experience with the most common tools and software used during assessment activities.

Chapter 18, Incident Response for the ICS Environment, takes you through the phases, activities, and processes of incident response as it relates to the industrial environment:

Preparation

Identification

Containment

Investigation

Eradication

Recovery

Follow-up

Chapter 19, Lab Setup, will help you set up a lab environment to be used for the exercises in the book.

To get the most out of this book

To get the most out of this book, you should have an interest in industrial cybersecurity and in security monitoring in general. Apart from that, all relevant technical concepts are discussed in detail throughout the book so no technical prerequisites are necessary.

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: http://www.packtpub.com/sites/default/files/downloads/9781800202092_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: We can see Snort detected the response from testmyids.ca (104.31.77.72) as being malicious.

A block of code is set as follows:

sd.aler_rt Feb 15 2021 16:46:11

sd.alert_category NetworkAttack

sd.alert_message NMAP Scan detecte

sd.alert_name nmap_scan

sd.alert_number 11

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

    Microsoft-Windows-Sysmon/Operational

    eventchannel

Any command-line input or output is written as follows:

idstools:

  config:

    ruleset: ‘ETOPEN’

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: Navigate to the Home | Host | Sysmon dashboard and view the event logs at the bottom of the dashboard screen.

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you've read Industrial Cybersecurity - Second Edition, we'd love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we're delivering excellent quality content.

Section 1: ICS Cybersecurity Fundamentals

In part one, we will briefly recap the first edition of the book to outline what was covered and to point out the content that is still very relevant and that will be built upon in this second edition. The remainder of part one will be dedicated to discussions around a revised IDMZ architecture, resulting from many deployments, experience in the field, practice, and feedback. Part one will conclude with a deep dive into how to design for security, architecture that allows all the tools, techniques, and activities discussed in the rest of the book to be implemented effectively and easily.

This section comprises the following chapters:

Chapter 1, Introduction and Recap of the First Edition

Chapter 2, A Modern Look at the Industrial Control System Architecture

Chapter 3, The Industrial Demilitarized Zone

Chapter 4, Designing the ICS Architecture with Security in Mind

Chapter 1: Introduction and Recap of First Edition

Welcome to the second edition of Industrial Cybersecurity. Over the next 24 chapters, we will discuss the next logical steps after building a secure Industrial Control System (ICS) environment and defining a comprehensive set of policies, procedures, and standards, discussed in detail in the first edition.

We are going to start off this second edition with a brief recap of topics and material that were covered in the first edition of Industrial Cybersecurity. This has mainly been added to get you up to speed with the terminologies, technologies, and principles that are expanded upon throughout the rest of this book. The remainder of the book concentrates on security monitoring and verification of the ICS security posture and the various tools, techniques, and activities involved.

This chapter will be a review of the first edition of this book. We will go over all the topics and material that were covered in the first edition, which should give you a solid base for the topics covered in this book. The chapter will conclude with an explanation of what to expect in the rest of this second-edition book.

In this chapter, we'll cover the following topics:

What is an ICS?

Information Technology (IT) and Operational Technology (OT) convergence and the associated benefits and risks

The comprehensive risk management process

The Defense-in-Depth (DiD) model

ICS security program development

Industrial Cybersecurity – second edition

The way I am positioning the first and second editions of Industrial Cybersecurity is with the first edition focusing on ICS cybersecurity fundamentals and ICS cybersecurity program design and implementation. The second edition should be a logical addition by taking these core concepts and expanding upon them with tools, techniques, and activities that are aimed at verifying, monitoring, checking, improving, and correcting the overall security posture of the ICS environment. Some topics we will be covering on this continued journey include the following:

Architecture design with security in mind

Active and passive security monitoring

Industrial threat intelligence

Visualizing, correlating, and alerting (Security Information and Event Management (SIEM))

Incident response activities

Security assessments (penetration testing, red/blue team exercises)

Threat-hunting exercises

As mentioned earlier, this book will expand upon the topics of the first edition, so let's first recap on what we covered back in 2017.

Recap of the first edition

If you have not yet read the first edition of Industrial Cybersecurity, now would be the time to do so. It covers in detail how to get from zero to hero on implementing an industrial cybersecurity program, to define a secure ICS environment and network architecture that fits your organization's needs and requirements.

Reading the first edition is not a requirement though, as the first four chapters of this book will recap on relevant topics and get you on track to follow along and understand the material presented in this second edition.

Without further ado, let's start our journey with a recap of ICS (cybersecurity) principles and practices.

What is an ICS?

The traffic lights on your way to work if you go by car; the collision avoidance system if you take the train or metro; the delivery of electricity that powers the light you use to read this book; the processing and packaging that went into creating the jug of milk in your fridge or the coffee grind for that cup of Joe that fuels your day... What all these things have in common is the ICS driving the measurements, decisions, corrections, and other miscellaneous actions that result in the end products and services we take for granted each day.

Strictly speaking, an ICS is a collection of equipment, devices, and communication methods that, when combined for the foundational system, perform a specific task, deliver a service, or create a particular product. Figure 1.1 shows an ICS architecture, spanning the various layers of functionality as described in the Purdue model (explained in a later section).

ICS functions

The following screenshot shows a typical ICS architecture, following the Purdue model and stretched out across the industrial and enterprise networks of an organization. It will be used as an illustration for the following sections:

Figure 1.1 – Typical ICS architecture

Within the ICS architecture shown in the preceding screenshot, the following main types of devices within the three main sections of the architecture can typically be distinguished:

The Enterprise Zone is predominantly IT space. Devices, systems, and equipment typically found here are computer-related, such as servers, workstations, and laptops, as well as mobile devices such as phones, tablets, handhelds, and others. These devices are connected together with various Ethernet equipment and media, including switches, wireless access points, routers, firewalls, and the cables that connect all of these devices (Category 6 (Cat6)/Cat6e media).

The Industrial Demilitarized Zone (IDMZ) functions as a barrier between the Enterprise Zone and the Industrial Zone and is typically implemented as a collection of virtualization hardware, firewalls, and switches.

In the Industrial Zone, we can find a variety of regular off-the-shelf IT equipment, along with proprietary and specialized hardware that is used to run the production process. In an upcoming section, ICS architecture, we will discuss some of the more common systems that can be found in the Industrial Zone.

The ultimate goal of an ICS is to create a product or run a process. This goal is achieved by implementing distinct functions within the ICS that, when combined, allow for control, visibility, and management of the production or process control. We will now look at typical functions found within an ICS.

The view function

The view function encompasses the ability to watch the current state of the automation system in real time. This data can be used by operators, supervisors, maintenance engineers, or other personnel to make business decisions or perform corrective actions. For example, when an operator sees that the temperature of boiler 1 is getting low, they might decide to increase the steam supply of the boiler to compensate. The view process is passive in nature, merely providing the information or view for a human to react to.

The view function is presented in the following diagram:

Figure 1.2 – The view function

From a security perspective, if an attacker can manipulate the operator's view of the status of the control system—or, in other words, can change the values the operator makes decisions on—the attacker effectively controls the reaction and, therefore, the complete process. For example, by manipulating the displayed value for the temperature of boiler 1, an attacker can make the operator think the temperature is too low or too high and have them act upon manipulated data.

The monitor function

The monitor function is often part of a control loop, such as the automation behind keeping a steady level in a tank. The monitor function will keep an eye on a critical value such as pressure, temperature, and level, comparing the current value against predefined threshold values, and will alarm or interact depending on the setup of the monitoring function. A key difference between the view function and the monitor function is in the determination of deviation. With monitoring functions, this determination is an automated process, whereas with a view function, that determination is made by a human looking at the values. The reaction of the monitor function can range from a pop-up alarm screen to a fully automated system shutdown procedure.

From a security perspective, if an attacker can control the value that the monitor function is looking at, the reaction of the function can be triggered or prevented—for example, in the case where a monitoring system is looking at the temperature of boiler 1, preventing the temperature exceeding 300 °F. If an attacker feeds a value of less than 300 °F into the system, that system will be tricked into believing all is well while, in the meantime, the system can be in meltdown.

The control function

The control function is where things are manipulated, moved, activated, and initiated. The control system is what makes actuators engage, valves open, motors run... The control actions can be initiated by an operator either pushing a button or changing a setpoint on a Human-Machine Interface (HMI) screen, or it can be an automated response as part of the process control.

The control function is presented in the following diagram:

Figure 1.3 – The control function

From a security perspective, if an attacker can manipulate the values (the input) the control system reacts on, or if they can change or manipulate the control function itself (the control program), the system can be tricked into doing things it wasn't designed to do or intended for.

Now, I can hear you all say, that is all fine and dandy manipulating values, but surely that cannot be done with modern switched networks and encrypted network protocols. That would be true if those technologies were implemented and used. But the fact is that on most, if not all, ICS networks, confidentiality and integrity of industrial network traffic is of less importance than availability of the ICS. Even worse, for most ICSs, availability ends up being the only design consideration when architecting the system. Combine that with the fact that the ICS communication protocols running on these networks were never designed with security in mind, and you can start to see the feasibility of the scenarios mentioned. Most automation protocols were introduced when computer networks were not yet touching automation devices, for media that was never meant to share data across more than a point-to-point link, so security around authentication, confidentiality of data, or integrity of send commands was never implemented. Later, those point-to-point protocols were adapted to work on communication equipment such as Ethernet, which exposed the insecure protocols to the entire production floor, the plant, or even out to the internet.

ICS architecture

ICS is an all-encompassing term used for various automation systems and their devices, such as Programmable Logic Controllers (PLCs), HMIs, Supervisory Control And Data Acquisition (SCADA) systems, Distributed Control Systems (DCSes), Safety Instrumented Systems (SIS), and many others.

The ICS architecture is presented in the following diagram:

Figure 1.4 – Large-scale ICS architecture

PLCs

PLCs are at the heart of just about every ICS. They are the devices that take data from sensors via input channels and control actuators via output channels. A typical PLC consists of a microcontroller (the brains) and an array of input and output (I/O) channels. I/O channels can be analog, digital, or network-exposed values. These I/O channels often come as add-on cards that attach to the backplane of a PLC. This way, a PLC can be customized to fit many different functions and implementations. Programming of a PLC can be done via a dedicated Universal Serial Bus (USB) or serial interface on the device or via the network communications bus that is built into the device, or comes as an add-on card. Common networking types in use are Modbus, Ethernet, ControlNet, and PROFINET.

An example of a mounted PLC is provided in the following screenshot:

Figure 1.5 – An Allen-Bradley rack-mounted PLC

PLCs can be deployed as standalone devices, controlling a certain part of the manufacturing process such as a single machine, or they can be deployed as distributed systems, spanning multiple plants in dispersed locations with thousands of I/O points and numerous interconnecting parts.

HMI

An HMI is the window into the control system. It visualizes the running process, allowing inspection and manipulation of process values, showing of alarms, and trending of control values. In its simplest form, an HMI is a touch-enabled standalone device that is communicated via a serial or Ethernet-encapsulated protocol.

Some examples of HMIs are presented in the following screenshot:

Figure 1.6 – HMIs

More advanced HMI systems can use distributed servers to offer a redundant supply of HMI screens and data. An example of one such system is presented in the following screenshot:

Figure 1.7 – FactoryTalk View SE Distributed HMI system

The preceding screenshot shows an example of a distributed Rockwell Automation FactoryTalk View Site Edition (SE)-distributed HMI application.

SCADA

SCADA is a term used to describe a combined use of ICS types and devices, all working together on a common task. The following screenshot shows an example SCADA network. Here, the SCADA network comprises all the equipment and components that together form the overall system:

Figure 1.8 – SCADA

As depicted in the preceding screenshot, SCADA systems can be spread out over a wide geographical area, being applied to the power grid, water utilities, pipeline operations, and other control systems that use remote operational stations.

DCS

Closely related to a SCADA system is the DCS. The differences between a SCADA system and a DCS are very small, and the two are becoming more indistinguishable all the time. Traditionally, though, SCADA systems have been used for automation tasks that cover a larger geographical area, whereas a DCS is more often confined to a single plant or facility. A DCS is often a large-scale, highly engineered system with a very specific task. It uses a centralized supervisory unit that can control thousands of I/O points. The system is built to last, with redundancy applied to all levels of the installation.

An example DCS is presented in the following screenshot:

Figure 1.9 – DCS

As depicted in the preceding screenshot, DCSes use redundant networks and network interfaces, attached to redundant server sets and connected to redundant controllers and sensors, all with the goal of creating a rigid and solid automation platform in mind. DCSes are most commonly found in water management systems, paper and pulp mills, sugar refinery plants, and so on. 

The distributed nature of a DCS makes it more difficult to secure as it often has to break network section boundaries, and the shared amount of human interaction with the DCS creates a greater chance of malware infections.

SIS

SISes are dedicated safety monitoring systems. They are there to safely and gracefully shut down the monitored system or bring that system to a predefined safe state in case of a hardware malfunction. A SIS uses a set of voting systems to determine whether a system is performing normally. If a safety system is configured to shut down the process of a machine when unsafe conditions are detected, it is considered an Emergency Shutdown (ESD) system.

An example of an SIS is presented in the following screenshot:

Figure 1.10 – SIS

Safety systems were initially designed to be standalone and disconnected monitoring systems (think bolt-on, local device/system inspection), but the trend over the past years has been to start attaching them to the industrial network, adding an easy way of (re)configuring them but also exposing them to potential attacks with all the accompanying risks. An ESD could be misused by potential attackers. They could reconfigure the SIS to shut down the system to cause financial loss for the company, or instruct the SIS to not shut down when required as an aim to perform physical damage to the operation, with the disastrous side effect that people's lives are at stake.

Consider, for example, the TRITON attack/malware campaign that targeted SIS systems back in 2017:

https://www.nozominetworks.com/blog/new-triton-ics-malware-is-bold-and-important/#:~:text=The%20attack%20reprogrammed%20a%20facility%E2%80%99s%20Safety%20Instrumented%20System,impacted%20not%20just%20an%20ICS%2C%20but%20SIS%20equipment

The Purdue model for ICSes

So, how does all this tie together? What makes for a solid ICS architecture? To answer that question, we should first discuss the Purdue reference model—or Purdue model, for short. Shown in the next screenshot, the Purdue model was adopted from the Purdue Enterprise Reference Architecture (PERA) model by ISA-99 and is used as a concept model for ICS network segmentation. It is an industry-adopted reference model that shows the interconnections and interdependencies of all the main components of a typical ICS. The model is a great resource to start the process of figuring out a typical modern ICS architecture and is presented here:

Figure 1.11 – The Purdue model

The Purdue model divides the ICS into four distinct zones and six levels. The following sections will describe the zones and levels, combining the bottom two zones into the Industrial Zone.

The Enterprise Zone

The part of the ICS that business systems and users directly interact with resides in the Enterprise Zone.

This is depicted in the following screenshot:

Figure 1.12 – The Enterprise Zone

The Enterprise Zone can be subdivided into Level 5 (Enterprise Network) and Level 4 (Site Business Planning and Logistics). Note that not all companies' Enterprise Zones will necessarily have a Level 5, and some might combine levels 5 and 4.

Level 5 – Enterprise Network

The Enterprise Zone is the part of the network where business systems such as Enterprise Resource Planning (ERP) and Systems Applications and Products (SAP) typically live. Here, tasks such as scheduling and supply chain management are performed. The systems in this zone normally sit at a corporate level and span multiple facilities or plants. They take data from subordinate systems that are located out in the individual plants and use the accumulated data to report on overall production status, inventory, and demand. Technically not part of the ICS, the Enterprise Zone does rely on connectivity with the ICS networks to feed the data that drives business decisions.

Level 4 – Site Business Planning and Logistics

Level 4 is home to all the IT systems that support the production process in a plant or facility. These systems report production statistics such as uptime and units produced to corporate systems, and take orders and business data down from the corporate systems to be distributed among the OT or ICS systems.

Systems typically found in level 4 include database servers, application servers (web, report, the Manufacturing Execution System (MES)), file servers, email clients, supervisor desktops, and so on.

The IDMZ

Between the Enterprise Zone and the Industrial Zone lies the IDMZ, depicted in the following screenshot:

Figure 1.13 – The IDMZ

The IDMZ contains a single level: level 3.5.

Level 3.5 – The IDMZ

As the level number might imply, level 3.5 was added to the model later. It stems from the efforts taken to create security standards such as the National Institute of Standards and Technology (NIST) Cybersecurity Framework and North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP). The IDMZ is an information-sharing layer between the business or IT systems in levels 4 and 5, and the production or OT systems in levels 3 and below. By preventing direct communication between IT and OT systems, but rather having a broker service in the IDMZ relay communications, an extra layer of separation and inspection is added to the overall architecture. Systems in the lower layers are not being exposed directly to attacks or compromise. If, at some point, something were to compromise a system in the IDMZ or above, the IDMZ could be shut down, the compromise contained, and production could continue.

Systems typically found in the IDMZ include (web) proxy servers, database replication servers, Network Time Protocol (NTP) servers, file transfer servers, Windows Server Update Service (WSUS) servers, and other transitional (broker) service servers. The IDMZ tends to be a virtual stack to allow flexibility when building broker services and implementing redundancy, failover, and easy restore functionality.

The Industrial Zone

At the heart (or bottom) of the ICS is the Industrial Zone; this is the part of the ICS environment we are trying to protect by shielding it off from the rest of the world. The ultimate goal is to have most of the user interactions occurring on the Enterprise network/zone, where systems can be more easily patched, monitored, and contained. Any traffic, data, or interactions that need to dribble down to production systems do so via tightly defined and well-configured methods (broker services—see later) in the IDMZ, and are shielded from directly manipulating the production and automation systems and devices.

The Industrial Zone is depicted in the following diagram:

Figure 1.14 – The Industrial Zone

The Industrial Zone consists of levels 3-0, explained in the next sections.

Level 3 – Site Operations

Level 3 is where systems reside that support plant-wide control and monitoring functions. At this level, the operator is interacting with the overall production systems. Think of centralized control rooms with HMIs and operator terminals that give an overview of all the systems that run the processes in a plant or facility. The operator uses these HMI systems to perform tasks such as quality control checks, managing uptime, and monitoring alarms, events, and trends.

Level 3, Site Operations, is also where the OT systems live that report back to IT systems in level 4. Systems in lower levels send production data to data collection and aggregation servers in this level, which can then send the data up to higher levels or can be queried by systems in higher levels (push versus pull operations).

Systems typically found in level 3 include database servers, application servers (web, report), file servers, Microsoft domain controllers, HMI servers, engineering workstations, and so on. These types of systems can be found on the Enterprise network as well, but here they interact with the production process and data. The Microsoft domain controller at Level 3, Site Operations, should be used to implement a standalone industrial domain and Active Directory that is in no way tied to the Enterprise domain. Any link from an Enterprise domain to the Industrial Zone can allow the propagation of attacks or malware from the Enterprise Zone down into the industrial environment.

Level 2 – Area Supervisory Control

Many of the functions and systems in level 2 are the same as for level 3 but are targeted more toward a smaller part or area of the overall system. In this level, specific parts of the system are being monitored and managed with HMI systems. Think along the lines of a single machine or skid with a touchscreen HMI to start or stop the machine or skid, and to see some basic running values and manipulate machine- or skid-specific thresholds and setpoints.

Systems typically found in level 2 include HMIs (standalone or system clients), supervisory control systems such as a line-control PLC, engineering workstations, and so on.

Level 1 – Basic Control

Level 1 is where all the controlling equipment lives. The main purpose of the devices in this level is to open valves, move actuators, start motors... Typically found in level 1 are PLCs, Variable-Frequency Drives (VFDs), dedicated proportional–integral–derivative (PID) controllers, and so on. Although you could find a PLC in level 2, its function there is of a supervisory nature instead of a controlling one.

Level 0 – Process

Level 0 is where the actual process equipment lives that we are controlling and monitoring from the higher levels. Also known as Equipment