A Primer on Industrial Control Systems Cybersecurity

It has been said that industrial control systems (ICS) are ruling the world. While traditionally thought of in the context of manufacturing and infrastructure, ‘ICS’ is actually a broad term (and a broad field) that can mean much more. These systems are often comprised of mission-critical applications for a corporation or community, in which uptime is of great importance. For corporations, any amount of downtime or Denial of Service (DoS) can result in significant loss of revenue and brand damage from dissatisfied customers. In the case of infrastructure, downtime or DoS can result in a break in the delivery of key services and resources that allow people to carry out their lives. In extreme cases, this could mean the difference between life and death. Perhaps of even more fundamental importance is the system’s data integrity: if the system is up but the integrity is compromised, then there is still potential for negative consequences. For example, recent research has demonstrated that data integrity attacks on smart grid wide area monitoring systems can trigger wrong decisions and create dangerous failures in the smart grid system.

Real World Instances of Cyber Attacks on Industrial Control Systems

Industrial Controls Systems are not immune to cyber attacks and the resulting damage and/or DoS from such attacks. One of the more well-known incidents was the Stuxnet worm that caused significant damage to Iran’s nuclear program. In addition to exploiting some Windows 0-day flaws, the worm also took advantage of some basic vulnerabilities in the Siemens control system software (including hard-coded passwords). The malware used in the attack focused on Iran’s centrifuges and recorded data under normal operating conditions for a period of time. Achieving root access to the programmable logic controllers (PLCs) allowed the malware to then present the recorded (normal-looking) data to the operator while throwing the actual behavior of the centrifuge out of tolerance, leading to more than 1000 centrifuges being damaged before operators discovered the cause. It’s clear, from this example, that protecting data integrity is critical for industrial control systems and that security measures play a key part in accomplishing this goal.

Recent surveys by FireEye and Forrester indicate that ICS are increasingly under attack and that the current state of security in these systems is generally poor. As an example of this, CyberX’s 2019 Global ICS and IIoT Risk Report found that 69 percent of industrial sites have plain text passwords traversing the network.

More and more, Industrial Control Systems are being connected to the Internet of Things and exchanging data with the cloud. The traditionally isolated OT (operational technology) networks employed by ICS are increasingly leveraging IP-based networking technologies and connecting to corporate IT networks and the cloud for remote control and monitoring. The 2019 CyberX Report found that 40 percent of OT networks had direct connections to the internet. System component providers are riding the Industrial IoT wave and supporting many of the IP-based messaging protocols (such as MQTT, XMPP, AMQP, Thread, HyperCat, ZigBee, Pub/Sub) even though they are operating on isolated OT networks. As such, the attack surface broadens and the security implications must be carefully examined.

This excerpt, from a blog article by Lumeta, captures how ICS is evolving, and therefore being exposed to additional risk:

“…when we move to non-proprietary communication and network technologies for these systems and use more off-the-shelf commercial operating systems, we also expose them to additional cyber risk.

In the past, organizations would have a strong separation between traditional IT infrastructure and operational technologies, thus the terms IT and OT as distinctly separate, to strictly control access to the OT network. While there has been this hard separation of IT/OT networks, they are both increasingly using similar commercial IP network and operating system protocols which are softening that separation.

TrendMicro also has something to say on this topic:

The convergence of IT and OT provides enterprises with greater integration and visibility of the supply chain– which include their critical assets, logistics, plans, and operation processes. Having a good view of the supply chain helps organizations remain competitive. On the flip side, however, the convergence of OT and IT allows easier access to these two components that are targets of cybercriminals. In many organizations, OT infrastructure is, at best, poorly protected against cyber attacks.

It’s worth it to clarify some of the acronyms and terminology around ICS.

