Securing Industrial Control Systems: What You Need to Know Now
Industrial operations are prime targets for hackers to disrupt and need to be hardened

Abstract

Hackers, including foreign saboteurs, and relentless, automated malware attacks are forcing factory and logistics operators of all sizes and across all industries to harden their industrial control systems (ICSs). While these systems can have many technical vulnerabilities, many operators face inertia and complacency in addressing them. This paper provides reasons why wait-and-see is no longer an option. At the same time, it offers guidance in how to proceed with a "defense-in-depth" best-practice strategy as well as resources for more information and guidance.

Authors
Keith A. Jones
President & CEO
Prism Systems
This email address is being protected from spambots. You need JavaScript enabled to view it.

Ming Ng
Profinet Technology Manager
Siemens Industry Automation Division
Siemens Industry, Inc.
This email address is being protected from spambots. You need JavaScript enabled to view it.

Industrial cyber attacks...just because hackers can, they will

For most people, April 8, 2014 came and went. For hackers worldwide, the date was a watershed. That's when Microsoft ended support for Windows XP, its 12-year-old operating system used by more than a billion PCs worldwide — including more than 30 percent of the PCs running industrial control systems (ICSs) across the globe.
With no more XP support, Microsoft stopped shipping patches to close security gaps in the estimated 45 million lines of code comprising XP. In effect, the cyber-barbarians pounding at XP's gates for more than a decade now found those gates unguarded and, soon enough, wide open.

Profound threats. Malware threats to ICSs using XP are profound because they can invade supervisory control and data acquisition (SCADA) and distributed control systems (DCS) in a wide variety of applications, from simple production to critical infrastructure. While hackers in the past may have ranged from bored but genius teenagers to the world's malcontents, recent evidence points to growing numbers of well-funded and trained foreign saboteurs intent on spying on operations or stealing data.

Worst of all, those threats can be potentially life-threatening. That's the biggest difference between a cyber attack on a corporate IT network and an ICS. If the former is attacked, the disruptions might be large, like data on millions of credit cards stolen from a large chain store. But if the latter is attacked at, say, a chemical factory, a toxic release could endanger the lives of thousands.

ICSs not using XP will typically use Unix-based operating systems, including Linux and Apple's Mac OS X. Although Unix may not be as prone to malware as XP, hackers still target it.

In September 2014, for example, the U.S. Department of Homeland Security's Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) issued an alert about a Unix security bug that enabled hackers to take complete control of any penetrated system. Experts rated it the highest in severity and the easiest for a hacker to use.

Targeting PLCs. But operating system malware isn't the only threat ICSs face. Hackers target PLCs, too, by penetrating the ICS, then drilling down to the PLC level. In 2014, the ICS-CERT notified five major PLC vendors of critical vulnerabilities found in their products that the vendors weren't aware of. These included buffer overflows, backdoors, weak authentication and encryption plus others that could allow attackers to take control of the device and interfere or halt the process it controls.

While Siemens PLCs were not among those identified, its own PLC software was attacked in 2010 by the Stuxnet virus, considered the most sophisticated virus ever developed. Since then, Siemens has redesigned and hardened its PLC software against cyber attacks. In fact, its latest PLC, the SIMATIC S7-1500, earned an Achilles Level II security certification, the highest accreditation possible from Wurldtech, a top industrial cyber-security provider.

Threats from within. All said, however, the biggest threats to industrial cyber security are unfortunately two of the hardest to address: operator inertia and complacency. Why? One reason is that large numbers of industrial operators, especially smaller ones, still don't fully understand cyber security risks. A brick maker, for example, might wonder why anyone would want to hack into its system. The answer, in short, is because hackers can.

With hackers automating their network assaults, one can occur every few minutes until a penetration occurs. To illustrate this, a Siemens security expert, who was leading a session on this topic at a recent conference, prefaced his remarks by opening a new, working web server connected to the Internet with its Modbus TCP/IP port 502 exposed. He left the port open while delivering his presentation. Before ending the session, he checked the web server's security monitoring software and found 35 attacks had occurred from all over the world—all in just one hour.

Other reasons for inertia and complacency about addressing security among ICS operators include:

• Management doesn't know how to monetize the risks to justify needed investments
• Operating personnel don't know how to protect their facilities from hackers
• Companies hesitate to act until they know what peers are doing

To be sure, awareness of the need for ever greater industrial cyber security has grown dramatically in the past decade. The U.S. Department of Homeland Security (DHS) established ICS-CERT in 2003 to support the private sector in hardening its industrial networks and systems.

