hiring
AAA  AAA 

Liveblogging: SANS Security Summit Day 1

Morning Keynote Panel

The SANS Security summit kicked off bright and early with about 200 people in attendence at Tom Donahue, CIA’s keynote. Interesting comment paraphrased, not clear that terrorists are interested in cyber attacks on critical infrastructure because they don’t have the dramatic display that impresses the terrorists constituency. Terrorists have focused more on dramatic physical events on iconic physical images and prominent people. This could change, “at some point someone is going to do something”. Do you have a plan to reconstitute (recover).

I’d call Tom a skeptic on the cyber terrorist threat to the critical infrastructure.

Next up is Jason Stamp of Sandia. “Security is 5-10 years behind typical IT systems. Same (security) mistakes as IT, only years later.” My comment - we have seen emerging countries leapfrog technologies in areas like mobile networks and communications infrastructure, moving from far behind to far ahead. Is this possible in some areas of control systems? Not a lot new here, but a nice overview of the state of control system security.

Final keynote panelist is Jason Larsen, INL. Jason leads the INL team that performs security assessment on vendor control systems. “Script kiddie is not going to be able to understand or control your system. Just going to click around.” Agree but I think this is missing the point that script kiddies may intentionally or inadvertently bring a critical system down.

“Professional hackers prefer to modify vendor’s software or patches in route.” Anti-virus used as a means to distribute attacks. Fairly provocative presentation by Mr. Larsen.

The audience has grown to 300+. About 50% of the audience is from the power industry.

The format of this event is shorter presentations followed by questions that must by written audience questions read by the moderator.

Tom, CIA, says HIPAA, SOX had the biggest impact on improving corporate security, and same would occur if Congress passed a law for SCADA. One thing that should be in the law is “isolation” of these networks. Audience is against Congress getting involved.

Interesting Question: Score security posture 1 to 10. James Stamp: Finance 7, SCADA Oil and Gas 5, SCADA Electric quite a bit lower than oil and gas, SCADA Water less than electric

Next up is Alan Paller, SANS on the Three Faces of Cybercrime.

I glanced through the presentation. Lots of clippings on cybercrime incidents. Skipping this one.

Technology Panel 1: Testing the Security of Industrial Control Systems

Rita Wells, INL – Like doing in house (at the lab) assessments vs. on-site assessments because in house does not affect a production system. 10 assessments done to date. This jibes with what I hear in the community. There is a lot of demand for INL to test vendor systems at the lab.

Eric Byres, BCIT – Ping sweep on a robotic arm, arm swung around 9’. Eric talked about Project Achilles that tests PLC’s for vulnerabilities.

Ray Parks, Sandia – His proposal: the community needs to develop a testing program structure. Today it is first through the door gets tested. Ray sees three categories, Technology, Protocol and Infrastructure and recommends a triage program. We should be testing the high impact systems first, not the first through the door. Wafer Fab lost 4 hours of production and a batch due to a scan.

Q&A – Eric Byres, “It would be cool if vendors would say these are acceptable tools (scanning) on our systems”. Alan Paller, “Gartner Group recommends buyers put in a RFP requirement to provide scanning results in the proposal”. Interesting. This ties in with the need for some good procurement language in patching, anti-virus.

Rita – Vendors determine whether the results of the assessment are shared with any affected asset owners.

Eric – we would bankrupt the vendors and the end users if we required them to retrofit all the systems to fix vulnerabilities. Huge problem. New systems are a more tractable problem.

Ray – Sandia is working on a NERC CIP compliance course. Alpha version of the course in a few weeks. Rita – NERC has reviewed the INL courses and ‘approved’ them. This does not mean you are NERC CIP certified.

Technology Panel 2: Building Blocks of Security on Control Systems

Came in late to this one. This is a vendor panel with Honeywell, Invensys and Emerson. All three combined in a single presentation. A lot of basics in this presentation. DMZ, anti-virus, Disaster Recovery, Security Policy … Not bad, just basic.

Honeywell, “It’s our responsibility to tell you what should go through the firewall”.
All three vendors say they test and certify patches within seven days. BP (the moderator) won’t buy a product unless they certify anti-virus, test with Achilles or other systems and commit to testing patches within xx days. Recommends other asset owners levy more security requirements on their prospective vendors.

Honeywell and other say they have a hardened Windows config. I’d like to see these and compare to the Center for Internet Security recommendations.

Technology Panel 3: The Asset Owners

Exxon Mobil, Southern Company, and PJM presented key points on the security program. Again there was little new here, but they are dramatic examples that securing control systems can be accomplished. Too often we hear about problems, these are success stories.

