ICS

For organizations today, it’s essential to use the right threat modeling methodology for network defense and risk management. The Purdue Model for ICS (Industrial Control Systems) Security is a great solution for threat modeling. Threat modeling for ICS security is a challenging task. As a solution, the Purdue Common Model for ICS Security provides structure, but it’s important to understand its implementation. This article aims to define and clarify the Purdue model for securing ICS from modern cyber threats. What Is the Purdue Model for ICS Security? The Purdue industrial control system (ICS) security model is a segmented approach to protecting physical processes, supervisory controls and operations, sensors, and logistics. Despite the rise of edge computing and direct-to-cloud connectivity, the ICS network segmentation model remains a crucial framework for protecting operational technology (OT) from attacks like malware. Industrial Control System (ICS) security has a lot to consider. Security professionals have to put processes and procedures in place based on the general risks involved in the industry. However, it is recommended that organizations specializing in ICS security should implement best practices as outlined by NSA and CISA for the Purdue Model for ICS Security. The model is a reference model for manufacturing data flows. As part of the Purdue Enterprise Reference Architecture (PERA), it helps organizations more efficiently transition to completely automated processes. It maintains a hierarchical flow of data throughout interconnected layers of the network. Six zones isolate ICS/OT from industrial technology (IT) systems, enabling improved access controls. Today the model is the standard for ICS network architecture that supports OT security. Breaking Down the Zones of the Purdue Model The OT system resides at the lower levels of the model, and the IT system takes up the higher levels. The systems interact in a “demilitarized zone” (DMZ). Let’s examine each zone of the Purdue reference model: Enterprise Zone: Levels 4 and 5 This is where you’ll find the IT network. These levels include storage, databases, and servers used to run manufacturing operations. In this zone, enterprise resource planning (ERP) systems control inventory levels, shipping, plant production schedules, and material use. Disruptions at this location can lead to extended downtime, which can cause damage to the economy, infrastructure failure, and loss of critical resources. Demilitarized Zone (DMZ): Level 3.5 Here you find security systems like proxies and firewalls. They protect against attacks on both the OT and IT environments. With increased automation and the need for bidirectional data flow between IT and OT systems, organizations can have new cybersecurity vulnerabilities in their system. However, the convergence layer can help mitigate this risk and increase organizational efficiency. Manufacturing Operations Systems Zone: Level 3 Here you find OT devices that manage workflows on the shop floor. Manufacturing operations management (MOM) systems provide a platform for companies to manage their production operations, while manufacturing execution systems collect real-time data. This can then be used to optimize production. Also on this level are data historians, which collect and store process data and conduct a contextual analysis. Disruptions at Levels 4 and 5 can lead to economic damage, infrastructure failures, and revenue loss. Control Systems Zone: Level 2 On this level, you’ll find systems that control physical processes and monitor their status. These include supervisory control and data acquisition (SCADA) software that monitors physical processes. The software collects this data and sends it to historians or other users. Distributed control systems (DCS) are on this level, and they perform SCADA functions locally. These systems are less expensive than other methods of implementing SCADA. Finally, human-machine interfaces connect directly to DCSs and PLCs. This allows for primary equipment control and monitoring. Intelligent Devices Zone: Level 1 This level contains instruments that transmit instructions to the devices at Level 0. These include programmable logic controllers (PLCs) that help monitor automated or human input in industrial processes and adjust output. And remote terminal units (RTUs) that connect hardware in Level 0 to systems in Level 2. This provides a reliable conduit for data to pass from one level to another. Physical Process Zone: Level 0 Here you’ll find sensors, actuators, and other machinery that monitor the assembly line’s condition and suggest adjustments in real-time. Many modern sensors use cellular networks to communicate directly with monitoring software in the cloud. How the Purdue Model Applies Today Since it was introduced by the Purdue University Consortium in the 1990s, the Purdue model has been used as an information hierarchy for CIM. At that time, few other models had outlined a straightforward way to organize CIM. Today, with IT and OT networks integrated through the industrial internet of things (IIoT), it would be reasonable to doubt if the Purdue model applies to modern ICS networks. For example, its data segmentation framework is irrelevant, as Level 0 data is sent directly to the cloud. But it isn’t time to throw out this model just yet. One advantage of the Purdue model that makes it still relevant today is its hierarchical structure. The model divides system components into distinct layers and clearly defines each component. Network segmentation is a logical way to control access between the layers in an OT network. Although the model won’t necessarily fit your current OT network, it still presents a good starting point for securing such a network. As new cybersecurity risks continually emerge, methods that have proven to be effective — even if they don’t perfectly match today’s systems — continue to have value. The Purdue model is a worthy asset to keep in your arsenal of cybersecurity tools. Final Thoughts Segmenting an OT network into layers allows you to control access between the layers. The model may not fit your current OT network exactly, but starting from the model is still an excellent way to secure an OT network. While historically the Purdue model has been used to secure ICS technology, as more of these systems have been connected to the internet they have become less resistant to intrusion. At Sectrio, we provide a service that helps fill the gaps in the Purdue model opened by internet

