control, and governance
The Battle Over SCADA Systems
Industrial control systems could be attractive targets for hackers and a big risk for auditors.
“Hacktivist” groups such as “Anonymous,” proliferating across the cyber world, have been causing havoc to government and corporate websites and network infrastructures. Their arsenal: savvy hacks and disastrous distributed denial-of-service attacks. Their mission: disrupt organizations, governments, and companies. For example, Anonymous took credit for taking down hundreds of Israeli websites in response to Israel’s 2012 military operations in the Gaza Strip. This formidable and physical army was attacked and defeated by the best way this formidable and virtual army knew how.
Recently articles such as this GlobalPost piece — “Anonymous Pledges Support to Canada Anti-fracking Protesters” — have reported that Anonymous may turn its hacking prowess against those in the fracking community. Fracking, the controversial drilling technique, has allowed exploration and production (E&P) companies to drill into areas once off-limits to traditional drilling techniques. Fracking opponents, however, argue that fracking chemicals and techniques are endangering the environment and the populace.
So, with Anonymous possibly turning its attention to U.S. oil and gas companies, is it possible that the group could actually create turmoil for energy companies in general just to get its message across? Yes. How? By disrupting their supervisory control and data acquisition (SCADA) systems. Is it currently happening? Absolutely, as this October 2013 Infosecurity article, “Attackers Ramp up Threats to the Energy Sector,” illustrates.
While SCADA may sound like a very technical coding language or the latest data analytics tool, it’s just a generic way to describe industrial control systems. In a nutshell, SCADA was created to act as a remote monitoring system. Imagine for a moment that you owned an E&P company in the 1970s. Your company operated thousands of wells across several states. Each day, the company sent out numerous employees to monitor and report on its wells. All day, employees drove their company vehicles to their assigned wells, where they measured the amount of oil produced, performed routine maintenance, ensured that all machinery was operating effectively, and confirmed that there were no oil spills or gas leaks. While computers are not a one-to-one substitute for humans, the aforementioned process was (and still is) an inefficient way to monitor wells.
Now, let’s imagine that Employee A was at Well #1 and wasn’t scheduled to travel to Well #100 until late in the afternoon. Let’s imagine that Well #100’s oil tank sprang a leak late the day before. This has disaster written all over it. Examples like this one are why SCADA systems were developed and implemented.
Here’s a simple example of a SCADA system at work. Rick’s Pipeline Co. owns 600 miles of natural gas pipeline from Williston, N.D. (A) to a bulk terminal in Duluth, Minn. (B). For the gas to be transported safely and efficiently from point A to point B, human operators in Denver use human-machine interfaces (picture an operator at a large control panel with lots of flashing lights) to open, shut, monitor, and manage the flow of the gas. If the pressure rises too high in one section, sensors will send a message to the control system. The message is translated into the form of an alarm, alerting the operator (or in some cases a computer) to act on this problem. The operator monitoring the system will respond to the alarm and then mitigate the pressure in the pipeline by shutting off that section or diverting pressure to another section to alleviate the dangerous situation.
If human operators or computers are not alerted to these situations, just imagine the danger it could pose to any humans, homes, or environment near that section of the pipeline. Whew! Glad those pipeline companies have implemented IT security over their SCADA systems. Or, have they? Computer Weekly’s October 2013 article, “US Researchers Find 25 Security Vulnerabilities in SCADA Systems,” says they haven’t.
A SECURITY DISCONNECT
Let’s rewind and examine why many SCADA systems are ill-equipped for cyber warfare. Rudimentary SCADA systems have been in place since the 1950s. Like much of today’s technology, SCADA’s roots can be traced back to military beginnings. However, it wasn’t until the 1960s and 1970s that these systems began to proliferate across the industrial space. Some SCADA historians point to the advent of these systems in the automotive industry, while others point to the utilities industry as their first true users.
Today, SCADA is used in numerous industries and areas: oil and gas, electric power transmissions, manufacturing, water treatment, wind farms, civil defense systems, and aerospace. However, if they are so prolific and have been used for decades, why haven’t they undergone the same IT security scrutiny that today’s corporate networks have? The easiest explanation is that they have been “off the grid.” Originally, SCADA systems were not connected to the Internet — the Internet wasn’t even around. Instead, they existed in self-contained environments. In the 1980s and early 1990s, as networked computer topologies were being created and the Internet was coming online, companies did not worry about malware, denial-of-service attacks, or computer viruses. It was during this time that companies were first slowly connecting their SCADA systems to their networks. However, with the advent of malware and computer viruses, IT security professionals began to arm their organizations’ networks, but beefing up security did not always include their SCADA systems.
Perhaps this lapse in security was due to the belief that because these systems were secured physically, no harm could befall them, or perhaps it was the fact that these systems were out of sight (out of mind) and were not valuable targets for hackers. Perhaps it was because they were built with proprietary technologies, and it was just too difficult to implement security measures therein. Whatever the reason for the lack of security measures in the past, their vulnerabilities have certainly gotten the attention of companies and governments. Enter Stuxnet. In 2010, Iranian nuclear facilities using Siemens SCADA systems were critically affected by this computer worm. Now other countries believe similar attacks could be launched against their critical SCADA systems.
Let’s turn our attention back to the original premise of a group such as Anonymous spreading a computer worm on an oil and gas company’s SCADA system. The answer is obviously “yes,” so what can be done to prevent or deter such an attack? The first step in prevention is education. These companies may not be aware of all the threats to their SCADA systems and how vulnerable they are. Secondly, auditors need to put SCADA systems on their audit radar. If auditors don’t even know whether their company uses a SCADA system, then they had better perform preliminary research on SCADA itself, meet with operations, and get this risk area on next year’s audit plan.
Even if they are neophytes to the SCADA world, auditors still can conduct a thorough audit program over their company’s system. It begins with the basics. First, what are the systems involved? Is there more than one? Has the company purchased or built its SCADA system? When was it implemented? If it was built and implemented by a third party, is that company still in business? Is the company’s SCADA data or devices more susceptible to attacks than others?
The audit also should focus on SCADA roles and responsibilities within the company. Has the company identified specific roles to manage and oversee the system? Who performs the maintenance over SCADA equipment? How do employees stay current in their knowledge of the company’s SCADA system? Have policies and procedures been developed? Are those documents up to date? Do they really address the risks?
Next, auditors should never underestimate what they can uncover from site visits. Meet with operational personnel to identify key sites equipped with SCADA components. Auditors should plan their visit with an employee who has strong SCADA knowledge, which will give them an opportunity to ask questions and inventory equipment. While on site, consider physical and logical controls. Who has physical access to these assets? How do they monitor access? Is logical access available at the physical site? Are control boards equipped with passwords? Who knows those passwords?
Finally, a SCADA audit should include interviews and tests of network security. Ascertain the skills and know-how of those in charge of IT security over SCADA. Who can access SCADA data or code? Is access monitored? How is it monitored? Are SCADA assets under the same antivirus protection and protocols as other company assets? Has this group implemented a threat model to understand whether the system security is under threat and by whom?
CLOSING WEAK LINKS
Regardless of the perpetrator, do not be surprised to read more news on hacks into corporate and government networks and physical assets. These cyber wars will continue to rage on and become more prevalent, while their list of targets widens. That is all the more reason why auditors must help strengthen their organization’s first line of defense and possible weak link in their armor by assessing and auditing its SCADA system.
Rick Roybal, CISA, is the Compliance & Risk Manager for FIML Natural Resources in Denver.