Logging cybersecurity incidents in an industrial network: which fields to record

Task: link the incident to real OT context

Logging cybersecurity incidents in an industrial network differs from office IT because the goal is not only to remove the threat but also to keep the process safe and running. The same indicator (for example, a suspicious network request) in IT often means “isolate and reinstall”, while in OT it can mean “do not touch right now, otherwise we will stop the line”.

If an incident is not tied to a specific OT asset and zone, the investigation quickly stalls. The team sees events in a log but cannot tell what node it is: an engineering station, HMI, historian server, controller or a contractor's test laptop. Without zone information it's also hard: traffic inside a cell is different from traffic crossing the IT‑OT boundary.

There is another side: some data cannot be written in the open, especially if the log is available to a broad group. Usually teams avoid recording in the public part:

• exact IP addresses and hostnames if they reveal segmentation
• logins, personal data and employee names
• process details (recipes, parameters, equipment names)
• full configuration dumps and key controller project files

Therefore you need a single incident-card format that carries OT meaning without unnecessary specifics. It is needed by several roles at once: shift personnel (to understand risk to the process), InfoSec (to investigate), control engineers (to assess equipment impact), and managers (to see status and consequences). In projects involving integrators and infrastructure suppliers (for example, when deploying servers and workstations as with GSE.kz), a unified format also reduces confusion between teams: everyone discusses the same incident using the same fields.

A simple example: SOC notices suspicious SMB access. If the card immediately states “engineering station, zone: OT-DMZ, criticality: high, permitted action: block on firewall only”, the team will not blindly disconnect the node and risk stopping the area.

How not to break confidentiality when keeping the log

The incident log in OT should help act quickly and reproduce successful responses, not collect everything. A practical rule: record only what you cannot do without to make a decision, carry out response and confirm it was done.

Separating the card into access levels works well:

• Public part: what most participants need (short description, time, status, category, affected zone and asset expressed as identifiers).
• Restricted part: details that help investigation but may reveal network structure or personal data.
• Secret part: raw artifacts and “full precision” (traffic dumps, configs, exact hostnames) — stored in a protected repository with access by request.

To avoid writing more than necessary, use aliases instead of names and addresses: Asset ID, Site ID, Zone ID, Case ID. Store the real mappings (which Asset ID corresponds to which station, its physical location, its IP) separately with access control.

A few simple practices usually deliver the biggest effect:

• Role-based access: SOC sees the public part, OT engineer sees technical details, manager sees conclusions and risks.
• Change logging: who changed what and when, and why.
• Data masking: not full names but roles (“shift electrician”), not full IPs but subnets or hashes.
• Attachment control: files and screenshots only when needed, marked with access level.
• Comment templates: so people do not paste configs and passwords into free text.

Example: when compromise of an engineering station is suspected, record “Asset ID: ENG-042, Zone ID: OT-ENG, indicator: unknown process start, impact: no stoppage”. Full username, hostname and exact file path remain in the closed part and are provided only to those actively working on the node.

Set retention by data type and risk. Metadata in the card is usually kept longer for analytics, while raw artifacts (packet captures, dumps, logs with personal data) are kept for less time and deleted automatically so the log does not become a repository of sensitive information.

Basic incident-card fields: what to always record

The card should be consistent across incidents. The simpler and more stable the field set, the easier it is to find links between events, compare similar episodes and avoid arguments over wording.

1) Case identification. A unique Incident ID is needed and the registration source: who created the record and where the signal came from (shift engineer, monitoring, contractor). This helps assess input reliability and keeps continuity when handing off between teams.

2) Time. In OT this is critical because of shifts, maintenance windows and planned works. It's convenient to separate at least four timestamps: when noticed, when it likely began, when confirmed, when resolved. Always state the time zone.

3) Classification. A clear class is enough: malware, unauthorized access attempt, policy violation, failure or anomaly. This choice affects who to involve and which procedures to start.

