Search Results

By Chris Sistrunk , Technical Leader of Mandiant, Google Cloud Security, & (CS)²AI Fellow September 29, 2025 We hosted a (CS)²AI Fellow Fireside Chat on September 10, 2025 that focused on Building OT Capacity for IR and Pentesting with (CS)²AI Fellows Chris Sistrunk , Technical Leader of Mandiant (Google Cloud Security) and Danielle Jablanski , Cybersecurity Consulting Program Lead of STV . Here is a bit about the event: Operational Technology (OT) environments face unique challenges when it comes to incident response (IR) and penetration testing. As cyber threats continue to evolve, organizations must strengthen their capacity to prepare, detect, and respond effectively to incidents—while also proactively testing defenses to uncover vulnerabilities before adversaries do. Leading experts explored strategies, best practices, and lessons learned for building OT-specific capabilities in both IR and pentesting. Participants gained actionable insights into: Tailoring IR processes for OT systems Overcoming common pitfalls in OT pentesting Strengthening team skills and capacity to meet today’s threat landscape Leveraging industry tools and frameworks to build resilience This session equipped practitioners, defenders, and decision-makers with the knowledge needed to enhance security postures across critical infrastructure. Do you want to have access to more content like this? Register for our next (CS)²AI Online™ seminar or symposium here , or consider becoming a member of (CS)²AI to access our entire library of recorded sessions. The Q&A portion below represents selected overflow questions and commentary from the event, and has been answered in detail by Chris Sistrunk . ****************************** On topic questions: QUESTION No.1: When does hardening systems really become crucial in OT/ICS? ANSWER: Hardening OT systems should be a continuous process, from installation, to maintenance windows, and throughout the lifecycle of the components, especially if there are any architecture or software/update changes. Hardening should include software, hardware, network components, and physical security/access. For software hardening best practices, follow OT vendor best practices as well as Center for Internet Security (CIS) hardening benchmarks (which are free). Don't forget about simple solutions such as USB and Ethernet port blockers, with a procedure around managing the blockers. QUESTION No.2: In your opinion, would integrating threat intelligence with specific industry-based business context help prioritize vulnerabilities based on their impact specific to critical infrastructure and ICS/OT operations? ANSWER: If your OT security program is rather mature with the basics covered very well, then you may be ready to incorporate threat intelligence. If you have the ability to ingest threat intelligence and act upon it (threat hunting, TTP specific use-cases and playbooks) then industry-specific threat intelligence will be a good tool in your OT security program. QUESTION No.3: How valuable do you find E/W network traffic based analysis, i.e. DarkTrace, et al? ANSWER: Monitoring East/West traffic is important for detecting lateral movement, especially for your OT crown jewel assets. Network security monitoring is important to consider if you don't have good enough OT endpoint visibility coverage and should include all North/South, Ingress/Egress points for your OT network as well. QUESTION No.4: How is the Purdue Model applied to segment and secure OT networks during incident response? ANSWER: The Purdue Model is a good discussion starting point for network classification, but I recommend following ISA/IEC 62443 or NIST SP800-82 Rev 3 for security segmentation best practices (IT/OT DMZ, OT zone specific firewalls, etc.). Segmentation should be designed BEFORE incident response and not DURING. If your IT and OT networks are not segmented during an incident response, you will likely have to manually segment the OT network to protect it and then during IR remediation, design an IT/OT DMZ based on the standard guidance above along with your OT Vendor/OEM secure architecture designs. QUESTION No.5: What are the key differences in incident response planning between IT and OT environments? ANSWER: You still follow the standard DFIR process (NIST SP 800-61r3 and NIST SP 800-86), but keep safety first and OT/ICS operations & constraints in mind (covered in NIST SP 800-82r3, section 6.4). I recommend you review my Blackhat 2016 talk on this exact subject (on YouTube) and my slides ( https://www.slideshare.net/slideshow/blackhat-usa-2016-whats-the-dfirence-for-ics/64706579 ) to see the key differences. Also, please review the DFIR Framework for Embedded OT devices here ( https://cloud.google.com/blog/topics/threat-intelligence/mandiant-dfir-framework-ot/?e=4875480 ). QUESTION No.6: What networking tools would you use to answer all of the questions? ANSWER: There is no perfect network tool to rule them all, and likely you will have to find the tools that your network folks and OT/engineering folks regularly use (especially OT Vendor/OEM tools such as Rockwell FactoryTalk AssetCentre, etc.) to start with. What gaps do those tools have? There are many free and professional/enterprise tools for monitoring OT networks out there (too many to list here). Several free network security monitoring tools that have both IT and OT capabilities are: Wireshark, NetworkMiner, Zeek, Suricata, and Snort. For a bigger list check this OT crowdsourced GitHub: https://github.com/ITI/ICS-Security-Tools/tree/master/tools/analysis . QUESTION No.7: Is 'Wireshark' is a popular tool for OT (environments)? ANSWER: Wireshark has over 20 OT protocol parsers, so it is a fantastic free tool for analyzing network traffic, troubleshooting network issues, and forensics for both IT and OT networks. QUESTION No.8: When it comes to assessing vulnerabilities or exploitable risks in ICS/OT operational environments (along with the critical nature of OT assets), what are operationally safe (best practice) methods for identifying vulnerabilities, enabling patching, and other mitigation efforts pertaining to the ICS/OT Industry? ANSWER: This can be a complex answer based upon your OT architecture and its dependencies and external connections. It starts with an asset inventory, especially of the systems that are most IT like (Windows, Linux, network devices) and the devices that are most exposed (to the Internet, to corporate networks, or to publicly accessible areas). All of these systems should be patched and hardened on a regular basis (whether you have to do this yourself or through your OT vendor). NIST SP800-82r3 has a framework for assessing and mitigating these types of risks, so each site or plant or OT network will likely have differences, but I would focus on the IT like "intermediary systems" first (we talk about this as the Theory of 99 in this blog: ( https://cloud.google.com/blog/topics/threat-intelligence/Mandiant-approach-to-operational-technology-security?e=48754805 ). QUESTION No.9: Can you comment on local log storage in ICS DMZ and log exports to cloud storage and analytics solutions from IR and overall RCA standpoint? ANSWER: Log storage is important part of your network security monitoring and root cause analysis strategy. Local log storage is important to analyze for all of your asset types (Windows Logs, Linux Syslog, Firewall Logs, and OT Device Logs (engineering and security). For NSM, a common rule of thumb is to have at least 120 days of netflow data and a 3-day window for full content data for critical network segments. If your OT device only has 255 rows in its error log, it will be good to know this so that those logs can be collected first before they roll over. Exporting logs to a SIEM in the cloud or on premise is a well-known best practice, but this could be a challenge for remote OT sites with low bandwidth or no external connections). NIST SP800-82r3 does cover logging strategies. QUESTION No.10: All of these recommendations make sense but how do you scale these recommendations when you have hundreds or thousands of PLCs, HMIs, etc.? Do you have some recommendations to streamline and automate it? ANSWER: If you have a large OT asset inventory, then you may need tools that can manage enterprise scale. OT Vendors/OEMs often have approved tools that already do this (Rockwell Factory Talk AssetCentre, etc.) or you can also look into ICS/OT network security monitoring vendors such as Nozomi Networks, Claroty, Dragos, etc. QUESTION No.11: Is patching legacy (MS) systems, something that could be automated, including anti-V? ANSWER: Patching Microsoft systems and Antivirus/Endpoint Agents can easily be automated with a whole host of different tools, however it's best to follow what your OT Vendor/OEM recommends. If you have an End of Support or End of Life system, then they cannot be patched you will have to design other mitigations to keep these devices from being exposed. QUESTION No.12: Are their any OT scenarios in which it might be practical to implement upgrades through incremental, parallel systems/solutions? ANSWER: Yes, for major upgrades it is common to implement the new OT system along side the old OT system and then perform the switch over to the new system, once site acceptance testing and commissioning is complete. Constraints are available space, field wiring and I/O cabinets, etc. OT Vendors often have solutions for these situations. QUESTION No.13: With the expansion of AI use, what are examples that you've seen so far of actors using AI or potential uses of AI tools used by an environment to carry out LotL or attacks on the environment? ANSWER: I personally have not seen any use of AI tools used by attackers in OT environments. However in general, attackers are leveraging AI for creating more believable spear phishing emails, voice phishing/vishing, and video/deep fakes. The FBI put out some details about this in December 2024 ( https://www.ic3.gov/PSA/2024/PSA241203 ) and Google Threat Intelligence Group published a blog this year about cybercriminals weaponizing websites using AI ( https://cloud.google.com/blog/topics/threat-intelligence/cybercriminals-weaponize-fake-ai-websites?e=48754805 ). QUESTION No.14: Ukraine in 2014, I believe it was blackenergy/killdisk on the UPS systems after recon on their system. How can we mitigate insider threat when neglect really opens the doors? ANSWER: Defense in depth is key for defending against targeted attacks including insider threats. Proper segmentation, tested backups, multi-factor authentication, and a well defined but not overcomplicated Incident Response Plan is critical to defending OT. For a compilation of lessons learned and protective actions you can do for targeted attacks, please review this Mandiant whitepaper: https://services.google.com/fh/files/misc/proactive-preparation-and-hardening-to-protect-wp-en.pdf . QUESTION No.15: Crypto mining is also a power hungry beast that has the capacity to harvest even supercomputer capability, and energy, this is happening everywhere. Will policy ever catch up? I mean energy and economics... scary. ANSWER: In the United States and around the world, large data centers, including those used by crypto miners, are being studied by the electric industry. There have been multiple studies in North America such as the NERC Large Load Task Force ( https://www.nerc.com/comm/RSTC/Pages/LLTF.aspx ) and others. NERC just put out an alert about this topic last week ( https://www.nerc.com/pa/rrm/bpsa/Alerts%20DL/NERC%20Alert%20Level%202%20%20Large%20Loads.pdf ). QUESTION No.16: Based on the "Theory of 99" do you see the threat landscape shift towards more OT based attacks increase by way of supply chain, nation state, AI, Wifi enabled devices and Cloud adoption? ANSWER: Theory of 99 referenced here: https://cloud.google.com/blog/topics/threat-intelligence/Mandiant-approach-to-operational-technology-security?e=48754805 . I don't see an increase of targeted OT attacks, but more of targeted IT attacks that indirectly or directly impact OT / production. Which is why I said ransomware is still the No.1 attack that impacts OT (even though it may not be a cyber-physical attack impacting embedded devices, as those attacks are rare). QUESTION No.17: If we already know that controllers and legacy system are vulnerable then why we need to go with penetration testing in OT? ANSWER: The goal of penetration in OT environments is to find and fix weaknesses in the IT (Windows, Linux, VMs, Network devices) that are at the perimeter of OT systems.  Attackers will target those intermediary systems first. So a penetration test is a real way to see if your cybersecurity mitigations, segmentations, and hardening are sufficient for the most common attacks targeting vulnerable remote services, weak firewall rules, weak server and workstation configurations etc. On career questions: QUESTION No.1: Hi Chris, I really enjoyed your work on the Mandiant DFIR Framework for OT. I’m very interested in this space and would love the opportunity to contribute, is there a way I could get involved with your team? ANSWER: We do not currently have any job openings on our Mandiant OT team, but we do often have Mandiant IR consulting roles open. Also Google DFIR team has roles open as well. We are also opening up Summer 2026 Internship applications now, so if you are a student, please submit! For any Mandiant or Google role, check out these helpful links: https://www.google.com/about/careers/applications/how-we-hire/ https://www.google.com/about/careers/applications/stories/google-internship-faqs/ QUESTION No.2: I see a number of people open to jobs ... What is the ICS/OT security job outlook and where does one go to find these? ANSWER: The best way to land an ICS/OT security job is to get involved with the ICS/OT community (online and in person). You can do this in multiple ways through ICS OT Security groups on LinkedIn, going to OT conferences (many have online options), and meeting other ICS OT folks. You can also build a small OT lab or try online OT capture the flag contests. There is a lot of OT training out there, for free and paid. Mike Holcomb has a lot of free training content on LinkedIn and YouTube ( https://www.youtube.com/playlist?list=PLOSJSv0hbPZAlINIh1HcB0L8AZcSPc80g ). There are many OT certifications out there, and the jobs you may want to apply for may list one or more OT cybersecurity certifications. A full list of security training including OT training is listed here: https://pauljerimy.com/security-certification-roadmap/ (see the column for ICS/IoT).

By Danielle Jablanski , Cybersecurity Consulting Program Lead at STV, & a (CS)²AI Fellow October 20, 2025 We hosted a (CS)²AI Fellow Fireside Chat on September 10, 2025 that focused on Building OT Capacity for IR and Pentesting with (CS)²AI Fellows Chris Sistrunk , Technical Leader of Mandiant (Google Cloud Security) and Danielle Jablanski , Cybersecurity Consulting Program Lead of STV . Here is a bit about the event: Operational Technology (OT) environments face unique challenges when it comes to incident response (IR) and penetration testing. As cyber threats continue to evolve, organizations must strengthen their capacity to prepare, detect, and respond effectively to incidents—while also proactively testing defenses to uncover vulnerabilities before adversaries do. Leading experts explored strategies, best practices, and lessons learned for building OT-specific capabilities in both IR and pentesting. Participants gained actionable insights into: Tailoring IR processes for OT systems Overcoming common pitfalls in OT pentesting Strengthening team skills and capacity to meet today’s threat landscape Leveraging industry tools and frameworks to build resilience This session equipped practitioners, defenders, and decision-makers with the knowledge needed to enhance security postures across critical infrastructure. Do you want to have access to more content like this? Register for our next (CS)²AI Online™ seminar or symposium here , or consider becoming a member of (CS)²AI to access our entire library of recorded sessions. The Q&A portion below represents selected overflow questions and commentary from the event, and has been answered in detail by Danielle Jablanski . ****************************** On topic questions: QUESTION No.1: When does hardening systems really become crucial in OT/ICS? ANSWER: Ask whether cybersecurity was a consideration during site acceptance testing. Hardening should be a consideration in any commissioning and rollout, as well as with configuration changes and any network management considerations. There are resources from OEMs to assist in hardening and configuration baselines for their systems as well as this resource for PLCs https://plc-security.com/ . Another good way to focus in is when to assign producers and consumers as well as physical port locks for the most critical systems. QUESTION No.2: In your opinion, would integrating threat intelligence with specific industry-based business context help prioritize vulnerabilities based on their impact specific to critical infrastructure and ICS/OT operations? ANSWER: In my opinion, it is more important to have a robust crown jewel analysis and interdependence mapping done and discussed with key personnel and management, and to consider scenarios that impact OT and the potential cascading effects based on this understanding before incorporating analysis of threat actor TTPs as means when your organization might not fully understand the effects of these attack patterns internally; see: https://nexusconnect.io/articles/throw-likelihood-to-the-wind-ot-cybersecurity-is-categorical-not-mathematical . QUESTION No.3: How valuable do you find E/W network traffic based analysis, i.e. DarkTrace, et al? ANSWER: I second Chris, and would add that some solutions for visibility of E/W do real-time diagnostics while others can keep a pulse and pull information and analysis as needed. Investing in visibility needs to include conversations around tuning and remediation efforts - if you are not doing anything about alerts don't invest in the tools yet: https://industrialcyber.co/features/implementing-intrusion-detection-in-industrial-systems-requires-visibility-resilience-and-regulatory-compliance/ . QUESTION No.4: How is the Purdue Model applied to segment and secure OT networks during incident response? ANSWER: PERA is useful for delineating your logical network mapping from your standard OSI model understanding, but it is not meant to be a hierarchy and is becoming increasingly limited when introducing additional edge devices and cloud applications, etc. - the zones and conduits model from 62443 is more adaptable to grouping systems based on different categories beyond network connectivity and segmenting based on function, for example. QUESTION No.5: What are the key differences in incident response planning between IT and OT environments? ANSWER: The key differences are in containment and remediation. For containment, you might not have the logging and tools for threat hunting to identify the extent of the breach and exploitation, and you may not be able to isolate systems and recover in a way that ensures the attacker(s) are out of systems and cannot regain entry to continue their exploits - this integrity problem is a main driver of compensating controls where patching, etc. may not be routine - more info: https://www.rsaconference.com/library/virtual-seminar/hds7-ot-ics . QUESTION No.6: What networking tools would you use to answer all of the questions? ANSWER: I don't publicly endorse tools but ping me privately and I am happy to unpack needs assessments and use cases! https://www.linkedin.com/in/daniellejjablanski/ QUESTION No.7: Is 'Wireshark' is a popular tool for OT (environments)? ANSWER: YEP! Here's a free PCAP analysis exercise: https://ampyxcyber.com/ics-pcap-analysis-challenge . QUESTION No.8: When it comes to assessing vulnerabilities or exploitable risks in ICS/OT operational environments (along with the critical nature of OT assets), what are operationally safe (best practice) methods for identifying vulnerabilities, enabling patching, and other mitigation efforts pertaining to the ICS/OT Industry? ANSWER: When writing OT advisories at CISA, we typically say remove internet connectivity, ensure network segmentation, and address remote access before patching, but I believe automated tools that do priority ranking for risk management are the best route to identifying vulnerabilities and reducing overall risk, though remediation efforts may not always result in patches. QUESTION No.9: Can you comment on local log storage in ICS DMZ and log exports to cloud storage and analytics solutions from IR and overall RCA standpoint? ANSWER: I agree with Chris, and another resource is https://www.cisa.gov/resources-tools/resources/best-practices-event-logging-and-threat-detection . QUESTION No.10: All of these recommendations make sense but how do you scale these recommendations when you have hundreds or thousands of PLCs, HMIs, etc.? Do you have some recommendations to streamline and automate it? ANSWER: Automation is the only answer for massive networks and distributed operations. Here's a recent publication on the basics though, https://www.cisa.gov/resources-tools/resources/foundations-ot-cybersecurity-asset-inventory-guidance-owners-and-operators . QUESTION No.11: Is patching legacy (MS) systems, something that could be automated, including anti-V? ANSWER: Some systems may not be compatible with updated versions of Windows and even some versions from OEMs are just now being rolled out for Windows 10 so auto updates may actually lead to incompatibility issues and knocking down systems. QUESTION No.12: Are there any OT scenarios in which it might be practical to implement upgrades through incremental, parallel systems/solutions? ANSWER: There are also fun ways to do things like re-IPing of systems with NAT that can be incremental as well so operations are not disrupted! QUESTION No.13: With the expansion of AI use, what are examples that you've seen so far of actors using AI or potential uses of AI tools used by an environment to carry out LotL or attacks on the environment? ANSWER: I agree with Chris, there are too many contingencies in OT currently to provide the type of repetitive learning and execution required, though this is an increasing concern for IT systems where routine exploits can easily be repeated and as Mandiant has proven, these intermediary systems can provide the access required to exploit OT. There are specific AI attack pattern mitigation strategies for OT here: https://www.dhs.gov/sites/default/files/2024-04/24_0426_dhs_ai-ci-safety-security-guidelines-508c.pdf . QUESTION No.14: Crypto mining is also a power hungry beast that has the capacity to harvest even supercomputer capability, and energy, this is happening everywhere. Will policy ever catch up? I mean energy and economics... scary. ANSWER: And we can't forget all the water it takes to cool them... big questions that are difficult to unpack but Andrew Bochman is someone to follow on this: https://www.linkedin.com/pulse/towards-grand-unified-theory-grid-risk-andrew-bochman-n2qkc/ . QUESTION No.15: Based on the "Theory of 99" do you see the threat landscape shift towards more OT based attacks increase by way of supply chain, nation state, AI, Wifi enabled devices and Cloud adoption? ANSWER: I see a trend of threat actors doing more research on native functionality for OT/ICS so that if undetected access is possible they do not need exploits to operate critical systems, similar to the LotL techniques from IT. QUESTION No.16: If we already know that controllers and legacy system are vulnerable then why we need to go with penetration testing in OT? ANSWER: Attack pattern analysis bridges the gap between TTPs and potential access & exploitation in a given environment. Doing these practices, it allows organizations to highlight and address risks to mitigate in the pursuit of continuous improvement, where efforts to avoid major downtime and improve for the mean time recovery for specific incidents can be sustainable and resilient.

By: Chris Humphreys Lead Cybersecurity Solutions Architect at Foxguard , (CS)²AI Fellow This week, I had the honor of presenting at the (CS)²AI Cyber Security for the Electric Sector Symposium . It was awesome to get some of the old band back together while also meeting new faces and hearing about the evolution of cybersecurity within the Electric Sector in a wide variety of complementary, yet differentiating, content. Derek Harp and his team were very clever and strategic in, not only gathering the content for this event, but also the sequence at which the presentations flowed.  The opening presentation by Phosphorus CEO/Founder Chris Rouland , was extremely insightful and provided an awesome view globally of the threat capability landscape-both present and future- to the Electric Sector and Industrial Control Systems space as a whole. His insights from his crystal ball on both where threat is headed and the technologies available to combat these threats were also really cool and informative.  Next up was PJM VP/CSO Steve McElwee . He gave a very complimentary presentation from an ISO/RTO perspective on how PJM addresses many of the threat vectors Chris Rouland mentioned in the previous presentation. Steve focused on how PJM looks at overall cyber risk through their maturity models and how they balance baselining that maturity with NERC CIP being the floor of their maturity and NIST being their ceiling. Steve also gave a great overview of how PJM fits and operates as an interconnection and the responsibilities associated.   I don’t know if Steve knew his content would fit logically as the middle of a “Chris Sandwich” as I would go next.  My presentation was another great transition by (CS)²AI from the previous two as I would leverage the global threat landscape from Chris Rouland's presentation and the ISO/RTO approach given by Steve and how Foxguard applies it to the specific challenges associated with Patch Management. Patch Management has been, since day 1 of NERC CIP, the most violated NERC CIP standard. I wanted to offer some ideas on why that continues to be the case. I focused on balancing the "3 legged stool” of people, process controls, and technology to create the synergies that are so often absent between compliance risk and operational cybersecurity risks. I also continued to highlight the massive challenge NERC CIP applicable entities face in balancing being compliant vs being secure.  Next up was an extremely interesting discussion on the rapidly evolving Cyber Insurance Industry moderated by one of my oldest colleagues and compatriots, Patrick Miller who is the CEO of Ampyx Cyber , along with Monica Tigleanu (Cyber Strategy Director/ BMS Group ) and David White (President/Co-Founder of Axio ). I’ve been tracking the trends in the Cyber Insurance industry for the last few years but the insight provided by Monica, David, and Patrick was extremely enlightening. They offered some great questions to ask when shopping/evaluating cyber insurance coverage options for electric sector organizations. While this is a newer frontier for the Electric Sector, I couldn’t help but feel like I’d seen a version of this movie before in that the cyber insurance industry seems to be another variable in measuring overall risk within an organization- much like the early days of the NERC CIP Standards. Additionally, the compliance/insurability vs security debate continues to evolve within the insurance verticals as well.  Last, but definitely not least, Alex Waitkus - OT Cybersecurity Architect for Southern Company - closed out the symposium with just an awesomely relatable and practical approach to addressing OT Cybersecurity Threat and Risk Mitigation. For Alex to be able to simplify how effective an entity like Southern Company’s architectures and methods are in addressing the OT side of cyber risk was extremely refreshing and should be equally encouraging to entities of all sizes that they can be equally as effective while being practical and sustainable. Alex and I both definitely subscribe to the “if my mother can understand my content- I’m good” approach to public speaking  and Alex absolutely nailed it! In closing, I wanted to again commend (CS)²AI for compiling such a great program of content- especially for a half day symposium. I can’t wait to see what they do in the future with an entire day…or two….or three…. www.LevelZeroConference.com

By: Steve Mustard , President & CEI of National Automation, Inc. & (CS)²AI Fellow, Khalid Ansari , Senior Engineer - Industrial Control Cybersecurity at FM Approvals and Jason Stiteler , Business Development Manager - IIoT & Cybersecurity at FM Approvals Following the (CS)²AI roundtable on March 5th, 2025, we had several audience questions that we didn’t have time to answer. We’ve grouped the questions into the following categories and provided some responses: ·      Questions about standards ·      Questions about people and knowledge ·      Questions about how certification works ·      Questions about new technology Questions about standards: What criteria do you base your standards on? Yes, especially for the IACS. ISA/IEC 62443 is a risk-based standard that has requirements defined in a consensus process by a group of more than 500 IACS subject matter experts from around the world, who work in all sectors and are asset owners, system integrators, product suppliers, consultants, and academics. Is this a national or international accepted standards like the ones in accounting for example? Or still in the process to acceptance? ISA/IEC 62443 is an international standard. The original editions of some parts were first published by the ISA99 committee in 2002. In 2010 they were renamed to 62443 and jointly published by ISA and IEC. IEC designated the series of standards as ‘horizontal’, meaning they are proven to be applicable to a wide range of different industries. The certification process evaluates conformity to this series of standards. Critical assets may need to be governed by National standard, now IACS vendor if they follow only IEC62443 will that be a problem? National IACS security standards, if they do exist, tend to refer to ISA/IEC 62443, for instance those in Qatar, Malaysia, and Saudi Arabia. In Europe the NIS2 Directive does not reference any specific standards but requires that organizations follow a risk-based approach to managing security. This can be demonstrated by conformity to ISA/IEC 62443. Considering how important ICS security is, shouldn't all relevant standards be available for free? (ISO and IEC aren't) Standards provide significant, but often unheralded, value to society and government. Many people are unaware that the global standardization system is a partnership between the public and private sectors – governments are not the owners of the documents, nor are they primary stakeholders in the process. If standards are made freely available, the cost to support their development must come from participation fees, which most standards development organizations (SDOs) keep intentionally low to encourage the broadest possible participation. In fact, it is free to participate in ISA standards development – this ensures that we have the maximum amount of technical expertise from all over the world. This model stands in contrast to the open-source standards environment where the end product is free, but the few major players who can afford to pay steep membership fees drive the technical work. By funding operations at least in part through sales and licensing of standards, SDOs can minimize barriers to qualified participation and maximize independence from entities seeking to influence the outcome for commercial or political reasons. Maintaining the current model for standards development keeps the system flexible and driven by the needs of the marketplace. The question implies that standards like ISA/IEC 62443 are a significant cost barrier. The truth is the cost is negligible to any organization that is involved in managing IACS security risk. Many organizations have access to standards through subscription services. Members of ISA get access to ISA standards. Annual ISA membership ranges from $15 for students, to $77 for eligible countries, and $154 for all others. There are so many legitimate ways to access these standards that we should stop asking why they aren’t free and instead focus on promoting and mandating them. Questions about people and knowledge: Most people in OT security they are not really expert at process and design engineering whatever industry they are working in, they just come up with checklist and they hardly go in-depth. This is a good point, and why formal conformity programs that are based on international standards are so important. Custom checklists are only as good as the input that goes into them, and there is very little chance of being able to compare results across industries or countries using such a method. I believe one better be good at understanding DCS, PLCs, networks and industry specific knowledge such as chemical engineering experience or degree if in industry. Provide you inputs please. Thank you Yes, very good point. People involved in IACS design, development, maintenance or conformity assessment need to have a good understanding of the operating environment, the safety and operational aspects, and a good grounding in instrumentation and control practices and technology. ISASecure® Conformity Assessment Bodies are mandated by the certification scheme to employ people with this broad skill base as well as IACS-specific experience so that they are able to do thorough evaluations. Are personnel trained? Are there only allowed device connecting? In the case of both questions, the answer is that the ISA/IEC 62443 series of standards includes requirements for personnel training and for the management of device connections (permanent, temporary, and remote). These aspects are evaluated during a conformity assessment. Questions about how certification works: Companies and asset owners often consider standards and compliance as additional cost and work. They sometimes limit compliance to producing the minimum set of documents.   How to counter that and ensure that the minimum controls are actually implemented even by smaller asset owners and operators? The ISA/IEC 62443 series of standards is risk based, which means it is possible for any sized asset owner or operator to choose the controls that allow them to manage their risk to tolerable levels. The standards series defines four levels of security, 1 through 4, that require progressively more controls to manage greater risk. The risk assessment process defined in ISA/IEC 62443-3-2 allows asset owners and operators to clearly quantify their risks and determine the appropriate response that suits their organization, rather than a generic set of controls that may be excessive or inadequate. The challenge with IEC 62443 standard is that the SL is based on the threat. If an organization threat profile is defending against Nation State, no product or system today exist that can have SL4. The best in the market today is SSA SL2? The ISA/IEC 62443 series of standards base SL-T (Security Level - Target) on risk, not threat. Obviously, threat is part of the risk equation, but it is not the only part. Consequence is probably the most significant element of risk for an asset owner. That said, the SL-C (Security Level - Capability) is defined in terms of protection against a given level of threat.  There are ongoing discussions in the joint ISA/IEC committee to review this approach. It is true that few components or systems have a certified SL-C of SL3 or SL4. However, an asset owner can have an SL-A (achieved) of SL3 or SL4 for their IACS by applying additional controls on top of the capability of the components or system. As noted in the roundtable, asset owners should demand higher levels of SL-C so that the additional controls they need to apply can be reduced. How do the vulnerabilities affect the products? Vulnerabilities offer opportunities for the bad actors to exploit them, leading to compromising of the product and potentially the larger system. Product vulnerabilities increase overall asset owner risk. Products are not the only element of an IACS that has vulnerabilities. Processes and people also have vulnerabilities. All of these need to be managed by a comprehensive risk-based security program. ISA/IEC 62443 identifies the controls that are needed to manage all of these risks. ISASecure is at component level, good, how do we achieve compliance of entire IACS which may involve multiple systems and who will certify that the system is compliant? ISASecure conformity assessment programs currently exist for product suppliers: Secure Development Lifecycle Assurance – SDLA; Component Security Assurance – CSA; System Security Assurance – SSA. A new program, Automation and Control System Site Assurance – ACSSA – is under development and will be launched in 2025. This will provide conformity assessment against the entire operational IACS environment. What leverage do I have as an asset owner to incorporate secure by design when purchasing complete control systems from an integrator? You have a lot of leverage as you are the customer. You can mandate that components and systems are certified to have a particular SL-C. In order to do this, you should perform a risk assessment in accordance with ISA/IEC 62443-3-2 and identify your SL-T for all zones in your IACS. You could make this part of the scope of the overall project. You can also require that service providers demonstrate conformity to ISA/IEC 62443-2-4. If you check today ISASecure website for Honeywell or Yokogawa SSA Certificate? It’s based on their architecture. which means Controller, application, communication card, network switches, and that’s all. While the actual deployment there are other systems and applications included as part of the system such as Advanced Process Control, PI, and others. These introduce new attack surface which make the certificate not valid or not enough. the SSA certificate need to clearly define the minimum system architecture that should be certified? Another example is the integration between BPC and SIS? this usually not included as part of SSA certificate? basically not in the scope of the certificate. Can the panelist shed some light on this? SSA certification requires that the product supplier provide reference architectures to be considered as in-scope during the assessment.  These architectures, ideally, would reflect the common architecture that gets deployed in the field. SSA certification evaluates the security capabilities of the product (SL-C).  It does not necessarily guarantee that all the security controls get configured and utilized when the system is deployed. When deployed in a wider IACS, the ACSSA would provide assurance that the complete IACS is conformant to ISA/IEC 62443. How does Update Management deal with the Secure Product Development Lifecycle? The secure product development lifecycle requirements (defined in ISA/IEC 62443-4-1) include update management. Providing timely and tested updates for vulnerabilities discovered in products are an essential part of the product’s lifecycle. Service provider requirements (ISA/IEC 62443-2-4) also include requirements in this area. What of the product dev lifecycle is typically made public? Product suppliers who achieve SDLA receive a certificate to confirm they are in conformance with ISA/IEC 62443-4-1. No product supplier specific details are made public. Can the panelists comment on the differences between (ISO) Common Criteria and the SDLA cert discussed now? There are some similarities in the approach between ISO/IEC 15408 and ISA/IEC 62443. ISA/IEC 62443 has been specifically designed to address the requirements of industrial automation and control systems whereas ISO/IEC 15408 is very generic, covering the security properties of IT products and systems. As for the methodology, under the Common Criteria, sets of desired security features are defined in various  Protection Profiles . An end-user may select a certain Protection Profile and request evaluation of a product against that profile. So, a Common Criteria certified product would very much depend on the Protection Profile that it was evaluated for, i.e., it would have only been evaluated for those security features that are defined in the Protection Profile. Whereas with ISASecure 62443 certification, all the Foundational Requirements are evaluated at the given Security Level. How will SDLA fit into DevOps and SAFe? Agile frameworks and concepts like DevOps and SAFe can be assessed against SDLA. The requirements are defined in ISA/IEC 62443-4-1. If a product supplier using DevOps and/or SAFe can demonstrate that it meets these requirements it can be certified. I heard from Andrew Kling the maturity level was removed from the latest SDLA certification Scheme? why? it used to be SDLA with maturity Level. Now, the maturity Level has been removed? ISASecure® does not indicate the maturity level on the SDLA certificate any longer. However, the maturity of the manufacturer’s organization is still assessed, i.e., the documented policies and procedures are consistently practiced, which would equate to ML3. Indicating the maturity level on the certificate had the potential of being misunderstood (and misused). For instance, an end user would see the SDLA certificate and may assume the organization is fully compliant with 62443-4-1 while not paying attention to the “ML” (ML1, for example) on the certificate. A Maturity Level 1 is where product development happens in “an ad hoc and often undocumented (or not fully documented) manner”. What are the biggest challenges you see as of today with deployment of OT scanning process within ICS? Especially since neither IEC 62443 nor NIST 800-82 explicitly require it; however, do recommend it as a comprehensive set of cyber programs? ISA/IEC 62443 does not typically mandate any particular product or method. It is a risk-based series of standards that defines controls and methods to manage security risk in IACS environments. Asset owners may choose to use products or techniques to inform them or support them in identifying vulnerabilities for risk assessment or testing controls as part of implementation. Those products and techniques will change over time, but the overall objective – to manage risk – will not change. With the proliferation of such tools in the market, it may be tempting to consider them a silver bullet—which there is none of in cybersecurity. Questions about new technology: How is influence of AI so far in OT industry? Generally speaking, AI is being used in various aspects in OT, from GenAI analyzing documents, through to ML for predictive maintenance. In OT security, AI plays a part in threat detection and is widely used by SOCs. ISAGCA will soon be publishing a report on a study on AI risks in critical infrastructure. I'd be interested in hearing how IT/OT employees are using AI in their day to day now whether you're in manufacturing, or utilities, or transportation. And with AI, does that help with Cybersecurity? See above response. AI can help by reducing the burden on people, freeing them up to do more targeted activities. Where are you guys relative to the broader market motion around Post Quantum Encryption - has this kept into the discussion yet? Post quantum encryption will change risk profiles for asset owners. They should be regularly re-assessing their risk, taking into account changes in threats, vulnerabilities, and consequences. As a result, an asset owner who is conformant with ISA/IEC62443 will be adjusting their controls as needed to manage any change in risk. If you need more information or have any additional questions related to these topics, please contact Jason Stiteler (FM Approvals, Business Development Manager, Industrial Control Cybersecurity) at jason.stiteler@fmapprovals.com .