Let’s find out what gives OT security experts the creeps. Most of the times, the issues are associated with IT. The duties of the Chief Information Security Officer (CISO) change and expand along with the industrial Internet of Things (IIoT) and operational technology (OT). The CISO must eliminate threats posed by warehouse systems, networked machinery, and smart devices dispersed over hundreds of workstations. Maintaining safety in industry, oil and gas facilities, public utilities, transportation, civic infrastructure, and other areas is necessary for managing those security concerns. By 2025, analysts estimate that there will be some 21.5 billion IoT devices linked globally, greatly expanding the attack surface. CISOs require novel mitigation techniques for IIoT and OT risks since embedded devices frequently lack patches, which differ in important ways from information technology (IT) vulnerabilities. The organization’s leadership team and board of directors (BoD) need to be aware of the distinction. IIoT and OT are now at the forefront of cyber threat management due to costly production disruptions, safety failures resulting in injuries or fatalities, environmental damage resulting in liability, and other potentially devastating scenarios. Addressing 5 cybersecurity threats to OT security Operational technology (OT) used to be a specialty network that IT professionals didn’t bother with, or maybe felt they didn’t need to. That made sense for a time since OT networks often operated on esoteric operating systems, were hidden by air gaps and were segregated from IT processes. Then, because of improved performance, increased output, and ultimately financial benefit, organizations in every area related to energy and vital infrastructure began connecting to IT networks. Networking, remote control, and wireless communication were all the rage, and from an administrative standpoint, it made it logical for IT and OT to be combined. OT rapidly ceased to be the secure backwater that everyone had imagined it to be. Also Read: How to get started with OT security Organizations and authorities now have to deal with the cybersecurity consequences of this. Even though real-world examples of serious compromise are few and far between, attacks on Florida water treatment facilities and energy infrastructure in Ukraine serve as stark reminders that things may change drastically very quickly. The number of OT-connected systems and devices is rapidly expanding, encompassing everything from telematics and robotics to personal technologies like the Internet of Medical Things, as well as supervisory control and data acquisition (SCADA), manufacturing execution systems (MES), discrete process control (DPS), programmable logic controllers (PLCs), and more (IoMT). The challenge is how organizations should tackle the security problem anew when doing nothing is not an option as isolation is eroding as these systems are connected to regular IT networks. Established security vendors have filled the void by adding more layers to their systems, but experts have also started to appear on the scene. What steps could organizations take to better handle the OT security issue? 1. Security Flaws in IT Attackers now have a wide range of targets to choose from if they want to take advantage of software flaws in OT. In the past ten years, this category of flaws has risen quickly from absolutely nothing to a list that is no longer manageable to recall off the top of one’s head. For begin, Armis’ white paper on the subject says the following: A new vulnerability in Schneider Electric Modicon PLCs, which might allow an authentication bypass leading to remote code execution on unpatched equipment, was revealed by Armis in July 2021. The most major actual assaults against SCADA and ICS OT to date, including Stuxnet and Triton, have all been conclusively linked to state-sponsored espionage. The last firm on our list, Colonial Pipeline, is telling since it was an ordinary ransomware assault on the IT system that compromised its invoicing capabilities rather than the OT network itself which caused the company’s operations to be halted. Therefore, there are two issues here, the largest of which is the connection between OT and IT, which is detrimental to the former. OT equipment flaws are a secondary source of vulnerability that is exploited only under certain conditions. Depending on the OT context, there are a variety of hazards associated with basic IT issues like credential theft. The ICS environment won’t be in danger from a compromised credential or RDP since there are so many layers of segmentation in place; just because you enter the IT environment doesn’t imply, you’ll also enter ICS. However, by just seeing someone’s network, we may determine who has considered this problem and who has not. Also read: Why IoT Security is Important for Today’s Networks? In addition, in the few instances where segmentation has not been successfully done, programmable logic controllers (PLC) may communicate to printers and there is no role-based access control. Anyone with access to a VPN could essentially access any network location. What are the main channels from IT to OT for infection? According to Norton, “Infected laptops belonging to maintenance engineers, USB sticks, an unauthorized wireless device, or even a malevolent insider” are among the causes of infection. 2. OT appliances don’t execute antivirus It may seem apparent, but OT devices cannot run a traditional security client for several reasons related to their architecture and history. As a result, an agentless strategy must be used to obtain visibility on what is happening on an OT device via different methods. The strategy used by various organizations suggests looking straightforward enough: observe network activity without interfering with production. It functions essentially as a network TAP in OT contexts. It develops an inventory based on the network traffic it is passively monitoring. In addition to having the assets, we need to monitor their usage to create a profile of behaviors. Ironically, the OT team may refuse to allow the IT department to clear up malware that was identified running on an OT device if they are concerned about service disruption. Organizations frequently observe old infections in OT settings. 3. Asset blindness The additional advantage of using an agentless strategy is that it provides organizations with complete

