GIAC GICSP ICS Incident Response Checklist: Containment Without Breaking Operations

Incident response in industrial control systems is not the same as incident response in regular IT. In a business network, the usual move is often simple: isolate the device, block the traffic, rebuild the host. In an ICS environment, that same action can stop a process, damage equipment, create a safety event, or interrupt a critical service. That is why a good ICS incident response checklist must focus on containment without breaking operations. The goal is to reduce harm from the cyber event while keeping the physical process stable, safe, and under control. This article walks through a practical checklist aligned with the kind of thinking tested in GIAC GICSP, with a focus on approvals, evidence handling, safe containment, recovery checks, and clear communication.

Why ICS incident response needs a different checklist

ICS environments behave differently because cyber actions have physical effects. A firewall rule, a controller reboot, or a network disconnect might not just affect data. It might stop a pump, freeze an HMI, interrupt safety logic visibility, or prevent operators from seeing alarms.

That changes the order of work. In IT, teams usually prioritize confidentiality and fast isolation. In ICS, the first concern is usually safety, then process continuity, then asset preservation, and then deeper eradication. You still care about evidence and attacker removal, but you cannot treat control systems like office laptops.

A useful checklist helps teams avoid common mistakes such as:

• Disconnecting a device before understanding what process it supports.

• Rebooting a PLC, HMI, or historian before preserving volatile evidence.

• Applying patches or AV scans during active production.

• Blocking traffic that also carries legitimate control messages.

• Making changes without approval from operations or engineering.

If you are preparing for GICSP-style scenarios, it helps to think in terms of operational impact first. A strong GIAC GICSP practice test resource can help reinforce this mindset, but the real skill is learning how to contain threats in a way that does not create a second incident.

Step 1: Confirm the incident and classify the affected process

Before containment, confirm what is actually happening. In ICS, false positives are common. A communications fault, misconfigured polling, failed switch port, or engineering workstation error can look like a cyber event. If you rush to isolate systems without validation, you may create downtime for no reason.

Start with a short fact-gathering step:

• What triggered the alert: malware detection, abnormal traffic, unauthorized logic change, lost visibility, strange operator behavior?

• Which asset is involved: PLC, RTU, HMI, historian, jump host, engineering workstation, domain controller, remote access gateway?

• What process does it affect: safety system, batch line, water treatment stage, power distribution segment, compressor control?

• Is the issue active, suspected, or historical?

• Is there any immediate safety or environmental risk?

This classification matters because not all systems can be treated the same way. An infected reporting server can often be isolated more aggressively than a controller connected to a live process. A checklist should force the team to identify the process consequence before any technical action is approved.

Step 2: Establish coordination and approvals before containment

In ICS, no one team should make containment decisions alone. Security may detect the event, but operations and engineering understand what a shutdown, disconnect, or device restart will do to the process. The incident commander needs the right voices in the room before any action is taken.

At minimum, involve:

• Operations supervisor or control room lead

• Control systems engineer or automation engineer

• OT security or cyber lead

• IT security if the event crosses business and control networks

• Safety representative when physical risk is possible

• Plant or site management if production impact is likely

Approvals should answer four practical questions:

• What action is being proposed?

• What is the expected security benefit?

• What process or safety risk could it create?

• Who is authorizing it and at what time?

This sounds formal, but it prevents risky improvisation. For example, blocking all traffic from an engineering workstation may seem reasonable. But if that workstation is currently the only path to monitor a controller during an unstable process, the action could increase operational risk. A checklist should require sign-off from the person responsible for the process, not just the network.

Step 3: Follow evidence collection rules that do not disturb the process

Evidence is important, but in ICS the method matters. Many industrial devices are fragile. Some do not handle active scanning well. Some lose valuable data when rebooted. Others keep only small event logs that roll over quickly. If evidence collection is careless, you can lose both forensic value and operational stability.

Use these rules:

• Do not reboot first. Rebooting may erase volatile data and interrupt the process.

• Do not run unapproved tools. Memory tools, EDR agents, vulnerability scanners, and script-based triage can break unsupported systems.

• Collect from central sources first. Historians, network taps, firewalls, remote access logs, Windows event logs, and engineering change logs are often safer to access than field devices.

• Capture time references. Record the system time on devices and compare it to actual time. ICS investigations often fail because logs from different assets are out of sync.

• Document every action. Who touched what, when, and why. This is important for both recovery and later review.

Examples of useful evidence include:

• Firewall and switch logs showing new connections

• Remote access session records

• Controller logic change history

• Windows security logs on HMIs and engineering stations

• Anti-malware alerts from jump hosts or support servers

• Screenshots of unusual alarms, unauthorized commands, or process anomalies

If a device must be isolated quickly for safety reasons, preserve what you can before the action, but do not delay a necessary safety response just to gather perfect evidence. The checklist should make that priority explicit.

Step 4: Choose safe containment options based on process impact

Containment in ICS should move from least disruptive to most disruptive, unless there is an immediate danger. The key question is not “How fast can we cut this off?” but “What action reduces attacker freedom while preserving safe control?”

Here are common containment options, from safer to riskier in many environments.

1. Increase monitoring before making changes

If the threat is suspected but not confirmed, increase visibility first. Mirror traffic, watch command activity, review remote sessions, and place staff on direct observation. This buys time when the process is too sensitive for immediate technical action.

2. Disable remote access paths

This is often a strong first move. If the threat may be coming through VPN, vendor access, remote desktop, or a jump host, shutting those paths can reduce attacker reach without touching controllers directly.

