OT SOC Strategies for Continuous Risk Assessment

OT Detection Use Cases for your OT SOC When it comes to building an OT SOC, there’s a big misconception: many assume success is about collecting every log or integrating every system In reality, the key is focusing on operationally meaningful visibility — the detections that actually help you understand what’s happening inside your control network >> In industrial environments, context defines everything > The same Modbus write command could mean two very different things: > a maintenance engineer performing a scheduled update — or an attacker changing control logic. > Without context, both look identical in your SIEM. >> An OT SOC must speak the language of process, assets, and operations, not just alerts. It should tell you when something changes, who initiated it, and whether it threatens safety, reliability, or integrity >> Below are 10 detection use cases I always recommend as a starting point. They’re mapped to MITRE ATT&CK for ICS and NCA OTCC, but more importantly, they’re grounded in what actually happens inside real plants and industrial networks 1. Unauthorized PLC Programming Detect logic or configuration changes outside scheduled maintenance windows 2. ICS Protocol in IT Zone Flag Modbus, DNP3, or BACnet traffic on IT networks — strong evidence of segmentation drift or misconfiguration 3. PLC Stop or Mode Change Command Detect STOP or PROGRAM mode changes — an event that can halt production and indicate malicious control 4. Remote Access to HMI from Unapproved Source Identify RDP, VNC, or TeamViewer sessions from IT zones targeting OT HMIs — a common lateral movement path 5. New Device in Control VLAN Catch unauthorized or rogue devices joining deterministic control networks where new assets should rarely appear 6. PLC Firmware Downgrade or Version Change Detect unauthorized firmware rollbacks — a subtle but serious method of tampering or hiding malicious code 7. OPC UA Anonymous Session Identify untrusted or anonymous OPC UA sessions that bypass normal authentication or encryption 8. Engineering Software on Non-Engineering Host Detect the execution of TIA Portal, Control Builder, or similar tools on unauthorized systems — often a sign of credential misuse or insider activity 9. PLC Configuration Upload Monitor FTP/TFTP uploads to PLCs — an activity that could replace control logic or inject malicious configuration 10. Abnormal HMI Behavior Spot rapid screen changes, tag edits, or command spamming from operators — signs of misuse, automation, or compromise They aren’t just security detections — they’re process integrity safeguards. Each one gives the SOC visibility into the exact actions adversaries use during real OT incidents — often before physical impact occurs When combined with contextual data (authorized engineers, maintenance schedules, device baselines) and network telemetry , these detections evolve from simple alerts into actionable operational intelligence #OTSOC #OTsecurity #ICSsecurity

Japan’s Ministry of Economy, Trade and Industry (METI) has released an in-depth OT Security Guide for semiconductor device factories. This 132-page document outlines practical, globally-aligned strategies covering: ✅ Safeguarding production goals, confidential information, and semiconductor quality. ✅ Using NIST CSF 2.0 and the Cyber/Physical Security Framework (CPSF) for risk management. ✅ Factory security best practices based on IEC 62443 zones and microsegmentation. ✅ Special focus on asset inventory, vulnerability assessment, and tailored mitigation , not just patching. ✅ Preparing for nation-state threats, APTs, and modern supply chain risks. A must-read for OT, cybersecurity, and semiconductor industry pros looking to align with the latest global standards and strengthen factory resilience.

💡 Stop Guessing: The Right Risk Assessment Drives Your Strategy Choosing the right type of Risk Assessment is not a detail—it's a critical strategic decision. Too often, organizations use a one-size-fits-all approach and end up misallocating resources or missing key threats. The key difference often lies in the data. Qualitative Risk Assessment uses expert judgment and descriptive, non-numeric scales (like High/Medium/Low) to rate severity and likelihood. This helps small teams prioritize quick fixes with a simple heat map. For a data-driven approach, Quantitative Risk Assessment is essential. It uses numerical values (P, %, frequency) to evaluate risk and forecast potential losses or calculate the ROI on controls. A middle ground is the Semi-Quantitative method, which assigns numeric scores (like 1-5 or 1-10) to impact and likelihood, offering more structure than a purely qualitative approach. Risk isn't static. In evolving situations, a Dynamic Risk Assessment is an on-the-spot, real-time evaluation performed when risks shift rapidly or new ones emerge unexpectedly. Furthermore, a Continuous Risk Assessment is a proactive, ongoing process where risks are constantly monitored and adjusted based on new information or threats. Finally, for operational precision, you must choose between: Generic Risk Assessment: A general evaluation covering common hazards across similar tasks or environments. Use this for standardized operations. Site-Specific Risk Assessment: A focused evaluation of risks unique to a particular location, event, or project setup, considering the environment and layout. Choosing based on your environment, data availability, and industry needs is the key to making stronger decisions. #RiskManagement #CyberSecurity #BusinessStrategy #RiskAssessment #DecisionMaking #Security

