Introduction to Control Systems Security
An introduction to industrial control systems, their security needs and the consequences of cyber incidents in operational environments.
Loading progress…
Loading browser progress…
Learning objectives
By the end of this module, you should be able to:
- Define OT and IACS in practical engineering terms.
- Identify the people, systems, services and dependencies that can influence an industrial process.
- Explain how a cyber event can lead to a physical, safety, environmental or operational consequence.
- Compare common IT and OT security considerations.
- Challenge common assumptions about isolation, legacy systems and protective controls.
- Explain defence-in-depth and the need for multiple opportunities to detect abnormal activity.
Introduction
Industrial cyber security is not simply IT security applied to a factory or plant.
In this module, interacts with the physical world. A compromised digital system can therefore affect how equipment behaves, how operators understand the process and, in some cases, whether the process remains safe.
Cyber security decisions in OT must consider more than information. They must also consider safe operation, reliability, environmental impact, equipment integrity, service continuity and recovery.
This module establishes that engineering perspective.
Planned video lesson
Video lesson coming soon. The written module can be completed without the video.
Planned recording: 6-8 minutes explaining why an OT cyber incident is an engineering and physical-process problem, using Riverside as the example.
Transcript will be added with the video.
Main lesson
What is being protected?
Operational technology includes programmable systems and devices that monitor, control or influence physical processes or environments.
An is wider than the cabinet. It includes the people, hardware, software, networks, procedures and information needed to operate and maintain the industrial process.
A security assessment must also consider supporting services, maintenance tools and external dependencies that can influence the system.
The assessment scope may therefore include:
- Controllers, RTUs, DCS nodes and safety-related systems.
- HMIs, engineering workstations, historians and application servers.
- Network switches, routers, firewalls, wireless infrastructure and serial gateways.
- Vendor laptops, removable media and portable test equipment.
- Identity, time synchronisation, backup, logging and remote-access services.
- Configuration files, software and other information required to operate or recover the system.
- Procedures, competent people and approved ways of working.
- External services and suppliers on which operation, maintenance or recovery depends.
A weakness in any one of these areas can create a route to, or dependency affecting, the physical process.
Figure 2. A cyber action can propagate from a compromised engineering workstation into a physical process deviation with safety, environmental, production and recovery consequences.
Think in consequences, not only data
In enterprise IT, cyber incidents commonly involve information, business systems and organisational services.
Those concerns remain relevant in OT, but the consequences can extend into the physical process.
Examples include:
- Loss of process visibility or control.
- Unauthorised changes to logic, setpoints or configuration.
- Suppressed alarms or falsified measurements.
- Equipment damage, abnormal operation or premature wear.
- Environmental release.
- Unsafe plant conditions.
- Loss of production or essential service.
- Extended recovery because of unavailable spares, unsupported systems, specialist dependencies or loss of known-good configuration.
The correct starting question is not:
“Which cyber product should we buy?”
It is:
“Which cyber events could prevent the process from remaining safe, controlled and recoverable?”
IT and OT require different engineering decisions
| Consideration | Typical enterprise IT | Typical industrial OT |
|---|---|---|
| Main purpose | Process, store and protect information | Monitor or control physical processes |
| Technology lifecycle | Often shorter refresh cycles | Long lifecycles are common, with legacy or unsupported equipment often remaining in service |
| Restart | Often routine | May interrupt production or create process risk |
| Patching | Often frequent and centrally managed | May require compatibility testing, vendor support and an approved outage |
| Network traffic | Diverse and frequently changing | Often application-specific, comparatively stable and process-dependent |
| Risk emphasis | Information, business services and organisational impact | Safe and reliable operation, physical process, environment and service delivery |
| Recovery | Rebuild or replacement may be practical | Restore known-good logic and configuration and return the process to a safe operating state |
These are typical characteristics rather than absolute rules. OT still requires confidentiality, integrity and availability, but the relative importance of each depends on the system and process.
Availability does not automatically override security. Every security control should instead be assessed against the actual process and its risks.
Automatically isolating a compromised engineering workstation may be appropriate. Automatically isolating a controller during a critical process state could create a greater hazard. The correct response depends on the architecture, process state, dependencies and pre-planned incident response arrangements.
Common assumptions to challenge
- “The system is air-gapped.” Do not assume isolation. Verify the actual architecture and every relevant route into or out of the environment, including engineering laptops, removable media, cellular connections, wireless networks, data transfers, vendor support and temporary commissioning connections.
- “Nobody would target us.” Not every damaging cyber event requires deliberate targeting of the site. Malware, ransomware, human error and supply-chain compromise can affect industrial systems without the organisation being the original target.
- “It uses a proprietary protocol.” A proprietary protocol is not automatically secure. Obscurity alone does not provide reliable authentication, authorisation, integrity or confidentiality.
- “A firewall makes the system secure.” A firewall can control permitted communications between networks. It does not correct weak accounts, insecure engineering practices, unsupported assets, compromised endpoints or inadequate recovery arrangements.
- “Safety and cyber security are separate.” Safety and cyber security are distinct engineering disciplines, but their risks can interact. A cyber event can challenge several layers used to maintain safe operation, including the basic process control system, alarms and operator response. Depending on the architecture and shared dependencies, safety-related or protective systems may also be affected.
Defence and detection in depth
The approach uses multiple, mutually supporting security controls so that failure or bypass of one control does not leave the system without protection.
Controls may exist across governance and procedures, physical security, identity and access management, device and system hardening, , secure communications, application security, engineering and maintenance processes, backup and recovery, incident response and security monitoring.
Defence-in-depth is not limited to preventive controls. A resilient security architecture combines prevention, protection, detection, response and recovery.
Safety-related or independent protective functions may reduce the consequence of some cyber-induced process failures, but they should not be treated as a substitute for cyber security controls.
A approach asks whether there are multiple opportunities to identify abnormal activity or failed controls. An unauthorised controller change might be detected through access records, unexpected engineering communications, network monitoring, logic comparison, system logs, process behaviour, alarm review or operator reporting.
No single detection method should be assumed to identify every event.
Engineering example
Riverside application
Riverside application
Riverside is a pumping installation containing controllers, operator interfaces, an engineering workstation, network infrastructure, telemetry, historical data services and external support dependencies.
The PLC may directly control the process, but protecting only the PLC would leave important paths and dependencies unaddressed. An engineering workstation can modify controller configuration, operators depend on trustworthy HMI information, and maintenance equipment and remote support can introduce additional connections.
A cyber event may therefore propagate beyond the originally compromised asset: compromised engineering workstation → unauthorised control change → loss of trustworthy control → process deviation → operational, safety or environmental consequence .
The engineering question is: What can influence the process, and what would happen if that influence could no longer be trusted?
Practical activity
Apply what you learned
Before listing threats or attack methods, identify three unacceptable outcomes for Riverside:
- Pumps run outside safe hydraulic limits.
- Operators lose trustworthy indication during a developing fault.
- The station cannot be restored within the required recovery time.
For each outcome, identify at least two plausible cyber paths or failures that could contribute to it.
Consider:
- Which systems would need to be affected?
- Which connections or dependencies could provide a path?
- Which existing controls might prevent or limit the event?
- How could abnormal activity be detected?
- What would be required to recover safely?
This consequence-first approach helps prevent a risk assessment from becoming a generic list of malware or threat names.
Record your reasoning and project notes here. Your response stays in this browser until you choose to save it to an account.
Loading saved response…
0 / 10,000Do not enter real credentials, confidential network details, sensitive asset information or security-sensitive project data.
Knowledge check
Answer every question correctly to complete this module. If an answer is incorrect, review the explanation and try again. This is not a formal examination.
Key takeaways
Remember these points
- OT cyber incidents can create physical, safety, environmental and service consequences.
The IACS boundary includes people, procedures, support tools and external dependencies as well as controllers.
- OT security decisions must account for the state and requirements of the physical process.
- Defence-in-depth combines complementary controls across people, process and technology.
- Effective security requires multiple opportunities to detect abnormal activity.
Safety-related systems can reduce some consequences, but functional safety is not a substitute for cyber security.
Relevant standards and guidance
This module uses original explanatory language. Consult the applicable editions, regulatory requirements and project requirements rather than treating this lesson as normative text.
International standards
- ISA/IEC 62443 series — Security for industrial automation and control systems.
UK guidance
NCSC Operational Technology guidance
Practical UK guidance for understanding OT architecture, connectivity, risk and resilience.
NCSC Cyber Assessment Framework
A structured framework for assessing security and resilience around essential functions.
HSE Cyber Security for IACS
Guidance for industrial automation and control systems where cyber security can affect major-accident risk.
Additional technical guidance
NIST SP 800-82 Rev. 3
The current final NIST guide to operational technology security.
NIST SP 800-82 Rev. 4
The Initial Public Draft of the next revision; Rev. 3 remains the current final publication.
CISA ICS recommended practices
Recommended practices and supporting resources for industrial control system security.
Last reviewed
6 October 2026.
Loading progress. You can keep reading.
Module completion is not a certificate or formal training record.