ICS Security Strategies for Engineers

𝗜𝗖𝗦 𝗔𝗰𝗰𝗲𝘀𝘀 𝗖𝗼𝗻𝘁𝗿𝗼𝗹: 𝗞𝗲𝗲𝗽𝗶𝗻𝗴 𝗖𝘆𝗯𝗲𝗿 𝗧𝗵𝗿𝗲𝗮𝘁𝘀 𝗢𝘂𝘁 𝟯:𝟬𝟬 𝗮.𝗺. 𝗶𝗻 𝗮𝗻 𝗲𝗻𝗲𝗿𝗴𝘆 𝗽𝗹𝗮𝗻𝘁: An operator sees the cursor moving—on its own. In 2021, hackers actually took control of a Florida water plant, nearly poisoning the water. Why? Shared passwords and open remote access. Access control in Industrial Control Systems (ICS) isn’t just IT hygiene—it’s a frontline defense. Unlike IT, ICS must balance security vs. uptime, making access control complex. 𝗞𝗲𝘆 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀 𝗶𝗻 𝗜𝗖𝗦 𝗔𝗰𝗰𝗲𝘀𝘀 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 ❌ Default & Shared Credentials – Many OT devices still use factory-set or hardcoded passwords. ❌ Overprivileged Accounts – Admins using the same account for both daily tasks & critical operations. ❌ Uncontrolled Remote Access – Unrestricted RDP, TeamViewer, or VPN access directly into OT. ❌ Lack of Continuous Audits – Old user accounts lingering long after employees leave. 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻𝘀 (Aligned with IEC 62443) ✏️ Kill Default Credentials – Change all default passwords before deployment. Use compensating controls if you can’t. ✏️ Unique, Least-Privilege Accounts – No shared logins. Admins should have separate work and privileged accounts. ✏️ Secure Remote Access – Jump servers, MFA, and firewalls between IT & OT. No direct access to controllers. ✏️ Regular Audits & Offboarding – Disable accounts immediately when employees or contractors leave. 𝙍𝙚𝙘𝙚𝙣𝙩 𝙇𝙚𝙨𝙨𝙤𝙣: The Florida water plant breach could have been prevented with MFA, segmented access, and unique passwords. Simple steps can block attackers from turning small mistakes into disasters. ICS security is about access—who gets in, what they can do, and when they’re removed. Every login should tell a secure story. #ICS #CyberSecurity #IEC62443 #AccessControl #OTSecurity

Please STOP using generic IT solutions for securing ICS/OT networks. It is very rare where you can "bolt on" an IT solution onto ICS/OT and have it be effective. Very rare. IT is "one-size-fits-all." ICS/OT is quite the opposite. Too many people deploy IT solutions in ICS/OT to realize: -> They've over paid -> They're under protected -> They're environment isn't reliable -> Ultimately, that they've made a mistake Do this instead: -> Conduct ICS-specific risk assessments to determine the gaps you need to address. -> Never stop improving. Addressed one issue? There's always another! -> Use network segmentation to limit connectivity between systems which limits the impact of incidents. -> Deploy network security monitoring to watch for operational AND security issues in the environment. -> Be proactive in identifying and responding to threats and alerts. -> Nurture an environment where OT and IT work well together, and WANT to work well together. -> Build your incident response plan so everyone, OT and IT, know how to work together to reduce the ultimate impact to people, the environment and the facility. We can assume IT security solutions and practices can be bolted on to ICS/OT and just work! Admittedly, I did when I first became interested in ICS/OT cyber security. But it doesn't work like that. Because ICS/OT doesn't work like IT. Each ICS/OT network is unique. Each requires its own unique approach. Custom-built just for it. From the ground up. Not with bolt on IT solutions. P.S. What steps to secure ICS/OT would you add?

Still using ChatGPT like it’s Google? If you work in OT/ICS cybersecurity, you’re leaving serious value on the table. I put together 20 practical ChatGPT prompts specifically for OT/ICS security professionals, and they go way beyond “explain zero trust.” We’re talking about using AI to help you: ✅ Build an ICS asset inventory template ✅ Create an OT vulnerability management plan ✅ Design secure network architecture (IT/OT/DMZ) ✅ Draft incident response plans ✅ Develop tabletop exercises ✅ Generate threat hunting rules for Modbus traffic ✅ Design honeypots for realistic PLC environments ✅ Define cybersecurity KPIs for leadership ✅ Prepare executive briefings ✅ Even map attacker TTPs to MITRE ATT&CK for ICS This isn’t theory. These are prompts you can actually copy, refine, and use in real environments. Why this matters: OT security teams are often: • Under-resourced • Time-constrained • Dealing with legacy systems • Trying to translate cyber risk into operational impact The right prompts can help you: → Think more systematically → Draft faster → Pressure-test your ideas → Improve documentation quality → Train junior team members AI won’t replace OT security professionals. But professionals who use AI effectively will outperform those who don’t. And if you’re already using AI in your OT/ICS workflow, I’d love to hear how.