In 2013, the White House issued Executive Order 13636 "Improving Critical Infrastructure Cybersecurity" followed a year later with a new Cyber Security Framework — a set of guidelines to help the private sector enhance cyber security and address cyber threats and vulnerabilities.

In turn, the DHS created and launched the Critical Infrastructure Cyber Community (C3) Voluntary Program. This gives critical infrastructure owners and operators access to services and cyber security experts in the DHS. They know about specific cyber threats as they emerge and quickly develop ways to counter those threats. They also provide counsel to identify and mitigate cyber vulnerabilities before an attack occurs.

How industrial systems are vulnerable to cyber attacks

Besides the life-safety distinction of ICS cyber security threats already mentioned, industrial networks differ from non-industrial IT networks in other ways. Many industrial facilities — nuclear plants and public communications, for example — must operate around the clock, in real- or near-real time and need 99.9% uptime or better. In contrast, most enterprise IT networks must simply work during "business hours."

Fact is, the disruption risks of a successful cyber attack on an industrial network can be much greater than for an enterprise IT network. Even if lives aren't in danger, production disruptions can have enormous costs not only in terms of lost output but also additional disruptions in downstream supply chains.

Extending vulnerabilities. While an industrial network may appear inside a company as a standalone, closed-loop system, one is often connected at some often obscure point to the company's enterprise network. If so, the latter's external-facing cyber vulnerabilities can then extend to the industrial network.

To make matters worse, the integration of the two kinds of networks can also introduce uncertainty within companies as to whether enterprise IT or process engineering owns responsibility for overall cyber security. As result, accountability issues can arise, manifesting themselves as cyber security gaps.

Legacy issues. Another set of security issues with industrial networks involves their evolution from early assortments of electrical relays or antiquated microprocessor controllers and manually monitored indicator lights, trips and breakers. While those legacy systems might work well enough to operate relatively simple processes even today, they likely lack proper security controls.

Still, they may well be connected to modern distributed control systems (DCSs) that feature the latest programmable logic controllers (PLCs), which are micro-computers using Windows or Linux and are connected over industrial Ethernet to human-machine interfaces (HMIs). In turn, these HMIs are often accessible anywhere in the world via PCs or touchscreen tablets and smartphones—by legitimate DCS operators or by hackers exploiting the vulnerabilities in the connections between old and new systems.

Problem: Flat networks. Finally, the ICS-CERT identified a particularly widespread risk in industrial networks: flat network topologies, especially interconnecting enterprise and control networks, as just described. According to a 2014 ICS-CERT report:

A commonly observed challenge and one of the easiest to address is a flat network topology. A risk associated with a flat network is the absence of logical segmentation, which serves to restrict communications originating from one portion of a network to another portion of the same network, for example that of a standard corporate/business network to the controls systems network. In a flat or non-segmented network topology, communications will be uninhibited and able to traverse across all elements within the network.

The problem of flat networks also applies to ICS networks themselves, putting aside the issues of interconnections with enterprise networks. Without getting into the technical details, a flat network is one in which the network switch or router, as shown in Figure 1, multicast the addresses of all the devices within the entire network's domain, so data can be sent and received from those devices. The domain can have as many devices as illustrated or even hundreds more. The problem? If hackers breach any part of a flat network, they can roam as far and wide as they want within that domain.

Figure 2 shows the ICS network split into two sub-domains. In this case, the network switch or router multicasts the device addresses within each of their respective sub-domains only. This is what the ICS-CERT refers to as a "logical segmentation" that keeps communications contained within that sub-domain. And should a sub-domain be penetrated, the hacker's field of play (or havoc) is restricted to that sub-domain.

"Defense-in-depth" — best practice to lower industrial security risks

The idea of segmenting ICS networks into logical sub-domains leads to an introduction of the network security industry's best-practice model known as "defense-in-depth." In effect, this strategy takes a layered approach to ICS security. It acknowledges that one countermeasure alone cannot mitigate all security threats. Instead, it increases an ICS's overall security by spreading the various risks of intrusion out over many layers of protection.

Securing the physical. Common-sense risk mitigation techniques should secure the physical environment, like locking PCs, servers, switches and other hardware elements in secure cages or rooms that are alarmed if anyone attempts unauthorized entry. The physical realm also includes establishing standardized, documented and enforceable security policies and procedures as well as staff training in those policies and procedures.

Securing the logical. In the logical environment, defense-in-depth risk mitigation techniques include network segmentation, as just discussed. It also involves using the most current versions of virtual private networks (VPNs), network firewalls and anti-virus software, plus keeping software patches up-to-date. Other logical mitigation techniques are using secure programming techniques and ICS components with software and firmware that have accredited security certifications and are backed by vendors who take cyber security seriously.

