SCADA Security 2.0
Siemens will consider whether to offer a bug bounty program as security experts look at new approaches to tackling SCADA security woes
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.
More Security Insights
- Integration with Oracle Fusion Financials Cloud Service
- Four Ways to Modernize Your Application Performance Monitoring Strategy for Web 2.0 and AJAX
- Solving Big Data Challenges with Simplicity & Speed
- Optimize Your SQL Environment for Performance & Flexibility
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.
|Read the first article in this series on SCADA security:
>> Part 1: The SCADA Patch Problem
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'