Your Security Team Just Launched A DoS Attack On Production After 20+ years in IT and industrial automation - from pulling wire in substations to architecting hyperscale systems - I've watched IT security models fail repeatedly when forced into OT environments. Zero Trust is following the same pattern. But here's what's different this time: The failure isn't because Zero Trust principles are wrong. Assume breach, least privilege, and continuous verification are absolutely correct for OT security. The failure is because we're trying to bolt cloud-native enforcement patterns onto deterministic industrial systems without changing the transmission. The result? ☠️ NAC solutions quarantining Windows XP HMIs, killing operator visibility ☠️ OT-unaware firewalls blocking undocumented protocols, triggering emergency shutdowns ☠️ ZTNA requiring MFA at 3 AM when the manager is asleep and the motor is failing ☠️ Operations installing cellular modem backdoors because "secure" access is operationally impossible I'm watching security tools become the attack vector. Worse: these failures incentivize shadow OT. APT groups specifically target emergency access pathways because they know operations will route around security during incidents. We found unauthorized cellular modems at 7 different utilities during IR engagements: installed by operations teams who couldn't afford to wait for security approval. The "secure" system created the vulnerability. But there's a path forward. Zero Trust principles work in OT when implemented through OT-native frameworks. IEC 62443 already operationalizes assume breach, least privilege, and continuous verification using controls appropriate for deterministic systems. The technology exists. The standards are mature. What's missing is organizational discipline to demand OT-specific implementations instead of accepting IT patterns with industrial marketing. Starting today, I'm publishing a 3-part series: 💠 Part 1: Why cloud-native Zero Trust enforcement patterns fail in ICS (the problem) 💠 Part 2: How IEC 62443 translates Zero Trust principles to OT-compatible implementations (the solution) 💠 Part 3: Industrial Independence as organizational framework for cross-functional collaboration (the methodology) This isn't about rejecting security. It's about engineering security correctly for operational reality. Operations teams resisting cloud-native ZTA aren't security-resistant. They understand that security models which break availability create the vulnerabilities they claim to prevent. What failure patterns have you seen when IT security models collide with OT operations? 🌊 #IndustrialCybersecurity #OTSecurity #ZeroTrust #ICS #SCADA #CriticalInfrastructure #IEC62443 #IndustrialAutomation #ControlSystems #CyberSecurity #IndustrialIndependence #ManufacturingSecurity #EnergyInfrastructure #ProcessControl #PlantOperations