By: Brent Huston , CEO, virtual CISO & Security Evangelist MicroSolved, Inc. and (CS)²AI Fellow Introduction For industrial control systems (ICS) and IoT devices, the prevalence of counterfeit or recycled electronic components is a serious threat, with wide-ranging consequences. Examples from the last decade alone demonstrate the critical nature of this issue: counterfeit components have caused failures in hydroelectric dams, medical devices, and even military systems. Beyond functional risks, counterfeit components bring a host of security vulnerabilities, posing new risks as device complexity and reliance on global supply chains grow. With increasing regulatory scrutiny and guidance from ISO, NIST, and CMMC frameworks, it’s essential for device manufacturers to understand and implement effective, practical protections against counterfeit components. Below, we have identified a set of cost-effective, time-sensitive best practices that can help manufacturers manage the risks of counterfeit components in their supply chains, from sourcing through authentication and risk management. Although aimed primarily at ICS and IoT device production, these insights apply to the broader electronics manufacturing space. 1. Supply Chain Management: Building a Trusted Vendor Network Work with Authorized Distributors and Manufacturers: Whenever possible, restrict sourcing to authorized channels. Partnering directly with component manufacturers or their authorized distributors minimizes exposure to fraudulent parts. Maintain an Approved Vendor List (AVL) with Regular Audits: An AVL should include only trusted suppliers who meet security, quality, and compliance criteria. Conduct regular audits to verify that these suppliers uphold sourcing and quality standards. Implement Chain of Custody Tracking: Adopt tracking mechanisms that maintain clear visibility into the journey of each component, from origin to delivery. For components that travel through multiple subcontractors, blockchain or digital ledger technology can add an additional layer of tracking and transparency. Require Documentation of Origin: In your procurement contracts, include requirements for documentation showing component origin and handling. This practice is particularly important for high-risk components and for devices subject to regulatory standards. Incorporate Anti-Counterfeit Clauses in Contracts: Set clear anti-counterfeit requirements within contracts. Specify penalties for any counterfeit part supplied, and ensure suppliers understand these contractual standards. 2. Technical Verification: Strengthening Component Authentication Incoming Quality Control (IQC) Inspections: Implement an IQC procedure that includes both visual and technical inspections. Establish baseline quality metrics for all components upon arrival. Detailed Visual Inspection Under Microscopy: Visual inspection can reveal telltale signs of counterfeits, such as markings inconsistencies or tampering. Use high-resolution microscopy to detect anomalies, especially on date/lot codes and other identifiers. X-ray Inspection for Internal Verification: X-ray inspections allow for a non-invasive look at the internal structure, making it possible to identify discrepancies without damaging the component. This is particularly useful for ICS and IoT devices, where critical components might need additional scrutiny. Electrical Testing and Parametric Validation: Conduct electrical testing to confirm that components meet original specifications. Testing protocols should include voltage, current, and parametric checks, comparing results against manufacturer-provided values to catch counterfeit components. Chemical and Decapsulation Testing (Sample-Based): Chemical analysis and decapsulation are destructive but valuable techniques for high-risk or high-value components. By exposing internal materials, manufacturers can verify authenticity based on material consistency and construction details. Scanning Acoustic Microscopy (SAM) for Die Inspection: SAM allows manufacturers to look at internal die structures without destruction, providing another layer of verification for die-related authenticity and quality. 3. Authentication Methods: Ensuring Component Authenticity Require Certificates of Conformance: Only source components with verifiable Certificates of Conformance (CoCs) from manufacturers. Cross-reference these certificates against known component data for additional assurance. Verify Date and Lot Codes: Regularly cross-reference date and lot codes on incoming components with the manufacturer's records to catch any inconsistencies, especially for high-value or long-lead-time parts. Check Component Markings Under Varying Lighting Conditions: Counterfeit components often lack quality in their surface markings. Using different lighting angles and wavelengths, conduct visual inspections that reveal anomalies in engraving or printing quality. Document and Photograph Reference Samples: Establish a reference library of genuine parts to compare against incoming stock. Regularly photograph and document samples of genuine parts, as these records provide an effective benchmark to detect counterfeits. Use Component Authentication Tools: Many manufacturers now provide proprietary tools or apps to verify components. These tools often rely on secure authentication codes or embedded micro-tags and offer an additional layer of verification. 4. Risk Management: Building Resilience into Manufacturing Operations Conduct Regular Supplier Audits: Periodic audits are essential to verify supplier practices. In addition to financial and contractual audits, include inspections focused on quality control and anti-counterfeit measures. Maintain a Counterfeit Incident Log: Tracking known counterfeit incidents provides insight into trends and high-risk sources. Shared intelligence from industry groups (such as industry-specific ISACs) can further enhance this log, helping the industry respond collectively to rising threats. Share Intelligence with Industry Partners: Proactively sharing information about counterfeit sources and high-risk suppliers within industry groups enhances overall security. Collaborative intelligence sharing can reduce counterfeit activity across industries. Develop Contingency Plans: In cases where suspect components are found, have contingency protocols in place. This can include alternative sourcing options, production adjustments, or design revisions to avoid manufacturing delays. Create Quarantine Procedures for Suspect Components: Set up a process to segregate potentially counterfeit components from legitimate stock. Ensure there’s a protocol for isolating suspect parts until further verification can confirm or rule out authenticity concerns. 5. Component Selection and Design: Reducing Counterfeit Risks through Strategic Design Design with Commonly Available Components: Whenever possible, design products with components that are readily available and widely sourced. This reduces dependence on hard-to-source components, which are often prime targets for counterfeiters. Avoid End-of-Life (EOL) Components: EOL parts pose significant counterfeit risks due to scarcity. Proactively monitor component lifecycles and design with current-generation parts to reduce reliance on EOL inventory. Maintain Buffer Stock of Critical Components: Stocking critical parts reduces the need for last-minute purchases from unknown suppliers, lowering the risk of introducing counterfeit components under time pressure. Consider Built-In Authentication Features: For critical ICS and IoT devices, consider designing products that incorporate built-in authentication capabilities. RFID tags, microdot technology, or secure microcontroller-based validation methods can help distinguish genuine components from counterfeits. Conclusion Given complex supply chains and global component demand, the risks associated with counterfeit electronic components are pervasive and costly. By implementing these protective measures across supply chain management, technical verification, authentication, and risk management, manufacturers can substantially reduce their exposure to counterfeit risks without incurring prohibitive costs or delays. The key lies in prioritizing high-impact, cost-effective practices that align with ISO, NIST, and CMMC standards—establishing an end-to-end protective strategy that secures components before they impact production and, ultimately, the integrity of ICS and IoT devices. For manufacturers, the stakes could not be higher: compromised ICS and IoT devices don’t just endanger the systems they control but can lead to severe safety, security, and financial repercussions. As the industry continues to face rising counterfeit threats, proactive and practical countermeasures are essential to safeguarding today’s devices—and the infrastructure and lives that depend on them. Additional and reference resources: ISO 9001:2015 - Quality Management Systems ISO 28000:2022 - Security and resilience — Security management systems — Requirements Semiconductor Industry Association (SIA) Reports and Policy Documents International Electrotechnical Commission (IEC) Standards ISO/IEC 20243-1:2023 - Information technology — Open Trusted Technology Provider Standard (O-TTPS) National Counterintelligence and Security Center (NCSC) - Supply Chain Security Guidelines; Office of the Director of National Intelligence https://www.dni.gov/index.php/ncsc-what-we-do/ncsc-supply-chain-threats https://www.dni.gov/files/NCSC/documents/supplychain/Risks_From_Foreign_Adversarial_Exposure.pdf "Global E-Waste Monitor 2020" – United Nations University, International Telecommunication Union, International Solid Waste Association, 2020 CMMC Guidance - https://dodcio.defense.gov/CMMC/ AI research tools used to gather, analyze, and correlate various meta-data from research documentation and studies: ChatGPT, Claude, and Perplexity *************** If this blog post is of interest to you, consider attending our Manufacturing for Cybersecurity on December 4 at 1:00PM ET. Free Online Register Here More Information: For more information or assistance with these controls, please feel free to contact: Brent Huston, MicroSolved, Inc. bhuston@microsolved.com +1.614.351.1237 www.microsolved.com Blog: stateofsecurity.com