Managing risk in #OT cybersecurity using the Risk Priority Number (#RPN) highlights the importance of using detection, not only prevention, when managing cyber risk to maintain availability, integrity, and safety of the physical process. Another important point is the distribution and difference between the capabilities of different assets across the Purdue Model. For example, Level 1, which contains process control and safety systems, has a chance of reducing occurrence by using defense-in-depth to reduce RPN. But at the same time, detection is low, especially in legacy systems, due to the lack of detection features. While in the upper levels (L2 for supervisory control), the situation is reversed: the occurrence is high, but detection becomes possible because we can forward syslogs to detect IOCs. The difference between level capabilities and the attack surface must be managed to reduce RPN, considering the different capabilities, attack surface, likelihood, and access points. Depending on defense-in-depth in the lower levels is more effective to reduce risk. Also, the impact/severity in lower levels is higher than the upper levels because lower levels have direct impact on the physical process, which can affect the safety of people, cause environmental impact, or lead to equipment damage. This is an important point in RPN and highlights the need for accurate distribution of OT cybersecurity investment based on risk (risk-based design). Foundational Requirements in ISA/IEC 62443 also reflect this logic. For example, FR1 and FR2 (access management) are more effective in L2 and above, while system integrity and restricting data flow are more effective in the lower levels. The aim of this post is to highlight the importance of deeply understanding OT through clear and real-time asset visibility, logging, and network monitoring to manage cyber risk. As a summary: risk can be reduced not only by preventing incidents, but also by detecting the occurrence of the risk "detecting IOCs" #iec62443 #otcybersecurity #icssecurity #TahseenSaber

This week’s joint federal advisory on Iranian-affiliated cyber activity targeting U.S. critical infrastructure should not be read as another routine warning. It is a reminder that in too many water and utility environments, the path from exposure to operational disruption is still shorter than it should be. The advisory states this activity has already resulted in operational disruption and financial loss, with actors targeting internet-facing PLCs, interacting with project files, and manipulating data displayed on HMI and SCADA systems. For those of us who have spent time in and around OT environments, this is the uncomfortable part: these conditions do not usually exist because no one cares. They exist because operational technology accumulates debt over time. Remote access gets layered in for supportability. Cellular pathways get added for field connectivity. Legacy assets stay in place because downtime is hard to win. Engineering access grows faster than governance around who can change logic, push code, or alter operational displays. That is why resilience in smaller and mid-sized utilities has to be approached as a program, not a project and not a product purchase. OT risk is continuous, operational, and tied to the full lifecycle of how systems are accessed, maintained, changed, and recovered. The right path is still crawl, walk, run: segmentation, secure remote access, reduced external exposure, tighter control over engineering changes, logging and monitoring of remote access and configuration changes, protected backups of logic and configuration, tested response procedures for OT-impacting incidents, and the ability to fail safely to manual operations when digital control is degraded or compromised. In critical infrastructure, known risk left unaddressed long enough eventually becomes real-world operational disruption. The leadership question is not whether the threat is understood. It is whether years of accumulated exposure are being methodically reduced before an adversary turns them into impact. #WaterSecurity #Utilities #OTSecurity #CriticalInfrastructure #CyberResilience #Fortinet