4) Criticality. Better as a scale (low/medium/high) and a short criterion of impact: “impact on availability of a technological segment”, “risk to production continuity”, “accounts affected”. Do not list specific vulnerabilities, addresses or equipment models in the public part.

5) Short description. Neutral and verifiable: what was observed and where, without accusations or hypotheses presented as fact.

A helpful rule for description text:

• only observable indicators
• location in general terms (site, zone, system role)
• status (confirmed or pending verification)
• scope (single node, group, unknown)
• next step and responsible person

Example: “An unusual login attempt to the engineering network was recorded from a non-typical account. Confirmation pending. No impact on the process detected. InfoSec and the shift engineer assigned to verify.”

Fields to tie the incident to an OT asset

To avoid an OT incident becoming an abstract “something happened”, the card must clearly indicate which asset is involved. At the same time the log should not become a store of personal and sensitive technical details.

Minimum set of identifiers

Rely on internal codes and the asset's role in production. This ties the incident to real context and preserves confidentiality.

• Asset ID (internal): identifier from CMDB/registry that does not reveal serial numbers.
• Asset type: PLC, HMI, engineering station, server, gateway, switch (preferably from a catalog).
• Role in the process: control, visualization, historian, maintenance, cross‑zone exchange.
• Owner and responsible role: for example “ICS dept, shop 3”, “shift engineer” (no full names).
• Asset criticality: impact on safety, quality, downtime (e.g., scale 1–4 or S/Q/D).

These fields are usually enough to build reports on “hot” assets without exposing more than necessary.

Technical data without excessive detail

Technical attributes help investigation, but in the public part keep them as ranges or classes. For example: OS family and class version (“Windows 10 LTSC, version 20xx”), PLC firmware class (“v3.x”), model group (“S200 series”). Exact build numbers, serials, MACs and full configs belong in closed attachments with restricted access.

Example: a rule triggers on a suspicious utility start on an engineering station. In the card record Asset ID, type “engineering station”, role “PLC maintenance”, criticality “high for downtime”, owner “ICS service”. That's enough to link the incident to an area and assign the right team without publishing exact software versions or serial numbers.

Fields to tie to network zone and segmentation

Linking to network zone and segmentation boundaries shows where the problem occurred, where it might have spread and which control points to check.

Minimal set of zone fields

Start with unambiguous codes and catalogs, not local shift nicknames.

• Zone ID and zone name: e.g. “OT-Z03, filling area, cell 2”.
• Zone class per ISA‑95/IEC 62443: level (L2/L3) or zone type (Control Zone, DMZ, etc.).
• Affected segments (codes): VLAN IDs, subnets, contours — in forms like “VLAN-120, NET-10.20.30.0/24”.
• Zone intersection points (by ID): firewall FW-07, gateway GW-03, jump server JS-02.
• Direction and type of connection: within zone, between zones, to DMZ; “initiator -> receiver”, plus the application-level protocol (e.g., RDP, SMB) without full dumps.

How to record boundaries without revealing too much

Separate “what goes into the card” and “what sits in evidence”. Leave segment codes and control-point IDs in the card. Store full IPs, hostnames, FW rules and concrete log lines separately with role-based access.

Example: suspicious access to an engineering station. The card notes OT-Z03, affected VLAN-120 and DMZ-VLAN-10, intersection via JS-02 and FW-07, direction DMZ -> OT. That already shows which logs to request and where to look for the root cause.

Evidence and observations: how to record without extra detail

In OT it's important to record observations so they can be verified and linked to context, but not to spread sensitive data (accounts, exact addresses, process details) across the log.

What to write in the public part of the card

Describe the signal in plain terms and state the source: protection tool alert, log entry, engineer report, process deviation by tag/code (without revealing recipes or parameters). Then record only verifiable facts and mark assumptions separately.

In most cases five items suffice:

• source of the signal and time (in a single time zone)
• essence of the observation (what is “wrong”)
• confidence (confirmed / probable / needs verification)
• impact (downtime, quality, safety) and criticality level
• likely vector (USB, remote access, contractor, other)

What to move to closed fields