𝗖𝗜𝗦𝗔 𝗷𝘂𝘀𝘁 𝗿𝗲𝗹𝗲𝗮𝘀𝗲𝗱 𝗮 𝗻𝗲𝘄 𝗮𝗱𝘃𝗶𝘀𝗼𝗿𝘆 on Iranian‑affiliated cyber actors exploiting programmable logic controllers (PLCs) across U.S. critical infrastructure (AA26‑097A). 👉 https://lnkd.in/eBgtyRKK 𝗠𝘆 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆? In many ways, there’s nothing new here. If an attacker gains access to:  • PLC programming software  • An HMI or engineering workstation  • A control system or SCADA network using unauthenticated / unencrypted protocols (e.g., Modbus) …they don’t need exotic “OT malware.” They can simply use 𝗹𝗲𝗴𝗶𝘁𝗶𝗺𝗮𝘁𝗲 𝘁𝗼𝗼𝗹𝘀 𝗮𝗻𝗱 𝗽𝗿𝗼𝘁𝗼𝗰𝗼𝗹𝘀 𝘁𝗼 𝘀𝗲𝗻𝗱 𝗹𝗲𝗴𝗶𝘁𝗶𝗺𝗮𝘁𝗲 𝗰𝗼𝗺𝗺𝗮𝗻𝗱𝘀 to:  • Open or close valves  • Start or stop pumps and motors  • Manipulate process values or operator displays As CISA highlights, these actors interacted directly with PLC project files and HMI/SCADA displays—causing real operational disruption. 𝗧𝗵𝗲 𝗿𝗲𝗮𝗹 𝗹𝗲𝘀𝘀𝗼𝗻 𝗶𝘀𝗻’𝘁 𝗮𝗯𝗼𝘂𝘁 𝗜𝗿𝗮𝗻, 𝗮 𝘀𝗽𝗲𝗰𝗶𝗳𝗶𝗰 𝗣𝗟𝗖 𝘃𝗲𝗻𝗱𝗼𝗿, 𝗼𝗿 𝗮 𝘀𝗶𝗻𝗴𝗹𝗲 𝘃𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝘆. It’s this: 𝗧𝗵𝗲 𝗺𝗼𝘀𝘁 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝘁𝗵𝗶𝗻𝗴 𝗶𝘀 𝗸𝗲𝗲𝗽𝗶𝗻𝗴 𝗺𝗮𝗹𝗶𝗰𝗶𝗼𝘂𝘀 𝗮𝗰𝘁𝗼𝗿𝘀 𝗮𝗻𝗱 𝗺𝗮𝗹𝗶𝗰𝗶𝗼𝘂𝘀 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗼𝘂𝘁 𝗼𝗳 𝘆𝗼𝘂𝗿 𝗢𝗧 𝗻𝗲𝘁𝘄𝗼𝗿𝗸𝘀 𝗮𝗻𝗱 𝗢𝗧 𝗰𝗼𝗺𝗽𝘂𝘁𝗲𝗿𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗳𝗶𝗿𝘀𝘁 𝗽𝗹𝗮𝗰𝗲. Yet I still see companies—particularly IT cybersecurity organizations—searching for a silver bullet product they can install on OT networks that will magically solve the problem. That product doesn’t exist. 𝗘𝗳𝗳𝗲𝗰𝘁𝗶𝘃𝗲 𝗢𝗧 𝗰𝘆𝗯𝗲𝗿𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗶𝘀 𝗮 𝗽𝗿𝗼𝗴𝗿𝗮𝗺, 𝗻𝗼𝘁 𝗮 𝘁𝗼𝗼𝗹. It requires:  • Assessing risk in the context of the 𝗮𝗰𝘁𝘂𝗮𝗹 𝗶𝗻𝗱𝘂𝘀𝘁𝗿𝗶𝗮𝗹 𝗽𝗿𝗼𝗰𝗲𝘀𝘀  • Establishing OT‑specific policies and standards based on risk and frameworks like 𝗡𝗜𝗦𝗧 𝗦𝗣 𝟴𝟬𝟬‐𝟴𝟮 𝗮𝗻𝗱 𝗜𝗦𝗔/𝗜𝗘𝗖 𝟲𝟮𝟰𝟰𝟯  • Implementing prioritized technical and procedural remediations  • Continuously 𝗺𝗼𝗻𝗶𝘁𝗼𝗿𝗶𝗻𝗴, 𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻𝗶𝗻𝗴, 𝗮𝗻𝗱 𝗮𝘂𝗱𝗶𝘁𝗶𝗻𝗴 the program over time If you want a practical view of what effective OT cybersecurity governance actually looks like—and how to build it without chasing shiny objects—we cover this in detail here: 👉 https://lnkd.in/ebV8rUav #OTCybersecurity #IndustrialCybersecurity #ICS #SCADA #PLCs #CriticalInfrastructure #RiskManagement #Governance

Integrating ISA/IEC 62443 Cybersecurity throughout Project Lifecycle How to integrate cybersecurity in project phases is a million dollar question, let's explore together! >> integrating Cybersecurity in the project life cycle provides many benefits: > Proactive risk mitigation to prevent vulnerabilities. > Compliance with industry standards and regulations. > Cost savings by addressing security early. > Ensures operational reliability and safety. >> The IEC 62443 framework provides a structured approach to secure systems throughout their lifecycle—from conceptualization to ongoing operation. >> Relevant Standards: > ISA/IEC 62443-2-1, > ISA/IEC 62443-2-4, > ISA/IEC62443-3-2, and > ISA/IEC62443-3-3, >>These standards cover > cyber security management, > risk assessment, and > technical requirements. 1. Concept Phase: Define project goals, scope, and requirements. >> Key Activities: > Define scope of work and requirements. > Develop strategy and methodology. > Assign roles and responsibilities. >> Relevant Standards: IEC 62443-2-1 and IEC 62443-2-2. 2. FEED Phase: Front-End Engineering Design >> Key Activities: > Identify Systems under Consideration (SuC). > Conduct a high-level risk assessment. > Partition zones and conduits. > Perform detailed risk assessments. > Specify cybersecurity requirements. >> Relevant Standards: IEC 62443-3-2. 3. Project Phase: Execute the design, build, and testing activities. >> Key Activities: > Conduct detailed engineering. > Perform Factory Acceptance Testing (FAT). > Commission systems. > Hand over systems to operations. >> Relevant Standards: IEC 62443-3-3 and IEC 62443-2-4. 4. Operation Phase: operations and Maintenance >> Key Activities: > Maintain systems. > Monitor cybersecurity performance. > Manage change. > Respond to and recover from incidents. >>Relevant Standards: IEC 62443-3-3 and IEC 62443-2-4. #icssecurity #otsecurity

