Pipeline security directives and the operator action nobody can attribute
Directive compliance is demonstrated with documents. An inspector reads the cybersecurity implementation plan, reviews the architecture, samples the monitoring. Every one of those artefacts describes a capability. None of them answers a question about a specific change made by a specific person.
Can a pipeline operator attribute a control action to a person?
Usually not at the device. Security directives require access controls and logging, and operators implement them at the enterprise and remote-access layers. The control action itself arrives at equipment that records a command rather than a commander, which is the same gap that runs through all OT.
- Directives specify capabilities and outcomes. Attribution is assumed to follow from access control, and access control in legacy midstream systems is session-based with surviving shared accounts.
- Session recording is observation. It shows what happened inside a session and not who was permitted to open it.
- Remote facilities with intermittent connectivity need an evidence mechanism that works offline, which rules out most of the obvious answers.
Part of Grid, water and OT identity
A compressor station at 2am
The call came in at 02:14. A compressor station three hours from the nearest office was alarming on a parameter that did not make sense, and the on-call controller needed a vendor engineer to look at a configuration that had been touched during a maintenance window eleven days earlier.
The question that took the longest to answer was not technical. It was: who made that change? The maintenance window had involved two contractor engineers and one employee. The system logged a single account. The work order named a company, not a person. Everybody remembered it differently, and everybody was honest.
That is what an attribution gap costs on an ordinary Tuesday, before anyone has alleged anything.
What the directives ask for
TSA security directives applicable to pipeline owner-operators require, in substance, network segmentation between IT and OT, access control measures, continuous monitoring and detection, and timely patching — implemented through a cybersecurity implementation plan and assessed through an assessment programme.
Those are the right requirements. The evidentiary consequence is that compliance is demonstrated through documented capability rather than through per-action records, and an assessment can be passed by an organisation that cannot attribute a single configuration change to a named human.
| Directive theme | Artefact produced | Attribution value |
|---|---|---|
| Segmentation | Architecture diagram, firewall configuration | None |
| Access control | Account inventory, role definitions, MFA coverage report | Names accounts, not people, where accounts are shared |
| Monitoring and detection | Alert logs, SOC runbooks | Detects anomalies; does not attribute authorised changes |
| Patching and configuration | Change records, baseline reports | Records the change; attributes it to an account |
Why shared accounts persist in midstream
It is worth being specific rather than disapproving. Shared accounts survive in this sector for three structural reasons.
- Legacy HMIs. Operator interfaces installed in the 2000s support a small number of local accounts and no directory integration. Replacing them is a capital project with an outage.
- Contractor turnover. Provisioning individual accounts for a two-day contractor visit to a remote facility costs more administrative effort than the visit.
- Connectivity. A station on a satellite link cannot reliably authenticate against a central directory, so local accounts are the fallback by design.
Each reason is real. Each also means that a control depending on individual directory accounts will not reach the environments where the consequence is highest.
An evidence mechanism that fits the constraints
The constraint set is unusual and determines the design: intermittent connectivity, legacy endpoints, transient personnel, and a requirement that works without a directory.
A signed authorisation meets all four. The engineer carries a credential on their own device. The authorising supervisor signs a scoped delegation before the visit. At the facility, the engineer signs a statement of the change against that delegation. Verification is local, against a published key, with no network call — which is the property that makes it work on a satellite link.
Nothing is provisioned in a directory. Nothing needs to be deprovisioned afterwards, because the delegation expires.
What this gives an assessor
A different kind of answer to a familiar question. Instead of we require change authorisation and here is the policy, the answer becomes here are the signed authorisations for every critical cyber system change in the assessment period, and you can verify them yourself.
That is not required. It is, in the experience of organisations that have moved to evidence-based answers in other regulated sectors, a materially shorter assessment.
Being honest about the public record
Directive text is partly non-public, and this article works only from published versions and from the publicly described requirement themes. Any organisation implementing against the directives should work from their own copy and their own counsel, not from a summary.
What is publicly clear is the shape of the obligation and the shape of the gap: capability requirements, documented compliance, and no prescribed attribution artefact.
What an operator can produce today
| Layer | Evidence quality |
|---|---|
| Identity provider | Strong — named person, MFA |
| Remote access broker | Good — session, recorded |
| Engineering workstation | Moderate — session |
| Control system action | Weak — a command, a timestamp |
An investigation reconstructs the last row from the ones above it by correlating timestamps. That inference is usually right and it is an inference, which is a weak position when the question is why a valve moved.
Objections and honest limits
“We meet the directive requirements.” Almost certainly, and the directive asks for access control and logging rather than per-action attribution. Meeting it and being able to attribute are different achievements.
“Correlation is good enough for an investigation.” It is frequently sufficient and it is an inference. Where the consequence is physical, the difference between an inference and a record is the difference between an explanation and evidence.
Extending attribution to the action
- List the consequential control actions. Valve, pump, pressure setpoint, protection changes.
- Gate those at a protocol gateway. Where attribution still exists.
- Require a signature bound to the command. One authorisation, one command.
- Retain the receipt with the process historian. So operations and evidence stay together.
Terms used here
- Security directive
- A binding requirement issued to pipeline owners and operators covering cybersecurity measures.
- Process historian
- The system recording process data over time, and the natural home for an action receipt.
- Correlation
- Reconstructing who acted by matching timestamps across layers — an inference rather than a record.
Frequently asked questions
Do TSA directives require attribution to named individuals? The published requirement themes concern segmentation, access control, monitoring and patching. They do not prescribe an attribution artefact, which is the gap described here.
Does this work at facilities with no reliable connectivity? Yes — that is the design constraint. Verification is offline against a published key, with no call to any service.
Can it work with legacy HMIs that support only local accounts? The signed authorisation sits alongside rather than inside the HMI. The HMI still uses its local account; the record of who was authorised to use it exists independently.
Is this a substitute for deploying PAM? For large operators with modern systems, privileged access management does more. For remote legacy facilities where PAM will not reach for years, this addresses the attribution question now.
Do directives require per-action attribution? They require access control and logging. Meeting them and being able to attribute a specific control action are different things.
Why is correlation insufficient? It is an inference across layers. Where the consequence is physical, an inference is an explanation rather than evidence.
Where should the gate sit? At the protocol gateway, which is the last point where attribution still exists.
Where this fits in Manav
Manav binds the operator to the exact command, session or two-person act, verifiable offline at the console or the gateway — which is the condition OT and field work actually run in.
Sources and further reading
- TSA security directives applicable to pipeline owner-operators (published versions).
- CISA cybersecurity advisories
- CISA — known exploited vulnerabilities and incident reporting
- TSA — pipeline security directives
- NERC — CIP reliability standards