"Defense-in-depth" — putting it to work

Deployment of a defense-in-depth strategy has three basic steps: (1) a current state security assessment; (2) hardening the environment, both physical and logical; and (3) ongoing vigilance.

Step 1: Security Assessment. Every security risk mitigation effort for an ICS must start by evaluating the current state of its security. Some questions to consider:

• Who's responsible for securing the ICS? For many companies, this might not be clear—yet it's critically important that a qualified person or person be in charge. Consider this Step 1's first step.
  
  Years ago, ICS, SCADA, distributed control systems (DCSs) and safety systems typically evolved with industrial and process engineering teams in charge. Back then, enterprise IT teams had their hands full with rationalizing the corporate IT landscape. That may have left a large gray area of unclear responsibilities and sometimes adversarial relationships between the two groups.
  
  It can be a classic human story of in-fighting going on inside a city while invaders are scaling its walls. Executives – especially CEOs, CIOs and CISOs (chief information security officers) – need to identify a qualified company person or team to be in charge of securing the industrial control system, in concert with enterprise IT and plant or production management.
  
  This person or individuals should have clear cyber security roles, responsibilities and authority to formulate and enforce well-defined security governance policies for managers, system administrators and end-users.
  
  
• Are network hardware components physically secure? If not, they should. For example, if a SCADA server and its software is locked down to prevent tampering with its configurations and data, is the server itself then securely located to prevent unauthorized access to its network ports, removable media, keyboard and mouse? (The Stuxnet virus is believed to have been introduced to affected networks via saboteurs with hand-held USB flash drives.) Anything connected to an ICS network — PCs, servers, switches and other hardware components — should be locked in physically secured areas.
  
  
• Where are the network's security zones and conduits? An ICS should have distinct functional zones that separate the SCADA remote monitoring layer from the field device control layer. In turn, these should be distinct from the distributed control system (DCS) control layer. It should also be separate from any layer of safety-critical systems. Finally, the DCS and safety-critical system layers must not be connected with the enterprise IT layer. All those layers should communicate with each other only via carefully prescribed and secure conduit connections, each of which has a firewall. And all those layers need to be separated from external connections, each of which should also be carefully documented and also secured with a firewall.
  
  
• What and where is each connection within the ICS? This step helps identify what's known as the network attack interface. Look for internal local area network (LAN) connections and wide area network (WAN) connections; remote connections with distant sensors and operating facilities; internal wireless connections, including Internet connections; modem or dial-up connections (yes, they do still exist); and external connections to third-parties, such as business partners, vendors and regulatory agencies. Document all connections in detail and note their current security measures, especially their firewall protection and update status.
  
  
• What devices and software applications are connected, and what are their functions? This step helps identify what's known as the software attack interface. Similar to the step above, all hardware devices—HMIs, PCs, servers, wireless access points, phones, even printers and video surveillance cameras—must be catalogued along with all their operating system versions, software applications and the port numbers that each device uses to communicate. All current security measures should be noted as well as their status regarding updates and patches.
  
  
• How vulnerable are the network and software attack fabrics? After identifying all the elements subject to cyber attack, the next step is to conduct penetration testing, to determine each one's vulnerability. This can be a time-consuming, tedious task for large systems comprising hundreds of connections and components or more, but it's needed to fully assess the strengths and weaknesses of ICS, SCADA, DCS and safety networks, which are only as strong as their weakest components.

IMPORTANT NOTE: Due to the nature of these critical, real-time production systems, it's most important that any penetration testing be done in a lab environment and not on the production system itself. With extreme care, caution and coordination, production, operations and process safety management will need to conduct a risk analysis and develop contingency plans – with executive management sign-off – before doing any penetrating testing or modification of a live control system. Failure to do so could have grave consequences not only for the personnel and property of a plant or production site, but also for the people and property in surrounding communities. This is why any third-parties selected to help with ISC, SCADA, DCS and safety system security testing or modification must be exceptionally well-qualified and experienced in the engineering and workings of your system(s).

Step 2: Hardening. A thorough assessment will reveal all existing and potential security holes and everything that needs strengthening. In effect, the list of all a system's security shortcomings will become its punch list for action. Depending on how long that list is, prioritization may be needed to close the worst vulnerabilities. Assigning Security Access Levels (SALs) to each element (see sidebar) can help with prioritization. Next steps in this stage would include:

