OT security is not IT security: why skills are the real bottleneck

This is part 11 of 12 of the “Common language” series on industrial cybersecurity; it continues with part 12, awareness and measurement.

Ask a site manager what is holding back their OT security programme and the first answers are usually budget and technology. Both matter. In my experience, though, neither is the most stubborn obstacle. Firewalls can be bought and capital can be found. What you cannot order at short notice is a person with real OT cybersecurity skills who is free to work on your site.

The word that matters is OT. Operational technology security is not IT security applied to a factory. The objectives shift, the constraints are different, and an excellent IT profile dropped onto a control network without support can do more damage than good.

When good IT practice breaks a plant

This is not a theoretical warning. NIST SP 800-82 Rev. 3, drawing on a Sandia National Laboratories report on penetration testing of industrial control systems (SAND2005-2846P), describes a natural gas utility that hired an IT security consulting firm to test its corporate network. The testers strayed into a part of the network directly connected to the SCADA system. The test locked up SCADA, and the utility could not send gas through its pipelines for four hours. The same appendix describes a ping sweep, run to identify hosts for an inventory, that caused a system controlling integrated-circuit fabrication to hang; according to NIST, the test destroyed $50,000 worth of wafers.

Nobody in those stories meant any harm. They used techniques that are routine in IT in an environment where those techniques are not safe. What was missing was not general competence. It was knowledge of how industrial systems behave when you poke them.

What really separates OT security from IT security

NIST SP 800-82 Rev. 3, the US reference guide to OT security, puts it plainly: OT operating systems and control networks “require different skill sets, experience, and levels of expertise”, and control networks are typically managed by control engineers rather than IT personnel. The table below summarises the differences that matter most on site.

The first row needs a little care. The old shorthand is that IT follows “CIA” (confidentiality, integrity, availability) and OT turns it upside down. NIST’s wording is more precise: OT security objectives typically prioritise integrity and availability, followed by confidentiality, with safety as an overarching priority. Which of integrity or availability comes first depends on the process. A controller that keeps running on falsified values is not “available” in any sense an operator would recognise.

On a pharmaceutical site the integrity row weighs more. A value the process runs on is often also a GMP record. A security practitioner who has never had to explain an audit trail, or why a controller’s clock matters to a batch record, will miss consequences a quality engineer spots straight away. So the scarce profile is someone who understands security, automation and data integrity together, and those people are rare.

Train the site experts first

If skills are the bottleneck, whose skills? The site’s own experts, engineers and technicians, before anyone else. They carry the programme. They design the architectures, approve vendor interventions, write the procedures and notice the odd behaviour on a Tuesday night that nobody else would.

Their training has to fit their trade. The instrument technician learns the security of smart transmitters and their configuration tools. The automation engineer works on controller access, backups and engineering workstations. The network specialist works on zones and conduits. A generic course on phishing and passwords does none of this. One hour spent building these people’s skills is worth more than ten hours of general communication.

The bridge has to work the other way too. IT colleagues who support the site need enough process knowledge to know what they must not touch, and why. The article on putting people at the centre makes the same case for cross-training in both directions; it is about the cheapest intervention a site can make.

Where the skills are not available internally, there are two routes, and they combine well. You can recruit OT cybersecurity capability, or bring in a specialist company whose explicit job is to raise the site team’s level.

Three staffing scenarios, depending on the site’s means

Not every site can afford the same answer. There are three realistic options, from the ideal down to the complement.

Target: a dedicated, full-time lead. Recruit, or grow from within, an OT cybersecurity lead attached to the site. Wherever the site is critical or large, this works best. The ideal profile often comes from automation rather than IT: teaching security principles to someone who already understands controllers, safety systems and shutdown planning is usually quicker than the reverse.

Realistic: a named best-effort referent. Failing that, name one or more people on site, with an officially allocated share of their time, a mission letter and a training budget. A referent with no dedicated time is just a name on an organisation chart.

Complement: external support. Engage a company specialised in industrial cybersecurity to frame the programme, audit and transfer skills. The condition is that the transfer actually happens, in the contract and in practice: shadowing, joint work on the site’s own systems, documentation the team can maintain. A provider who leaves with the knowledge leaves the site where it started.

Three lines for the mission letter. Whichever scenario is chosen, write down the percentage of time actually allocated, the scope covered (and therefore what is not covered), and the annual training budget. Without those three lines, the role erodes at the first unplanned shutdown.

Why this is a management decision

It is tempting to treat skills as an HR matter to settle later, once the technical roadmap is agreed. That gets the order wrong. Every measure in an OT security programme, from segregation to remote access control to incident response, depends on someone who can judge whether it is safe to apply on a running process. Without that person, measures are either not deployed or deployed badly.

The standards say the same. IEC 62443-2-1, the part of the series that sets requirements for an asset owner’s security programme, lists security awareness training and security responsibilities training among its organisational requirements. A programme that names roles but does not train the people who hold them falls short of its own standard.

None of the three scenarios needs a large capital budget. What they need is a decision from site management, a named person, protected time and a training line in the operating budget. Ordinary management tools, in other words, and they are what turns a security plan into something the site can actually carry out.

Where to start

1. List the people who already touch OT security: automation, instrumentation, network, IT support, vendors. Note what each one actually does, not what the organisation chart says.
2. Pick the scenario that fits the site’s means (target, realistic or complement) and write down why.
3. Write the mission letter: time allocated, scope covered and not covered, annual training budget.
4. Plan field-specific training for the experts, one module per trade, on the site’s own equipment, before any generic campaign.
5. Add a rule of engagement for IT and external testers. No scan, test or tool on the control network without the process owner’s written agreement and a stated rollback.

Five common mistakes

• Hiring an IT profile and leaving them alone on the plant. Good intentions plus routine IT techniques is exactly how the incidents above happened.
• Naming a referent without time. A name on a chart does not turn up to a MOC review.
• Sending experts to a generic awareness course. Phishing tips do not teach anyone to secure a smart transmitter.
• Buying external support without skills transfer. The report stays on the shelf and the knowledge drives away with the consultant.
• Treating skills as an HR topic for later. Every technical measure is waiting for someone able to judge it.

Technology can be bought and capital can be found. The person who knows both the process and its security has to be chosen, trained and given the time.

References

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023. nvlpubs.nist.gov
• IEC 62443-2-1:2024, Security program requirements for IACS asset owners. webstore.iec.ch