Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

1/24/2013
03:52 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

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.

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' Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

 

Recommended Reading:

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/22/2020
The Problem with Artificial Intelligence in Security
Dr. Leila Powell, Lead Security Data Scientist, Panaseer,  5/26/2020
How an Industry Consortium Can Reinvent Security Solution Testing
Henry Harrison, Co-founder & Chief Technology Officer, Garrison,  5/21/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-10737
PUBLISHED: 2020-05-27
A race condition was found in the mkhomedir tool shipped with the oddjob package in versions before 0.34.5 and 0.34.6 wherein, during the home creation, mkhomedir copies the /etc/skel directory into the newly created home and changes its ownership to the home's user without properly checking the hom...
CVE-2020-13622
PUBLISHED: 2020-05-27
JerryScript 2.2.0 allows attackers to cause a denial of service (assertion failure) because a property key query for a Proxy object returns unintended data.
CVE-2020-13623
PUBLISHED: 2020-05-27
JerryScript 2.2.0 allows attackers to cause a denial of service (stack consumption) via a proxy operation.
CVE-2020-13616
PUBLISHED: 2020-05-26
The boost ASIO wrapper in net/asio.cpp in Pichi before 1.3.0 lacks TLS hostname verification.
CVE-2020-13614
PUBLISHED: 2020-05-26
An issue was discovered in ssl.c in Axel before 2.17.8. The TLS implementation lacks hostname verification.