230,000 – This is the number of people affected by a single successful SCADA attack. Attackers successfully intruded Ukraine’s power grid using BlackEnergy 3 malware in 2015. The attack left 230,000 people and more stranded without power for over 6 hours. The SCADA systems were left non-functional, forcing the workforce to restore the power manually. This attack on the SCADA system set alarm bells ringing across the globe, exposing the weak cybersecurity posture of critical infrastructure. But what are SCADA systems in the first place? The acronym SCADA stands for Supervisory Control and Data Acquisition. Ranging from power plants to railways and water treatment plants to air traffic controls, applications of the SCADA system are vast and deep. Using SCADA systems (software), one can control processes in real-time and obtain data from sensors, devices, and other associate equipment. In short, SCADA systems help an organization manage and operate an industrial plant efficiently. Also read: How to get started with OT security SCADA systems find uses across industries, infrastructure, facility processes, and others. Computers, GUI, networked data communications, and proprietary software make up a typical SCADA system. Thanks to SCADA systems, one can quickly identify a non-functioning part in an industrial plant with over 10,000 functioning parts and numerous connections. SCADA Structure: SCADA system works on collecting data and then relaying commands through the architecture to control a process or a machine. A typical SCADA system involves various collection points, administrative computers, field controllers, communication infrastructure, software, a human-machine interface, and many more. Administrative Computers: These form the core structure of a SCADA system. The administrative/supervisory computers send all the control commands to the respective machines and devices. The administrative computers harvest all the data collected in a SCADA-enabled system. Depending on the complexity of the SCADA system, the administrative computer(s) can be one or multiple, often forming a master station. Exclusive Human-Machine interface systems propel the interactions between these computers and the workforce. Field Controllers:  These come in two forms: Communication Infrastructure: This deals with establishing a secure connection between the SCADA system, RTUs, and PLCs. Communication connection comes in two forms: Most of the infrastructure is modular, and the data passing through them is often unencrypted in both Field and IT communication infrastructure. The primary design objective of these systems is easy troubleshooting and ease of implementation, emphasizing reliability over security. A manufacturer-specific or industry-defined protocol is adopted while establishing the communication infrastructure. The PLCs and RTUs can operate autonomously based on the latest command received from the administrative system. Human Machine Interface (HMI) System: The administrative system can comprise a single computer to a master station comprising over ten computers. The data ranges from simple flow diagrams of processes to complex schematic diagrams of the entire plant. An operator can access graphics, data charts, and other graphical data displayed on the system using a mouse, keyboard, or touch. The HMI system presents the status of every process, component, and plant-related aspect in an interpretable manner. Evolution of SCADA Systems SCADA systems have come a long way since beginning in the early 1960s. Over the 60 years, SCADA systems have transformed from monolithic to IIoT-based systems. As per the industry standards, the Fourth Generation of SCADA Systems is in use. Shortly, the fifth generation of SCADA systems will enter industrial spaces. SCADA Generation Category Features First Generation (1960s to mid-1970s) Monolithic RTUs incorporated at industrial sites directly connected to minicomputer systems.Low RiskIndependent system Second Generation (Mid 1970’s to late 1980s) Distributed Security risk elevated from low to moderate Availability of proprietary LAN  networks Smaller computers and greater computing power Multiple systems connected via LANLack of interoperability due to vendor lock-in practice Third Generation (Late 1980s – 1990s) Networked The emergence of Ethernet and fiber optic.Improved interoperability  Scalability of SCADA systemSecurity risk heightened Less operating costs Fourth Generation 2000s SCADA and IoT integrated system Equipped with IoT, Cloud computing, and big dataSSL and TLS have improved security posture while exchanging data between the SCADA systems and external networks.Better interfaces on handheld devices Greater interoperability SQL database support Web-deployable The next generation of SCADA systems will have cloud computing at their core. Researchers expect the new SCADA systems to optimize resource management (at peak surges and low demand) and enhance security protocols. Even without in-depth knowledge of software, one can design complex applications using RAD (Rapid Application Development) and the upcoming new-age SCADA systems toolkit. What makes SCADA so effective? The vast industrial expanses make it very difficult for physical monitoring. We need a reliable and efficient system to automate recurrence processes and constantly get the status of everything in an industrial expanse. SCADA has been rightly serving this purpose since its inception. From data collection to setting up alarms, SCADA plays a crucial role in improving an industrial expanse’s productivity, maintenance, and functionality. SCADA Architecture: SCADA systems run through 5 levels from Level 0 to Level 4. They form five of the six levels described in the Purdue Enterprise Reference Architecture, followed by enterprise integration. The dissemination of levels helps us understand SCADA systems better and define each security policy for each level. SCADA System Levels Description Level 4 Planning and Logistics Scheduling of production processes Managing ongoing processes Level 3 Production Control Level Made up of administrative systemsData aggregation from Level 2 systemsReporting to ongoing production is produced Executing alerts and other region-wide functions Level 2 Plant Administrative Level Data aggregation from level controllersIssuing commands to respective level controllers It consists of supervisory and administrative systems Level 1 Direct Control Level Comprises local controllers – RTUs and PLCs Accepts data inputs from sensors Actuator receive commandsDirect interaction with field devices Level 0 Field Device Level Includes sensors that forward data Includes actuators that control processes SCADA Security Framework: We can confidently say SCADA systems have opted for a reliable and straightforward framework for smooth functioning. SCADA systems were relatively safe, given that they were greatly restricted to on-site locations before the internet exploded. Every security framework of SCADA should be able to meet specific objectives. These help build a strong posture contributing toward a