So you think you know how to threat model? Many SOCs claim to do formal threat modeling (whether they really do is another story). But let’s talk about the right way–because a half-baked threat model can be worse than none at all, especially when it comes to organization risk. 𝟭. Introspection: Know your business–and its risk • Identify the crown jewels: Which assets, if compromised, would cripple your operations or reputation? • Spiral method: Envision a crime scene–except it hasn’t happened yet (hopefully). Start at your most critical points and circle outward, noting controls in place. • Map your processes: Understand your dependencies, supply chain links, and workflows to figure out where the real business risk lies. 𝟮. Extrospection: Know your threat landscape • Threat actors 101: Who’s targeting your vertical? How do they operate–ransomware, data exfil, or something else? • Outcomes & motives: Whether it's a quick payday or long-term espionage, each threat actor’s endgame shifts your risk profile. • Worst-case mindset: If they succeed, what’s the impact on revenue, reputation, or compliance? 𝟯. Union: Combine Business & Threat Risk • Introspection + Extrospection: Once you see your weaknesses and adversaries' strengths, theoretically set fire to your own org to find the flashpoints. • Prioritize by Risk: Not all threats matter equally. Tackle high-likelihood, high-impact scenarios first. • Feed it back: These insights drive your detection engineering–especially behavioral and sequential detections that address the most significant threats. 𝟰. Evolve: Threat Modeling is Never Done • Track & Iterate: Each exercise introduces new defenses (lowering some risks) and may uncover new attack paths (introducing others). • Stay Current: New business ops, acquisitions, or tech adoptions all shift your threat landscape. Revisit your model regularly. • Continuous Improvement: Capture lessons learned, adjust your controls, and refine your detection logic to stay in step with reality. Threat modeling isn’t just a one-off workshop–it’s a cycle that guides strategic security decisions and aligns detection capabilities with genuine business risk. How do you keep your threat model updated as the business and threat landscape evolve?

Does your psychosocial risk assessment only tell you half the story? In psychosocial risk assessments, don’t stop at hazards - measure the protective factors too. Under the Job Demands–Resources (JD-R) model, demands (e.g., work overload, role conflict, customer aggression) drive strain - unless they’re counterbalanced by resources (protective factors) such as job control/autonomy, role clarity, and support. Psychosocial hazard elimination is ideal but not always possible. Peak seasons, emergency work, and customer interactions can’t be “engineered out”. And while controls (e.g. resourcing, rostering, process redesign) reduce risk - protective factors can reduce it further - helping you further reduce the risk SFAIRP. How to bake hazards and protective factors into your assessment: Consider both sides Consult workers about their experience of demands (severity, frequency and duration) and allow an opportunity to consider if psychosocial factors are acting as a protective factor. Identify high-strain combinations Risk isn’t just “high exposure” to demands; it’s high demand + low resource. Prioritise these high-impact hotspots. Select layered controls ⚠️ Demand controls: staffing plans, workflow redesign, transparent communications, administration time-sink removal. 💚Resource boosters (protective factors): decision latitude, role clarity, coaching & supervision, recovery breaks, team backup, and defined career progression. Make it measurable Track worker experience of both sides (e.g., work overload, change, incivility and autonomy, supervisor support, career progression). Report them to leadership alongside lag measures. Best practice psychosocial risk assessment: 1️⃣Plan & scope – define objectives, duty holders, teams in scope and demographics. Align state legislation requirements, and your hazard profile. 2️⃣Consultation first – leaders and HSRs/worker representatives early; set expectations, explain confidentiality, and outline expected next steps. 3️⃣Mixed-methods data – combine a fit-for-purpose survey with targeted focus groups/interviews and operational data (turnover, absence, incidents). 4️⃣Team-level insight – analyse at the smallest practical unit to surface local conditions; organisation level averages can obscure significant team-level risks. 5️⃣Risk analysis – rate likelihood x consequence, that is adjusted for protective factors. Use a validated score to rank risk between groups. 6️⃣Monitor – set re-assessment cadences based on risk level and control implementation timeframes. 7️⃣Confidentiality – protect respondent anonymity, manage sensitive disclosures, and provide immediate support routes for workers to self-select into. Sound hard? It doesn’t have to be. Get a QuickStart with FlourishDx guiding you through the above within 4 weeks. *Stats extrapolated from Safe Work Australia summary #psychosocialriskmanagement #psychosocialhazards #psychhealthandsafety #ISO45003

Current IoT risk assessments are broken—and here’s how to fix them courtesy of new research… As IoT systems grow more complex, traditional risk models fail to account for the cascading, interconnected threats these devices introduce. The research from this paper highlights that IoT risks aren’t isolated incidents; they’re part of a web of dependencies where one device's vulnerability can trigger widespread system failures. If you are in manufacturing or healthcare, this is a significant challenge. The authors propose a dependency-based cyber risk model to capture the interdependencies between IoT components and estimate how risks in one part of the system can affect the whole. The model uses AI/ML techniques for real-time risk estimation, making it adaptable across various IoT domains like healthcare, smart cities, and industrial IoT. It also integrates risk transference strategies, such as cyber insurance, to help organizations mitigate financial losses from cyber incidents. Key takeaway? The old ways of assessing cyber risk don’t work for IoT. The proposed model offers a dynamic, scalable approach to understanding and managing IoT-specific risks, and it’s time we embrace these more holistic strategies before it's too late. 74 pages...but well worth the read if IoT security is on your radar. #cybersecurity #IoT #risk #ai Claroty Upa Campbell