A couple of things caught my attention. Exxon Mobil is planning to deploy firewalls between the control center and the PLC’s. This has been a hot button of mine as Ethernet ports with IP connectivity to the control center are increasing available in unmanned field sites. Exxon Mobil also has a standard, hardened config for Windows in the process control environment.

Southern Company breaks their efforts into three categories: Assessments, Hardening and Compliance.

The presenter from PJM had a good pitch on not overclassifying systems as critical, especially in the NERC context. Consider what would happen if the system is not available.

Technology Panel 5: The Government

I’ m losing steam as the day gets long. So the length of the blog is not a reflection of the presentations. Hank Kenchington (DoE), Hun Kim (DHS), Karl Williams (NISCC), Will Pelgrin (State of NY) and a rep from NY Power Authority finished the last panel.

Hank said the labs will have tested systems from Areva, ABB, GE and Siemens by the end of the year. Good news is the testing has resulted in some security patches and therefore more secure systems. Also, as Matt noted earlier, the DoE roadmap is available at www.controlsystemsroadmap.net .

The State of NY is leading an effort to define security language for control system procurement. A number of entities, including DHS, are contributing to this effort.

Hun and Karl gave an overview of the efforts in their respective organizations.

Achilles

Finally, I got to see a demo of BCIT’s Achilles program. As always, BCIT had a unique spin on this unveiling. They are looking to spin this product off to a commercial entity and led a session to critically review the product from an asset owner and control system vendor perspective.

Achilles has a lot of features and options. Hard to give a detailed review without a serious test drive. It looks highly interesting, especially the grammer/fuzzing tools.

Long day and I cut out a bit early at 7:30PM.

Comments

Comment from Anonymous
Time: March 2, 2006, 10:32 am

Three Faces - was all about ancient hacks.

Alan showed a IMAPd/Netbus attack on a corporate network. It was news to the audience that this was possible. There were audible gasps of surprise.

The threats are all real, getting to the point where people understand them is going to take much more work. Not enough of the right people are here I think. I’m an actual security guy for my org - but we should’ve sent some of the SCADA side people, they need this kind of talk delivered from the outside - I can’t have this kind of impact on them.

Comment from Matt Franz
Time: March 2, 2006, 1:26 pm

Although I may not have enough context for proper critique, I’d have to disagree with Eric Byres comment on bankrupting vendors.

Vendors aren’t responsible for fixing bugs?

Vulnerabilities are not vulnerabilities are not vulnerabilities!

Having to retrofit legacy protocols and devices may be unreasonable, but making one line code changes to prevent “one packet killers?”

Customer should demand this and vote with their purchase orders to reward vendors that are responsive to fixing security flaws.

Plugging a device into Ethernet/802.11 network implies a certain level of responsibility and due diligence, whether that product is new or years old.

Comment from Anonymous
Time: March 2, 2006, 4:41 pm

Matt, from my perspective, no one is willing (apparently) to admit that this problem could be fixed. What I’ve heard (for two days) is a whole lot of “we’ll get there - it will take a decade, but we’ll get there”, instead of a “we need to work on the problem with people and we need to apply what technical fixes we can”.

It would be so simple to sandbox, isolate or otherwise provide bolt on protections for the bulk of these protocols. It would be so easy to add intelligent application layer firewalls in front of the FEPs. It would be so easy to apply the lessons learned in the last 10 years on the “commercial” or traditional IT front - if we could just flip the culture of the engineers to allow them to listen to people who have spent their professional lives figuring out how to break through pre-conceptions.

It doesn’t have to bankrupt anyone - it would cost something like a dollar per employee in just the power industry to do the necessary R&D work to make this a solved problem.

I’m looking around, and all I can see is ostrich butts.

Comment from Matt Franz
Time: March 3, 2006, 1:17 pm

Anonymous,

Agreed about the external countermeasures–would love to chat some more about this offline, unless we already have ;)
I’m still curious about fixing implemention flaws in the products.

How long does it take for non-security “sev-1 bugs” (as we used to say at Cisco) to get fixed? Interoperability, performance, reliability, etc.

It’s all about a big/important customer raising hell, right?

I had a discussion with a vendor several weeks back on this topic. He said upgrading firmware is painful for his customers. But I asked they do upgrade firware, right? He said yes. And I asked how often? He said every 6 months and they have regulatory requirements that fixes be tested.

So I asked how is this so different from Tier 1 ISPs?

Upgrading IOS can be “quite painful” as well–what can be worse than using Xmodem to an old 3600 when you hose the bootflash?

And yes these folks doing a fair amount of testing, since there are things called SLA’s.

Write a comment