ICS — Industrial Control Systems. This is the catch-all term. TrendMicro has a good definition: “ICS is a collective term used to describe different types of control systems and associated instrumentation, which includes the devices, systems, networks, and controls used to operate and/or automate industrial processes. Depending on the industry, each ICS functions differently and [is] built to electronically manage tasks efficiently.
IACS — Industrial Automation and Control Systems. This is the term for ICS that is used by ISA (International Society of Automation)
SCADA — Supervisory Control and Data Acquisition. You will often see SCADA mentioned alongside ICS. This term is a subset of ICS and refers to systems that provide centralized control and monitoring for geographically-dispersed site components common in infrastructure projects like gas pipelines, water distribution, and electrical grids.
OT — Operational Technology. This refers to the computing systems that are used to manage industrial operations. It is the environment in which ICS is implemented.
IIoT — Industrial Internet of Things. IoT technology employed for industrial purposes. IIoT can be leveraged to implement an ICS, but can also be used for monitoring and safety purposes in the workforce.

Image credit: KuppingerCole

Examples of Industrial Control Systems

Public Infrastructure. This can include gas pipelines, water distribution, and electrical grids.
Manufacturing automation and control. This covers a wide array of automation in product-producing factories from building automobiles to brewing beer.
Supply chain. ICS and IoT technologies are increasingly being employed to optimize supply chains. Automated warehouses (with robotics) working together with e-commerce systems and rigorous shipping logistics represent the future of supply chain.

Overview of ISA/IEC 62443

ANSI/ISA 62443 is a series of standards, technical reports, and related information, the primary goal of which (according to the standard itself) “is to provide a flexible framework that facilitates addressing current and future vulnerabilities in IACS and applying necessary mitigations in a systematic, defensible manner. It is important to understand that the intention of the ISA‑62443 series is to build extensions to enterprise security that adapt the requirements for business IT systems and combines them with the unique requirements for strong availability needed by IACS.

The series is organized into 4 main categories:

1. General (62443–1). This group includes elements that address topics common to the entire series.
2. Policies and procedures (62443–2). Elements in this group focus on the policies and procedures associated with IACS security.
3. System Requirements (62443–3). The Elements in the third group address requirements at the system level.
4. Component Requirements (62443–4). The fourth and final group includes elements that provide information about the more specific and detailed requirements associated with the development of IACS products.

When it comes to the software development lifecycle (SDLC) for Industrial Control Systems, the following parts of the standard define the security requirements in detail:

ISA-62443–3–3, as part of the series, defines detailed technical requirements for IACS security. There are seven foundational requirement (FR) groups and four security levels (SLs) that are defined in the standard. The required security level for the system is determined through risk analysis. System requirements (SRs) for various security levels are different. SRs are defined in the standard under relevant FRs. Some of the SRs have requirement enhancements (REs) that apply to all or some of the SLs. A list of FR and SR for this section appears below for reference.
ISA-62443–4–2, as part of the series, defines detailed technical requirements for embedded components, network components, host components, and applications. There are seven foundational requirement (FR) groups and four security levels (SL-Cs) in the standard. The requirements in the 62443–4–2 standard are derived from ISA-62443–3–3 (system security requirements) but address devices, components, and applications rather than the entire control system.

Overview of NIST 800–82

NIST Special Publication 800–82 is a Guide to Industrial Control Systems Security. This is a similar, alternative framework to ISA 62443, and related to the well-known NIST Risk Management Framework and associated “special publications”. As stated in the SP 800–82 executive summary, it can be considered an ‘overlay’ to SP 800–53:

The National Institute of Standards and Technology (NIST), in cooperation with the public and private sector ICS community, has developed specific guidance on the application of the security controls in NIST Special Publication (SP) 800–53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations [22], to ICS. While many controls in Appendix F of NIST SP 800–53 are applicable to ICS as written, many controls require ICS-specific interpretation and/or augmentation…

