Episode 07: OT/ICS Incident Response - the PICERL workflow Presented as Denise Cross, Senior Incident Response Consultant, OTCogniShield Synthetic narration; not a recording or clone of the pictured person. [00:00:00.450] WELCOME Hello, I'm Denise Cross, a Senior Incident Response Consultant at OTCogniShield. In this lesson, we'll use the platform's Incident Response module to walk through a practical response, from preparation to lessons learned. [00:00:17.307] WELCOME Cyber incidents can disrupt industrial operations. Preparing for them is sensible, without treating every equipment fault as an attack. A useful response brings engineering, operations, safety and security into the same conversation. [00:00:34.590] WELCOME This is a guided overview, rather than a two-day course or a substitute for your site procedures. We'll follow a fictional packaging-cell example and finish with the incident form you can print or save. [00:00:49.360] FOUNDATIONS IT and OT incident response share familiar activities: gathering facts, coordinating people, limiting harm and restoring service. In OT, decisions can also affect machinery, utilities, interlocks and the physical process. [00:01:07.091] FOUNDATIONS The objective is safe, controlled restoration with avoidable downtime reduced. The quickest technical change is not automatically the safest operational decision. A disconnected engineering workstation, for example, may still have a critical process dependency. [00:01:25.868] FOUNDATIONS OTCogniShield helps organise cases, observations, evidence and review notes. It does not take control of equipment, authorise isolation or certify that a plant is safe. Those decisions stay with qualified, authorised site personnel. [00:01:45.246] THE METHOD PICERL stands for Preparation, Identification, Containment, Eradication, Recovery and Lessons Learned. Use these as a structure for questions and records, not as a rigid queue that everyone must complete in sequence. [00:02:01.377] THE METHOD New information can send the team back to identification while containment planning continues. Record why a decision changed, who reviewed it, and which evidence supports the revised position. Uncertainty should remain visible. [00:02:17.402] THE METHOD For a two-day workshop, you could explore preparation, identification and containment on day one, then remediation, recovery and a tabletop review on day two. This video introduces the workflow and the platform support. [00:02:34.156] 01 PREPARATION Begin with a usable inventory and a defined production boundary. Identify the process, relevant assets, communication paths, owners and dependencies. Record what is unknown, rather than assuming the inventory is complete. [00:02:50.565] 01 PREPARATION Name the incident lead and the people who can approve operational decisions. Include operations, engineering, safety, security and vendor support where relevant. Agree an alternative communication route if normal business systems are unavailable. [00:03:08.573] 01 PREPARATION In the Preparation worksheet, reference the inventory, contact tree, escalation procedure and last recovery test. A named backup is more useful when the team also knows whether it has been tested and who can approve its use. [00:03:25.093] 01 PREPARATION A tabletop exercise is a discussion, not a live attack or an unapproved plant test. Present a realistic scenario: a packaging cell stops, and unexpected maintenance activity appears in the available observations. [00:03:41.629] 01 PREPARATION Ask the team who receives the first call, who assesses the process condition, and who records the timeline. Explore how the team would work if email or the usual engineering laptop were unavailable. [00:03:55.670] 01 PREPARATION Capture the gaps as improvement actions with owners and dates. Do not mark readiness complete merely because a meeting happened. Record the decisions tested, the assumptions challenged and the changes still outstanding. [00:04:11.336] 02 IDENTIFICATION Open Incidents and choose Start an incident, or use the Open incident form. Enter a clear title, the priority from your site severity procedure, the case owner and the affected zone and conduit. [00:04:25.398] 02 IDENTIFICATION Write an initial summary that separates observed facts from possible explanations. Our example might say: packaging stopped at nine fifteen UTC; an unfamiliar maintenance connection was observed; the relationship between those events is unconfirmed. [00:04:43.833] 02 IDENTIFICATION Create the case and review the recorded safety gate. Treat the gate as part of case governance, not as permission to isolate a device or restart equipment. The relevant operational approvals still belong in site procedures. [00:05:00.758] 02 IDENTIFICATION An unusual protocol exchange can justify investigation, but it does not establish a cyber root cause. Compare available network observations, host information and maintenance records with engineering and process evidence. [00:05:17.593] 02 IDENTIFICATION In the example, a legitimate maintenance connection and a mechanical fault could occur together. A compromised workstation could also be relevant. Record competing explanations and what evidence would distinguish them, without declaring one proven prematurely. [00:05:35.239] 02 IDENTIFICATION Use the Identification notes for first-observed time, timezone, affected assets, protocol context, confidence and remaining gaps. Root cause analysis is a team activity; a passive observation is one input, not the entire diagnosis. [00:05:54.767] 02 IDENTIFICATION Use the evidence locker to associate an appropriate supporting file with the correct incident. The existing form accepts formats such as packet captures, logs, text, JSON and CSV, subject to the platform's own validation. [00:06:11.794] 02 IDENTIFICATION An evidence hash helps check whether stored bytes have changed. It does not, by itself, prove who collected the material, whether the source was trustworthy or whether a complete chain of custody exists. [00:06:25.259] 02 IDENTIFICATION Record collection time with its timezone, collector, source and any transfers. Preserve originals under your evidence procedure. Do not run additional intrusive collection on production equipment merely to make the case record look more complete. [00:06:43.293] 03 CONTAINMENT Containment planning asks what action would reduce harm and what new consequences it could introduce. In the packaging-cell example, restricting a maintenance path may be a candidate option, but its dependencies must be understood first. [00:06:59.573] 03 CONTAINMENT Operations and safety personnel should review proposed isolation, shutdown or fallback measures under the site's approved procedures. Manual operation is appropriate only where a validated procedure, trained people and suitable safeguards already exist. [00:07:17.902] 03 CONTAINMENT Record the proposed option, expected effect, operational consequences, approver and decision time. Include the relevant fallback or rollback reference. The platform documents that review; choosing a playbook does not execute its steps. [00:07:35.701] 03 CONTAINMENT The Response decision support area lets you select a recorded playbook and read its steps. Treat that material as a prompt for the response team, rather than a universal instruction for every factory or device. [00:07:50.787] 03 CONTAINMENT Check whether the playbook fits the affected process, device type, maintenance condition and current operating state. Record where the assumptions do not match. A reusable playbook cannot know every local interlock or utility dependency. [00:08:07.409] 03 CONTAINMENT Use the case status to communicate progress under your own procedure, and keep the reasons for significant decisions in the supporting record. Changing a status is not evidence that containment has been technically validated or completed. [00:08:24.462] 04 ERADICATION Eradication is about addressing the supported cause of the incident. A generic instruction to remove malware is not an adequate plan for an industrial controller, engineering station and their surrounding process dependencies. [00:08:40.743] 04 ERADICATION Where restoration is required, coordinate with engineering and the relevant vendor. Identify the approved firmware, logic, configuration and trusted backup references. The video does not provide device-specific flashing, reset or program-download instructions. [00:08:59.562] 04 ERADICATION Use the Eradication worksheet to reference the change authorisation, vendor advice, validation results and rollback plan. Record remaining uncertainty. An installed firmware version alone does not show that the running logic and process configuration are correct. [00:09:19.537] 05 RECOVERY Recovery needs agreed acceptance criteria, not simply a green status message. Define what the authorised team must demonstrate before the affected process is returned to service under the approved restart procedure. [00:09:35.541] 05 RECOVERY Reference the relevant functional checks, configuration verification, dependency checks and observation period. Record the actual results and any restrictions. A quiet monitoring display does not prove that an operating process is safe. [00:09:52.525] 05 RECOVERY Name the operations and safety owners who authorise return to service, and record the time with its timezone. Keep residual risks and follow-up monitoring visible. Recovery remains a controlled site decision, even when production pressure is high. [00:10:11.029] 06 LESSONS LEARNED After the immediate response, reconstruct the timeline using recorded facts and clearly labelled estimates. Review what the team knew at each decision point, rather than judging earlier choices using information discovered much later. [00:10:27.715] 06 LESSONS LEARNED Document effective actions, communication difficulties and evidence gaps. Create improvement actions with an owner, a due date and a way to verify completion. Avoid a closure note that merely says training is required. [00:10:43.547] 06 LESSONS LEARNED Update the response program, contact tree, recovery references and tabletop scenarios where the review identifies a need. Record why the case is being resolved or closed, including any outstanding actions and their continuing owners. [00:11:01.475] PLATFORM WORKSHEET The PICERL worksheet sits within the Incident Response module. Choose the relevant case before entering notes. Each phase provides prompts for decisions, owners and evidence references, while allowing the team to revisit an earlier phase. [00:11:17.883] PLATFORM WORKSHEET In this release, worksheet notes are temporary in the current browser tab. They are not automatically saved into the incident database, and they are lost on reload or sign-out. A completed-looking screen is not proof of retention. [00:11:33.396] PLATFORM WORKSHEET Before leaving the page, open the incident form and export or print what you need. Save the resulting record to an approved location, then associate it with the correct incident through the supported evidence process. [00:11:48.977] PRINT AND EXPORT Select Print incident form, Save as PDF. The form opens in a separate window using the chosen case, matching loaded evidence references and your current worksheet notes. Allow that window if your browser blocks it. [00:12:04.681] PRINT AND EXPORT A blank form deliberately shows no selected case. For a populated form, check the case ID, owner, scope, recorded status and full evidence hashes. Review missing fields rather than treating Not recorded as a completed response. [00:12:21.410] PRINT AND EXPORT Add the site context, timeline entries, review owners and acceptance references where needed. The form supports documentation of authorisation; printing it or typing a name does not itself grant operational permission or independently authenticate a signature. [00:12:41.236] PRINT AND EXPORT Use the print control to print the form or save a PDF through your browser. Check the preview for paper orientation, margins and page breaks before keeping a formal copy. Long notes can change the page count. [00:12:56.706] PRINT AND EXPORT Download completed form, text, provides a text copy of the form's current contents. That export can be reviewed and attached using the existing text evidence upload. The present evidence file filter does not list PDF as an accepted format. [00:13:14.523] PRINT AND EXPORT Keep PDF copies in your approved incident-record location. Check that the uploaded text belongs to the selected case and retain the resulting evidence reference. Neither a PDF nor a text snapshot replaces an attributed incident audit trail. [00:13:33.858] WORKED EXAMPLE Return to our fictional example. The observation is an unexpected maintenance path near a packaging interruption. Finding F zero one records that approval and timing context are unverified. It does not claim that an attacker caused the stoppage. [00:13:51.973] WORKED EXAMPLE Draft action A zero one asks the Engineering Lead to compare maintenance approval, session timing and relevant process records before the agreed review deadline. This is an illustrative handover, not an automatically generated case outcome. [00:14:09.150] WORKED EXAMPLE If new evidence changes the explanation, update the review record and preserve the earlier rationale. Connect observations to owners and decisions without turning every unusual communication into a confirmed incident. The boundary and remaining gaps should stay explicit. [00:14:29.488] RECAP Preparation asks whether the people, scope and recovery references are ready. Identification asks what is known, how confident the team is, and what evidence is missing. Containment asks which reviewed option can limit harm without creating unacceptable consequences. [00:14:49.011] RECAP Eradication asks whether the supported cause has been addressed through an authorised plan. Recovery asks whether the agreed acceptance criteria are met. Lessons Learned asks who owns the improvements and how their completion will be verified. [00:15:05.505] RECAP Use the module to support clear records and accountable conversations. Rehearse the workflow with your plant team, and keep the approved site procedure close at hand for your next exercise. [00:15:19.017] CLOSING Prepare the people. Preserve the evidence. Keep decisions accountable. [00:15:24.183] CLOSING This concludes the OTCogniShield Incident Response module overview. [00:15:29.434] CLOSING Thank you.