Store artifacts “accurately” but not publicly: file hashes, full names and paths, IPs and MACs, specific accounts, serial numbers, exact project names on engineering stations. In the public part leave an anonymized identifier (“acct-3”, “host-7”) and an internal artifact number.

Example: an engineer reports a new executable on an engineering station followed by slow responses. The card records the appearance, time and impact (risk of stoppage). The closed fields include the hash, full path, account used to run it and the list of destination addresses attempted.

Response measures and action-tracking fields

In OT it is important to record not only the incident but every response action. The record should show what was changed, who authorized it, what risks were accepted and how the system was returned to normal. Personal data is usually unnecessary — roles and internal IDs are enough.

Status and progress

Keep statuses simple and consistent: new, in progress, contained, remediated, closed, deferred. It is useful to add timestamps and a short reason (1–2 words) to explain delays.

Actions block

Each action is a separate line with a result. Typical OT measures repeat: isolate a node, block an account, change firewall rules, disable remote access, roll back a configuration.

Minimum fields for each measure:

• measure type (isolation, blocking, rule change, recovery)
• object (asset ID, account ID, rule ID)
• start and end time
• executor (role/team) and approval (role) + time
• result (success, partial, rolled back) and a short comment

In OT always include a "risk from the measure" field: what might stop immediately. Record expected impact on the process ("possible telemetry loss", "line N stoppage", "switch to manual mode") and the pre-agreed workaround ("local control", "backup channel", "work per procedure").

To keep measures manageable, link them to change and recovery processes: change request ID, recovery request ID, emergency window ID. This helps prove authorization and quickly find rollback plans.

Example: triage shows suspicious activity on an engineering station. Status — “in progress”. They decide to first “contain” without stopping production: restrict the station's connections to required services, log approval by role “shift ICS engineer”, describe the risk (possible delay in project updates) and the workaround (move work to backup station). After checking and cleaning, change status to “remediated”, link recovery ID (image reinstall) and close after a monitoring period.

Simple investigation process: steps from triage to closure

In OT it's important to investigate quickly but carefully. A wrong response can stop the process, so the procedure should be short and consistent across shifts.

Steps most OT incidents go through

1. Triage and owner. Confirm this is an incident and not planned work. Assign an owner (SOC, InfoSec on duty or ICS engineer) and set a time for the next status update.

2. Containment with minimal interference. Choose the mildest action that reduces the risk: block remote access, temporarily disable an account, move a node into a restricted VLAN. Abrupt disconnection only when agreed and if it does not create greater risk.

3. Fact collection. Record: OT asset ID, role (engineering station, PLC, HMI), zone and network segment, affected protocols, available logs (EDR, domain, switches, change log). If personal data is involved, use service identifiers and store details separately.

4. Root-cause analysis. Reconstruct the chain: where the impact came from, which accounts were used, what settings changed, whether persistence attempts occurred. Common OT findings include contractor remote access, shared passwords, and USB file transfers.

5. Remediation, recovery and closure. Remove the cause (password, access rule, vulnerable service), verify area functionality and set controls to prevent repeat (alert, config check). At closure record the outcome, lessons learned, tasks, deadlines and responsible parties.

Example: an alert fires on an engineering station in the control zone. Containment: temporarily block inbound RDP from outside the zone and change the account password without powering down the station. Facts: time, host-ID, zone, connection list, recent project changes. Lesson: ban shared accounts and introduce a contractor remote-access regimen with session logging.

Example scenario: incident around an engineering station in OT

On an ICS shop the dispatcher notices a spike of requests to a PLC originating from an engineering station (ES-17). The requests are within the usual configuration zone but at an unusual time: late evening, outside the maintenance window. Simultaneously the switch logs short attempts to contact a neighboring zone via an allowed service.

An incident card is created immediately so the record does not dissolve into verbal agreements. The team fills only what links the event to OT context without extra specifics.

A minimal set of fields may look like:

• Incident ID: OT-2026-014
• Detection/period: 21:42–22:05
• Asset ID (engineering station): ES-17
• Related OT asset: PLC-3A (registry ID)
• Zone ID: OT-Z3 (cell/line), plus note about adjacent OT-Z2
• Criticality: high (risk to the technological process)

They first check the most common benign explanation: planned work. They request the maintenance change log and service tickets from operations, and from IT/Sec the recent logins to the engineering station. They also verify whether a contractor had access and how (local/remote), without personal data in the card.

While checking, they perform soft containment. They temporarily tighten inter-zone traffic rules: leave only required services for the technological exchange, allow configuration protocols only in approved windows and only from ES-17. The card records the action, time, responsible role and justification.

Investigation result: a contractor performed diagnostics but used an outdated access profile, causing the engineering station to poll the PLC with an incorrect template. They restore original settings, update the profile and verify configuration integrity.

Lessons are best recorded as short, actionable items:

• bind contractor access to a specific Zone ID and time window
• keep containment rule playbooks ready
• run a short validation after work: who talks to whom, any excess requests

Common mistakes in OT incident logging

Often the card becomes either a “novel” with too many details or a couple of lines that allow no reconstruction. The balance needed is enough OT context for investigation and audit without exposing sensitive data.

Mixing personal and technical data in one field. Descriptions combine station events, full employee names and shift contacts. As a result the card cannot be safely shown to a contractor, SOC or other shop colleagues. Separate the public technical part and the closed personal data part.

No stable IDs for assets and zones. When everything is written in free text (“PLC on line 3”, “shop network”), duplicates and inconsistencies appear. Minimum: a single OT-asset identifier (from the registry), zone/segment identifier and an immutable naming rule.

Too many details in the public part. IPs, firmware versions, hostnames, accounts and project paths increase leakage risk. Keep them in closed attachments or replace them with aliases.

Failing to record decisions and approvals. They write “port disabled” but not why that measure was chosen, what risks were accepted and who approved it. Later it is hard to justify a stoppage or repeat a successful tactic.

Closing incidents without lessons and tasks. If no short conclusion (root cause) and tasks (what to change in segmentation, access, backups, monitoring) are recorded, the incident will recur. A good habit: close only when there are 1–3 measurable actions and assignees.

Small example

A log entry reads: “Virus on engineering station, resolved.” A month later it repeats because they did not record station ID, zone, or the fix (why shared access remained), nor tasks (segregate project access and update whitelists). A proper card shows which asset, where, what approved measure was taken and what needs to change to prevent recurrence.

Quick checklist and next implementation steps

If a unified log does not exist yet, start small: one card template and one storage location. The card should link the event to OT context (asset, zone, impact) and avoid exposing extra details.

A minimal checklist of fields that usually delivers 80% of value:

• Incident ID and time: unique number, detection time, start time (if known), reporter.
• OT binding: Asset ID, asset type (PLC/HMI/engineering station/server), asset owner (department).
• Network and zone: Zone ID, segment (e.g., Level 2/3), communication path (inter-zone channel, gateway), zone criticality.
• Impact and risk: affected process, impact level (person safety, quality, downtime), scope.
• Status and measures: stage (triage, investigation, containment, recovery, closed), measures taken, responsible roles, deadlines.

For confidentiality keep at least two levels: public fields for most participants and closed fields for a narrow group. The closed part typically holds usernames, specific IPs/serials, full logs and vulnerability details.

For quality control three reports are usually enough: by zones (where incidents cluster), by assets (which devices repeat) and by causes and measures (what actually reduces recurrence).

Next steps to embed the process:

• choose one card template and pilot it on 1–2 zones
• assign roles: who creates incidents, who approves closure, who owns assets
• introduce a weekly 30-minute review: a few incidents, 1–2 lessons, one action to the plan
• configure access rights and storage: the log, attachments, retention periods, change audit

If the log and related artifacts need to be placed on resilient infrastructure with vendor support, this is often done with a system integrator. In Kazakhstan such tasks, including server infrastructure and support, are carried out by GSE.kz as a vendor and integrator with the S200 Series servers and 24/7 technical support.