The short answer
Security Program Basics
A security program is not a product; it is a set of decisions and habits with a named owner. It starts with knowing what the utility has, an asset inventory, and what could go wrong, a risk assessment, and turns those into a few written policies for remote access, change management, backups, accounts, and incident response. It puts in place a baseline of controls that defeat the common attacks: segmentation with a firewall between the office and the plant, multi-factor authentication on remote access, no default or shared credentials, tested offline backups, logging, and patching. It trains staff, sets rules for vendors, writes and exercises an incident plan, and reviews itself every year against a framework such as the NIST Cybersecurity Framework, the sector performance goals published by the federal cybersecurity agency, or the IEC 62443 series, and against the water sector requirements such as the America's Water Infrastructure Act assessments.
Key points
- A program is ownership, decisions, and habits; buy products for the gaps it identifies, not instead of it.
- Inventory and risk assessment first; you cannot protect what you have not listed or prioritize what you have not weighed.
- Five policies cover most of it: remote access, change management, backups, accounts, incident response.
- The baseline controls stop most attacks: segmentation, multi-factor remote access, no default or shared credentials, offline backups, logging, patching.
- Exercise the incident plan on a tabletop; a plan that has never been walked through is a document.
- An annual cycle: measure against a framework, fix the worst gaps, report to management, repeat.
What a program is
Utilities that have had an incident describe the same gaps afterward: nobody owned security, nobody knew what was connected, the backups were on the same network as the ransomware, the vendor had a permanent remote connection, and the plan for running the plant by hand existed only in the memory of an operator who had retired. A security program is the arrangement that closes those gaps and keeps them closed. It is small at a small utility, larger at a large one, and it is always the same shape: someone in charge, a picture of the system, a judgment about what matters most, a few rules everyone follows, controls that make the common attacks fail, people who know what to do, and a review that keeps it honest.
The elements
| Element | What it is | Minimum at a small utility |
|---|---|---|
| Owner | A named person responsible for control system security, with the authority to decide and the ear of management | The operations manager or the control engineer, formally named |
| Asset inventory | Every controller, computer, network device, radio, and connection, with what it is and where | A spreadsheet built by walking the sites, kept current |
| Risk assessment | What could go wrong, how bad, how likely, ranked | A consequence-first list of a dozen scenarios, ranked, with owners |
| Policies | Written rules for remote access, change management, backups, accounts, and incident response | One page each, approved by management |
| Baseline controls | The technical measures that defeat the common attacks | The list in the next section, in priority order |
| Training | Staff know the rules and the reasons; operators know the signs of an incident | An hour a year, plus a briefing at every change |
| Vendor management | Rules for integrators and vendors: accounts, remote access, software, project files | A clause in every contract and a checklist at every engagement |
| Incident response | A plan for the day the system is not trusted, and a manual operation procedure | A written plan, an exercise a year |
| Review | An annual measurement against a framework, a report to management, and a plan for the year | A half-day with the framework checklist |
The baseline controls
- Segmentation: a firewall between the office and the control network, with rules that allow only what is needed, and a DMZ for anything shared.
- Remote access: through a jump host with multi-factor authentication, individual accounts, sessions logged, vendor access enabled per session.
- Credentials: no defaults, no shared accounts where the platform supports individuals, unique device passwords in a vault.
- Backups: controller programs, SCADA, historian, and configurations backed up on a schedule, with a copy offline, and a restore tested.
- Logging: security and application logs from servers, firewalls, and network devices to a collector, reviewed on a schedule.
- Patching: a cycle for servers and clients, a firmware process for devices, compensating controls for what cannot be patched.
- Hardening: servers and consoles configured to a baseline, unused services removed, allowlisting where practical.
- Physical security: locked panels, locked rooms, intrusion alarms at remote sites.
- Manual operation: the plant can be run without the SCADA, and the operators have practiced it.
Frameworks and requirements
| Reference | What it offers | How a utility uses it |
|---|---|---|
| NIST Cybersecurity Framework | A structure of functions from governance through recovery, with outcomes to assess against | The annual self-assessment and the language for reporting to management |
| Federal cross-sector cybersecurity performance goals | A prioritized list of practical controls with cost and impact ratings | The starting checklist for the baseline; the water sector version maps them to utilities |
| IEC 62443 | The industrial automation security standard series: zones and conduits, security levels, requirements for owners, integrators, and products | The design reference for segmentation and for what to require of vendors |
| America's Water Infrastructure Act | Requires community water systems above a size threshold to conduct a risk and resilience assessment and update an emergency response plan on a five-year cycle, including cybersecurity | The regulatory driver; the program provides the cybersecurity content |
| Federal environmental agency and sector guidance | Checklists, assessment tools, and technical assistance for water utilities | Free help, a self-assessment tool, and the expectations a state regulator may inspect against |
| State requirements | A growing number of states require cybersecurity assessments or specific controls for water systems | Check the state; some require attestation |
A first year
- 1
Quarter one
Name the owner. Build the inventory by visiting every site. Draw the network as it actually is. Find every remote connection, including the ones nobody remembers.
- 2
Quarter two
Run the consequence-first risk assessment. Change every default password. Remove or replace uncontrolled remote access with a jump host and multi-factor authentication. Start the backups and take a copy offline.
- 3
Quarter three
Put the firewall between the office and the plant, or fix its rules. Write the five policies. Set up logging to a collector. Start the patch cycle.
- 4
Quarter four
Write the incident response plan and the manual operation procedure. Run a tabletop exercise. Assess against the framework checklist, report to management, and plan next year.
Frequently asked questions
- We have an IT security program. Does that cover the control system?
- Rarely. Office security assumes patches can be applied at will, machines can be rebooted, and confidentiality matters most; control systems invert all three. The IT program is a resource and a partner; the control system program is owned by operations, uses the frameworks written for industrial systems, and sets its own priorities. The two coordinate at the firewall between them.
- What is the first thing to fix?
- Whatever gives an attacker on the internet a direct path to the plant: a modem with a public address, a remote desktop port forwarded through the office firewall, a vendor remote tool, a default password on anything reachable. The inventory finds them; removing them is the highest-value day of the year.
- How do we show progress to the board?
- With the framework assessment: a score or a maturity level per function this year against last year, the top risks and what was done about them, the incidents and exercises, and the plan and budget for next year. One page, once a year, in language a board member understands.
- Do we need a consultant?
- For the first assessment and for specialized work such as firewall design, often yes, and the state and the sector organizations offer free assistance to small systems. For running the program, no: the owner, the inventory, the policies, and the annual cycle are the utility's own work, and a program that only a consultant understands is not the utility's program.
Related topics
- Small Utility Cybersecurity PrioritiesWhat a utility with a few operators and no IT department should do first: the ten measures that remove most of the risk for the least money and time, in the order to do them, with what each one costs, what it prevents, and how to know it is done.
- OT Risk AssessmentRanking what could go wrong in a control system and what it would cost: the consequence-first method for utilities, the assets and scenarios to list, likelihood without pretending to know it, the risk matrix, and turning the ranked list into a work plan.
- IEC 62443The international standard series for industrial automation and control system security: how it is organized, what security levels and foundational requirements mean, and how a utility or integrator actually uses it.
- Water and Wastewater Utility Threat LandscapeWhat has actually happened at water utilities, what those incidents had in common, and the small number of controls that would have prevented most of them.
- OT Incident Response PlanThe plan for the day the control system is not trusted: who decides, the triggers, the first hour, isolating without stopping treatment, running by hand, preserving evidence, who to notify and when, recovery from backups, and the exercise that makes it real.
- OT Security vs IT SecurityWhy the familiar security priorities invert on a plant floor, and what that changes about patching, scanning, authentication, and incident response.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.