Jason D. Christopher1 and Ben Miller2 1Energy Impact Partners, New York, NY, USA 2Dragos, Inc., Hanover, MD, USA While there are many different types of industrial environments and facilities, pipelines represent one of the most important critical infrastructure sectors of the modern age. Stretching across vast geographic footprints, the pipelines themselves act as vital arteries for the lifeblood of our society. The reliability and safety of these intricate systems are the top priority of system operators and engineers. There is, however, a looming threat that is unseen and—for the most part—unknown to this audience. Cyber threats, existing in the realm of digital connectivity, have become one of the most pervasive, yet rarely understood, risks to pipeline operations. In every control room, at every compressor station, within every meter and sensor—there are potential entry points for digital intruders, individuals, or entities with motives ranging from espionage to sabotage. In an age where connectivity is king, these pipelines are not only just conduits of fuel but also channels through which information flows, making them vulnerable targets for cyber threats. Yet, for many engineers and operators whose expertise lies in the mechanical intricacies of pipelines, the realm of cybersecurity remains uncharted territory. The concepts of firewalls, malware, and intrusion detection may sound like jargon from a distant, unfamiliar world. But the truth is simple: understanding the nuances of industrial cybersecurity is important for ensuring the safety and integrity of the very pipelines upon which societies rely. In this chapter, we will demystify industrial cybersecurity, breaking down complex concepts into digestible, relatable pieces. We will explore not only the “how” of securing pipelines in the digital age but also the “why,” delving into the relationship between cybersecurity and safety. By the end of this chapter, you will not only comprehend the challenges posed by digital connectivity in industrial environments but also appreciate the pivotal role cybersecurity plays in safeguarding not just data, but health and human safety. We will delve into real-world case studies, examining instances where cybersecurity vulnerabilities have had tangible, far-reaching consequences. Through these narratives, you will gain an understanding of the stakes involved and why bridging the gap between industrial operations and cybersecurity is no longer optional but imperative. When people think of “cybersecurity,” they usually think of headlines around ransomware or movies where shadowy individuals type endless code into a computer. The average person’s interaction with cybersecurity concepts is limited to annual training from their security department or what they see on TV. Unfortunately, that usually leaves a lot for interpretation. At best, you will have a list of things to not do at work. At worst, you will have a misconception of what adversaries do based on sensationalized fictional plots or attention-seeking headlines. This problem is magnified when discussing industrial cybersecurity. Unlike traditional information technology (IT) environments, industrial facilities have a unique set of challenges and impacts, unlike anything in an IT data center. In the IT world, the zeros and ones that make up data relate to information being stored, used, or transmitted. In industrial environments, the zeros and ones (and analog) data are information being used to manipulate the physical world. They control a process, provide visibility to operations, or otherwise maintain reliability and safety within the environment. As such, the impact is extremely different when considering the loss or manipulation of IT or industrial control system (ICS) data. The loss or manipulation of IT data could mean customer data, billing data, or even intellectual property is at risk. The loss or manipulation of ICS data could mean the destruction of the facility. ICS data impacts are so different that traditional IT security protections may not be useful in the industrial operational environment. For example, a common IT control is to encrypt data while in transit. This turns plain text into obfuscated cipher text that cannot be read by adversaries. But ICS data change routinely and are used for real-time operations—providing limited value to a would-be attacker. As a matter of fact, if encryption is used in an ICS, like pipeline operations, it may provide further cover for an adversary—covering their tracks by simultaneously obfuscating their own malicious traffic. Between the difference in risks, impacts, and security controls, it has become obvious that a new type of cybersecurity is required for ICS and operational technology (OT) systems. Industrial cybersecurity is the specific field of protecting real-time systems that control physical processes. This can also be referred to as cyber-physical security, ICS cybersecurity, or OT cybersecurity. Professionals in this field have a blend of skills and knowledge that should include knowledge of ICS/OT systems, traditional IT cybersecurity, safety and reliability impacts, and a variety of specializations for incident response, security operations, and even risk and compliance. At the end of the day, these professionals need to be well-versed in the specific threats and security controls for industrial operations—but also be able to bridge the barriers between enterprise IT security and the operators and engineers that keep the molecules flowing throughout the pipeline system. They are not just focused on cybersecurity but on overall resilience across the process control loops leveraged in daily operations. Challenges arise from three main factors: When discussing pipeline operations and ICS cybersecurity, it is important to recognize the evolution of threat actors and their focus on OT. In the realm of industrial cybersecurity, distributed control systems (DCSs) and supervisory control and data acquisition (SCADA) systems stand as both the backbone and the Achilles’ heel of modern pipeline operations. These intricate networks of hardware and software enable remote monitoring, control, and data acquisition, ensuring the seamless flow of molecules. In the 1990s through the early 2000s, most cyber threats were nuisances for pipeline operators. Untargeted, IT-centric malware would find its way into a control room because someone clicked on a bad link, plugged in a USB or loaded a CD that was not scanned by antivirus software, or otherwise unknowingly installed the malware. And the malware itself did not have any OT-specific impacts, since it would not know the difference between an IT help desk computer or one used as an engineering workstation (EWS). This largely meant that any computer virus during those early years would just stumble around the relatively closed-off network, and very few escalations required immediate clean up. Over time this changed. As we will discuss in the next section, the past two decades have seen an alarming increase in the number of real-world attacks focused on ICS/OT systems, including pipelines and similar critical infrastructure sectors. Attackers have realized the importance of these systems and may target them for a variety of reasons, including: As there are numerous motivations, there are also numerous skills based on the threat adversary’s skills, resources, and overall knowledge of ICSs. That knowledge, however, is not hard to attain. It just takes time and patience. A normal IT-based threat actor needs to understand the vulnerabilities in a given information system while also understanding the security controls in place and how to circumvent them. An ICS-specific threat actor needs to understand the physical process being controlled and how safety and reliability can be impacted by adjusting the process or manipulating the view or control of the process. While this requires perhaps years of studying and experience, our pipeline operations stay relatively static. We have not changed the way we operate DCS or SCADA systems over the past 20–30 years. As such, the attackers have all the time they need. It may require operational knowledge, engineering knowledge, or both—but there are several dedicated threat groups that have attained this level of knowledge with the sole intent of disrupting operations or compromising health and human safety. To compound the situation, we do not—and in many cases cannot—update our ICSs to address vulnerabilities like they do with IT systems. A system patch can require bringing down operations for hours, days, or weeks depending on the physical process being interrupted and restarted. No organization will routinely bring down operations for routine patches within that time frame. Add this to the fact that these systems have a lifecycle measured in decades rather than years (imagine not updating your laptop for 30 years instead of the usual 3–4 in corporate IT!), and we have a myriad of vulnerable systems in pipeline operations. That said, these vulnerabilities are not even the top priority of ICS/OT security professionals. An attacker that knows your system knows your processes (and the operations/engineering behind them) does not need a vulnerability to exploit—they simply need to land on an EWS or human–machine interface (HMI) with poor (or no) logon credentials and act as a legitimate user, adjusting valves or pressure or silencing alarms. ICS/OT attackers do not need to be novel—they just need to spend the time needed to understand your system. Unfortunately, in the scenario outlined above—a bad actor disguising themselves as a legitimate user—is an all-too-real scenario that has actually occurred in the real world. Knowing that this is a plausible reality for a security incident, the next question should be—how would you know if this was happening to you? Most ICSs lack the basic monitoring capabilities to ascertain if they are under attack. As such, many organizations are unaware of the full extent of their ICS network topology, the common access points that can be exploited by threat actors, or the tools, techniques, and procedures (TTPs) used by ICS-specific adversaries. Many of the devices used in operations are complex but designed without security in mind. Therefore, what could be a malicious attack may look and feel like a maintenance error. Did the controller stop communicating or did the screen freeze? Unfortunately, we have been trained to reboot or flash the device and call the equipment vendor. Doing so may not only “fix” the issue but also destroy any evidence of an attack. Similarly, without knowing the TTPs that threat groups use in pipeline operations, how would you be able to detect an attack before it happened? Without monitoring, what indicators would you have of an active threat in your environment? If a tree falls in the forest, but no one is there to hear it, does it make a sound? Understanding how threat actors compromise industrial operations is the first step in creating a defensible architecture for your pipeline cybersecurity program. Understanding prior attacks against OT, critical infrastructure, including pipeline operations, can offer insights into how potential vulnerabilities can be used against the asset owner and operators. This section will overview these prior attacks as a primer to illustrate the evolving threat landscape. Stuxnet, identified and publicized in 2010, is significant as it is the first known instance of malicious code leading to direct physical consequences. Stuxnet was used to disrupt Iran’s nuclear program though it remains relevant to the pipeline industry in that the equipment and software targeted were nothing more than industry standard programmable logic controllers (PLCs), and associated operator and engineering software. Stuxnet offered a glimpse of how future attacks could be used against industries and their own unique industrial operations across the world. In April 2012, the US Department of Homeland Security released initial reports of a series of targeted intrusions directed at 23 known pipeline entities. This campaign unfolded over a period from 2011 to 2013. These intrusions focused on the collection of information relating to the pipeline SCADA infrastructure, including personnel lists, usernames, passwords, and dial-up access information, network architectures, and manuals. DHS noted that due to a lack of visibility or logging, it remains unknown if the threat actors only collected the relevant information to gain access to the OT environments or if they used the information to gain short-term or persistent access. In follow-up reporting nearly a decade after the initial intrusions, the successor organization of DHS’s cybersecurity arm, CISA, assessed “China was successful in accessing the supervisory control and data acquisition (SCADA) networks at several U.S. natural gas pipeline companies.” While no impact on pipeline operations was observed, the DHS advisories offer the first public details of Chinese state-sponsored actors gaining unauthorized access to multiple pipeline’s SCADA environment. This campaign illustrated that pipeline operations were susceptible to intrusion and that state-sponsored actors possessed both the intent and capability to do so. Prior to 2012’s reporting, this was only theoretical. A geo-political hotspot, Ukraine, has undergone a series of attacks across its critical infrastructure dating back to 2015. While the pipeline intrusion set highlighted the intent and capability to gain unauthorized access, the Ukraine attacks highlighted the intent and capability to create outages and hamper restoration efforts through a cyberattack. The 2015 cyberattack was a result of a month-long attack coordinated against several distribution utilities where the threat actors gained remote access to the system operator’s machine and opened breakers in combination with disruption of communications and workstations to disrupt recovery efforts. This resulted in over 220,000 customer outages for several hours. Over time these focused attacks against Ukraine’s electric grid evolved with a degree of automation where malware (dubbed CRASHOVERRIDE or INDUSTROYER2) manipulated protective relays and substation equipment. The sophistication of attacks continues to advance. In 2017, a petrochemical refinery went into unscheduled shutdown due to a safety trip. During the course of the root cause analysis, it was determined one of the safety instrumentation system safety controllers entered a fail-safe state. The safety control was found to have malicious code, dubbed TRISIS, implanted on the controller. This novel attack technique resulted in creating a backdoor to the safety systems where attackers could manipulate logic that could impact human safety or the environment. TRISIS served as kill-switch for the attackers and demonstrated a progression of the adversary to further understand industrial and safety processes with the intent to disrupt and manipulate the industrial process itself. In October 2020, the US Department of Treasury sanctioned the Russian government in direct connection to this TRISIS attack. In recent years, the state-sponsored attacks against critical infrastructure have broadened to financially motivated attackers leveraging Ransomware. Notably, Colonial Pipeline was hit by ransomware in May 2021. Ransomware led to pipeline operations being shut down while the safe restoration of systems and services was completed; this ultimately led to fuel price increases and fuel shortages across the US southeast. The introduction of financially motivated threat actors capable of gaining access and disrupting OT adds less sophisticated but higher volume of attacks to the world’s pipeline infrastructure. As mentioned previously, industrial cybersecurity is fundamentally different from traditional IT-based cybersecurity. It requires a combination of expertise from IT, OT, operations, compliance, risk management, safety, procurement, and even human resources. Instead of protecting data, the mindset needs to be shifted to protecting the physical process. Security is a wrapper around the DCS and SCADA systems used to deliver products across pipelines. It is not that IT security is less important, but an acknowledgment that both IT and OT cybersecurity need to coexist and their scopes are not the same, nor is the skill set that is required to secure ICSs. This is the most important question to ask throughout the development of an ICS/OT cybersecurity program. The question needs to be answered from two primary perspectives: Both of these provide guardrails for the focus of a pipeline ICS/OT cybersecurity program because they clearly define what is being prevented (safety, environmental, and reliability impacts) and how to deter, prevent, or detect such incidents. For example, when evaluating scenarios that may cause safety, environmental, or operational impacts, ICS/OT cybersecurity professionals must understand how the protected systems are used (and can potentially be misused). This can help narrow the focus to a handful of plausible scenarios that may have disastrous consequences. Consider the following two scenarios: For Scenario 1, the traditional IT-centric response would be to potentially take the EWS offline for investigation. A routine activity like this is normal in IT environments. The very same action, however, could negatively impact operations in OT networks, depending on the site. Instead, in many cases where malicious code requires manual cleanup in ICS/OT environments, it is not uncommon to wait until routine maintenance cycles. In the meantime, an investigation can be initiated to understand how the malware ended up on the DCS (Did someone plug in a USB or phone? Or click on a bad link?), but technical actions on the impacted machine may be limited to start. Understanding both the impacts of the incident—but also the impacts of traditional IT-centric controls—is important when understanding the best response during an incident. As a matter of fact, the US Department of Homeland Security notes that “standard cyber incident remediation actions deployed in IT business systems may result in ineffective and even disastrous results when applied to ICS cyber incidents.” Meanwhile, Scenario 2 outlines immediate concerns for reliable operations and potential environmental impacts. Any suspected unauthorized action within a control center should be escalated and managed accordingly. In the case of Scenario 2, a potential threat actor may cause pressurization issues or leaking of product into a localized area. This manipulation of control may require exercising a disaster recovery plan for loss of visibility and control—and possibly require localized, manual operation where possible. When examining these two scenarios, it is obvious that not all cyber incidents are the same and that not all responses are equal. Direct impacts and the divide between IT and OT are not always so clear. The Colonial Pipeline incident mentioned previously is a great example. The ICSs were not impacted by the ransomware event, but the Manufacturing Execution System (MES) was part of the impacted controlled shutdown. The MES is a bridge between the business enterprise IT systems and the process control systems used to deliver gas products. The system tracks the batches of gasoline, jet fuel, home heating oil, and other product sequencing tasks. Without the MES, Colonial had limited visibility into what was actually in the pipeline and had to halt operations. This is an example of dependent systems that may interact with the ICS/OT network. It is vital that these systems are accounted for in the ICS/OT cybersecurity program, even though they may lay outside the purview of the operators in a broad sense. When evaluating system dependencies, it is important to ask the following questions: While a more specific asset inventory for IT and OT systems is a best practice, even a “system inventory” will go a long way in helping define the appropriate roles, responsibilities, and security controls required for your ICS/OT cybersecurity program. In traditional IT-centric security programs, vulnerability management is a labor-intensive priority for IT systems. Broadly speaking, vulnerability management is a systematic approach to identifying, evaluating, mitigating, and tracking security vulnerabilities in software and networks. In IT systems, vulnerabilities can be exploited by threat actors to gain a foothold in the network and launch an attack. Critical vulnerabilities may be those focused on unauthorized access, remote code execution, or security misconfigurations. Discovering vulnerabilities in IT systems may include active scanning across a network, and remediation usually involves software patches. An IT-centric approach to vulnerability management in ICS/OT systems would be catastrophic. Within pipeline operations we leverage dedicated controllers, for example, that cannot reliably handle the flood of network traffic associated with active vulnerability scans. Similarly, it is not an option to bring down operations for “patch Tuesday,” as it is infamously referred to in IT cybersecurity. Instead, other mitigations may be pursued when evaluating for vulnerabilities, including stronger perimeters between vulnerable systems or an investment in detection within critical environments in order to respond and recover quickly from an incident. That said, an attacker may never need to exploit a vulnerability in a pipeline control center asset in order to disrupt operations. Recall that these control systems were designed with reliability in mind—and to last decades, not years. Security has usually been an afterthought for these systems; a principle called “insecure by design” by ICS/OT security professionals. Controllers do not have the ability to install antivirus software, for example, and the most stringent access controls for such devices may be a four-digit PIN code—hardly an effective security control. This is compounded by the fact that many pipeline facilities leverage software that is no longer supported and riddled with vulnerabilities. A threat actor does not need to work hard to compromise a legacy operating system like Windows XP. Instead, many threat actors will just leverage the poor security control in place, like a lack of strong passwords on an EWS or HMI, and “live off the land.” In this capacity, the threat actor could perform the same tasks as an operator: change pressure in the pipeline, manipulate control variables, halt operations for an emergency, and so on. When examining scenarios for cyber incidents, a common practice is to understand how engineering and process control systems can be misused by threat actors to achieve reliability, safety, or environmental impacts. Evaluating each system with this perspective can help refine the incident response plan to be effective and timely against loss or manipulation of visibility and control across the geographic footprint of the pipeline operations. In October 2022, the SANS Institute published the Five ICS Cybersecurity Critical Controls to help organizations, including pipeline asset owners and operators, create and maintain a sustainable ICS/OT security program [1]. Similar to the concepts in this chapter, the controls are focused on the obligation for a safe operating environment for personnel and protecting the local community and environment from catastrophic harm. They are not designed to exceed the minimums of mandatory or expected good practices to further protect business interests—this is a focus on protecting the community being served. Unsurprisingly, the first control focuses on what to do during an ICS/OT incident. In pipeline operations, this would be specific to the DCS and SCADA systems used for process control. The very first question when evaluating this control should be: what does such an incident look like? Said another way, “what does a bad day look like?” Fundamentally, these incidents look and feel different than the IT-centric incidents that commonly grab newspaper headlines. As a result, the incident response plan should be specific to those scenarios impacting ICS/OT systems. For example, if a human resources database was compromised, an adequate response may include forensics across the IT system, notification processes for employees and credit monitoring, and an analysis of other potential data breaches. However, if the process control network for a compressor station was compromised, immediate response actions would include manual operations, establishing visibility and validating safety parameters, coupled with an investigation across engineering, operations, and cybersecurity professionals. The first step in establishing a sustainable ICS/OT cybersecurity incident response plan is to understand which scenarios matter most to your organization. This can be done by either: Based on these scenarios, an ICS-specific incident response plan would act as a playbook for how engineers, operations, and security professionals will collaborate during the incident. While there is a bias toward making this a security-based document, it is important to note that activities like safety walkdowns and facility restarts would be managed and owned by operators, not security practitioners. As such, it is important to “tabletop” the scenario or exercise it to make sure the plan matches what would happen during the actual incident. Having a response plan is not enough; it must be regularly revisited and exercised to make sure the team’s skills stay relevant as threats evolve. There are dozens of security frameworks that can be applied to pipeline operations. API 1164, ISA/IEC 62243, NIST SP800-82 are the most common standards discussed across the pipeline security practitioners. Standards and frameworks are invaluable for demonstrating compliance and communicating in a common language, however, they can also be overwhelming with thousands of pages of documentation. Control No. 1, however, can help us with limiting our focus to what really matters: those scenarios that can lead to system outages, safety events, or environmental impacts. Figure 2.1 Model for secure network architecture. ([2]/SANS™ Institute). Leveraging Control No. 1 as a scoping element, ICS/OT security practitioners can prioritize controls based on preventing, deterring, or quickly identifying the incidents based on the previous scenarios. While compliance must always be adhered to, other focal points for defensible architecture should include: The SANS Institute has provided a publicly available foundational reference architecture (Figure 2.1) for consideration [2]. The model in Figure 2.1 shows clear distinctions for different network boundaries and where specific operational and security functions take place. No matter what standard or framework is being used by the pipeline security program, each will be able to address the bullet points above, at a minimum. Tailoring it further to the scenarios outlined in Control No. 1 will strengthen the approach by ensuring that the security program is based on your organization’s unique operations. “If a tree falls in the forest and no one is there to hear it, does it make a sound?” The same riddle can be applied to ICS/OT security incidents. If a controller is compromised and fails to respond or requires a reboot—is it a cyber incident? Or is it a maintenance event? How would an operator discern between the two? In order to make a distinction between “cyber incident” and “maintenance,” pipeline security practitioners require ICS-specific data ranging from network traffic to asset information to threat detection capabilities. This is a combination of both technology and a trained workforce skill set. The technology, for example, needs to understand the various vendors and protocols used in the process control network, have the ability to passively monitor and not disrupt pipeline operations, and collect and aggregate data to support incident response and root cause analysis—among other system constraints that may be present in the process control environment. Meanwhile, the security team needs to be trained on what assets and activity matter most, how to interpret the various data being ingested, and when to escalate monitored events to cyber incidents. Control No. 1 has another prioritization role to play with ICS network monitoring, too. A common concern when creating a monitoring program is the number of alerts received through security technologies. By linking specific scenarios to the tactics, techniques, and procedures that potential adversaries may use to cause catastrophic impacts, security operations can provide playbooks for specific alerts to help scale ICS-specific response capabilities. As technologies advanced, the promise of remote access for isolated sites and regions became more enticing for businesses. Done properly, remote access can provide benefits for pipeline operations, including less constraints on the workforce, quicker response times for alerts, and improved efficiency for operations and troubleshooting. The earliest implementations of remote access involved dial-up modems, something that is still used in many operational environments today. That technology, however, is not scalable (nor is it real-time), so in recent decades, we have seen improved technologies for installing remote access in pipeline operations. If done correctly, remote access implementation is planful—requiring vendor documentation, access control review, and limiting the scope of what is included for remote operations. Unfortunately, remote access is not always leveraged with cybersecurity in mind. This has been compounded in recent years ever since the COVID pandemic, where lockdown procedures required pipeline operators to quickly put in remote access solutions with far fewer considerations than normally planned. Vendors started to provide free remote access technologies, employees began working from home on less secure home networks, and operational constraints led to nonideal situations that expanded remote access. This explosion of insecure remote access requires ICS/OT cybersecurity teams to know backtrack some poor decisions and, in some cases, rearchitect their remote access programs. Ideally, remote access will involve two-factor authentication, leveraging both a VPN for enterprise and a jump box or intermediate system that can verify users. Those solutions should then provide a trusted path to the ICS system where, again, the user should have to authenticate at the asset level. These multiple levels of authentication provide a defense-in-depth approach to remote access that, when combined with a least-privilege and defensible architecture (from Control No. 2), would provide multiple barriers for an attacker to exploit a system. Furthermore, with multiple steps required to access pipeline operational systems, each level of authentication should have their own logs that can be used in forensics investigations for any incident (and exercised with Control No. 1). Vulnerability management in ICS/OT cybersecurity has historically been a challenge for industrial sites. Many of these critical systems need to have near-constant uptime, and the corresponding lack of visibility or control while an asset is being patched presents unnecessary risks for operators and engineers. While patching systems are often viewed as routine in a traditional IT environment, the same is not true for ICS/OT systems. Since the main driver for ICS/OT cybersecurity is reliability and safety, the same must be true for specific elements of a cybersecurity program, including vulnerability management. Most vulnerabilities are IT-centric and focus on gaining access to specific assets. Recall, however, that many ICS/OT-based assets have a lifecycle measured over decades and often have poor access controls to begin with. An adversary does not need to exploit a 0-day vulnerability to gain access to an EWS—there are easier methods to achieve the same result. As such, it can be overwhelming and fruitless to chase down IT-centric vulnerabilities. Instead, asset owners and operators should focus on the small percentage of vulnerabilities that can actually impact reliability and safety through loss of visibility or control. Annually, this represents less than 10% of disclosed vulnerabilities, which is a far easier number to manage for resource-constrained programs. Once a vulnerability is identified as having the potential to impact ICS/OT reliability and safety, a risk-based approach should be used to identify what, if any, mitigation should be pursued. Sometimes, the best strategy is to simply monitor for the vulnerability being exploited within the system and have a playbook (similar to Control No. 1) on what to do when that happens. The US Department of Homeland Security has published a helpful flowchart for evaluating vulnerabilities and risks, Figure 2.2 [3]. Regardless of the specifics in the approach, mitigations for vulnerabilities must consider how it could potentially impact operations while providing a comparative level of security if the patch is not further pursued. Figure 2.2 Flowchart for evaluating vulnerabilities and risk. ([3]/U.S. Department of Homeland Security). As outlined in Section 2.5.2, pipeline operations comprise of a variety of interconnected systems. These include pumping stations, storage facilities, SCADA environments and networks, both passive and active safety systems, and a continuous range of maintenance operations and logistical support functions. Each of these systems and functions has downstream and upstream interactions and dependencies that have a cybersecurity footprint. Using scenarios can help pipeline owners and operators prioritize and apply mitigation strategies. The industry commonly does this when cybersecurity is not a consideration. Process hazard analysis (PHA) is a systemic approach to identify the scenarios where failure of processes or equipment may lead to a hazardous event. Taking this engineering discipline to the OT cybersecurity teams can allow owners and operators to understand how a hazardous scenario could be produced through the manipulation of data or systems or how purposely wrongful data is provided to human operators to intentionally make wrong decisions. As an example, engineering knowledge exists at the local facility to know that a particular variable frequency drive (VFD) to a particular pump is critical to the facility and overall operations. The OT cybersecurity teams, understanding that, can then analyze the architecture to identify the risks of control, damage, or manipulation to that VFD unit from a cybersecurity vantage point. Identifying, prioritizing, and mitigating on a scenario-by-scenario basis allows for thoughtful, planned, and specific application of the 5 ICS Cybersecurity Critical Controls outlined in Section 2.5. Pipeline cybersecurity shares a history with other critical infrastructure sectors leveraging ICS and operational technologies. There have been a variety of cyber incidents ranging from espionage to reliability and safety impacts. In this chapter, we explored the terminology and concepts required to build an ICS/OT-specific program—including the five critical controls that must be implemented. Industry will continue to see cyber incidents, especially as attackers gain more sophisticated techniques and understanding of how ICS/OT systems, like pipeline operations, work. Asset owners and operators should, therefore, be proactive in their approach and continue to evolve their security programs to meet the growing threat. Simultaneously, laws and regulations will continue to focus on critical infrastructure. While these localized requirements may change specifics within any given compliance-based program, the overall approach of the security policy will not need to deviate from the broader Five Critical Controls listed in this chapter. That said, it is vital that any security practitioner in pipeline operations stay current on regulatory trends to avoid any potential conflicts in the future. At the end of the day, the real driver for pipeline cybersecurity is to maintain reliability and safety across the organization’s service territory. Essentially, a security program is supposed to supplement operations—it is a partnership driving further efficiency, reliability, and safety. Every good partnership has compromises, and this one is no different. Be prepared for difficult conversations, but if everyone involved understands the objectives—and works together to obtain them—then we can, as an industry, make a difference.
2
Cybersecurity and Safety Implications of Pipelines
2.1 Introduction
2.2 Defining Industrial Cybersecurity
2.3 The Industrial Cybersecurity Challenge
2.4 Industrial Intrusion Case Studies—A Short History
2.5 Industrial Cybersecurity Considerations for Pipeline Operations
2.5.1 Is It Safe?
2.5.2 Dependent Systems and the Systems-of-Systems View
2.5.3 Understanding Vulnerabilities and the Engineering Mindset
2.6 The Five ICS Cybersecurity Critical Controls
2.6.1 Control No. 1: ICS-Specific Incident Response Plan
2.6.2 Control No. 2: Defensible Architecture
2.6.3 Control No. 3: ICS Network Visibility and Monitoring
2.6.4 Control No. 4: Secure Remote Access
2.6.5 Control No. 5: Risk-Based Vulnerability Management Program
2.7 Getting Started: Identify Common High-Impact Scenarios for Pipeline Operations
2.8 Conclusion
References