By Steve Mustard, PE, CAP, GICSP (CS)²AI Fellow October 8, 2022 I’ve recently had a book published, titled Industrial Cybersecurity Case Studies and Best Practices. The book is my attempt to summarize all that I have seen and learned about in industrial cybersecurity in the past two decades. I feel that we have made progress since the early 2000’s, but I still feel we have a way to go before we are fully managing our collective industrial cybersecurity risks. Some sectors are doing better than others, but every facility I’ve ever visited has multiple vulnerabilities. Even the most modern greenfield facilities include inherent vulnerabilities that could have been removed with the right processes and procedures in place. Much of what I have seen in my travels relates to failures of people and process. The cybersecurity profession responds to the challenge by offering more technology, but technology can only do so much to cover up failures in people and process. On a positive note, the industrial environment offers established practices and culture around safety that can be readily adapted to manage cybersecurity. The book covers several areas including: Measure to Manage Risk - Now that organizations have a better understanding of the difference between industrial cybersecurity and IT cybersecurity, there is an opportunity to apply existing proven industrial risk management practices. The use of statistical methods can provide a more reliable estimate of the likelihood of a cybersecurity incident. This more reliable estimate can be used to better identify the risk reduction needed to manage the risk to as low as reasonably practicable (ALARP). The use of existing tools such as bowtie diagrams can help to elevate the significance of controls needed to maintain a secure industrial facility. Standardized designs and Vendor Certification - I believe one of the biggest opportunities to improve cybersecurity in industrial facilities is with better design practices. The Purdue hierarchy has been a mainstay of automation and control systems for 30 years and is utilized in the ISA/IEC62443 series of standards when considering cybersecurity of these systems. In recent years the applicability of the hierarchy has been called into question. In fact, the Purdue hierarchy remains as essential to automation and control systems design as the OSI seven-layer model is to network design. Certification is not the only answer to effective cybersecurity, but it does drive improvements in design and development, and it does provide an independent level of assurance. The Pitfalls of Project Delivery - Despite the widespread awareness of the cybersecurity threat and the availability of standards, certified products, certified professionals, and collective experience, systems are still being deployed that lack the most basic security controls. In addition, the projects themselves create additional security vulnerabilities due to poor training, awareness, and oversight among personnel. In addition, a focus on efficiency and cost reduction means that many of the duties involved in managing cybersecurity are added to existing workloads, rather than to dedicated professionals with the right mix of skills and knowledge. What We Can Learn from the Safety Culture - Visit any OT facility today and you will likely find several obvious cybersecurity policy violations or bad practices. Even in regulated industries, compliance with cybersecurity regulations is, at the time of this writing, not where it should be. NERC, for instance, continues to fine companies that fail to follow its cybersecurity regulations. Human behavior must be understood if organizations are to provide good awareness training for their employees. Additional controls can be deployed to minimize the consequences of such mistakes, but effectiveness varies. Safeguarding Operational Support - Safety is a major concern in industrial environments, yet cybersecurity, despite being a potential initiating cause in these hazards, is not respected in the same way as safety is. Many organizations begin meetings or presentations with the refrain that safety is the number one concern. But in those same meetings, there may be comments to the effect that “We have more important priorities than cybersecurity.” Clearly, there is still much to do before cybersecurity receives the attention it requires in operational environments. I hope that the book adds to the body of knowledge and can help others with our collective mission of improving industrial cybersecurity. You can read more about the above topics in a series of posts on the ISAGCA blog.