Your OT security dashboard may be busy. But is it proving that operational risk is going down? A vulnerability count does not prove a plant is safer. • An alert count does not prove the SOC understands process impact. • An asset count does not prove those assets are segmented, monitored, backed up, or recoverable. The Industroyer / CrashOverride incident is a useful reminder. It was designed to impact industrial control system processes, including components used in electrical substations. The lesson for OT security is clear. Teams need protocol visibility, process context, response readiness, and resilience. That applies directly to manufacturing environments. Imagine a monthly report says: “500 OT vulnerabilities identified.” That may be technically accurate. But leadership still needs to know: • Which vulnerabilities affect production-critical assets? • Which assets are reachable from remote access paths? • Which systems have compensating controls? • Which PLCs and HMIs have current backups? • Which zones have validated segmentation? • Which risks could affect safety, quality, or downtime? A better metric would sound more like this: “95% of production-critical assets have an owner, mapped communication paths, known remote access exposure, backup status, and defined recovery procedures.” That is a different conversation. Useful OT metrics should answer five questions: • Do we know what matters most? Critical assets identified, owned, and classified by process impact. • Do we understand how it communicates? Mapped communication flows, industrial protocols, and zone boundaries. • Can we detect meaningful change? Unauthorized logic changes, abnormal protocol activity, unexpected remote access, and engineering workstation activity. • Can we recover what matters? PLC logic backups, HMI projects, SCADA configurations, network configs, and tested restore procedures. • Are we reducing exposure over time? Exceptions closed, vendor access reviewed, compensating controls applied, and high-risk paths reduced. This matters because weak metrics create weak decisions. • If leaders only see vulnerability counts, they may fund patching without fixing segmentation. • If they only see alert volume, they may miss whether alerts reflect process risk. • If they only see asset numbers, they may miss whether critical assets are recoverable. My point of view: OT metrics should not only show what security teams are doing. They should show whether the plant is more resilient than it was last quarter. The best metrics connect cyber controls to operational outcomes: Production continuity. • Safety. • Quality. • Recovery. • Auditability. • Business continuity. • Measure what reduces operational risk. Which OT metric has been most useful in your organization: asset criticality, segmentation coverage, remote access review, vulnerability reduction, or recovery readiness? #OTSecurity #IndustrialCybersecurity #RiskManagement #ICS #SCADA

For SOCs, it’s not just the hackers that pose a threat - it’s the avalanche of data that buries real signals under noise. Security logs, once the fuel for detection, are now both an asset and a liability. The flood of redundant, misaligned, or uncurated telemetry drains not just budgets - but analysts. The challenge isn’t just collecting data - it’s collecting the right data, in the right shape, at the right time. Security tools generate logs by the terabyte. Yet most organizations lack a strategy to qualify, contextualize, or prioritize what enters their SIEMs. As a result: ▪ Real threats get buried in noise. ▪ False positives clutter dashboards, wasting attention. ▪ Costs balloon from excessive licensing and storage. To move from reactive firefighting to proactive defense, SOCs must elevate telemetry management as a core security function. Here's how leading teams do it: 1. Precision Filtering, Not Blanket Collection Start with a threat-informed view: what data truly supports detections? Eliminate noise - e.g., suppress successful login logs unless from unusual geographies or times. 2. Normalization and Enrichment as Multipliers Standardize formats and enrich with business context - asset criticality, user identity, threat intel, geolocation. This transforms raw logs into events that trigger rules more accurately and reduce triage ambiguity. 3. Retention That Reflects Risk Abandon “store everything” habits. Align retention with risk: real-time detection data stays hot; compliance data can go cold. 4. Use Case-Driven Collection Let strategy guide ingestion. Data should map to real correlation rules, MITRE ATT&CK coverage, or compliance needs. If it doesn’t, reconsider ingesting it. Log optimization isn’t just about saving money, it enables: ▪ Faster decision-making ▪ Reduced alert fatigue ▪ Stronger detection fidelity When telemetry pipelines are treated with the same rigor as detection logic or incident response, the SOC becomes sharper and more effective. Final thought…. Data isn't your greatest asset - useful data is. 👉Ask Yourself Are you collecting data to feel secure - or to be secure? #CyberSecurity #SOC #SecOps #ThreatDetection #Telemetry #DataStrategy #DataQuality #OptimizeLogs #LogReduction #SecurityEfficiency #SIEMOptimization #AlertFatigue #TelemetryPipeline