SCADA Cybersecurity Your Practical Defense Playbook After 3 decades in industrial controls, I've seen SCADA systems evolve from isolated workhorses to connected, vulnerable targets. Your SCADA system is a target. The Four Deadly SCADA Vulnerabilities You Can Fix Today Legacy Systems Running on Borrowed Time: That Windows XP HMI you've been nursing along? It's a ticking time bomb. Unpatched systems are low-hanging fruit for attackers. Quick Win: Inventory every piece of software in your control network. Anything without vendor support gets isolated or replaced. Protocols That Trust Everyone: Some industrial protocols send commands in plain text with zero authentication. It's like leaving your front door wide open. Watch Out For: Any industrial protocol traffic crossing network boundaries without encryption. Attackers can read every command and forge new ones. The IT/OT Bridge That Became a Highway: Connecting control networks to corporate networks creates direct attack paths. The Oldsmar hacker exploited poorly secured remote access. Rule of Thumb: Never allow direct IT/OT connections. Use industrial firewalls, an industrial DMZ, and, if needed, data diodes for one-way data flow. Remote Access Convenience vs. Security: TeamViewer, VNC, and similar tools are security nightmares. Shared passwords, direct internet exposure, and always-on connections invite attackers. Your Defense-in-Depth Action Plan 1. Network Segmentation (The Purdue Model): Segment your network into security zones. >>> Level 0-1 (sensors, PLCs) stay as isolated as possible.  >>> Level 2 (SCADA masters and HMIs) gets limited access.  >>> Everything above level 2, like corporate networks, stays separate or connects through an industrial demilitarized zone (DMZ). 2. Access Control That Actually Controls >>> Implement Multi-Factor Authentication (MFA) for ALL remote access >>> Use role-based permissions, operators view data, engineers modify logic >>> Kill shared passwords immediately 3. Monitor What Matters: Deploy ICS-aware intrusion detection systems. Set up baseline monitoring, when pump pressures spike at 2 AM, you need to know why. 4. The Human Firewall: Train operators to recognize cyber incidents as process anomalies. That unresponsive pump might not be a mechanical failure; it could be a cyberattack. The Bottom Line The Oldsmar incident was stopped by an alert operator, not sophisticated cybersecurity. Most attacks succeed through basic failures: weak passwords, unpatched systems, and poor network design. You don't need a million-dollar security budget. You need disciplined execution of fundamentals. Remember: in industrial cybersecurity, availability and safety come first. But unsecured systems won't stay available long. The attackers are already here, make sure you're ready. If you want to go deeper, I've got a video on my YouTube channel with more detail. Check the link to my channel in my profile.

Here is a situation I've seen more than once. IT flags a critical vulnerability. They want it patched immediately. OT says no, because the last time someone pushed an update without proper testing, a production line went down for two days. Both sides are right. That is exactly the problem. We just released an episode that gets into the technical reality most security teams avoid:  ➤ OT environments run older operating systems by design,  ➤ Patch dependencies require updates in a specific sequence,  ➤ OEM contracts can block changes entirely ➤ Security tools built for enterprise IT can cause the exact outage they were meant to prevent What actually works: ✅ Virtual patching at the network layer for systems you cannot touch ✅ Lab-based testing before anything goes near production ✅ Continuous monitoring and asset visibility as the foundation ✅ Risk-based prioritization instead of blanket patch cycles ✅ IT and OT working from a common risk framework This is not about IT versus OT. It's about building a security program that respects how industrial systems actually operate. Worth 25 minutes of your time. 🎙️ Link to the full episode is in the article and comments below. Follow Dino Busalachi and Industrial Cybersecurity Insider for the latest industry trends, insights and best practices. #OTSecurity #ICS #SCADA #IndustrialCybersecurity #CTO #CyberDefense #Manufacturing