> ## Content Index
> Fetch the complete content index at: https://www.ostering.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Control Centre and SCADA (CC)

- URL: https://www.ostering.com/taxonomies/critical-infrastructure/bks-control-centre-and-scada/
- Published: 2026-11-05T21:00:00.000Z
- Updated: 2026-11-05T20:46:56.323Z
- Description: SCADA, HMIs, historians and the operators at the desk: 13 threats with mitigation principles, design measures and ATT&CK for ICS mappings.
- Author: Brett Crawley

[Taxonomies](https://ostering.com/taxonomies/) › [Critical Infrastructure](https://ostering.com/taxonomies/critical-infrastructure/) › CC · Control Centre and SCADA

Where operators see and steer the process: HMIs, historians, engineering workstations, alarms and the people at the desk. Part of The Estate deck, ranked Ace to 2 by severity in the game. This page is part of the [Critical Infrastructure (Cyberwarfare) Threat Taxonomy](https://ostering.com/taxonomies/critical-infrastructure/), the reference for the Black Start card game.

![CC Control Centre and SCADA taxonomy table, 13 entries: BKS-CC-A The screen is the only witness; BKS-CC-K The operator's tools do the damage; BKS-CC-Q One directory for IT and OT; BKS-CC-J The engineering workstation holds every key; BKS-CC-10 Alarm floods bury the critical one; BKS-CC-9 A flat network behind the firewall; BKS-CC-8 The historian is a bridge; BKS-CC-7 Nobody has rehearsed manual operation; BKS-CC-6 The backup centre fails too; BKS-CC-5 Shared operator accounts; BKS-CC-4 Legacy operating systems on HMIs; BKS-CC-3 Too little logging in OT; BKS-CC-2 Data crosses on USB sticks. Each row gives the threat, any public case, the mitigation principle and the design measures.](https://www.ostering.com/media/posts/185/critical-infrastructure-control-centre-and-scada-taxonomy-table.png =1400x2081)

## Mappings at a glance

STRIDE, CAPEC 3.9, CWE 5.0, ATT&CK for ICS v20.0, the Cyber-Informed Engineering principles (main one first) and standards, entry by entry. The same mappings are in each entry below and in the [Excel, SKOS and STIX downloads](https://ostering.com/taxonomies/critical-infrastructure/#downloads).

![CC Control Centre and SCADA mapping table, 13 entries: BKS-CC-A The screen is the only witness; BKS-CC-K The operator's tools do the damage; BKS-CC-Q One directory for IT and OT; BKS-CC-J The engineering workstation holds every key; BKS-CC-10 Alarm floods bury the critical one; BKS-CC-9 A flat network behind the firewall; BKS-CC-8 The historian is a bridge; BKS-CC-7 Nobody has rehearsed manual operation; BKS-CC-6 The backup centre fails too; BKS-CC-5 Shared operator accounts; BKS-CC-4 Legacy operating systems on HMIs; BKS-CC-3 Too little logging in OT; BKS-CC-2 Data crosses on USB sticks. Each row gives the STRIDE categories, CAPEC patterns, CWE weaknesses, ATT&CK for ICS techniques, Cyber-Informed Engineering principles and standards for the entry.](https://www.ostering.com/media/posts/185/critical-infrastructure-control-centre-and-scada-mapping-table.png =1400x1238)

## Entries

<h3 id="bks-cc-a">BKS-CC-A · The screen is the only witness †</h3>

Control rooms have removed local gauges, panel indicators and independent instruments, so the HMI is the only way to know the state of the plant. When its values are replayed or altered, operators see a normal plant while the process is driven out of control, and nothing tells them otherwise.

*Case:* Stuxnet, 2010.

**Principle.** Critical process states must be visible through a path the control system cannot falsify.

**Design measures.**

1. Install independent instruments for the most critical variables, with their own display or alarm.
2. Cross-check SCADA values against physics and independent sensors, and alarm on disagreement.
3. Train operators to trust local readings and plant behaviour over the screen when they conflict.

*Mappings:* STRIDE S, T · [CAPEC-148](https://capec.mitre.org/data/definitions/148.html) · [CWE-451](https://cwe.mitre.org/data/definitions/451.html) · ATT&CK for ICS [T0832](https://attack.mitre.org/techniques/T0832/), [T0829](https://attack.mitre.org/techniques/T0829/) · CIE 2, 5

<h3 id="bks-cc-k">BKS-CC-K · The operator's tools do the damage †</h3>

The control system lets an operator session open breakers, stop pumps or change modes across many sites in a few clicks, with no second check. An attacker who takes over a session uses the operator's own HMI to cause the outage.

*Case:* Ukraine grid attack, 2015.

**Principle.** Wide-area and irreversible commands should need more than one person and more than one session.

**Design measures.**

1. Require a second authorised person to confirm commands that affect many sites or critical assets.
2. Limit how many sites or assets one command or one session can change in a period.
3. Show operators who else is connected and what they are doing in real time.

*Mappings:* STRIDE E, T · ATT&CK for ICS [T0823](https://attack.mitre.org/techniques/T0823/), [T0831](https://attack.mitre.org/techniques/T0831/), [T0886](https://attack.mitre.org/techniques/T0886/) · CIE 2, 4

<h3 id="bks-cc-q">BKS-CC-Q · One directory for IT and OT</h3>

The control environment trusts the corporate directory, so compromising the business domain grants accounts and administrative rights on SCADA servers and workstations. The boundary between IT and OT exists on the diagram only.

*Case:* Volt Typhoon pre-positioning, 2024 advisory; NotPetya, 2017.

**Principle.** Operational systems must not depend on the business identity system to decide who is trusted.

**Design measures.**

1. Run a separate directory for OT with no trust relationship to the corporate domain.
2. Use separate, MFA-protected accounts for OT administration, never reused from IT.
3. Test whether a fully compromised corporate domain can reach any OT system.

*Mappings:* STRIDE E, S · [CAPEC-560](https://capec.mitre.org/data/definitions/560.html) · [CWE-653](https://cwe.mitre.org/data/definitions/653.html) · ATT&CK for ICS [T0859](https://attack.mitre.org/techniques/T0859/) · CIE 3, 5

<h3 id="bks-cc-j">BKS-CC-J · The engineering workstation holds every key †</h3>

One engineering workstation holds the project files, programming software and passwords for every controller in the plant. Compromise it, or infect its project files, and the attacker can reprogram the whole estate with the engineers' own tools.

*Case:* Stuxnet, 2010.

**Principle.** Engineering capability should be split, protected and used only when needed.

**Design measures.**

1. Keep engineering workstations off the network except during planned work, and log every session.
2. Store controller credentials in a protected vault, not in project files or on the desktop.
3. Check project files against approved versions before downloading them to controllers.

*Mappings:* STRIDE E, T, I · [CAPEC-441](https://capec.mitre.org/data/definitions/441.html) · [CWE-256](https://cwe.mitre.org/data/definitions/256.html), [CWE-653](https://cwe.mitre.org/data/definitions/653.html) · ATT&CK for ICS [T0873](https://attack.mitre.org/techniques/T0873/), [T0843](https://attack.mitre.org/techniques/T0843/) · CIE 3, 11

<h3 id="bks-cc-10">BKS-CC-10 · Alarm floods bury the critical one †</h3>

Alarm management is weak, and false or nuisance alarms can be generated from the control network. An adversary floods operators with alarms during the attack, so the one that matters is missed, acknowledged in bulk or shelved.

**Principle.** Operators must be able to see the critical alarm whatever else is happening.

**Design measures.**

1. Rationalise alarms to a load operators can handle in a serious incident, with clear priorities.
2. Route the most critical alarms through an independent path and display that bulk acknowledgement cannot clear.
3. Detect abnormal alarm rates and treat a flood as a possible attack.

*Mappings:* STRIDE D, S · ATT&CK for ICS [T1692.002](https://attack.mitre.org/techniques/T1692/002/) · CIE 2, 6

<h3 id="bks-cc-9">BKS-CC-9 · A flat network behind the firewall</h3>

Inside the control centre, servers, HMIs, engineering workstations and controllers share one network with no zones. A single foothold reaches everything, and nothing slows or reveals lateral movement.

**Principle.** Divide the control network into zones by function and consequence, with controlled conduits between them.

**Design measures.**

1. Zone the control network following IEC 62443 zones and conduits, with the most critical assets in the smallest zones.
2. Allow only the protocols and hosts each conduit needs, and deny the rest.
3. Monitor traffic between zones and alarm on new connections.

*Mappings:* STRIDE E, T · [CAPEC-700](https://capec.mitre.org/data/definitions/700.html) · [CWE-653](https://cwe.mitre.org/data/definitions/653.html) · ATT&CK for ICS [T0886](https://attack.mitre.org/techniques/T0886/), [T0867](https://attack.mitre.org/techniques/T0867/) · CIE 3, 5

<h3 id="bks-cc-8">BKS-CC-8 · The historian is a bridge</h3>

Historians, reporting servers and data links that copy process data to the business network are two-way or dual-homed. The route built to let data out becomes the route the attacker uses to get in.

**Principle.** Data should leave the control network by a path that cannot carry traffic back in.

**Design measures.**

1. Use a DMZ with a replica historian, so business users never connect to the OT historian.
2. Use one-way data diodes for data that only needs to leave.
3. Remove dual-homed hosts and document every link between IT and OT.

*Mappings:* STRIDE E, I · [CAPEC-700](https://capec.mitre.org/data/definitions/700.html) · [CWE-669](https://cwe.mitre.org/data/definitions/669.html) · ATT&CK for ICS [T0886](https://attack.mitre.org/techniques/T0886/) · CIE 3

<h3 id="bks-cc-7">BKS-CC-7 · Nobody has rehearsed manual operation †</h3>

Procedures, staffing and training assume the SCADA system works. When it must be switched off because it cannot be trusted, operators do not know how to run the plant by hand, so a cyberattack becomes a total outage.

*Case:* Norsk Hydro, 2019; Ukraine grid attack, 2015.

**Principle.** Be able to run essential functions safely without the control system, for long enough to rebuild it.

**Design measures.**

1. Write and rehearse manual operating procedures for the essential functions, with field staff.
2. Keep the local controls, gauges and hand tools that manual operation needs, and test them.
3. Plan staffing for sustained manual operation, which takes many more people.

*Mappings:* STRIDE D · ATT&CK for ICS [T0827](https://attack.mitre.org/techniques/T0827/) · CIE 10, 12

<h3 id="bks-cc-6">BKS-CC-6 · The backup centre fails too</h3>

The backup control centre replicates the primary in real time, with the same accounts, software and connections. A wiper or malicious change in the primary reaches the backup in seconds, so it fails at the same moment.

**Principle.** A backup control centre must be able to survive what destroys the primary.

**Design measures.**

1. Use separate credentials and administration for the backup centre.
2. Delay or check replication of configuration and software changes, so damage can be stopped.
3. Exercise switching to the backup after a simulated destructive attack on the primary.

*Mappings:* STRIDE D, T · ATT&CK for ICS [T0809](https://attack.mitre.org/techniques/T0809/) · CIE 10, 5

<h3 id="bks-cc-5">BKS-CC-5 · Shared operator accounts</h3>

Operators share generic accounts on HMIs and servers, so no action can be tied to a person. An attacker using the same account looks like a shift worker, and investigators cannot tell which actions were legitimate.

**Principle.** Every action on the control system should be traceable to one person.

**Design measures.**

1. Give each operator and engineer a named account, with quick log-on at the HMI.
2. Log commands and setpoint changes with the named user, and keep the logs off the HMI.
3. Review use of any remaining shared or service accounts.

*Mappings:* STRIDE S, R · [CWE-778](https://cwe.mitre.org/data/definitions/778.html) · ATT&CK for ICS [T0859](https://attack.mitre.org/techniques/T0859/) · CIE 12, 3

<h3 id="bks-cc-4">BKS-CC-4 · Legacy operating systems on HMIs</h3>

HMIs and SCADA servers run operating systems the vendor no longer supports, because the control software is certified only for them. They cannot run current protection and carry known weaknesses for years.

**Principle.** Contain what cannot be updated, and plan its replacement.

**Design measures.**

1. Isolate unsupported hosts in their own zone, with application allow-listing.
2. Require vendors to certify current operating systems within an agreed period.
3. Track unsupported systems in the risk register with an owner and a date.

*Mappings:* STRIDE T, E · [CWE-1104](https://cwe.mitre.org/data/definitions/1104.html) · ATT&CK for ICS [T0866](https://attack.mitre.org/techniques/T0866/) · CIE 8, 10

<h3 id="bks-cc-3">BKS-CC-3 · Too little logging in OT</h3>

Control systems keep few logs, store them on the device or host, and nobody watches OT network traffic. An adversary can live in the environment for years, clearing what traces there are, and leave no record to investigate.

*Case:* Volt Typhoon pre-positioning, 2024 advisory.

**Principle.** Collect OT security logs and network data centrally, where the adversary cannot erase them.

**Design measures.**

1. Send logs from OT hosts and devices to a protected collector with retention measured in years.
2. Deploy passive OT network monitoring that understands industrial protocols.
3. Alarm when a log source falls silent.

*Mappings:* STRIDE R, I · [CAPEC-571](https://capec.mitre.org/data/definitions/571.html) · [CWE-778](https://cwe.mitre.org/data/definitions/778.html) · ATT&CK for ICS [T0872](https://attack.mitre.org/techniques/T0872/) · CIE 6, 8

<h3 id="bks-cc-2">BKS-CC-2 · Data crosses on USB sticks</h3>

Patches, recipes, backups and reports move in and out of the control network on removable media because there is no other path. Malware rides in on them and reaches hosts that have no network route to the outside.

*Case:* Stuxnet, 2010.

**Principle.** Data crosses into the control network only through one controlled, checked point.

**Design measures.**

1. Provide a single transfer point, such as a scanning kiosk or one-way gateway, for all files entering OT.
2. Block unknown USB storage on OT hosts and issue checked, company-owned media for the rest.
3. Log every file transfer into OT with who, what and why.

*Mappings:* STRIDE T, E · ATT&CK for ICS [T0847](https://attack.mitre.org/techniques/T0847/), [T0864](https://attack.mitre.org/techniques/T0864/) · CIE 9, 5


## Public cases cited in this suit

- **Stuxnet, 2010.** Malware found in 2010 changed the speed of uranium enrichment centrifuges at Natanz, Iran, while operators saw normal readings, damaging equipment over months. *Attribution:* No official attribution; widely reported as a US and Israeli operation. *Sources:* [Schneier on Security: More Stuxnet news](https://www.schneier.com/blog/archives/2011/01/more_stuxnet_ne.html); [iTnews: Stuxnet the first to attack Iran nuclear plant](https://www.itnews.com.au/news/deadly-ninja-stuxnet-the-first-to-attack-iran-nuclear-plant-365124)
- **Ukraine grid attack, 2015.** On 23 December 2015 attackers used three Ukrainian distribution companies' own control systems to open breakers, cutting power to about 225,000 customers. They also overwrote firmware on serial-to-Ethernet converters, wiped systems with KillDisk, tampered with backup power and flooded call centres with calls. *Attribution:* Attributed by the US Department of Justice (2020 indictment) to Russia's GRU Unit 74455 (Sandworm). *Sources:* [CISA ICS alert IR-ALERT-H-16-056-01](https://cisa.gov/news-events/ics-alerts/ir-alert-h-16-056-01); [MITRE ATT&CK campaign C0028](https://attack.mitre.org/campaigns/C0028)
- **Volt Typhoon pre-positioning, 2024 advisory.** A February 2024 joint advisory found PRC state-sponsored actors inside the IT networks of US communications, energy, transport and water organisations, holding access, in some cases for at least five years, to disrupt operational technology in a crisis or conflict. *Attribution:* Attributed by CISA, NSA and FBI to PRC state-sponsored actors. *Sources:* [CISA advisory AA24-038A](https://cisa.gov/news-events/cybersecurity-advisories/aa24-038a)
- **NotPetya, 2017.** In June 2017 NotPetya, destructive malware disguised as ransomware, spread from a Ukrainian accounting software update. Maersk rebuilt its network and recovered its directory from a domain controller in Ghana that had been offline during a power cut; Mondelez's insurer cited a war exclusion, a dispute settled in 2022. *Attribution:* Attributed by the UK and US governments (2018) to the Russian military. *Sources:* [Redmond: the domain controller nightmare](https://redmondmag.com/blogs/scott-bekker/2018/08/domain-controller-nightmare.aspx); [The Record: Mondelez and Zurich reach settlement](https://therecord.media/mondelez-and-zurich-reach-settlement-in-notpetya-cyberattack-insurance-suit)
- **Norsk Hydro, 2019.** In March 2019 LockerGoga ransomware hit the aluminium maker Norsk Hydro; plants switched to manual operation while systems were rebuilt. *Attribution:* Criminal ransomware; no state attribution. *Sources:* [Fortune: Norsk Hydro cyber attack](https://fortune.com/2019/03/19/norsk-hydro-cyber-attack)

---

*© 2026 Jonathan Brett Crawley. Licensed under [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) with additional permissions: see the licence on the [overview](https://ostering.com/taxonomies/critical-infrastructure/#licence). † marks a physical-safety consequence.*
