SCADA Security 2.0

Second installment in an occasional series on SCADA security

No one disputes that there's a dire need for major change in addressing serious gaping security holes in SCADA/industrial control systems (ICS) today. Frustrated with the inertia associated with blatantly insecure SCADA/ICS systems in production at power plants and other sensitive operations in the U.S. and around the globe, security experts are now rethinking how to fix the SCADA/ICS security problem.

Among the strategies under consideration are bug bounty programs for SCADA vendors, and a more proactive and prescriptive role by government officials in the U.S. Patching, they say, is a short-term solution to a much bigger problem of products that by design are insecure. And with only 10 to 20 percent of customers applying the patches, it can be an exercise in futility in many cases. Security researchers at the S4x13 SCADA conference in Miami last week showed how easily they found some of the most basic security bugs in these systems, prompting discussion on new tactics for securing these systems.

Some experts are calling for better collaboration between SCADA vendors and the security community -- and to consider bug bounty programs like Google and Facebook have successfully deployed. Under those programs, the vendors pay security researchers for the vulnerabilities they find in their products.

And at least one SCADA vendor isn't averse to the idea. Siemens Product CERT member Tobias Limmer did not dismiss the concept of a bug bounty program in an interview with Dark Reading last week. "We really have to think about that," Tobias said. "But I can't comment further."

Bug bounty programs in the sensitive SCADA world might be tricky, however, security experts say. Dale Peterson, CEO of Digital Bond, which hosted the S4x13 SCADA conference, says it would depend on the types of SCADA products.

"It could work, but you have to be careful of what you picked on. A lot of products we saw picked apart [last week at S4x13] were Siemens products that were not ready for bug bounties. They were just old, bad code. That wouldn't work," Peterson says.

It's difficult for researchers to get hold of SCADA/ICS products, anyway, he says. A better approach would be bug bounty programs for newer-generation software that has been designed with secure coding in mind. "If you take software like Raspberry Pi server ... they've gone several years into their SDL [software development life cycle]. Other vendors with newer products designed with secure coding have simple design bugs ... those vendors could use [a bug bounty program]," he says.

But many SCADA vendors would be hesitant to offer a bug bounty program for intellectual property reasons, he says.

Chris Wysopal, a.k.a. Weld Pond, and CTO of Veracode, says bug bounty programs would be a good fit for the SCADA space. But secure coding should remain a top priority for the vendors: "I think bug bounties send the right message to the research community that you want to receive bug reports and you are going to act on them. It is not a replacement for a secure SDLC [software development life cycle], of course," Wysopal says. "Given the sensitivity, SCADA vulnerabilities need to be disclosed to the vendor and fixed before they are made public. A bug bounty can only help this."

[One of the most prolific SCADA bug-finding research teams is building a prototype defensive technique for protecting industrial control systems they are best known for hacking. See SCADA Hackers Go On Defense.]

No More Excuses
Peterson, meanwhile, is also calling for vendors and critical infrastructure owner/operators to dismiss the mindset that it's too hard to secure existing products. He calls this a "SCADA apologist" phenomenon in the SCADA/ICS industry, where people talk about the seriousness of SCADA security, but don't follow through and demand fixing it.

One of the biggest SCADA apologists, he says, is the federal government. "When you see the Project Basecamp results or other similar very serious issues, you do not also hear DHS [Department of Homeland Security] or other parts of the government say this needs to be fixed. Their guidance is compensating controls -- stop the bad guys from getting there," Peterson says.

He says the feds are the some of the biggest "SCADA apologists."

"Both government and vendors take pride in handling vulnerabilities, but the underlying product is still insecure. There's a false comfort happening" there, he says. "We've been pushing the government, saying, 'Can't you come out and say [these products] are insecure by design and need to be upgraded?' But they won't."

DHS's ICS-CERT program over the past two years has become more prolific in issuing security alerts. ICS-CERT issued a handful of advisories last week addressing SCADA product vulnerabilities and in one case, a password-cracking tool, which were unveiled at S4x13.

SCADA systems are known for their longevity, especially systems on the plant floor, because they are expensive and entrenched into the operation. Many plant-floor systems are decades old, and obviously highly sensitive to any disruption in operation, especially when you're talking about a power plant. Those that can be patched probably won't be, though: If something goes wrong when an engineer applies a software update and a plant ends up getting shut down, his job is on the line.

But Digital Bond's Peterson contends that the excuses for not updating this equipment are overblown. "The only reason they have that long life cycle [for those products] is because they choose to," he says. "Most of these projects to replace PLCs are about one to three years. That's typical."

It's less a technical problem and more a money issue, he says. The cost associated with replacing vulnerable PLCs is a lot cheaper than the costs an attack would incur, he contends. "It's just a matter of money and will, but until the 'experts' stop being SCADA apologists, it will be difficult to make progress because they have convinced the policy-makers and C-level execs that it is an intractable problem," he says.

Next Page: Compartmentalization 'a good option' Scary Reality Check?
Veracode's Wysopal says patching isn't the answer for most SCADA systems. "The systems are not designed to be updated and patched at the pace that security updates would require," he says. "I think there has to be the mentality of compartmentalizing these systems such that you use network security to keep from reaching those systems ... That means essentially having an air-gapped network because you can't even have clients on the inside."

Until those systems are designed so they can be safely and easily updated, compartmentalization is a good option, he says.

Meantime, the worry is that it will take a big wake-up call to force any palpable change to securing the systems that run critical infrastructure and other processes.

"Many people tell me this will not be fixed until some power plant, pipeline, chemical plant, or something else has a major disaster caused by a cyberattack -- one that causes a huge financial impact to the economy, loss of life, etc. Then everyone will spring into action and say these insecure-by-design systems need to be replaced in 'X' years," Peterson says. "I'm hoping they are wrong, and we can begin this prior to the disaster."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Idaho National Lab Working On
'Resilient' Critical Infrastructure

Researchers at the Department of Energy's Idaho National Laboratory (INL) are testing and designing ways to make process control systems resilient to cyberattacks and natural disasters like Hurricane Sandy.

INL's resilience project focuses on two basic ways resilient systems can automatically cope and react to such events: by adaptation and transformation.

Craig Rieger, INL's program lead for Instrumentation Control and Intelligent Systems, says the project predates Stuxnet's discovery. INL has joined forces with universities and SCADA industry players to help integrate resilience into control system designs.

"The outcomes of these initiatives will affect how future generations of system designers approach next-generation designs to ensure they are inherently resilient," according to an INL article on the program.

Rieger says the goal is to automate the systems' reactions when an attacker is detected and to quickly alert the necessary human operators as well. "It's not just recognizing attacks so that select sensors go uncorrupted, for example ... But it's presenting this to operators so they have awareness" as well, he says. "We present it in a way that the operator can understand it."

"The faster we can make them made to react better, and to getting a quick adjustment that is not dependent on a human as much," is key, he says.

"We're trying to make the current system more secure," he says.

Among the individual projects under the resiliency program: one that handles fluid-flow systems, including valves and transmitters. "We are working on implementing a full-scale system like a car," he says.

---Kelly Jackson Higgins, Dark Reading