By Steve Mustard, PE, CAP, GICSP, President & CEO of National Automation, and past president of the International Society of Automation, (CS)²AI Fellow May 8, 2024 Following the webinar on January 31st 2024, I received the list of audience questions and comments. We did get into some of them in the session, but there was not time to address the vast majority. I grouped all the questions and comments into these broad categories so I could comment: Standards in general ISA standards Risk assessment How to apply ISA/IEC62443 Workforce development Conformance assessment Standards in general When discussing standards for anything, two comments always come up, and rightly so. The audience said it better than I could: “Security is more than just ticking all of the boxes” “Standards are inherently a lagging activity” One audience member gave additional comments on the first point: “Security and compliance are not equal to each other, we have to remember that Security is a process, that evolves overtime, therefore best using a framework that includes the concepts of continuous improvement, audit and change to continuously improve Security. Align Security with the Business, and the business outcome, as business becomes more agile (Industry 4.0), security needs to be built for agility.” All of this is true. No standard, ISA/IEC62443 included, can provide 100% security. As noted, security is an evolving situation. A common mistake for asset owners is to think they can invest one time in a cybersecurity management system and then forget about it. The ISA/IEC62443 cybersecurity management system requirements defined in ISA/IEC62443-2-1 recognize this, and include performance measurement and audits, as well as a continuous process of “assess, implement, and maintain”. Likewise, someone else said: “Being compliant doesn't necessarily mean that you're secure; being secure (risk reduced to an acceptable level) doesn't imply that you’re compliant to regulations. But in my view the latter should always prevail, compliance should not be the goal it should be a ‘by product’”. The key to ISA/IEC62443 is indeed to implement a risk-informed solution and recognizing that an organization can only reduce the risk to as low as reasonably practicable (ALARP), not zero. Regulations, by nature, are the minimum level that must be achieved by all. ISA/IEC62443 defines multiple security levels that align to varying degrees of risk, allowing for more security where needed, and less security when not necessary. Back to the second point, expressed by someone else like so: “Standards are inherently a lagging activity.  Vendors only want to collaborate on standards when they enable the market to grow in some way, otherwise they much prefer the monopoly rents associated with proprietary offerings.” There’s certainly plenty of examples in the automation and control space of vendors enjoying the benefits of proprietary solutions, for instance with their own communications protocols. I think this is much harder to achieve with security. I always use the analogy of hazardous equipment design, since the objective is similar – one to reduce the likelihood and consequence of an ignition source in a potentially explosive atmosphere, the other to reduce the likelihood and consequence of a threat exploiting a vulnerability in a control system. Vendors can’t really come up with their own proprietary security solutions any more than they can come up with their own hazardous equipment solutions. In my view, conformance to security standards is a way to increase product sales. Products that meet ISA/IEC62443-4-2 from vendors that meet ISA/IEC62443-4-1 are not only objectively more secure, but evidence shows they are more reliable. Questions about ISA standards There were a few questions in this category, some easy, like this one: “Where does the ISA 62443 standard vary from the IEC 62443 standard?” The ISA version of the standard, ISA99, is identical to IEC62443, so ISA99-01-01 is the same as ISA/IEC62443-1-1 and so on. This question came up too: “Is Steve aware of a reference that maps 62443 to other frameworks like NIST 800-82?” I don’t know of any official mapping, but I have seen people do their own. I think te best “official” mapping is in the NIST Cybersecurity Framework, which lists normative elements in ISA/IEC62443 alongside similar statements in the NIST 800 series, CSC, COBIT, and ISO 27001, like this: Someone else asked a very reasonable question: “I always like to ask what alternatives there are to 62443?   Are there other models or frameworks or assessments ?” And someone asked something similar: “For an OT operator, why having so many standards/documents (too complex) and why not go with a single one, like NIST SP 800-82 instead?.” I think it’s true to say that the security profession is not short of frameworks, guides, or methodologies. I believe one of our problems in the control systems world is that we still haven’t converged on one single standard. Everywhere I go I see people doing things in different ways. Different can be good, but not when it is incomplete or more subjective. For example, in the insurance space, brokers still create their own checklists to assess an organization’s security posture. How can an insurer be confident that one checklist is as good as another? Other guides cover aspects such as technical controls, policies, procedures, and training. Assessments can be used to check for gaps, and other risk assessment guides can be used. Any organization can use any methodology they feel is appropriate. I would argue that if you are going to choose one then choose the most comprehensive one and choose one that is internationally recognized. Even if the asset owner is limited to one country, vendors and service providers are rarely tied to one geographic region and don’t want the time and expense of responding to multiple sets of requirements. ISA/IEC62443 is the only international consensus-based series of standards for industrial automation and control systems security. It addresses every aspect of security, from governance, policies, procedures, training, as well as the risk-based implementation of security controls. As already noted, ISA/IEC62443 won’t make anyone 100% secure, nor will it keep anyone secure if they stop following it after implementation. Someone asked this about the ISA committee producing this series of standards: “How do you staff up for this standard? Is there a single coordinator or a committee?” The ISA99 committee has two co-chairs (volunteers) and staff administration. It is broken down into multiple working groups and is run in accordance with ANSI requirements for standards development organizations (SDO). The following link provides more information about the committee and how to get involved or find out more: https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa99 Someone else asked a similar question to ones earlier about the slow pace of standards development: “Steve-is there any thoughts how to balance getting input from a global ISA community to develop high quality standards while getting them out in a more timely manner to consume? For example, it's very exciting that IIoT standard is being crafted but in my opinion, this standard would have been more timely when IIoT started to become an emerging trend years ago.” Producing standards in accordance with ANSI/IEC/ISO requirements takes time, and there’s no getting round some of the steps required to ensure a true consensus-based result. Having said this, I would say that since the foundational parts of ISA/IEC62443 were published, new elements have been created much more quickly. One of the important things to emphasize about the series of standards is that it is intentionally vendor- and technology-agnostic. Requirements in ISA/IEC62443-2-1 and ISA/IEC62443-3-2 are fundamental and apply regardless of whether it’s IIoT that we are considering – for instance the principles of risk assessment are unchanged even if the technology changes. In my view, the way that ISA/IEC62443 standards can be produced more quickly are: Have asset owners demand that their vendors and service providers meet consensus-based international standards. A common set of requirements is attractive to vendors and service providers as it makes their work responding to proposals easier. Asset owners will be better able to compare offerings based on objective measures such as Security Level. Have vendors and service providers coalesce around ISA/IEC62443, in the same way they have around IEC61511, IEC61131, ISO27001, and so on. The work will still have to follow the necessary processes but all the effort that goes into creating competing guides and checklists can instead be directed to accelerating a common consensus-based international standard. Questions about risk assessment I mentioned in the session that I believe risk assessment is the biggest issue in control systems security. Look at all the checklists and methodologies. Almost all focus on gap or vulnerability assessment. Ask a vendor and they’ll tell you what vulnerabilities their product addresses. Vulnerability is an important part of security, but it is only one part of the risk equation: Risk = Threat x Vulnerability x Consequence In the risk assessment process we convert Threat x Vulnerability to Likelihood so the equation becomes: Risk = Likelihood x Consequence Then we plot the risks on a matrix like this: In my experience, very few people do the risk assessment process. If they do, they create their own security risk method or matrix. This is a recipe for having security risks ignored. Leadership will assume that you are taking care of that stuff and they’ll continue to focus on their business risks, which are plotted on a matrix like the one above. Someone in the audience pointed to this academic paper, which recommends caution with the use of risk matrices: https://www.researchgate.net/publication/310802191_What's_Wrong_with_Risk_Matrices_Decoding_a_Louis_Anthony_Cox_paper The article focused on the mathematical and logical limitations of risk matrices as sources of information for risk management decision making and priority setting. In short, the concern is “how can you guarantee your estimate of likelihood or consequence is correct?” which is a valid point. In my book Industrial Cybersecurity Case Studies and Best Practices (https://www.isa.org/products/industrial-cybersecurity-case-studies-and-best-pra) I dedicate an entire chapter to this issue. I identify many methods to systematically determine likelihood (e.g. Monte Carlo Simulation and Bayesian Analysis). The results of any method are only as good as the inputs. Ultimately no-one is looking for a precise answer (99.82% likelihood that it will cost $1,203,420), but a justifiable, repeatable indication of the risk that can be used to compare against other risks determined using the same method. The other thing that people do wrong if they do risk assessment is misunderstand what consequence means. This member of the audience made this point: “Something that I think is missing in the standard and could be there in -3-2 is the relevance of a Business Impact analysis for the IACS High-level risk assessment. Such a BIA might point you to the crown jewels.” In fact, it is defined in ISA/IEC62443-3-2 that consequence is the business impact, measured as things like physical safety, environmental impact, financial, production, regulatory, or reputation. And identifying the crown jewels is exactly why this is important. Once you identify the crown jewels, then you create your zones and conduits to protect them. Someone suggested: “In my opinion it would be better to start with your risk assessment and work from there.” And this is also what the ISA/IEC62443 defines. Initial- or high-level risk assessment is the first step in the process: As I mentioned in the session Jim McGlone and Ed Marzal explain perfectly in Security PHA Review (https://www.isa.org/products/security-pha-review-for-consequence-based-cybe-1) how to conduct a process hazard analysis (PHA) and incorporate security into that process, rather than create a separate process with different consequences. Since we are talking about this book, I’ll address another comment from the audience related to the book’s concept of unhackable controls or, as the book defines them, non-hackable safeguards. In my explanation of the cyber PHA process, which considers whether causes are hackable, and then whether safeguards (controls) are hackable: The aim is to identify at least one non-hackable safeguard so that if the programmable electronic equipment is compromised the consequence is avoided. I said that controls like firewalls are programmable electronic equipment so, although they are important controls in defense in depth, they are still hackable and there is still a need to for a non-hackable control. Someone in the audience asked: “What about Waterfalls products? They claim they are unhackable?” This is a good question, because data diodes/unidirectional gateways like Waterfall produce have one-way communications based on physical means, not software. However, Jim and Ed define non-hackable safeguards (or controls) as those that “are typically simple mechanical devices that have been in use in industry for hundreds of years.” The book gives examples such as pressure relief valves, mechanical overspeed trips, check valves, buckling pins, and rupture discs. The common theme of these is that they are not dependent on any software, electronics, or in many cases, power to function. The reason why this is important is also that the data diode is a preventive control, not a mitigating control. This is best understood by looking at a bowtie diagram: This simplified diagram shows preventive controls, or barriers/safeguards on the left of the cybersecurity incident. They are in place to reduce the likelihood of the incident. Firewalls and data diodes are typical preventive controls. The barriers to the right of the incident are mitigating controls. These reduce the consequence of the incident when it occurs. Mechanical failsafes are a typical mitigating control. In the control systems world, it is essential to understand the need for both types of control, and not rely only on preventive controls. Another point to note is that it is becoming more common to use electronic protection devices, and the cyber PHA process helps inform how to do this while ensuring a well-considered set of preventive and mitigating barriers is in place. One of the unique things about ISA/IEC62443 is that it is a risk-based approach. There were some questions about this from the audience: “Are there any special cybersecurity risk assessments techniques as it is for 61511?” “What I'm missing so far is the concept of Security Level Target (SL-T) and Security Level achieved (SL-A) (SL-C based on -4-2)” “How critical it is to define threat vectors in Risk Matrix for the assessment? A calibration wrt is needed?” ISA/IEC62443 does not specify how risk assessments should be done. It states that a risk assessment process needs to be defined and used. This is where it is important to use the organization’s existing methodology. Doing so will ensure that security risks will be considered at the same level as other business risks. The principles of risk assessment set out in ISA/IEC62443 are derived from long standing risk assessment processes defined in other standards such as IEC61508 and its derived standards such as IEC61511. In ISA/IEC62443, after the initial (or high-level) risk assessment and assignment of zones and conduits, there is a detailed risk assessment. In that stage it is essential to identify the threat vectors, as well as vulnerabilities and exploits. How to apply ISA/IEC62443 It is not unusual to assume that ISA/IEC62443 may not apply to a sector, technology, or process. In fact the series of standards is written to be independent of sector, technology, or process. The audience asked some interesting questions related to the series of standards: “How can Bacnet /ip or sc be modified to be conformant with 62443-3” ISA/IEC62443 defines a series of security requirements in seven foundational requirement areas: Identification and authorization control Use control System integrity Data confidentiality Restricted data flow Timely response to events Resource availability Some of the requirements will apply to the protocol (or its deployment) and some of the requirements will apply to devices, systems, and process and procedures around the protocol. The security capabilities of the protocol will inform what additional controls, if any, need to be in place to achieve a particular desired Security Level Target (SL-T). “I work for a company that supply things like vehicles, these products have a set of assets that make it up, and won't change for say 5 or 10 years, so would you treat them different to a nuclear plant for instance? Does 62443 work for these, ISO27001 does not, or is there something better?” ISA/IEC62443 can be applied to any of those examples. The basic principles of ISA/IEC62443 are as follows: Define a cybersecurity management system to ensure that cybersecurity is managed throughout the lifecycle of the asset (whatever that asset might be). Define and implement a risk assessment methodology and identify the risks related to the asset. Define the Security Level Target (SL-T) for the asset and then identify the controls needed to meet that SL-T. The requirements defined in ISA/IEC62443 recognize the unique nature of OT environments. For example, the focus on availability/safety versus data confidentiality found in ISO 27001. “Thank you for a great presentation. Do you have some preferred references for handling non-employees/externals in OT environments?” ISA/IEC62443-2-4 (Security program requirements for IACS service providers) provides requirements for third parties involved in systems integration, product supply, and maintenance. These include requirements for staffing, assurance, architecture, configuration management, remote access, event and account management, malware protection and patch management, and backup and restoration. These requirements would apply during project and operations phases. “Does the cloud fit into the zone and conduits model? Is it a new zone? Or does it, for example, appear in the Plant A Supervisory Control Zone?” In ISA/IEC62443 the cloud would likely be its own zone. The connection between other zones and the cloud would be defined as conduits. The creation of the cloud zone and related conduits would take into account what function it performed (e.g., condition monitoring) and what data was required to perform this function. However, the creation of zones and conduits is not prescribed. The ISA/IEC62443 series of standards defines some requirements for zones (e.g. separate safety zones, separate wireless zones, etc.) but otherwise users can define zones how they see fit to manage their security risk. “The zones & conduits concepts seem to share some parallels with the ministry of Defence domains, islands and causeways from Domain Based Security (DBSy) from the late 90s and the later government IS1. was the DBSy approach any inspiration, is it just coincidence, or is it my misinterpretation?” There are some similarities between zones and conduits and the DBSy concept. A domain in the DBSy concept is a logical place where people work with information using a computer system. A Zone in ISA/IEC62443 is a logical grouping of physical, informational, and application assets sharing common security requirements. One of the main inputs into the zone and conduit model was the Purdue Enterprise Reference Architecture (PERA) in which end users, integrators and vendors share in integrating applications at key layers in the enterprise, including the industrial automation and control system environment. Understanding how to use the concepts of PERA, zones, and conduits is fundamental to creating a secure and reliable architecture, and it is one of the areas that I see is most often misunderstood. “Are networked sensors and actuators components of a control system required to meet component level security requirements?” ISA/IEC62443 defines requirements for embedded devices, host devices, applications, and network devices. An embedded device is defined by the series of standards as “special purpose device designed to directly monitor or control and industrial process.” So if a user wishes to require that all devices, including networked sensors and actuators, are ISA/IEC62443 conformant, then they would need to meet the relevant requirements. “How applicable are the standards to non-OT/ICS systems, such as telecoms systems like access control, CCTV, radio that support operations but are not quite IT, but not OT either?” The principles of ISA/IEC62443 can be applied to any system that has an impact on the real or operational world. The risk assessment process identifies the consequences of failure of the system, and this helps inform what the security level should be for the system. This in turn identifies the security requirements needed to meet that security level. “How do you determine SL for a system?  How does the SL relate to the risk matrix and is there a standard way to determine the SL of any given system?” The ISA/IEC62443 process is to assign security level to each risk level. Consider the risk matrix earlier. The associated SL-T would be as follows: Workforce assessment Some members of the audience asked questions about how to ensure that we could ensure people are trained in this important series of standards. For example: “How can individual professionals obtain the standard and qualify themselves if they are not tied to a company that has purchased the standard?  If there is no other way, how will the workforce be developed?” Individual professionals can access the standards documents as members of ISA (as well as obtain discounts on training and publications). Membership of ISA (https://www.isa.org/membership), like membership of CS2AI (https://www.cs2ai.org/plans-pricing), costs very little. In fact, membership of both ISA and CS2AI will cost around $5 per week total. If industry professionals are serious about working in this space, I believe they should be prepared to invest this nominal sum. “This a huge toolkit of guidance - are there courses now routinely required in engineering schools teaching young engineers about all this?  Thx - great presentation! :-)” ISA provides training in the series of standards, and a certificate program for those who wish to demonstrate their competence across the entire security lifecycle (https://www.isa.org/certification/certificate-programs/isa-iec-62443-cybersecurity-certificate-program). Various programs exist to help improve student awareness of control systems security. A two-year associate degree program in mission critical operations was developed by the US Department of Labor, and a certification exists for those who wish to demonstrate their knowledge in this area. A study guide is available for those wishing to take the exam (https://www.isa.org/products/mission-critical-operations-primer). The US Department of Labor also provides the Automation Competency Model (ACM - https://www.careeronestop.org/competencymodel/competency-models/automation.aspx), to which ISA subject matter experts contribute. This model defines the key skills, knowledge, and abilities that automation professionals need from entry level to advanced career level and is updated regularly to ensure that emerging technologies are included, recognizing that the automation profession is constantly evolving. One of the key blocks of skills, knowledge, and abilities relates to control systems security. Conformance assessment One of the important aspects of an international consensus-based standard is that it is possible to demonstrate conformance with the standard. Since ISA/IEC62443 is a series of standards covering different elements of the security lifecycle, there are different conformance possibilities. Audience members asked several questions related to conformance. First: “Is there a device certification for 62443 similar to the UL rating in the US?” ISA/IEC62443-4-2 defines requirements for IACS components. Requirements are defined for embedded devices (PLCs, RTUs, IEDs), host devices (servers, workstations), network devices (routers, switches, firewalls), and applications (DCS, SCADA, historian). Some requirements are common across all categories, and some are specific to the category. As with system security, there are security levels defining progressively more comprehensive requirements. Vendors can obtain a certificate of conformance to ISA/IEC62443-4-2 for their component by having it assessed by an independent test lab. One of the pre-requisites is to have conformance to ISA/IEC62443-4-1, secure product development lifecycle requirements. Another good question, highlighting that ISA/IEC62443 is not just about product security requirements: “Are suppliers or operators/integrators certified?” ISA/IEC62443-2-4 defines requirements for IACS service providers, including integrators, product suppliers, and maintenance providers. An evaluation methodology is being produced that will allow these service providers to obtain conformance to ISA/IEC62443-4-2. A separate program is under way to develop a conformance program (IACS Security Assurance) that would allow operators to have their facilities demonstrate conformance to ISA/IEC62443-2-1, -2-3, -2-4, -3-2, and -3-3. This question covers some similar ground, but also asks an additional question: “What systems are there in place to certify compliance in SL0-4?  What are the time frames expected to progress through them?  How much of the industry is covered/rates at the SL levels?” The conformance programs are mentioned above. The ISASecure website provides details of vendors who have obtained a conformance certificate for their development lifecycle, system, or component. The level of coverage is still growing. I believe asset owners need to drive the demand for vendors, along with their products, to be conformant to the requirements. Conformance can be a key differentiator between vendors and their products as asset owners seek security by design. This was an interesting question: “We are currently developing a SL1 product (Equipment under control). it is not clear how to take into account the location when accessing the requirements. seems like it should be a limited subset compared to a product at the operations management level.” The requirements for SL-C of a device do not change based on where in the hierarchy of a facility the device is used. What changes based on the hierarchy is the SL-T, which is based on the risk that is assessed for that part of the hierarchy (typically the zone). Also, as noted in the session, SL1 is the lowest level of security requirements, to protect against “casual or coincidental violation.” The level below this is SL0, which is “no specific requirements or protection necessary”. Another valid question: “Is there any checklist included for applying 62443?” There are no checklists provided as part of the series of standards, although each document in the series tends to provide a table of requirements associated with varying security levels, for instance this extract of the table in ISA/IEC62443-3-3: This was an important question to ask: “How long does a certification last? has expiration date?” Certificates related to processes must be renewed every three years. Certificates for products are based on a particular version of the product (hardware/software/firmware) and a particular instance of the standards/assessment methodology. Vendors cannot transfer this product conformance to other products. A question about one of the newer developments in the ISA/IEC62443 series: “The new 1-5 development which provide a profile, it is intended to be similar to Common Criteria Protection Profile that are focused on types of products (network devices, biometric, databases, etc.)? or it is more focused on sector or areas of application adding mandatory SL and requirements to meet for those profiles?” This development is still in the early stages and will specify a scheme for drafting cybersecurity profiles for the ISA/IEC 62443 series. Cybersecurity profiles based on this scheme are intended to be published as subparts of the ISA/IEC 62443-5 series. ISA/IEC 62443 cybersecurity profiles can be used by interested parties to adopt a defined set of requirements specified in the ISA/IEC 62443 series. The necessity of cybersecurity profiles can reside in the need to adopt for example the generic ISA/IEC 62443 terminology (e.g. roles) or the interpretation of requirements to a distinct industry sector or area of application. And finally, to close: “Could Steve please give us a sense about the level of adoption of this standard(s)? For example, in the EU market vs the US and, if possible, which industry (energy, utilities, etc) has the highest adoption?” Based on my experience, I would say oil and gas supermajors have fully embraced the series of standards, whereas other sectors are in various stages of adoption. World-wide I believe adoption is growing rapidly around the world. Requests for proposal now routinely include ISA/IEC62443. As I mentioned, it is my experience that some of these references are incomplete or vague (e.g. “meet ISA/IEC62443 without specifying which part(s)) but as awareness grows this is changing. The ISA Global Cybersecurity Alliance (https://isagca.org/) is a global consortium working to provide guidance on how to implement ISA/IEC62443. They provide many free white papers and guides. ISA also organizes an annual OT Cyber Summit to bring together thought leaders in this area. The next event is in London in June 2024 (https://www.isa.org/events-and-conferences/ot-cybersecurity-summit).