In fact, NIST SP 800–82 refers to many other NIST special publications throughout the document and then goes on to provide the “ICS-specific Recommendations and Guidance” in each case. There are entire sections dedicated to ICS Security Program Development and Deployment in addition to ICS Security Architecture. Section 6 covers the application of security controls to ICS in the context of the NIST RMF (Categorize, Select, Implement, Assess, Authorize, Monitor) and SP 800–53 controls. NIST SP 800–82 exists only in the context of SP 800–53 as an ‘overlay’ and the two standards go hand in hand.

About Policies and Procedures

Beyond the actual coding, testing, and deployment of systems and software, there are the policies and procedures related to the control system lifecycle. The lack of a security policy itself can introduce vulnerabilities and predisposing conditions for industrial control systems. A comprehensive and documented security policy is necessary to define the roles, implementation guides (i.e., procedures) and enforcement of the system’s security program. Management support and governance of the security policies and procedures is a key driver in the success of any program.

•800–82 quote: “Enforcement is a partner to policy, encouraging people to do the “right” thing.”

Both ISA/IEC 62443 and NIST SP 800–82 cover the topic of policies and procedures in depth, but each takes slightly different approaches.

The 62443–2 category is dedicated to this topic and is broken up into 4 subparts that all speak mostly in terms of building a cybersecurity management system that is relevant for IACS environments. This is also referred to in the standard as an IACS security program or (more frequently) an IACS security management system. The first part (62443–2–1) outlines requirements for a successful IACS security management system, while part 2 (62443–2–2) provides guidance for implementing such a system. The third part (62443–2–3) goes into detail about the recommended patch and change management processes for the system, while the fourth part (62443–2–4) echoes security program requirements, but this time for IACS service providers.

NIST SP 800–82 is also an excellent resource for policies and procedures and even dedicates an entire section in Appendix C about identifying vulnerabilities and predisposing conditions related to (lack of) policies and procedures. Appendix G covers the list of recommended controls and, in essence, recommends to have documented security policies and procedures for each control family (an overlay of SP 800–53) in the standard.

Which ICS Security Framework is Right for You?

Both the ISA/IEC 62443 and NIST SP 800–82 standards are comprehensive in their coverage and guidance for ICS Security. Although there are other security standards, initiatives and recommended practices in this space, these two frameworks are the most well known and adopted. There is no single product, technology, or methodology that can fully secure ICS applications. A multi-faceted, holistic approach is required to address the varying (and increasing number of) threats that uses a diverse toolset, applied to many different layers of the system, by many personnel. Following a security framework can help guide organizations into such a holistic approach.

In many cases, the selection of a framework will depend on the industry and associated regulatory drivers that may call for a specific framework. The public sector, for example, is generally required to follow NIST standards.

The main thing is to select and execute on one of the standards because to do nothing is negligent and a recipe for disaster. Whatever framework you choose, it is good to be familiar with both — even though there is quite a bit of overlap, each provides a wealth of information about protecting ICS.

Conclusion

The security related to Industrial Control Systems is undoubtedly critical: communities and nations rely on such critical infrastructure being adequately secure, and the functioning of business critical systems is essential for revenue. Fortunately, standards organizations such as NIST, IEC, and ISA have done the research to develop frameworks for ICS security. Leveraging such frameworks, however, is challenging and requires extensive planning, as well as resource allocation and budgeting for the necessary tools and execution processes. Most importantly, organizations will require buy-in from key stakeholders for the successful adherence to these security policy-derived procedures. This article is the second in a series of IIoT and ICS Security pieces. Stay in touch to read the next piece on the new California Regulation, SB 327ISA/IEC 62443.

Security Compass’s expert policy-to-execution platform, SD Elements, can help with the implementation of relevant security policies into your ICS and IIoT software.

To learn more about SD Elements, visit here: www.securitycompass.com/sdelements

Previous Article
An Introduction to California’s Upcoming IoT Regulations
An Introduction to California’s Upcoming IoT Regulations

Learn about California's new IoT regulations.

Next Article
Why IoT Development is Heading to Agile
Why IoT Development is Heading to Agile

Research Directory Atlaz Valani weighs in on IoT development practices.