IC32M+v5.12 Noteset Vol I - Control System Security - PDF

Using the ISA/IEC 62443 Standard to Secure Your Control Systems Course IC32M (Online) Participant Noteset Volume I Copyright © ISA PO Box 12277 Research Triangle Park, NC 27709 USA All rights reserved. This book or any portion thereof may not be reproduced or used in any manner whatsoever without the express written permission of the publisher. The unauthorized reproduction or distribution of a copyrighted work is illegal. Criminal copyright infringement, including infringement without monetary gain, is investigated by the FBI and is punishable by fines and federal imprisonment. ISA Training Equipment Donors ISA would like to thank the following companies for donating equipment for use in our hands-on training labs. By donating equipment, these companies have increased their name recognition within the industry while helping ISA continue its efforts to offer superior automation and control training. Emerson Process Management- Rosemount Measurement Wade Associates, Inc. Learn more with ISA’s hands-on Portable Training Labs! Our hands-on labs are ready to ship to your facility. Offering state-of-the-art equipment and expert instruction, ISA Onsite Training brings automation training directly to you. Learn more at www.isa.org/OnsiteTraining. EP30-6408-0516 Course Presentation Course Presentation IC32M Module 1 v5.12 1.1 Module 1 ©2024 International Society of Automation 1.2 FBI Anti-Piracy Warning ©2024 International Society of Automation 1.3 Disclaimer Notes: Please take a moment to read the following disclaimer statements carefully. Click Agree and Continue when you are ready to proceed. ©2024 International Society of Automation 1.4 Instructions Notes: Let's take a moment to review some course tips to ensure the best learning experience. A ”Getting Started Guide” is available here to download. The course is made up of 12 instructional modules. One of these is a lab exercise demonstration of various packet capture tools. At the end of each module, you will take a short quiz to verify what you have learned. You must pass the quiz with a minimum score of 80% to receive credit for a module. You may retake the quiz. ©2024 International Society of Automation 1.5 Navigation Notes: Use the Play bar at the bottom of the screen to navigate to the next screen or return to the previous screen.There is also a replay button should you choose to play a slide again. We suggest the use of headphones for the best audio results.The course player includes an audio button for volume control. The side bar on the left includes a Menu tab which can be used to navigate to a speciﬁc slide and indicates which slides have been viewed.The other tab on the side bar is for additional resources.You may exit the module and resume where you left oﬀ upon return. ©2024 International Society of Automation 1.6 Course Materials Notes: All course materials and modules can be accessed from ISA's LMS dashboard. Once you select this course, you’ll ﬁnd the materials available under course contents. Documents, including course Note Sets can be downloaded by selecting the item from the Course Contents list, and then clicking the Download button found in the upper right corner of the document. ©2024 International Society of Automation 1.7 Course Contributors Notes: Developing this course was a team eﬀort. On this slide we listed the professionals who created the most recent version. many other SMEs have contributed to this course since its inception. ©2024 International Society of Automation 1.8 Course Goals Notes: Let's get into the course. What are our goals? The primary focus of this course is the structure and content of the ISA/IEC 62443 standards. We will introduce the fundamental concepts that form the 62443 standards, things like defense in depth, and terminologies like zones and conduits. We must learn the terminology and taxonomy, in order to have a common basis to communicate. Take a moment to read the overall course goals for this course carefully. These are listed, so you have a better understanding of what to focus on as we move through each section. ©2024 International Society of Automation 1.9 In this module Notes: The following topics are covered in this module. ©2024 International Society of Automation 1.10 Module Objectives Notes: After completing this module, you should be able to: Describe the need and importance for control system security. Discuss current trends in control system cybersecurity and how they could aﬀect control systems. Analyze the diﬀerences between IT and IACS. Recognize there are still myths that exist regarding cybersecurity in IACS environments. Explain how awareness can be an eﬀective countermeasure to reduce risks in an IACS environment. ©2024 International Society of Automation 1.11 What is Control System Cybersecurity? Notes: Let's look at some deﬁnitions here about control systems and cybersecurity. How are these terms deﬁned in the 62443 standards? So electronic security is deﬁned as the actions required to protect critical systems, informational assets, unauthorized uses, denial of service, modiﬁcations, disclosure, loss of revenue, destruction, pretty much anything. A control system is deﬁned as hardware and software components of an industrial automation and control system, IACS, or sometimes pronounced eye-axe. Then, cybersecurity is deﬁned as measures taken to protect a computer or a computer system against unauthorized access or attacks. Notice that these deﬁnitions are taken directly from the standards, and the source is listed for each. ©2024 International Society of Automation 1.12 Trends in Control System Cybersecurity Notes: Trends in control systems cybersecurity have increased emphasis on security because of the increase in cyberattacks. Businesses are reporting more unauthorized attempts, and there's a marked increase in malicious code attacks. Commercial oﬀ-the-shelf, COTS, is equipment you can go out and buy, and you can just plug and play. We buy these devices, we install them, and we're not even sure what the conﬁguration is. We just need to get the process up and running. This can create security issues. We have implemented a lot of TCP/IP protocols in control systems, and thus, we have the same vulnerabilities as the business systems do. There's more use of remote monitoring and access which can create opportunities for unauthorized use. Tools to automate attacks are commonly available. You can buy them, download them, they do all the work for you. Artiﬁcial Intelligence, AI tools are being used by hackers to develop automated malware. It is important to monitor these trends in order to build a strong defense. ©2024 International Society of Automation 1.13 Implications Notes: What are some of the implications of these trends? We mentioned commercial oﬀ-the-shelf, COTS components. What are the implications of using these? There's increased connectivity and the use of common protocols. Potential adversaries are familiar with that technology. There are many risks that are common with business systems. There's remote access, which broadens that system's attack surface. Isolation or separation of business and operational networks is diﬃcult. In many places, it is impossible, especially with legacy equipment. More vulnerabilities in IACS components are being published and used by attackers. ©2024 International Society of Automation 1.14 Potential Consequences Notes: There can be serious consequences for organizations as a result of a cybersecurity breach. You can have unauthorized access, theft or misuse of data, and loss of the integrity or reliability of the control system. The availability of the control system could be lost. There could be equipment damage or personnel injury. How about violations of legal and regulatory requirements? All of these potential consequences can occur within an organization with compromised control systems. ©2024 International Society of Automation 1.15 Potential Consequences Notes: There is the possibility that cyberattacks on control systems could lead to major consequences for society. Consider the examples listed, which could impact large numbers of people. The manipulation of water supplies and electricity grids is a major concern, along with plant explosions and the alteration of product recipes. Potential consequences like these should drive an organization’s need to establish a strong cybersecurity defense. ©2024 International Society of Automation 1.16 Ransomware Notes: What are some of the implications of these trends? We mentioned commercial oﬀ-the-shelf, COTS components. What are the implications of using these? There's increased connectivity and the use of common protocols. Potential adversaries are familiar with that technology. There are many risks that are common with business systems. There's remote access, which broadens that system's attack surface. Isolation or separation of business and operational networks is diﬃcult. In many places, it is impossible, especially with legacy equipment. More vulnerabilities in IACS components are being published and used by attackers. ©2024 International Society of Automation 1.17 Threat Landscape Notes: Because of the increase in attacks on industrial and automation control systems, many government agencies around the globe are issuing alerts and reports. Let’s go over a high-level overview of these and then you can explore the documents and get the details. At the top left, we reference the USA National Security Agency, the NSA. They discuss stopping malicious cyber activity against connected operational technology, OT. The key takeaway from this one: look at your value versus risk versus cost for enterprise IT to OT connectivity. Why are you connected? What's necessary? At the bottom left, ENISA, the European Network, and Information Security Agency, known as the European Union Agency for Cybersecurity, published an updated version of their Threat Landscape report in 2022. At the top right, the USA Cybersecurity and Infrastructure Security Agency, CISA, encourages asset owner-operators to review the contents of the alert for threat actor techniques and ensure the corresponding mitigations are considered. Commodity ransomware, also referred to as Ransomware as a Service (RaaS), is addressed. ©2024 International Society of Automation Ransomware as a service is now as easy to get as ordering a pizza online. And last but not least, in the bottom right, we have the Canadian Center for Cybersecurity, Canadian National Cyber Threat Assessment Report. The document focuses on ﬁve cyber threat narratives that are considered the most dynamic and impactful and that will continue to drive cyber threat activity to 2024. You can click on the four documents and explore each to understand the recent threat landscape better. While ransomware is the recent trend here, the industry must keep its eyes out for all malware in the external as well as the internal threat landscape. That new variant of malware is just around the corner. ©2024 International Society of Automation 1.18 Malware Oldies but Goodies Notes: The creation of new malware continues to grow. However, there are many oldies but goodies, malware that keeps coming back with new variants. We can still learn much from studying events from the past. One of these is Stuxnet, which claimed to be the ﬁrst global digital weapon. In 2010, Iran centrifuges were targeted. Then in 2018, the telecommunications infrastructure was targeted with this same malware. Shamoon is a destructive malware designed to wipe infected systems by overwriting information with garbage data. Shamoon, back in 2012 reported that there were about 30,000 computers wiped at Saudi Aramco. In 2016, Virtual Desktop Interface, a Saudi company, was aﬀected by the Shamoon variant. Then we had a third Shamoon hit on an Italian oil and gas company in 2018. So, it just keeps morphing. Malware is operating system agnostic. Windows OS makes up about 80% of the market, so that's a richer target. But malware can be found on all operating systems. Anything could be compromised via a password phishing attack. We have Shellshock (Bashdoor) which has Unix, Linux, Mac OS X variants. There is equal opportunity for everybody to be hacked. We're just not picking on one particular operating system variant. We must protect all these devices. ©2024 International Society of Automation 1.19 Cyberattack Example Part 1 Notes: This is a real-life cyberattack example. Three Power distribution companies sustained a cyberattack in western Ukraine on 23 December 2015. The Ukrainian electricity grid was hit twice with a targeted attack. It was a nation state type attack. The attack was initiated via sophisticated phishing mail. The Information Technology (IT) environment was used as a stepping-stone to enter the Operations Technology (OT) network. The ﬁnal attack on the electricity grid was executed fast, opening breakers at the substation and overwriting ﬁrmware of critical components. ©2024 International Society of Automation 1.20 Cyberattack Example Part 2 Notes: In this attack, the forensic information is extensive from a technical point of view. A large amount of network activity took place. The remote-controlled malware scanned the IT network, detected an open connection from an IT system to an OT supervision platform, performed OT network scans, collected OT component information, and eventually installed ready-to-trigger malware components on both the IT and OT systems. ©2024 International Society of Automation 1.21 Cyberattack Example Part 3 Notes: The morning of the attack, a local operator noticed the mouse moved on the human- machine interface (HMI) and started switching oﬀ breakers remotely. When the operator attempted to regain control of the supervision interface, he was logged oﬀ and could not log in again because the password had been changed. The gateway’s ﬁrmware was overwritten with random code. Workstations and server disks were erased. A Denial of Service (DOS) attack was placed on the call center preventing customer communication. Uninterruptible Power Supplies (UPS) were shut down, aﬀecting the control center directly. This step was obviously aimed at switching oﬀ the power for hundreds of thousands of western Ukrainian subscribers connected to the grid. However, most of the eﬀort was spent making sure that the power would not be switched on again: all of the speciﬁc malwares were developed with that objective. Once triggered, the only way for the operator to prevent that issue was to stop the attack as it was performed. But the attack was too fast to allow any reaction. In a critical infrastructure environment, operator actions may cause safety issues. There, only predeﬁned actions are allowed. ©2024 International Society of Automation Operators must follow guidelines for taking any action. In the event of an unforecasted operational situation, they are not trained to make decisions on the spot. This was exactly the situation in the Ukrainian case. “Obvious” actions could have stopped the attack (like pulling the cable connecting the OT to the IT network), but untrained operators cannot be expected to take such disruptive steps on their own initiative in a stressful situation. Mistakes are quite possible. A forensic analysis of this event as it relates to ISA/IEC 62443 standards can be found in the linked article from ISA’s InTech publication. ©2024 International Society of Automation 1.22 Five Common Myths Regarding IACS Security Notes: Let’s check out these 5 common myths regarding IACS Security. Myth one, we don't connect to the internet. Myth 2, Control systems are behind a ﬁrewall. Myth 3, Hackers don't understand control systems. Myth 4, Our facility is not a target. And myth 5, Our safety systems will protect us. ©2024 International Society of Automation 1.23 Myth #1 Notes: We don't connect to the internet. That's quickly dispelled by going out to the site, Shodan ICS Radar. Shodan is a project that was created to be a search engine for Internet- connected devices. It shows directly facing Internet systems. It is going to show you the typical applications, the buildings, building automation, back nets, DNP3, and everything that's internet-facing, and is probably not secure. Maybe it doesn't even have a password or it's using default passwords, so we can ﬁnd all types of protocols out there. So, many of these sites had non-existent log-on credential requirements. So, Project Shine is an intelligence extraction tool, it’s a project that was done to enumerate all these devices, over a million IP addresses enumerated. Systems are connected, and you can check that out yourself. As a word of caution: Be careful where you go on this site. You can look. Don't click too far, read all the instructions. Remember to think before you act with any of these things that you do. ©2024 International Society of Automation 1.24 We Don’t Connect to the Internet Notes: So, here's a typical network as an example of what auditors may ﬁnd on consulting engagements at facilities. These are all potential connections that could allow a breach. The ﬁrst place the internet could be connected here would be unauthorized connections. Then the oﬃce LAN could allow access through a misconﬁgured ﬁrewall. How about infected third-party remote support that's been compromised? Then we have modems. You may think nobody uses modems anymore. However, we still ﬁnd a lot of modems in our business. Most are not documented. Wireless. We're all using wireless in some form, that could be a way to get in. Infected laptops. That's not a direct connection to the internet, but there is a risk from portable media such as discs or USB sticks. We could have some type of infected maintenance equipment, like infected laptops. A lot of this is IP-based nowadays, so it's just something you might want to consider. And then the RS-232 links. You may think, “I can't get an IP address out of that,” but what if there is an IP to a serial converter? And then we have external PLC networks that may be undocumented because they were added as part of a project as a quick ﬁx. ©2024 International Society of Automation 1.25 Myth #2- OUR Control Systems Are Behind a Firewall Notes: Myth #2, Our control systems are behind a ﬁrewall, we're protected. Back in 2004, there was a study of 37 ﬁrewalls in ﬁrms in various industries. What did they ﬁnd? Any service inbound rules. It is important to understand that if your ﬁrst ﬁrewall rule says to allow any- any, that means there's no protection. You can have a thousand rules after that, but if the ﬁrst thing it sees says allow any-any, it will let all traﬃc through. These were gross mistakes. You may think, "Hey, that was 2004. Things have deﬁnitely improved." Unfortunately, not. In 2010, there was basically the same type of ﬁndings in a follow-up study. 84 ﬁrewalls were evaluated this time. Firewalls were still badly misconﬁgured. Modern conﬁguration software was supposed to help eliminate mistakes. It did not. Then 2014, and ‘15, the top control system cyber weakness was insuﬃcient network boundary protection. Indicating that even if conﬁgured correctly, there are published vulnerabilities. According to Gartner, through 2023, 99% of ﬁrewall breaches will be caused by ﬁrewall misconﬁgurations, not ﬁrewall ﬂaws. Vulnerabilities are vendor agnostic. Firewalls are not necessarily the cure-all. They are an important part of your defense-in-depth approach. And like anything else they require ©2024 International Society of Automation care and feeding. 1.26 Myth #3 Hackers Don’t Understand Control Systems Notes: Myth 3, Hackers don’t understand control systems. This may have been true many years ago. That’s no longer true, hacking is no longer just for fun. Hacking as a service has hit the mainstream. It is not just underground on the dark web, you can ﬁnd it openly. Jobs are put out to bid. At Devcon or Black Hat conferences, SCADA and process control systems are now common topics. Another trend that has become more signiﬁcant with time is crime. Hacking has moved from a hobbyist pursuit with a goal of notoriety to a criminal pursuit with the goal of money. Hackers can sell unknown vulnerabilities- zero-day exploits-on the black market to criminals who use them to break into computers. Hackers with networks of hacked machines or botnets can make money by selling them to spammers or phishers. They can use them to attack networks. We are seeing more and more criminal extortion over the Internet: hackers with networks of hacked machines threatening to launch DoS attacks against companies. These attacks started against fringe industries- online gambling, online computer gaming, online pornography-and against oﬀshore networks. They are now attacking mainstream ©2024 International Society of Automation businesses and it is becoming more commonplace. 1.27 Myth #3 Notes: Taking it further about hackers not understanding control systems, they can just go to these advisory sites and learn a lot. It’s a double-edged sword providing timely information about current security issues, vulnerabilities, and exploits. We hope that these are published after there’s a patch available to ﬁx them, but then we can’t always patch in a timely matter anyway. We may have to wait till the next scheduled turnaround or scheduled outage. The hackers know that. We’ll have a whole discussion about that later. It is a balancing act, but these advisories are out there, they get published. As you may know, Microsoft publishes its advisories on Patch Tuesday, the second Tuesday of the month. Whether that’s a good thing or a bad thing is a good topic for a healthy discussion. Vulnerabilities need to be addressed, as the information is out there. ©2024 International Society of Automation 1.28 Myth #4 Our Facility Is Not A Target Notes: Our facility is not a target. Who would target us? ©2024 International Society of Automation 1.29 Myth #4 Notes: The European Union Agency for Cybersecurity (ENISA) is the Union’s agency dedicated to achieving a high common level of cybersecurity across Europe. Thanks to ENISA’s Threat Landscape (ETL) 2023 reporting, we have this ﬁgure that highlights the aﬀected sectors concerning incidents observed based on OSINT (Open- Source Intelligence) and is a result of ENISA's work in Situational Awareness. They refer to incidents related to the prime threats of ETL 2023. The chart, with its various colors and numbers, can be diﬃcult to consider. Right now, the percentages aren’t the focus. For our purpose, note all the sectors and consider which may include IT and/or OT incidents. ©2024 International Society of Automation 1.30 Myth #5 Our Safety Systems will protect us Notes: One of the myths about safety systems is that they will protect us. Unfortunately, these systems are now microprocessor-based, running on Windows PC. It’s commonplace to integrate these control and safety systems using ethernet communications because they’re available. There are open, insecure protocols, like Modbus and Operation. The safety systems communicate on an embedded operating system,s and their ethernet stacks may not be as robust as they need to be. They have known vulnerabilities. One of the 2017 malwares targeted safety systems. It tripped the plant. It disrupted an emergency shutdown capability and triconic safety instrumented systems. Shut down operations, easy as that, unfortunately. Nowadays, that big red emergency button on the wall may not be connected directly to a mechanical safeguard shutdown device. You are ﬂipping a bit, a logical 1 or 0, which then sends a command to activate the mechanical safeguard. If you can ﬂip that bit, so can the adversary without having physical access to the red button. ©2024 International Society of Automation 1.31 Myth #5 Our Safety Systems will protect us Notes: Here is an example of legacy old malware targeting safety systems still used by state actors. The USA Federal Bureau of Investigation (FBI) is warning the group responsible for the deployment of TRITON malware against a Middle East-based petrochemical plant’s safety instrumented system in 2017, the Russian Central Scientiﬁc Research Institute of Chemistry and Mechanics, continues to conduct activity targeting the global energy sector. This warning follows the 24 March 2022 unsealing of a US indictment of a Russian national and a Russian research center employee involved in that attack. ©2024 International Society of Automation 1.32 Myth #5 Notes: This slide is a continuation of Myth 5, showing that even the most sophisticated safety integrated systems (SIS) and safety integral levels (SIL) can be defeated by an attacker. You can see there is a process control system, normal activities, and process alarms. So here we have basic automation, things are running ﬁne, and everybody's happy. Some alarms come in, causing plant personnel to look into the issue. It escalates quickly, and things get out of control. Valve pressures increase, ﬂows start ﬂowing, and energy is released where it's not supposed to be. The Safety Instrumented Systems are supposed to stop this and shut the place down. Well, if they've been compromised, that isn’t going to happen. So there goes your over-pressure valves, and rupture valves, the collection basins overﬂow, and disaster protection measures do not function properly. Everything that could go wrong, goes wrong. ©2024 International Society of Automation 1.33 Next Topic Notes: ©2024 International Society of Automation 1.34 Diﬀerences between IT and IACS Notes: There are important diﬀerences between IT and IACS. Our problems occur because assumptions that are valid in IT may not be valid on a plant ﬂoor and vice versa. One of the key diﬀerentiators is that IACS Cybersecurity has to address issues of health, safety and environment (HSE). The 62443-1-1 Introduction on page 14 states that “Because mutual understanding and cooperation between information technology (IT) and operations, engineering, and manufacturing organizations is important for the overall success of any security initiative, this standard is also a reference for those responsible for the integration of industrial automation and control systems and enterprise networks.” Understanding the diﬀerent needs of the staﬀ leads to cooperation and collaboration between historically disconnected camps. The manufacturing organization, the information technology, the physical security, it’s all- important for the overall success of any security initiative within a company. We want all stakeholders that are responsible for the integration of industrial automation and control systems and enterprise networks to be able to use these standards and incorporate what works for them. ©2024 International Society of Automation 1.35 Diﬀerent Security Priorities Refer to the text in ANSI/ISA 62443-1-1, sub-clause 5.2 Security Objectives on page 36. We want you to be familiar with the standards and begin to reference information. This may also help reinforce your learning prior to sitting for the certiﬁcate exam. Please open the note set and ﬁnd the reference. Information security typically includes three properties, conﬁdentiality, integrity, and availability, which are often abbreviated by the acronym "CIA” and depicted as a triangle. An information technology security strategy for typical “back oﬃce” or administrative systems may place the primary focus on conﬁdentiality, and the necessary access controls needed to achieve it. Integrity might fall to the second priority, with availability as the lowest. In the industrial automation and control systems environment, there is generally an inversion of these properties, with availability and integrity more important to IACS. Protecting proprietary batch processes and recipes may take higher precedence. Security in these systems is primarily concerned with maintaining the availability of all system components. Integrity is important. For example, you want to know what those tank levels are. If it says it's at 50%, it's at 50%. If the values are available, but they are not correct, that can make for a bad day. There are inherent risks associated with industrial machinery that is controlled, monitored, or otherwise aﬀected by industrial automation and control systems. ©2024 International Society of Automation Usually, conﬁdentiality is of lesser importance in the IACS environment because often the data is raw in form and must be analyzed within context to have any value. 1.36 Diﬀerent Performance Requirements Notes: We have diﬀerent performance requirements between the information technology and the industrial automation control system side, or OT, Operations Technology. In IT, response has to be reliable, have to have high throughput. Delay in jitter is tolerated in communications. Jitter would aﬀect your voice over IP, VoIP, video, timing in the packets being inconsistent, and it can impact and add to delays. Less critical emergency interaction, and there are IT protocols speciﬁc. They are totally control system unaware. In the control side, response time is critical, modest throughput. Sometimes if I'm doing an assessment and need to get some traﬃc above broadcasts and general traﬃc, might have to have folks log in, log out, depends on the system. The newer ones are becoming more busier. High delay is a very serious concern. When we turn a valve on, we want to get the reply that that valve on is within a certain number of milliseconds, microseconds in some cases. Then response to emergencies as critical. IT and industrial protocols, we're using both, speciﬁc industrial protocols, vendor speciﬁc, proprietary. It's diﬃcult to use business ©2024 International Society of Automation level type switches, networks designs in the control system world. Those are some of the issues that come up when we're working with our networks. 1.37 Diﬀerent Availability Requirements Notes: The availability requirements for IT and IACS are also diﬀerent. The IT side has a scheduled operation, which is typically a business work week, 9 to 5, with call out available. Occasional failures may be tolerated, rebooting could be tolerated, and beta testing in the ﬁeld may be acceptable. Modiﬁcations may be possible with little paperwork. Then on the IACS side, we have a continuous operation. It's not a business work week, it's continuous 24/7. Outages are intolerable because the money stops coming in when you can't make the product. Rebooting may not be acceptable, but may be the only alternative, and thorough quality assurance testing is expected in a non-production environment before you put anything out. Health, Safety, and Environmental (HSE) must be taken into consideration. All stakeholders have to understand these reliability impacts that aﬀect both sides. Having occasional failures tolerated, this would apply to IT as well as IACS. If you're using email for alarming and notiﬁcations, and the email server goes down, what's the uptime for that? What is the guaranteed service level agreement? What is the guaranteed delivery of email? ©2024 International Society of Automation We see email being used a lot for alarming nowadays. What if the email server goes down, where do you get your alarms from? IT and OT have to work together. Technology is how we are all connected. Whether we like that or not. 1.38 Diﬀerent Operating Environments There are diﬀerent operating environments. On the IT side, we have oﬃce applications and standard operating systems. Microsoft Operating systems (OS). Upgrades and updates are usually straightforward. Technology is refreshed and commercial oﬀ-the-shelf (COTS), pushed out every three to ﬁve years. You're going to see some legacy equipment on the IT side that's been there for a while. But generally, three to ﬁve years, they're replacing it. They have a cycle. Their vendors have a hard end-of-life cycle for software and hardware. It's the cost of doing business. It is more eﬃcient to keep the hardware and software updated than trying to “ﬁx” issues for hundreds or thousands of users every day. The IT department is usually located in a data center, server rooms, and/or oﬃce environments. On the IACS side, we have special applications and special embedded operating systems like WinCE, RTOS, and vxworks. Upgrades are challenging. It's going to aﬀect the hardware, logic, and graphics. Legacy systems. Does anybody have 15 to 20 year old systems out there? Legacy systems are quite common in IACS environments. The resources for IACS are constrained. There's limited bandwidth. It never really needed a lot before, but now we're starting to put COTS equipment, commercial oﬀ-the-shelf equipment out there. Some of these devices are bandwidth hogs. Now, we have IoT and ©2024 International Society of Automation IIoT to contend with. An industrial environment can be harsh. For example, those who have worked in a coal ﬁre facility know how dirty coal dust makes everything, and the air ﬁlters are continuously clogged up. Or if you're in a type of chemical environment, a chlorine environment. Your typical oﬃce supply copper wire RJ45 connectors don’t last long in a harsh environment. 1.39 Diﬀerent Risk Management Goals Notes: Let’s look at a few more diﬀerences between IT and IACS. These are related to risk management goals. Data conﬁdentiality and integrity is paramount on the IT side. Risk impacts include loss of data and/or a delay in business operations. It costs a lot of money to get rid of ransomware on the corporate side. Recovery by reboots might work in IT, sometimes you can go ahead and get back up quickly. What is the business Recovery Time Objective (RTO) - The acceptable downtime for critical functions and components, i.e., the maximum time it should take to restore services before the business has to close its doors and maybe declare bankruptcy. What is the Recovery Point Objective (RPO) - The point to which your state of operations must be restored following a disruption. In relation to backup data, this is the oldest age and level of staleness it can have. Is one hour ago good enough? How many online orders ©2024 International Society of Automation and payments has the business lost? In the control system world, HSE, Health, Safety, and Environment are paramount. Integrity and Availability are up there in importance. Risk impact can be loss of life, equipment, or a product. Fault tolerance is essential. You must have backup systems ready to go. Consider how following a typical IT risk management policy for password lockout procedures could lead to a potentially disastrous result if applied in an IACS environment. IT may lock out ALL access for 10 minutes after three failed login attempts. On the control system side, we want to make operator access easy and foolproof, but we also want to be secure. So, how do we handle that? What if an operator panics during a chlorine leak and misspells his password three times? The HMI locks all access for 10 minutes. That outcome can be disastrous. Applying IT security measures in an IACS environment doesn’t always work. You need to take that into consideration. ©2024 International Society of Automation 1.40 Addressing the Diﬀerences Notes: How do we address all these diﬀerences? Don't throw out all the IT security technologies and practices and start from scratch. About 90 % of it can be repurposed and used. Take advantage of their expertise, borrow from those IT security technologies and practices, modify them, and learn how to use them properly. They use technologies like Windows, TCPIP, and Ethernet. So do we. Much of that IT policy and technology will work for control systems. Keep in mind, they don't deal in safety, but only security. Consider taking your IT experts on a ﬁeld trip, educate them, and maybe go visit their data centers if they let you. Go check in with them. Develop a clear understanding of how the IACS assumptions and needs diﬀer from the IT environment. Identify and address the 10 % that may be diﬀerent. A simple acronym like RAS can become a friction point. What does it stand for? Remedial Action Scheme or Remote Access Systems? These are two diﬀerent technologies. Remedial Action Schemes have to do with industrial control systems or electric substations relay protection. For IT, RAS is Remote Access Systems. If you say RAS to IT, they're not thinking about relays. And then consider CIA. What comes ﬁrst availability or conﬁdentiality? You can learn more about the important diﬀerences between IT and IACS by clicking the box below. There's a good reference article from ISA's blog. Note that the authors use the term ICS versus IACS. For our purposes, we'll consider the terms one and the same. ©2024 International Society of Automation 1.41 Knowledge Check Notes: ©2024 International Society of Automation 1.42 Defense-in-Depth Notes: Switching topics here, let's talk about defense-in-depth. Perimeter defenses are never enough. Eventually, the bad guys, the hackers, or bad actors are going to get in. Many times, it isn't if you're going to get breached, it's when you were breached. A lot of breaches are discovered about 26 to 30 months after the initial probing by the adversary. They have been spending all that time getting the lay of the land, scoping out your systems at their leisure. You can't just ﬁrewall and forget about security. You'll ﬁnd that that isn't the best procedure when the law enforcement authorities or government agencies knock on your door and they go, "Hey, we're ﬁnding your IP addresses and intellectual property out there on the internet and it looks like somebody might be doing some bad things with them. You may want to check that out." All of this security takes care and feeding. You put it out there, somebody's got to take care of it, and it costs money. Are there the resources, the ﬁnancial resources, the business resources, and the management support to fund all of this? You must harden the control system’s network. You may not be able to do a lot. You're going to have to work with the vendor. So that defense-in-depth is important. Detection-in- depth is paramount to timely incident response. It's got to be accountable. Detection without response is totally useless. ©2024 International Society of Automation 1.43 Defense-in-Depth layers Notes: Defense-in-Depth is the provisioning of multiple security protections, especially in layers, with the intent to delay, if not prevent an attack. Defense in depth implies layers of security and detection, even on single systems, and provides the following features: attackers are faced with breaking through or bypassing each layer without being detected, a ﬂaw in one layer can be mitigated by capabilities in other layers, system security becomes a set of layers within the overall network security. Considering that security is not a perfect circle, it may require more emphasis on one layer versus another layer for a particular process. In this perfect circle diagram, there is no intent to imply an order for countermeasures. For example, policies and procedures may be required before physical security can be assessed. ©2024 International Society of Automation 1.44 Detection in Depth What about detection in-depth? There should be alarms, logs, and detection methods to identify unusual data transfer patterns. First, you need to know what’s normal. If you don’t create a baseline, you have no way to know what’s unusual. You may notice bursts of traﬃc, unusual protocols, and out-of-time data traﬃc. Maybe there are unknown, unexpected addresses, Mac addresses, IP addresses, media access control, internet protocol addresses, physical addresses, as well as logical ones. So there needs to be a way to turn on some type of system logging that operates on port 514. You can send these logs to a central logging server the same way IT does. A lot of control system equipment does have that capability now, but it needs to be conﬁgured. You must send them the backup log server, just in case a rogue insider knows about this and says, hey, I'm just going to wipe all of these logs. So have a place where you're going to keep pertinent logs. It may be diﬃcult to log everything, but you can log quite a bit in text format. If you're collecting this information, that could be helpful. Log services are turned oﬀ by default, Windows security log service is one of those that by default, in the past, straight out of the box, you ﬁre it up, and logging is turned oﬀ. You must actually go in there and consciously turn it on. Patch management and antivirus should be reporting devices that are out of date. So, you see how this helps our defense-in-depth approach? Firewalls and Intrusion Detection Systems (IDS) should be conﬁgured to identify any traﬃc that is not part of the expected traﬃc across zones. ©2024 International Society of Automation 1.45 Cyber Risk Notes: Cyber risk. You can't have a cybersecurity course without having a risk equation. There have been papers, theses, and dissertations written on this risk equation. The one that the 62443 standards allude to is three factors, threat, vulnerability, and consequence. You will need to establish values to these, depending on the approach that you use with it. Generally, you do that using a bunch of matrixes with references such as high, medium, and low. There is no one set form of risk response. We will discuss the risk equation in an upcoming module. In this course, we consider ﬁve risk responses. Design the risk out. One form of mitigation is to change the design of the system so that the risk is removed. Reduce the risk to an acceptable level through the implementation of countermeasures that reduce the likelihood or consequence of an attack. The key here is to achieve a level of “good enough” security, not to eliminate the risk. Accept the risk. There may be an option to accept the risk, to see it as the cost of doing ©2024 International Society of Automation business. Organizations must take some risks, and they cannot always be cost-eﬀectively mitigated or transferred. Transfer or share the risk. It may be possible to establish some sort of insurance or agreement that transfers some or all of the risk to a third entity. A typical example of this is the outsourcing of speciﬁc functions or services. This approach cannot always be eﬀective because it may not cover all assets completely. An insurance policy can recover certain damages but not loss of customer conﬁdence. Eliminate or redesign redundant or ineﬀective controls. A good risk assessment process will identify the types of controls that need to be addressed. You are the fact ﬁnder reporting to management using a good risk assessment process that will identify types of controls that need to be addressed. Your job is very important. Ultimately it is management’s responsibility to determine the level of risk the organization is willing to tolerate. ©2024 International Society of Automation 1.46 Review Exercise ©2024 International Society of Automation 1.47 Next Topic Notes: ©2024 International Society of Automation 1.48 Security Awareness Notes: Security awareness for all personnel is an essential tool for reducing IACS cybersecurity risks. Knowledgeable and vigilant staﬀ are one of the most important lines of defense in securing a system. It is therefore important for all personnel to understand the importance of security in maintaining the safe operation of the system. According to NIST-800-50 Building an Information Technology Security Awareness and Training Program, “A robust and enterprise-wide awareness and training program is paramount to ensuring that people understand their IT security responsibilities, organizational policies, and how to properly use and protect the IT resources entrusted to them.” According to ISA/IEC 62443, in the area of IACS, the same emphasis should be placed on cybersecurity as on safety and operational integrity, because the consequences can be just as severe. ©2024 International Society of Automation 1.49 Eﬀective Awareness Programs Notes: Cybersecurity awareness programs are most eﬀective if tailored to the audience, consistent with company policy, and communicated regularly. This means you need to know your audience: Board Members, CISO, Operations Manager, Technicians, Safety Subject Matter Experts, IT Staﬀ, Maintenance Engineer, etc. You need to tailor the awareness activities, so they relate to your context and applicable policies. The awareness activities need to be planned and repeated in a fashion that keeps drawing attention to the targeted audience and as and changes their behavior in the desired direction. ©2024 International Society of Automation 1.50 Awareness Activities Notes: Some examples of IACS speciﬁc awareness activities include: A demonstration of Industroyer malware on protection relay at electricity grid operator, causing malfunction of critical grid functionality A Red team / Blue team training exercise using a realistic simulation of the organizations IACS environment E-learning for all OT and IT staﬀ with a questionnaire at the end, and Board Member sessions that uncover high-impact IACS cybersecurity risks and how they aﬀect the business ©2024 International Society of Automation 1.51 Recap Notes: In this module, Introduction to Control System Security, we covered a lot of topics. In deﬁning control system security, we used the terms electronic security, control system, and cybersecurity. We looked at trends. What are the businesses seeing out there? What's really happening in the outside world? What are the implications? The potential consequences that may include equipment damage, personal injury, or violation of legal and regulatory requirements. We looked at malware events and trends. Malware knows no borders. We discussed common myths regarding IACS security. We don't connect to the internet. Our facility's not a target. Our control systems are behind a ﬁrewall. Our safety systems are protected. And hackers don’t understand control systems. We discussed the diﬀerences between IT and OT and the importance of awareness as a countermeasure in IACS cybersecurity. Hopefully, this has given you a good foundation to build upon in the following modules of the course. ©2024 International Society of Automation 1.52 Assessment Notes: Now that you have ﬁnished the module, you should pass the quiz to make sure you've learned the material. You must achieve at least 80% to successfully complete this module. ©2024 International Society of Automation 1.53 Question1 ©2024 International Society of Automation 1.54 Question 2 ©2024 International Society of Automation 1.55 Question 3 ©2024 International Society of Automation 1.56 Question 4 ©2024 International Society of Automation 1.57 Question 5 ©2024 International Society of Automation 1.59 ISA Connect Notes: Students often look for additional resources and networking opportunities. In response, ISA has created a virtual community designed to enhance your learning experience through ISA Connect. This is your opportunity to collaborate with your peers, beneﬁt from their experience, and engage in technical conversations relating to securing IACS systems and ISA/IEC 62443. Access to the community requires enrollment in any IC32 course and an active ISA membership. Participation in the learning community is voluntary and requires an active ISA membership and enrollment in any IC32 course. You will have access for one year. IC32 students without an ISA membership may join ISA and we will add you to the community. ISA Connect’s Cybersecurity Learning Community will help you build professional resources and contacts through discussion boards, library content, shared contacts and more. It is important to note that the ISA Connect Cybersecurity Learning Community is not to be used for sharing certiﬁcate exam details or questions. Exam speciﬁcs, including questions, should not be posted, shared, or discussed. ©2024 International Society of Automation 1.60 Follow Up Assignment Notes: Read: Industrial Automation by Ronald L. Krutz, Chapter 1 – 2 NOTE: You may access your e-textbook using the link provided in the ISA email with the subject: "Access your ISA digital purchase" ©2024 International Society of Automation 1.61 End of Module 1 Notes: ©2024 International Society of Automation IC32M Module 2 v5.12 1.1 Module 2 Notes: ©2024 International Society of Automation 1.2 FBI Anti-Piracy Warning Notes: ©2024 International Society of Automation 1.3 In This Module Notes: The following topics are covered in this module. ©2024 International Society of Automation 1.4 Learning Objectives Notes: After completing this module, you should be able to: Identify ISA/IEC 62443 as the focus of this course. Identify the differences between regulations and standards. Explain the difference between normative and informative. Describe the structure and content of the ISA/IEC 62443 series of documents. Summarize the role of ISA99 in developing documents within the ISA/IEC 62443 series. ©2024 International Society of Automation 1.5 Regulations and standards Notes: ©2024 International Society of Automation 1.6 Alphabet Soup of Acronyms Notes: There are many regulations throughout the world that contribute to cybersecurity for a specific region or industry. The acronyms may seem like an alphabet soup of various letters. Do you recognize any of these regulation examples? ©2024 International Society of Automation 1.7 Mandatory Regulations Notes: Let’s take a look at some mandatory regulations in North America and Europe. Chemical Facility Anti-Terrorism Standards from the US Department of Homeland Security. The US Nuclear Regulatory Commission’s cybersecurity rules. There's the Department of Energy, our Federal Energy Regulatory Commission, FERC. They have mandates for the electric industry. Their NERC-CIP has been adopted by Mexico and Canada. ©2024 International Society of Automation 1.8 Mandatory Regulations DHS/TSA Notes: On October 23, 2023, the Transportation Security Administration (TSA) renewed and revised its cybersecurity requirements for passenger and freight railroad carriers. The revised TSA Security Directives include updates intended to strengthen the rail industry’s defenses against cyberattacks. The changes were made following discussions with industry stakeholders and federal agencies, such as the Department of Homeland Security, in an effort to better address the needs and challenges of the industry. The Rail Cybersecurity Mitigation Actions and Testing directive applies to freight and passenger railroads. Guidance is provided to establish and implement a TSA-approved Cybersecurity Implementation Plan that includes the following mitigation efforts. Implement network segmentation policies and controls to ensure that the OT system can continue to safely operate in the event that an IT system has been compromised; Implement access control measures to secure and prevent unauthorized access to Critical Cyber Systems; Implement continuous monitoring and detection policies and procedures to detect cybersecurity threats and correct anomalies that affect Critical Cyber System operations; Reduce the risk of exploitation of unpatched systems through the application of security patches and updates for operating systems, applications, drivers and firmware on Critical Cyber Systems in a timely manner using a risk-based methodology. ©2024 International Society of Automation 1.9 Mandatory Regulations EU Notes: Here are several key EU regulations and directives related to cybersecurity. The EU NIS Directive 2022/2555, enacted on January 16, 2023, replaces Directive 2016/1148 and aims to enhance EU cybersecurity by establishing a cyber crisis management structure, harmonizing security requirements and reporting obligations, addressing new areas like supply chain security and vulnerability management in national strategies, introducing peer reviews for collaboration among Member States, and expanding coverage to more sectors. The Network Code on Cybersecurity for European Electricity Grid Operators also sets rules on cyber risk assessment, common minimum requirements, cybersecurity certification of products and services, monitoring, reporting, and crisis management in the electricity sector. It aims to enhance the cyber resilience of critical EU energy infrastructure. Several upcoming regulations include the EU Cyber Resilience Act (CRA), Radio Equipment Directive (RED), and Machine Directive. The examples are focused on North America and Europe. Consider the regulations in your region or industry. What is mandated? ©2024 International Society of Automation EU Network Code (Slide Layer) NIS2 (Slide Layer) ©2024 International Society of Automation 1.10 Limitations Notes: So, let's think about the limitations of mandatory regulations. A review of publicly available information shows that there's mixed resistance to mandated government frameworks and policies. Different countries approach that differently. Not all frameworks and regulations that exist align well with each other, even within a country. The number of enforced cyber and physical security regulations is growing. Some nation-states may have cybersecurity strategies that are still evolving. Public-private partnerships are lacking in some countries and sectors. Then we have the sector-specific cybersecurity plans that the governments may be putting out. Here in the United States, we actually have 16 different sectors, like chemical, water, electric, and even hospitals and financial banks. Regulation compliance is mandatory, while standards compliance is voluntary. But there is one general agreement across all the nations. No country or government can address cybersecurity risk in isolation. Remember we talked about the fact that malware has no borders. ©2024 International Society of Automation 1.11 Standards Compliance Notes: Standards are voluntary codes for which there are no legal obligations to comply. There are no requirements to use them unless it's agreed to in a contract or referred to in a regulation. In the absence of any type of relevant regulation, if something goes wrong or there's a breach, the courts may look at it and say, "Were you compliant with a standard?” What would a reasonable man on the street do? We call that the MOS test, man on the street. This question is used to determine if there are sufficient grounds for liability. Compliance with the standards is notionally voluntary. However, in the case of litigation, failure to comply with an existing standard or typical business standard process may result in liability if that would have reduced or eliminated the impact of the occurrence. It might be deemed as demonstrating negligence and not taking due diligence. ©2024 International Society of Automation 1.12 Standards Content Notes: Most standards contain both normative and informative elements. The normative elements are those parts that shall be complied with in order to demonstrate compliance with that standard. Normative elements are indicated by the use of the words “shall” or “must”. The informative elements provide clarification or additional information like guidelines. The informative elements cannot contain requirements. The words shall and must are not used there. As we get into the 62443 standards, we will point out the normative and informative elements. ©2024 International Society of Automation 1.13 ISA/IEC 52443 Series Notes: ©2024 International Society of Automation 1.14 62443 Overview Notes: This graphic, taken from the ISA99 committee’s web page, provides an overview of the ISA/IEC 62443 Series of Standards. The primary sources for this course are circled in red. These include the published versions of Part 1-1, Part 2-1, and Part 3-3 of the ANSI/ISA version. This course will focus on published standards though we may mention the progress of revisions. You can check the ISA99 SharePoint site for the latest status. ©2024 International Society of Automation 1.15 Work Product Organization Notes: The diagram organizes documents into four distinct groups, each with a specific focus. The first or top group, General, contains standards and reports that are general in nature. The second group, Policies & Procedures, addresses the people and process aspects of an effective security program. The third group, System, focuses on the technology-related aspects of security. The fourth group, Component, focuses on specific security-related technical requirements of products and components. You should be familiar with these four groups. ©2024 International Society of Automation 1.16 Work Product Highlights Notes: Going over the work product highlights, there are fourteen publications, of which ten are standards and four are technical reports. Technical reports or TRs are informative publications. They provide data or information on a particular technical subject. A TR looks like a standard, but it is informative. It doesn't use any shall or must statements. Standards use shall or must statements. There are nearly 400 of these normative requirements, which turn into standards (again, these contain the shall and must statement), and approximately 150 requirement enhancements shoring those up. When these are combined, there are over 900 pages. The official designation for the standards is either “IEC 62443” or “ANSI/ISA-62443”, depending on which edition is purchased. For convenience, we are recommending the use of the less formal designation “ISA/IEC 62443” to highlight that both editions are identical in content. Also, note that for the ISA editions, the “ANSI/” prefix applies only to standards and not technical reports. ©2024 International Society of Automation 1.17 General Group Notes: In the general group, Part 1-1, introduces the terminology, concepts, and models used throughout the series. The intended audience includes anyone wishing to become familiar with the fundamental concepts that form the basis for the series. There's a master glossary of terms and definitions that are used throughout the series in Part 1-2. The master glossary, which is a work in progress will likely be delivered in an online format. Part 1-3 describes a methodology to develop and quantify metrics that are derived from the process and technical requirements in the series. Part 1-4: IACS security lifecycle and use cases provides a more detailed description of the underlying lifecycle for IACS security, as well as several use cases that illustrate various applications. ©2024 International Society of Automation 1.18 Policies & Procedures Group Notes: In the policies and procedures group, we start off with Part 2-1: Establishing an IACS security program. It describes what's required to define and implement an effective IACS security program In Part 2-2: Security Program Ratings, there's a methodology provided for evaluating the level of protection provided by an operational IACS against the requirements in the ISA/IEC 62443 series of standards. Part 2-3 is a popular technical report on patch management processes in the IACS environment. The industry has been seeking the holy grail of patch management, and this technical report lays the foundation for the process. Part 2-4 specifies requirements for IACS service providers such as system integrators or maintenance providers. Part 2-5:Implementation guidance for IACS asset owners provides guidance on what is required to operate an effective IACS Security Program. The intended audience includes asset owners who have responsibility for the operation of such a program. ©2024 International Society of Automation 1.19 System Group Notes: The System group starts off with Part 3-1: Security technologies for IACS, which describes the application of various security technologists to an IACS environment. Part 3-2: Security risk assessment for system design addresses cybersecurity risk assessment and system design. The output of this standard is the zone and conduit model, the associated risk assessments, and target security levels. These are documented in the Cybersecurity Requirements Specifications. Part 3-3: System security requirements and security levels describes the requirements for an IACS system based on security level. The principal audience includes control systems suppliers, system integrators, and asset owners. ©2024 International Society of Automation 1.20 Component Group Notes: The last group is Component which includes two parts. Part 4-1: Secure Product development lifecycle requirements describes the requirements for product developer’s security lifecycle. The principal audience includes the suppliers of control systems and components products. Part 4-2: Technical security requirement for IACS components describes the requirements for IACS Components based on security level. Components include Embedded Devices, Host Devices, Network Devices and Software Applications. The principal audience include suppliers of Component products that are used in control systems. ©2024 International Society of Automation 1.21 Planned Future Work Notes: Planned future work on Part 1-5 specifies a scheme for cybersecurity profiles. Profiles based on this scheme are intended to be published as subparts of the 62443-5 series. Interested parties can use profiles to adopt a defined set of requirements specified in the series. For example, a substation profile will be a set of requirements describing the substation as an object that has specified 62443 attributes. This is a work in progress. Part 1-6: Applying 62443 to IIoT (Industrial Internet of Things) is primarily for the asset owner but may interest the service providers and product suppliers. Part 6-1: Security evaluation methodology for ISA/IEC 62443 - Part 2-4 will specify the evaluation methodologies to achieve repeatable and reproducible evaluation results for the part 2-4 requirements. Part 6-2: Security evaluation methodology for ISA/IEC 62443 - Part 4-2 will specify the evaluation methodologies to achieve repeatable and reproducible evaluation results for the 4-2 requirements. As you can see, there is a lot of work going on by the ISA 99 committee. It is quite an accomplishment for a committee supported by over a thousand volunteers across the globe. ©2024 International Society of Automation 1.22 ICS or IACS? Notes: You may be wondering, is it ICS or IACS? ICS stands for Industrial Control Systems. It is a general term for types of control systems acting together to achieve an industrial objective. IACS is an acronym for Industrial Automation and Control Systems. You may hear it referred to as the letters I A C S or pronounced as ”eye axe.” The 62443 publications use IACS and takes the definition a step further. It's a collection of personnel, hardware, software, and policies involved in the operation of the industrial process that can affect or influence it's safe, secure, and reliable operation. ©2024 International Society of Automation 1.23 ISA99 Committee Overview Notes: The International Society of Automation’s committee on Security for Industrial Automation and Control Systems is known as the ISA99 committee. It was established in 2002 with just a handful of members and has grown exponentially to over 1000 volunteer members representing all automation industry sectors. It's not specific to any sector or industry type. Membership is global, which is very important, as it is consistent with ISA’s global reach and mission. Being global makes it a challenge to reach a consensus sometimes. However, it is moving along, and progressing. A group using consensus is committed to finding solutions that everyone actively supports, or at least can live with. ©2024 International Society of Automation 1.24 Committee SCOPE and Purpose Notes: The ISA99 committee establishes standards, recommended practices, technical reports, and related information that defines procedures for implementing electronically secure manufacturing and control systems and security practices and assessing electronic security performance. Guidance is directed toward those responsible for designing, implementing, or managing manufacturing and control systems and shall also apply to users, systems integrators, security practitioners, and control systems manufacturers and vendors. The committee’s scope is based primarily on an analysis of potential consequences, as shown here. The Committee focuses on improving the confidentiality, integrity, and availability of components or systems used for manufacturing or control and providing criteria for procuring and implementing secure control systems. Compliance with the Committee's guidance will improve manufacturing and control systems electronic security, and will help identify vulnerabilities and address them, thereby reducing the risk of compromising confidential information or causing manufacturing control systems degradation or failure. ©2024 International Society of Automation 1.25 Collaboration- SDOs Notes: In addition to ISA, there are two other Standards Development Organizations or SDOs interested in developing cybersecurity standards for industrial automation control systems or operation technology. The first of these is the International Electrotechnical Commission, IEC. There's an agreement between ISA and IEC to coordinate on the development of cybersecurity standards. That way, there wouldn't be a duplicate committee in each organization. It's a collaborative approach to working together. ISA 99 takes the bulk of the load, developing most of the standards. There are a couple of standards that IEC has either developed or has promoted and ISA has adopted them, but it's inherently beneficial to have IEC/ISA collaborate and align. ISA and IEC want to have standards consistent with general cybersecurity standards. If you're in the IT world, information technology cybersecurity, or information security, the ISO 27000-series has been specifically reserved for information security matters. ISO is the adopted acronym for the International Organization for Standardization. The committees want to be consistent. There's a review process to make sure that this all comes together. That takes a little time, but it's good to have input from each committee. ©2024 International Society of Automation 1.26 Collaboration on Related Topics Notes: The SDOs, Standard Development Organizations, IEC, and ISO have committees that maintain liaison relationships with several other committees and groups within ISA and externally. They work closely with the other committees to ensure that their perspective and needs are adequately addressed. The ISA99 committee works with ISA 84-Process Safety, and ISA 100- Wireless Communications. ISA 84 has taken on more importance in the cybersecurity realm concerning the type of assessments you must do for your Process Hazard Analysis (PHA). Collaboration also occurs with Automation Federation, Industrial Security Compliance Institute (ISCI), and the ISA Secure certification programs to maintain alignment with the standards. The terminology may differ a bit among the various organizations, but the alignment is the same. We also maintain relationships with external groups, such as the United States Department of Homeland Security. They have an Industrial Control System Joint Working Group and various sector-specific groups and government initiatives in this framework. Now, these aren't just US-centric. There are global players from all the different companies. This is important because many companies, such as Emerson, Honeywell, or M & M Mars, are global. They need to be involved in an organization that will look at their global perspective and respects that. The ISA 99 maintains active relationships with the IEC and ISO to ensure global adoption and ©2024 International Society of Automation consistency. 1.27 Active Work Groups Notes: Perhaps you've been involved in a standard drafting organization or standard drafting team. They all pretty much follow a similar format. There are active workgroups. ISA99 isn't any different. Here's a list of some of the workgroups that exist right now. Let’s highlight a few of these. Workgroup 7-Safety and Security, is a joint workgroup with the ISA84 Committee. So, they are talking about how they can impact each other. Then we have workgroup 9, IoT, Internet of Things. And there's also IIoT, the Industrial Internet of Things. They review the implications involved here. If you want to find out more information, you can visit the ISA99 site and check the status of the workgroups. ©2024 International Society of Automation 1.28 Committee Participation Notes: You don't have to be a member of ISA to be a member of the committee. You can participate by being in a work group or task group. You can contribute to the work activity by reviewing and offering comments or feedback. Various perspectives offer valuable feedback. You can also assist the committee in establishing joint working relationships with other committees and organizations. ©2024 International Society of Automation 1.29 Membership Types Notes: The ISA99 committee has three membership types. Informational is the default classification. You get to participate in one or more task groups if you want to. You can comment on draft documents, but you can't vote. There's the membership type of voting. Maximum one per company based on contributions and nominations approved by existing voting members. You are expected to vote on draft documents. You must participate. It's an active sport. It's not a spectator sport. There is an alternate type of membership where the member is paired with a voting member and given the ability to vote if the primary voting member is unavailable. So, it's a backup position. Again, membership types are informational, voting, and alternate. ©2024 International Society of Automation 1.30 Our Purpose Is Standards Notes: The purpose of the various committees is to support the standards. These committees want to help develop a consensus industry standard on automation. ISA99 focuses on cybersecurity, and physical security in the industrial and automation control system space. It takes several years to create a standard. This includes development, the review, the votes, the publications. They're always looking for new participants, fresh subject matter experts. It's all volunteer work. That's typical, again, of any standards drafting organization. It's all volunteer time and effort. You can use it as continuing education units, CEUs, or continuing professional education, CPEs, or as time to support your certifications. You need to check with your certification body to see if this is applicable. You can join the standards committee by clicking the link to the ISA committee web page. Fill out the form and select ISA99 from the dropdown menu to get on the mailing list. You'll have access to the SharePoint site in the areas that you are involved in. You do not have to be an ISA member. ©2024 International Society of Automation 1.31 Knowledge Check ©2024 International Society of Automation 1.32 Assessment Notes: Now that you have finished the module, you should pass the quiz to make sure you've learned the material. You must achieve at least 80% to successfully complete this module. ©2024 International Society of Automation 1.33 Question 1 ©2024 International Society of Automation 1.34 Question 2 ©2024 International Society of Automation 1.35 Question 3 ©2024 International Society of Automation 1.36 Question 4 ©2024 International Society of Automation 1.37 Question 5 ©2024 International Society of Automation 1.39 Follow Up Assignment ©2024 International Society of Automation 1.40 End of Module 2 ©2024 International Society of Automation IC32M Module 3 1.1 Module 3 1.2 FBI Anti-Piracy Warning © 2024 International Society of Automation 1.3 Instructions Notes: Let's take a moment to review some course tips to ensure the best learning experience. To learn more about accessing materials or navigating modules, click on the icons below. At the end of this module, you'll take a short quiz. You must pass the quiz with a minimum score of 80% to receive credit for the module. You may retake the quiz. © 2024 International Society of Automation Materials (Slide Layer) Navigation (Slide Layer) © 2024 International Society of Automation 1.4 In This Module Notes: The following topics are covered in this module. © 2024 International Society of Automation 1.5 Learning Objectives Notes: After completing this module, you should be able to: · Identify the models in the ISA/IEC 62443 Series · Interpret how these models can be used in an IACS environment · Define the Security Levels · Explain the IACS Cybersecurity Lifecycle and the activities in each phase. · List which courses ISA offers to understand each phase better. Discuss the IACS Automation Solution Security Lifecycle from ISAGCA. © 2024 International Society of Automation 1.6 Section 5 ISA/IEC 62443 Models & Security Levels Notes: The 62443 series, a work in progress. © 2024 International Society of Automation 1.7 Models Notes: The standard series reference for this section is ISA/IEC 62443-1-1. The goal here is to identify the security needs and important characteristics of our environment. We want to get the level of detail necessary to address the security issues and get everybody on the same page with a common understanding of the framework and vocabulary. In other words, share a common taxonomy. All these different types of reference models are addressed in 62443, part one, dash one, clause six, page 69. © 2024 International Society of Automation 1.8 Models Notes: Take a moment to open the standard and look at Clause 6, Models. Reference models provide the overall conceptual basis. An asset model describes the relationship between assets within an industrial automation control system. The network reference architecture describes the configuration of assets, and we'll show you these as we go along. Zone Model groups reference architecture elements according to defined characteristics. The models provide context for the definition of policies, procedures, and guidelines applied to the assets. We will build upon this common model reference structure. © 2024 International Society of Automation 1.9 ISA99 Model Relationships Notes: The ISA99 Committee used model relationships to develop the standards. They started off with policies, procedures, and guidelines, and then incorporated assets, reference architecture, and zones and conduits models. As you can see in this diagram, they are all related to one another. These models make up your security program, and we're going to take a little bit of a deeper dive into that. In part 1-1 clause 6.6, you'll find this figure, figure 23, on page 89. Pause here for a moment and pull out the standard, take a look at this Clause 6 on Models. We all learn differently; it can help to reinforce your learning by reviewing the slide references within the standards. In any case, it may help you get familiar with the structure and contents of the standards. © 2024 International Society of Automation 1.10 Reference Model Levels Notes: A reference model describes a generic view of an integrated manufacturing or production system, expressed as a series of logical levels. Reference models start off using the ISA 95 approach. ISA 95 is a functional hierarchy. At the top, we have level four, business planning and logistics, the enterprise systems. It's all the functions that are related and the activities needed to manage the organization: financial systems, production scheduling, operational management, maintenance management. This could be for an individual plant or the whole enterprise. We also have engineering systems that are at this level. Moving down to the next level, three, we include the functions involved in managing the workflows. Here we produce the desired end products such as dispatching production, detailed production scheduling, reliability assurance, and site-wide control optimization. Level two includes the functions involved in monitoring and controlling the physical processes. You typically have multiple production areas in the plant. Moving on to level one, some overlap here includes the functions involved in sensing and manipulating the physical processes, and maintaining process history. The actual production process is level zero. It's where all the sensors and actuators and DPs, differential pressure transducers, and all equipment is located. Positioning of the functions such as supervisory control within a reference model is far from an exact science. The ISA 95 model describes activities and functionality, not the system or network level it is implemented with or on. Sometimes there is confusion about what we call levels and layers. Here we want to emphasize that we are referring to a functional hierarchy based on levels. This is how you would set up an IACS business model. © 2024 International Society of Automation 1.11 Reference Model for ISA99 Standards Notes: The ISA-99 committee took the ISA-95 Purdue model and broke it into these sections, which looks almost identical. Note that at level one, we have safety and protection, which wasn't specifically called out earlier. With our basic control, we start at the top with level four enterprise systems and operations management. Looks very similar, whereas supervisory control is not an exact science. This is just used to create this model. A model is just that, it can change, it can be adjusted or adapted. At level one is safety protection and basic controls. Level zero contains the process equipment under control. The objective is identified as security needs and the important characteristics of the environment at a level of detail necessary to address security issues. We want to have that common understanding of the framework and vocabulary. Now we have a common taxonomy to start with and can engage the vendors that are looking at the big picture. © 2024 International Society of Automation 1.12 Asset Models Notes: Asset models start at a high level and include everything from the ISA 95 model: all Level 4, 3, 2, 1, and 0 equipment and information system. They explicitly include networking and auxiliary equipment. It's a generic model that will fit the many situations where control systems are deployed. © 2024 International Society of Automation 1.13 Asset Model SCADA system example Notes: In this asset model SCADA system example, from a security perspective, the concerns are with the control equipment itself, the users of the equipment, the connections between the control system and components, and all the interconnections with business systems and other networks. There are ancillary connections on the right-hand side that may not be directly part of the control system or the process, or do not interact with it directly, but they are site information systems that provide data. Here we start at the very bottom, with the sensors and actuators. Next is field IO. Field IO must contain sensors and actuators, which may be linked by IO networks. Go up another level, control equipment may be linked by control networks. So the standards are intended to apply to a broad range. This is not a prescriptive model. It'll vary, but we want to come across multiple industry segments and start at a high level and be generic enough to fit the many different situations that are out there. © 2024 International Society of Automation 1.14 Reference Architecture Example Notes: Reference architecture is specific to each situation and review, and it will be specific for each analysis. There isn’t any one size fits all. This is simply an example. An organization could have a single reference architecture for the corporation that's been generalized to try to cover all the operating facilities, but they also may have more detailed reference network architectures and diagrams that expand on an enterprise model. Here is where you start getting into the terminology of zone and conduit models that can be developed from this reference architecture. We will show you the logical groupings we decided to use within that enterprise as a subset of this whole enterprise drawing. There is no one “right way” to do groupings. It varies with the systems. That is when you need your subject matter experts to help define the groupings. There's a distinct advantage to aligning the security zones or physical areas in a facility. We can align a control center within a control security zone. By grouping we can determine the access control lists in the switches and routers and the different devices out there. Zone is our logical or physical grouping of assets. And anytime we talk about that in the 62443's, we are focusing on security zones. Manufacturing functions are being shown, but we want to focus on a security zone protecting that manufacturing function. Here we have plant A, plant B, plant C, the control systems cascade down to the IO level out in the field. © 2024 International Society of Automation 1.15 Security Zones Notes: Let's dig down a little deeper on the concept of security zones. What is a security zone? It’s a logical grouping of physical, informational, and application assets, sharing common security requirements. There can be zones within zones, or subzones. Subzones create layered security, providing defense-in- depth. Zones and subzones must have a logical border, with a device there that controls traffic in and out. The security policy of a zone is typically enforced by a combination of mechanisms both at the zone edge and within the zone. These mechanisms typically include firewalls, routers, and switches. © 2024 International Society of Automation 1.16 Security Zone Model Notes: Let’s look at a graphic representation. These security zone models were developed from the reference architecture we showed earlier. We described the logical groupings of assets within an enterprise or a subset of the enterprise. We can group by business facility site or the industrial automation control system itself can be considered as a group. Then we can analyze each one of these groups and zones for security policies. Hence the requirements for each one. Here we have the enterprise zone at the very top shaded in yellow, It includes servers, workstations, the main frame, and a laptop computer. Now, follow it down to Plant A zone, on the left-hand side in the green. Here we find workstations, data servers, and routers. Next is the Plant A control zone, shown in blue. Plant A control zone is protected by a firewall, so it is not connected directly to the enterprise zone. The control zone includes application servers, data servers, and maintenance servers to control the IO out in the field. This breakdown helps determine the type of security you want to put in each zone. You may decide to break down these zones even further into sub-zones. By grouping the devices, you can define all the members of each zone. These diagrams can be viewed in Noteset II, ISA-62443-1-1, clause 6.5, page 78. © 2024 International Society of Automation 1.17 Conduits Notes: Conduits are a logical grouping of communication assets that protect the security of the channels it contains. It is similar to a physical conduit, protecting cables from physical damage. We have a lot of cables and wireless, a lot of channels in a control system. Stated another way, this is a logical grouping of those communication channels connecting two or more zones. They share common security requirements. Trusted conduits that cross zone boundaries must use an end-to-end secure process. The physical devices and applications that use the channels contained in the conduit define the conduit end points. © 2024 International Society of Automation 1.18 Conduits Notes: Physically a conduit can be a cable or wireless channel that connects zones for communication purposes. A conduit is a type of zone that cannot have subzones. It is allowed to traverse a zone as long as the security of the channels contained within the conduit is not impacted by the zone. They can be trusted or untrusted. Conduits are defined by the list of all zones that share the given communication channels. It can be a single service (i.e., a single Ethernet network), or it can be made up of a multiple data carrier. A conduit is the wiring, patch panels, black boxes, hubs, media converters, routers, switches, and network management devices that make up the communications path under study. © 2024 International Society of Automation 1.19 Conduit Models Notes: Here we're looking at the zones and conduits, with the conduits highlighted in red. I encourage you to take a look at Part 1-1, page 86, clause 6.5.4. You'll find these diagrams there with more discussion about the zoning conduit model approach. We identified zones so we can break things down and give specific security controls and security target levels. Conduits are the connections between these zones, and they can run into the zones. It's not set in stone how you do this, but you're trying to break it down and determine how to protect your conduit, your switches, your routers, the pipes that connect these zones? This is the wiring, the patch panels, black boxes, hubs, media converters, router switches, network management devices, that make up the communication under study. It's amazing what you may find when you do an assessment, if you start crawling into ceilings and finding splices. Maybe from a security perspective that's not an issue but from an operational or a functional perspective, that could be a problem, having intermittent loose connections or providing a point where an adversary can easily tap into the network. © 2024 International Society of Automation 1.20 Zone & Conduit Characteristics Notes: We have identified our zones and conduits. What are the characteristics we should document? The name or a unique identifier, and the accountable organization. Who's responsible for the security of that zone or conduit? We need a definition of a logical boundary. That's important so we know where everything's connected. We also need a definition of a physical boundary. What do we need to lockdown from a physical perspective to maintain our security level target? Everything should be properly documented. It's important to identify the safety-related designations or if it contains safety-related assets. It's a little different from the IT, information technology side. Document the SL-T, the target security level determined by your risk assessment. Include applicable security requirements and policies. Make note of any assumptions and external dependencies. Be sure to include a list of all logical and physical access points, a list of data flows, as well as a list of all assets. When you make these lists, you can see the equipment that's online. Keep in mind that you may not see the equipment that's offline, so it may require some physical walk throughs and checking the systems out. © 2024 International Society of Automation 1.21 Zone & Conduit Models Notes: Here we have a SCADA zone and conduit example. There's a WAN in between, a wide area network. The conduits are highlighted in red. There are public-private telephone networks and radio microwaves. The zones include a primary control center and a backup control center, with similar equipment on both sides. And then, there are control zones for Sites A, C, X, and Z. Right now, we're looking at our zones and conduits. We started asking ourselves questions like, does that make sense? Is it cost-effective from a security perspective? What am I protecting? Is there a way for an attacker to get in? You can find this figure in Part 1-162443-1-1. It's figure 22 on page 87. © 2024 International Society of Automation 1.22 Security Level (SL) Definitions Notes: What is a security level? It's a measure of confidence that the industrial automation control system is free from vulnerabilities and functions in the intended manner. In the 62443s, security levels are defined in five different levels. Starting with security level zero, where there are no specific requirements or security protection necessary. Level one, we want to protect against casual or coincidental violation. Security level two is protection against intentional violation using simple means with low resources, generic skills, and low motivation. Then security level three is protection against intentional violation using sophisticated means with moderate resources, IACS-specific skills, and moderate motivation. Security level four is protection against intentional violation using sophisticated means with extended resources. An attacker has IACS-specific skills and is highly motivated. © 2024 International Society of Automation 1.23 Knowledge Check © 2024 International Society of Automation 1.24 Section 6: Introduction to the IACS Cybersecurity Lifecycle Notes: © 2024 International Society of Automation 1.25 Security Lifecycle Notes: The security lifecycle in the ISA 62443 standard includes three phases: assess, develop and implement, and maintain. The security life cycle is a continuous process needed to minimize risks. During the assess phase, zones are assigned a target security level based on a risk assessment. In the Develop and Implement phase, countermeasures are applied to meet the target security level. In the maintain phase, countermeasures are audited and/or tested and upgraded, if necessary, to reach and maintain the Achieved Security Level (SL-A). © 2024 International Society of Automation 1.26 Cybersecurity Management Notes: ISA’s cybersecurity training series includes courses that address all three phases of the cybersecurity lifecycle. Let’s take a closer look at each course and the topics included. © 2024 International Society of Automation 1.27 Assess phase Notes: ISA’s IC33 course is an excellent way to get theoretical knowledge and hands-on experience in assessing the risks of an IACS. Course topics include high-level cyber risk assessment, allocation of IACS assets to security zones or conduits, and detailed cyber risk assessments. ISA 62443-3-2 provides guidelines for the assess phase. Labs provide experience applying the ISA/IEC 62443-3-2 standards to a fictitious Paint Factory company. © 2024 International Society of Automation 1.28 Develop and Implement Phase Notes: The Develop and Implement phase topics include cybersecurity requirements specification, the design and engineering of cybersecurity countermeasures, and the installation, commissioning, and validation of cybersecurity countermeasures. ISA 62443-3-3 provides guidelines for the development and implementation phase. The design and development of other means of risk reduction may also be included. © 2024 International Society of Automation 1.29 Maintain Phase Notes: ISA’s IC37 course is an excellent way to get theoretical knowledge and hands-on experience in maintaining an IACS. The maintain phase in the cybersecurity lifecycle includes cybersecurity countermeasures maintenance, monitoring, and change management, as well as incident response and recovery. ISA standard 62443-2-1 addresses cybersecurity maintenance. © 2024 International Society of Automation 1.30 Continuous Proccesses Notes: ISA 62443-2-1 provides guidelines for processes which should be continuously monitored. This includes a cybersecurity management system for: · Policies · Procedures · Training · and Awareness Periodic Cybersecurity audits should also be conducted as a continuous process. Continuous processes are touched on in ISA’s IC32, IC33, IC34, IC37, and IC-CSMS courses. © 2024 International Society of Automation 1.31 Product Security Lifecycle Notes: Another view of the ISA/IEC 62443 Series is the lifecycle view. There are two independent lifecycles described in the series: the Product Security Lifecycle, seen here, and the Automation Solution Security Lifecycle. The diagram shows the relationship between the Parts of the ISA/IEC 62443 Series and the various lifecycles and phases. © 2024 International Society of Automation 1.32 IACS Automation Solution Security Lifecycle Notes: The IACS Automation Solution Security Lifecycle is a conceptual approach by ISAGCA Applying ISA/IEC-62443 involves multiple roles. © 2024 International Society of Automation 1.33 Knowledge Check Notes: Knowledge Check: Drag the labels below to match each process to the correct phase of the IACS Cybersecurity Lifecycle. © 2024 International Society of Automation 1.34 Assessment Notes: Now that you have finished the module, you should pass the quiz to make sure you've learned the material. You must achieve at least 80% to successfully complete this module. 1.35 Question1 © 2024 International Society of Automation 1.36 Question 2 1.37 Question 3 © 2024 International Society of Automation 1.38 Question 4 1.39 Question 5 © 2024 International Society of Automation 1.40 Question 6 © 2024 International Society of Automation 1.42 Follow Up Assignment 1.43 End of Module 3 © 2024 International Society of Automation IC32M Module 4 v5.12 1.1 Module 4 ©2024 International Society of Automation 1.2 FBI Anti-Piracy Warning ©2024 International Society of Automation 1.3 In This Module Notes: In this module we will cover policies and procedures, the cybersecurity management system (CSMS), the process to develop a CSMS, and the CSMS top level activities. You may be familiar with the ISO/IEC 27000 series of standards typically used by Information Technology (IT). We’ll discuss how the ISA/IEC 62443-2-1 and the ISO/IEC 27000 series are complementary parts in managing the information security of an organization. Other topics include how to develop a Cyber Security Management System (CSMS), identify the six top- level activities, and summarize how a CSMS is based on the ISA/IEC 62443-2-1. ©2024 International Society of Automation 1.4 Learning Objectives Notes: After you complete this module, you should be able to: Discuss the complementary nature of ISA/IEC 62443-2-1 and ISO/IEC 27001 Identify what categories and elements are in an ISA/IEC 62443-2-1 CSMS Summarize how to develop a CSMS based on ISA/IEC 62443-2-1 ©2024 International Society of Automation 1.5 CSMS Boils Down to Six Top Level Activities Notes: CSMS boils down to six top-level activities. ©2024 International Society of Automation 1.6 ISA/IEC 62443-2-1 Notes: As you can see in the slide’s title, there is a CSMS and an ISMS. ISO/IEC 27001 provides requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System. Key in on the words “security management system”. ISO 27001 provides a list of commonly accepted controls to be used as a reference for establishing security requirements. ISO 27002 provides further detailed guidance for organizations implementing these information security controls. A white paper from the ISAGCA, the International Society of Automation’s Global Security Alliance, covers applying ISO and ISA series for Operational Technology Environments. The title is “Applying ISO/IEC 27001/2 and the ISA/IEC 62443 Series for Operational Technology Environments” ©2024 International Society of Automation 1.7 ISA/IEC 62443-2-1 Notes: If your organization already has an information security management system (ISMS) based on the ISO 27000 series you may be able to leverage the ISMS to aid in developing an ISA 62443 Cyber Security Management System (CSMS). Use the ISMS policy and procedures as templates in developing the CSMS. You don’t have to reinvent the security wheel. This diagram shows how ISO/IEC 270001/2 addresses the information security of an organization’s office environment. The ISA/IEC 62443 addresses the Operation Technology environment. ©2024 International Society of Automation 1.8 Policies & Procedures Notes: The information we will cover in this section comes from the series overview, the second group, second row down, policies and procedures, 62443-2-1, security program requirements for IACS asset owners. This will be our primary source for talking about the CSMS. I'll be referring to this standard as part 2-1. ©2024 International Society of Automation 1.9 CyberSecurity Management System (CSMS) Notes: Here is an overview of our cyber security management system, CSMS. I'll be referring to this acronym as CSMS. In this slide, we point out the different categories, elements, and element groups. In the next few slides, we'll list each of the categories. We'll then go through the process of creating a cybersecurity management system. You can refer to your notes for this graphic. You can also find it in the 62443. Here are our three categories, risk analysis, addressing risks with cybersecurity management system, monitoring, and improving the cybersecurity management system. Then we have the elements, elements within the categories. Business rationale, risk identification up here, with risk analysis down here at the bottom, compliance, review and improve and maintain the CSMS. Rinse, lather, and repeat is what I usually call this type of a section. Then we have element groups within this category of addressing risk with the CSMS. Let me run over that once more. We have three categories. Categories consist of the elements and element groups, as you see in this slide. ©2024 International Society of Automation Developing a CSMS is a journey that may take mont

IC32M+v5.12 Noteset Vol I - Control System Security - PDF

Document Details

Tags

Related

Summary

Full Transcript