By Jay Gignac, Head of Global Sales & Marketing, Framatome Cybersecurity, Cyberwatch & Foxguard February 29, 2024 Ensuring smooth performance amidst various constraints is imperative in the complex landscape of industrial operations. Industrial plants often face operational challenges such as limited shutdown windows, critical process availability requirements, and demanding safety considerations. In such environments, implementing effective remediation measures becomes crucial to maintain operational integrity while addressing security vulnerabilities. Here, we dive into the strategic approach to address operational constraints and propose remediation actions. Many industrial plants operate with annual shutdowns or planned maintenance slots. These limited windows restrict the opportunity for implementing security updates or modifications to systems. Certain assets within industrial processes must operate continuously without interruption and the processes must be available at all times. Halting these processes for maintenance or security updates is not feasible due to the potential impact on production and operations. Finally, industrial systems often play integral roles in safety mechanisms. Any modifications to these systems should be approached with extreme caution to prevent compromising safety protocols or regulatory compliance. In some sensitive Industries like Nuclear or Pharma, any change in the system requires a new qualification phase which can be long and costly. There are some pre-implementation considerations to take. For example, it is critical to maintain up-to-date backups of critical systems and data to facilitate recovery in case of unforeseen complications or failures during remediation activities. It is important to develop documents and test comprehensive restart or fallback procedures, outline steps to revert changes or mitigate adverse effects if remediation measures result in disruptions or unforeseen consequences.  Make sure to verify the authenticity and integrity of patches to mitigate the risk of introducing malicious code into the industrial environment. With that in mind, acquiring patches and updates from a single trusted source and through secure channel could be beneficial and time saving. Then thoroughly validate patches and remediation measures in a controlled environment before deployment to production systems. Testing should encompass compatibility, functionality, and security impact assessments. Make sure to have your vendors approved and warranties contracted. In the specific case of patch management, after patches have been thoroughly tested and approved, the focus shifts to effectively rolling out these updates across the organization's network. Centralized patch management tools play a crucial role here, enabling administrators to orchestrate the deployment process efficiently. These tools provide a centralized dashboard where administrators can schedule deployment times, target specific groups of devices or systems, and monitor the progress of patch installations in real-time. Automated deployment mechanisms streamline the process, ensuring that patches are applied promptly while minimizing disruptions to normal operations. Additionally, organizations may employ techniques such as phased deployments, where patches are rolled out gradually to different subsets of devices or systems, allowing administrators to monitor for any unexpected issues and adjust deployment strategies as needed. In environments with air gap equipment, specialized methods such as offline patch distribution may be required, where updates are manually transferred to isolated systems via physical media or dedicated network segments. Throughout the deployment phase, careful coordination and communication are essential to ensure that patches are applied effectively across all endpoints, reducing the organization's exposure to security vulnerabilities. To summarize, navigating operational constraints in industrial environments requires a meticulous balance between security and continuity. By adopting proactive remediation measures such as patching, hardening, and asset isolation, industrial plants can fortify their defenses against evolving cyber threats while ensuring uninterrupted operations. However, a cautious and methodical approach to implementation, including secure patch acquisition, pre-implementation considerations, and robust fallback procedures, is indispensable for safeguarding both security and operational integrity in industrial settings. Learn more about:

By Jay Gignac, Head of Global Sales & Marketing, Framatome Cybersecurity, Cyberwatch & Foxguard February 22, 2024 Maintaining an accurate asset inventory in cybersecurity, particularly within industrial and critical sectors is a fundamental baseline. Despite the challenges posed by diverse and evolving assets, consolidating data from various sources, and contextualizing it is crucial for effective risk management. By implementing robust asset management strategies, organizations can enhance their cybersecurity posture, ensuring operational continuity and safeguarding critical infrastructure. Resource constraints and the need to prevent operational disruptions necessitate prioritizing corrective actions in cybersecurity. Not all vulnerabilities can be addressed simultaneously, making it essential to prioritize based on risk severity. By mitigating the most critical risk first, organizations can allocate resources effectively and minimize potential impacts. The complexity of industrial systems - the range of vendors, the fact that they are often geographically spread, and the obsolescence of some equipment - sometimes lacking cybersecurity capabilities poses significant challenges to prioritization. Additionally, regulatory requirements further add compliance constraints to prioritization efforts. A risk-based prioritization methodology is essential for effective cybersecurity management. When utilizing information gathered from asset inventories and vulnerability assessments, organizations can conduct risk assessments to identify critical systems and evaluate the likelihood of exploitation. This method correlates severity, exploitability, and criticality obtained through context. Following this methodology, designing a remediation plan involves determining what actions to take, in what order, and considering operational constraints. This ensures that resources are allocated efficiently, focusing on mitigating the most significant risk first. Therefore, adopting a risk-based prioritization approach is crucial for effectively mitigating cyber risks and ensuring the resilience of critical infrastructure. The next step is to implement a remediation plan, addressing vulnerabilities and threats based on their risk severity and operational impact. Learn more about:

By Jay Gignac, Head of Global Sales & Marketing, Framatome Cybersecurity, Cyberwatch & Foxguard January 23, 2024 In the realm of Operational Technology (OT), the identification and management of vulnerabilities and patches are pivotal to maintaining a robust defense against evolving cyber threats. This critical process goes beyond mere detection; it's about understanding the intricate details and implications of each vulnerability. The sophistication in identifying vulnerabilities lies in the ability to consolidate data from multiple, trusted industry sources. This aggregation provides a rich tapestry of information, painting a complete picture of each vulnerability’s potential impact and the urgency of its remediation. Evaluating a vulnerability’s exploitability and maturity is a nuanced exercise. It's not just about identifying the weaknesses but also understanding the likelihood of these vulnerabilities being exploited in the wild. This understanding is crucial in prioritizing which vulnerabilities need immediate action, such as the application of a patch, and which ones may need continuous monitoring for potential future risks. In the context of OT, patch management is a critical yet complex task. Each patch deployment must be carefully considered, balancing the need to mitigate vulnerabilities against potential operational disruptions. The key lies in understanding the specific operational context and the criticality of the systems involved. A rushed patch might solve one problem but create several others in an OT environment where system stability and availability are paramount. Moreover, the process of identifying vulnerabilities and managing patches must be continuous and dynamic, adapting to new information and evolving threats. It involves not only technical insight but also strategic foresight, ensuring that the defenses are not just reactive but also proactive, preparing for future vulnerabilities and threats. The role of cybersecurity in OT environments extends beyond protection; it's about enabling secure and uninterrupted operations. Organizations must therefore prioritize their efforts around vulnerability management, engaging with platforms and solutions that provide comprehensive data analysis and contextual insights. This approach ensures not only a more secure environment but also one that is resilient and prepared for the challenges of a connected industrial world. In conclusion, the journey towards a secure OT environment is ongoing and ever-evolving. Emphasizing the identification of vulnerabilities and the strategic management of patches is crucial in this journey. It's about building a cybersecurity posture that's not only robust today but also adaptable for the uncertainties of tomorrow. Learn more about:

By Gregory Dupuis, Global Head of Marketing and EU Sales Team Leader at Framatome Cybersecurity (IBCY) January 11, 2024 In the ever-evolving world of cybersecurity, Chief Information Security Officers and Operational Technology cybersecurity specialists face unique challenges. Among these, maintaining an up-to-date asset inventory stands out as a fundamental pillar for ensuring a robust security posture. This article delves into why an accurate and current asset inventory is critical, particularly in industrial or critical environments, and how organizations can effectively overcome the associated challenges of managing it. Managing an asset inventory in OT environments can be complex due to the diversity and constant evolution of assets. This task becomes even more challenging in industrial and critical sectors, with often siloed systems and a mix of old and new technologies. The first step involves acknowledging and addressing these unique challenges. An effective approach to maintaining an up-to-date asset inventory involves consolidating existing data. This means leveraging pre-installed tools that gather data on both IT and OT assets. For instance, using industrial network probes for mapping can provide significant visibility. However, another layer of information can be obtained from more traditional tools such as antivirus software, Endpoint Detection and Response (EDR) systems, firewalls, and network switches. Merely gathering data is not enough; its contextualization is imperative. Without this, it’s impossible to add value in threat management. A good asset mapping should include not just a complete view but also a clear context, covering the location, functionality, and criticality of each asset. The software used to maintain the asset mapping must be capable of interconnecting with various tools to extract and consolidate data. It’s also vital that it offers functionalities for classifying assets into different categories. This classification should align with the company’s risk management policy, allowing for a more precise and targeted risk analysis. Maintaining an up-to-date asset inventory is fundamental to a strong cybersecurity posture, especially in OT environments. By addressing the unique challenges of these environments, consolidating and contextualizing data, and using appropriate tools for asset classification and analysis, organizations can greatly enhance their ability to manage risks and respond effectively to threats. Investing in these processes is not just a precautionary measure; it’s a strategic necessity to ensure operational continuity and protect critical infrastructure. Learn more about:

By Brent Huston, MicroSolved, Inc., (CS)²AI Fellow December 21, 2023 Introduction: OpenPLC is an open-source Programmable Logic Controller (PLC) for industrial applications. Installing OpenPLC on a Raspberry Pi can provide a low-cost and compact PLC system that can be used to control and monitor industrial processes. The OpenPLC runtime has a built-in web server, allowing program upload and configuration via a web interface. Installation Checklist: 1. Ensure your Raspberry Pi is running a recent version of the Raspbian operating system. 2. Make sure git is installed on your Raspberry Pi. If it's not installed, run the command: `sudo apt-get install git`. 3. Clone the OpenPLC repository using git with the command: `git clone https://github.com/thiagoralves/OpenPLC_v3.git`. 4. Navigate to the cloned directory: `cd OpenPLC_v3`. 5. Run the installation script for Raspberry Pi: `./install.sh rpi`. 6. Reboot your device after the installation is complete. 7. Once rebooted, OpenPLC will start automatically. 8. Access the OpenPLC web server by typing the IP address of your Raspberry Pi at port 8080 in your web browser. 9. Login using the default credentials (username: openplc, password: openplc) and change the default username and password under the Users menu. 10. Under the "Hardware" section, select the appropriate Raspberry Pi driver from the popup menu and save changes. 11. For pin mapping and creating your first project, refer to the official OpenPLC project page. Use Cases: Prototype Development and Testing: Raspberry Pi combined with OpenPLC offers a cost-effective platform for developing and testing new Industrial Control System (ICS) protocols and applications. This setup allows researchers and developers to simulate real-world ICS environments and test their prototypes under various scenarios, enhancing the robustness of new technologies before they are deployed in actual industrial settings. Educational and Training Tool: The Raspberry Pi and OpenPLC can be utilized as an educational tool for training personnel in the fundamentals of ICS. This setup provides a hands-on experience in a controlled environment, allowing trainees to understand the workings of PLC systems and the intricacies of industrial automation without the risk of impacting real-world systems. Cybersecurity Research and Testing: With the increasing importance of cybersecurity in industrial environments, Raspberry Pi with OpenPLC serves as an excellent platform for cybersecurity research. Researchers can use this setup to simulate ICS environments to study the impact of various cyber threats, develop mitigation strategies, and test the effectiveness of security solutions in a safe and controlled setting. Remote Monitoring and Control Experiments: Raspberry Pi, when integrated with OpenPLC, can be used for remote monitoring and control experiments. This application is particularly useful for research teams looking to develop and test new methods of remote operation, data acquisition, and process control in industrial systems, offering a practical and scalable approach to innovation in remote ICS management. Cost-Effective ICS Solution for Small Scale Industries: For small scale industrial setups or start-ups, the combination of Raspberry Pi and OpenPLC provides a cost-effective solution for implementing basic ICS functionalities. This setup allows smaller operations to automate processes and integrate control systems without incurring the high costs associated with traditional ICS infrastructure. These use cases highlight the potential of OpenPLC on a Raspberry Pi in providing a low-cost and effective platform for ICS security research and education, enabling asset owners and security teams to understand better, secure, and manage their industrial control systems.