3. Block non-essential north-south traffic

Limit traffic between IT and OT zones while preserving approved industrial flows. This works well when the infection or intrusion appears to be spreading from the business network.

4. Isolate specific support systems

Historian servers, patch servers, engineering workstations, or reporting systems can sometimes be isolated with manageable impact. Validate dependencies first. Some HMIs rely on shared services that are not obvious.

5. Put the process into a stable operating mode

Operations may decide to hold current setpoints, move to manual control, suspend recipe changes, or stop non-essential transitions. This is not a cyber control, but it is often the safest containment support measure because stable processes are easier to defend.

6. Disconnect or power down an endpoint only with engineering approval

This is the high-risk option. It may be necessary if a device is actively issuing harmful commands, but it should be done only after confirming the physical effect. For example, disconnecting an HMI may be acceptable if local controller logic continues safely. Disconnecting a controller that manages an unstable process may not be.

A good checklist should ask these questions before each containment action:

• Does this device have direct control of the process?

• Will the process continue safely if communications are lost?

• Is there a fallback mode such as local control or manual operation?

• Could the action affect alarms, interlocks, or operator visibility?

• Has engineering confirmed the dependency map?

This is the heart of containment without breaking operations. You are trying to reduce cyber risk while keeping the plant in a known safe state.

Step 5: Protect safety functions and critical dependencies

Not all assets have equal importance. During an incident, teams often focus on the visibly affected machine and forget upstream and downstream dependencies. In ICS, that is dangerous.

Your checklist should explicitly identify and protect:

• Safety instrumented systems

• Protective relays and emergency shutdown paths

• Core network switches in the control zone

• Time synchronization sources if sequence-of-events data is needed

• Operator visibility systems, including alarm handling

• Backup engineering files and known-good controller logic

For example, if malware is discovered on a Windows HMI, the HMI matters. But just as important is whether operators still have alarm visibility somewhere else, whether controller logic has been changed, and whether safety systems remain independent and functional. Containment decisions should preserve those functions first.

Step 6: Eradication should wait until the process is stable

Many teams rush from detection to cleanup. In ICS, that can be a mistake. Deleting files, killing processes, or applying patches too early can remove evidence, destabilize systems, or interrupt production at the worst possible moment.

Only move into eradication when:

• The process is stable and safe

• Containment boundaries are in place

• Required evidence has been collected

• Engineering has approved the maintenance action

• A rollback or recovery plan exists if the change fails

Common eradication steps include removing malicious files from support systems, resetting credentials, rebuilding Windows hosts, restoring known-good controller logic, and closing exploited access paths. But controllers and embedded devices should be treated cautiously. If a PLC is suspected of unauthorized logic changes, verify against a known-good baseline rather than assuming a simple reboot fixes the issue.

Step 7: Use strict recovery verification steps before returning to normal

Recovery is not complete when the malware alert disappears. In ICS, you need proof that both the cyber side and the physical process are back to an expected state. This is where many incidents leave hidden risk behind.

Your recovery verification checklist should include:

• Asset integrity check. Confirm software versions, controller logic, configurations, user accounts, and network rules match approved baselines.

• Functional testing. Verify commands, alarms, trends, interlocks, and operator displays work as expected.

• Communications testing. Confirm all required OT communications are restored and no temporary rules are blocking needed traffic.

• Safety validation. Ensure safety functions were not altered and are still independent where required.

• Monitoring confirmation. Make sure logging, alerting, and visibility are back online before declaring recovery complete.

It helps to use a staged return. For example, restore one engineering workstation, validate it, monitor for abnormal traffic, then restore additional systems. The reason is simple: if the attacker still has access or the infection source remains, a full return to service can recreate the incident within minutes.

Step 8: Prepare a short communications brief for each stage

During an ICS incident, confusion creates risk. Operators need to know what changed. Management needs to know the business impact. Security needs technical facts. A short communications brief keeps everyone aligned without flooding them with unnecessary detail.

Each brief should answer:

• What happened or what is suspected?

• What systems or processes are affected?

• What actions have been taken?

• What approvals were obtained?

• What is the current operational risk?

• What are the next planned steps?

Keep the language plain. For example: “Remote vendor access has been disabled. The process remains stable in manual mode. No safety impacts are observed. Engineering is verifying controller logic against the baseline. Next update in 30 minutes.” That is more useful than a vague note saying the incident is “under investigation.”

A practical ICS incident response checklist

Here is a compact version you can adapt into an internal asset:

• Confirm the incident and identify affected assets

• Determine process, safety, and environmental impact

• Notify operations, engineering, security, and safety as needed

• Assign an incident lead and record decision authority

• Collect safe evidence from central and low-risk sources first

• Preserve logs, screenshots, and time references

• Map dependencies before isolating any asset

• Choose the least disruptive containment option that reduces risk

• Protect safety systems, alarms, and operator visibility

• Stabilize the process before eradication

• Restore from known-good baselines where needed

• Verify logic, configs, communications, and safety functions

• Return to normal operations in controlled stages

• Issue clear status briefs at each phase

• Document all actions, approvals, and lessons learned

Final takeaway

The best ICS incident response checklist is not the one that isolates fastest. It is the one that helps teams make safe, informed decisions under pressure. In industrial environments, containment has to support operations, not fight them. That means coordinated approvals, careful evidence handling, low-risk containment choices, disciplined recovery checks, and simple communication. If you build your checklist around those points, you reduce cyber risk without creating operational damage at the same time.