• Remove, disable or disconnect anything not needed. An assessment will probably uncover a lot of elements that were never needed but were installed as part of bigger installation or became unnecessary over time. If any such connections are found, disconnect them. If any unneeded software applications or default network services are found, remove or disable them.
  
  
• Secure all physical and logical interconnections. After the previous step, what's left needs protection. Ensure physical and logical security coincide, with strict access privileges for all users, providing access only to what they need to do their jobs. Logs should be kept for all accesses and video surveillance placed on the locked-down physical confines of network elements—HMIs, servers, routers, switches and so on. All firewalls should be up-to-date. Full security features should be turned on in all hardware devices, operating systems, software and hardware devices.
  
  
• Document, document, document. The catalog of a system's network and software attack surfaces should be the start of a full documentation of its security. This should include "as-built" system architecture diagrams showing all elements, their locations, their functions, their governance (i.e., owners/administrators) and their connections with other elements.
  
  Add to that written policies and procedures for: establishing, updating and terminating user accounts; upgrade and patch management policies, procedures and assigned responsibilities for all firewalls, devices and software applications; and scope, frequency and procedures for conducting security audits and penetration testing.
  
  All this documentation itself should have both version and access controls, plus always be backed up to an offsite location. That way, it will be available by alternative means if the system goes down due to a cyber attack or some unrelated disaster.
  
  
• Communicate, communicate, communicate. During the hardening stage, many employees and other stakeholders will become aware of what's going on, so it's important to communicate with them the reasons for doing so, let them know who is in charge of the effort, advise them of any changes in their day-to-day work as a result, and set proper expectations for their roles in supporting the effort.

Step 3: Ongoing vigilance. After hardening a company's ICS, SCADA, DCS and safety networks, the heightened protection will begin degrading over time without ongoing efforts to maintain security levels, to watch for and respond to apparent and actual attacks, and to conduct periodic security audits and tests. More specifically:

• Establish response teams to identify and evaluate potential attack scenarios. The designated person or team in charge of industrial network security should identify potential attack scenarios and then convene the core stakeholders of each scenario into a rapid response team.
  
  Each team member needs to imagine, describe and document the potential impact on his or her function should a security attack succeed, as well as what mitigation measures will be taken. Roles and responsibilities need to be assigned and contact information shared in a central place.
  
  The team should meet at least annually to reacquaint themselves with each other and with their risk and mitigation scenarios. It's a good idea to conduct so-called tabletop exercises that assume the worst-case scenario has occurred, to provide the team with practice in responding.
  
  
• Conduct periodic audits and penetration testing. The frequency of audits and penetration testing depends on how critical an industrial control system is to a company's functioning or the life-safety of personnel and surrounding communities. Obviously a nuclear plant would require much more frequent audits and systems testing than a dairy products plant. Industrial facilities, however, should conduct an audit and systems testing no less frequently than once a year.
  
  Notably, audits often overlook evaluating the currency of existing documentation, which can become as outdated along with the system being documented. That's why it's important to review and update documentation, too.
  
  Finally, if production lines are frequently reconfigured, with consequent changes made to their control systems, then mini-audits should be conducted periodically to avoid introducing any unintended system vulnerabilities.

* * *

Operators of industrial facilities must avoid inertia and complacency in addressing the increasingly urgent needs to harden the security of their ICSs and networks. Not only can security intrusions cause serious and costly production disruptions, they can also threaten lives of personnel and even of those in surrounding communities. But operators can take big steps to avoid these consequences by conducting an end-to-end assessment of their systems and networks, then deploying required protections. They should also institute an ongoing security audits and reviews by well-qualified individuals or cross-functional teams with the authority to enforce security policies and procedures. Ultimately, by securing their facilities against cyber attacks, they will ensure their reliable and safe operation.

Additional Information Sources

Below are three internationally recognized sets of ICS security standards, which can provide excellent starting points and guidance for securing complex ICSs and their networks:

• ISA/IEC 62443 (formerly ISA99): This series of standards, technical reports and other supporting information defines procedures for securing electronic ICSs. (Originally created by the International Society for Automation (ISA) and publicly released by the American National Standards Institute (ANSI), they were renumbered to correspond to the document numbering conventions of the International Electrotechnical Commission (IEC).)
  
  
• NIST 800-82: Published by the U.S. Department of Commerce's National Institute of Standards and Technology (NIST), the 155-page "Guide to Industrial Control Systems (ICS) Security" covers security for ICSs, SCADA systems, DCSs and PLCs in depth.
  
  
• NERC-CIP: The North American Electric Reliability Corporation (NERC) has created a series of Critical Infrastructure Protection (CIP) standards published as CIP-002-3 through CIP-009-3 to safeguard bulk electric systems.

In addition, the DHS and ICS-CERT websites offer extensive information resources for securing ICSs. These include assessment tools, recommended practices, reports and advisories. ICS-CERT also offers onsite assistance and has a toll-free hotline for reporting ICS security incidents.