Comment from Sardis Renfro
Time: November 30, 2007, 11:34 am

How does the insider attack on the California canal SCADA system have anything to do with the doom and gloom remote attack scenarios making the headlines? He had full access to the systems and could install whatever he liked, just like the thousands of other SCADA system programmers and administrators out there.

Comment from Jake Brodsky
Time: November 30, 2007, 6:27 pm

The FIRST application note mentions a wireshark crash on the DNP protocol. True, one shouldn’t crash over stupid stuff like this. And note that it has been fixed in the Wireshark DNP stack.

However, at ACS’s recent security conference in Knoxville we all observed how easy a denial of service attack could be accomplished against ANY SCADA protocol.

Not even secure authentication or encryption can stop that.

Remember folks, the first letter in SCADA stands for Supervisory. The remote device is supposed to do something reasonable in the event communications is lost. A denial of service isn’t supposed to be the end of the world. Unpleasant? Sure. But while that something is attacking, people are going to be hunting down the culprit. Finding the problem is only a matter of time.

Comment from Jake Brodsky
Time: November 30, 2007, 7:16 pm

Regarding the TCAA SCADA attack, the most important rule anyone can follow regarding such a high profile firing under duress, is to CHANGE ALL PASSWORDS, and lock down any external access ports until they can be properly secured.

I won’t say they deserved it. Nobody deserves to get hacked, if indeed they were hacked. However, if a manager or his employees don’t understand at least this much about a computer system, they might as well walk around with “Kick Me” signs on their asses.

I suspect the only thing we’re going to learn about this whole affair is the depths of stupidity that people can sink to. The only questions I have is where to apportion it.

Comment from Eric Murphy
Time: December 1, 2007, 1:30 am

A very good suggestion. I should of thought of that myself! See what happens when you get too buried in the details and forget the big picture I’ll get a post up with all six links

Comment from Ron Southworth
Time: December 1, 2007, 9:35 am

Jake,

Spot on the mark with the treatment of denial of service attacks.

As you say DOS is something that your mitigation processes and procedures need to address, how effectively and timely this can occur does depend on the communications medium as to what resources you can bring to bear on the problem. System knowledge also has a factor too.

As systems maintainers the more depth of knowledge key personnel have, the greater the potential risk is to the organisation, if and when people leave or become disenchanted. Having management identify the signs and dealing with the situation in an appropriate and proper manner. If you don’t have an exit strategy prepared for key personnel you are not managing your system very well, or your risks just like you say Jake.

Reading the preliminary stuff uncovered by Brian Mast it would seem there is more to the story than what has been released so far. I hope future transcripts can illuminate the situation background so we can have a better understanding of what has transpired.

It does sound eerily similar to other insider incidents and I really think HR management needs to be looked at more openly.

Identity and human resource management is certainly something that needs to be reviewed in a lot of cases – how we treat people. The human being is such an important aspect to a SCADA system and so very often overlooked on so many layers.

Part of Defense in Depth practices as prescribed by DHS identifies the need to hire and keep good dependable and reasonable people. Looking after them and treating them well, paying them well and treating them with respect and not under valuing them. Providing an environment of mutual respect and developing a healthy level of trust.

Dale I enjoyed your discussion with Walt this week on his blog. I do understand the differences of opinion expressed in the discussion. At times I don’t think you always “get it” or agree with a dinosaur like me but at least you are willing to be open and to debate something. I hope with our discussions we can bridge this gap over time and I think this happening.

What I think Walt is expressing is the frustration that does occur in the industry globally where people don’t always “get it” with the convergence of what is seen nowadays as the traditional technology boundaries. I still maintain it is all different aspects of engineering and that by enlarge it is a training and experience issue that is resolvable. The parochial nature of humans does come into play I suspect and this has to be overcome as well.

I have to deal with the frustration Walt speaks of on a daily basis and it can wear thin at times. Still we need to persist and to work through it and tear down these barriers and obstacles.

I have sent Walt two messages so far with being able to register on the control global blogs. I presume he has been too busy to respond to me.

I would like to discuss Walts comments and some of the un-fetted comments from Joe’s post in an open forum or a closed one for that matter. There is always some middle ground in perspectives for an objective compromise and to debate differences in a health way. I believe it can and does stimulate better understanding and can change attitudes over time.

Keep smiling.

PS I will be posting the second part of this on the SCADA Gospel.

Comment from Ralph Langner
Time: December 1, 2007, 4:14 pm

Wait a second, Jake. The guy is CHARGED, he isn’t CONVICTED. And with a 5,000$ damage, the story certainly wouldn’t make it into Computerworld if I was their editor.

Comment from Dale Peterson
Time: December 1, 2007, 7:58 pm

Ron,

Throughout all the noise of the posts and comments I think the basic point keeps getting missed. The vendor learned of a new vulnerability, had a fix, and did not notify the customers in any manner for many months and may never had except for the fact it was submitted to US-CERT. This is all too common.

When we find a serious (like you can crash or own the whole SCADA or DCS) vulnerability on an assessment, a conference call occurs quickly with the asset owner and vendor. Very often the vendor will say another customer had found the same thing. Sometimes they will even already have the patch that they gave to one customer who found it months or years ago!!! It is unacceptable, but asset owners keep accepting it. We push as hard as we can for our clients to notify at least their User Groups, and our preference is US-CERT as well. I wish we were having a higher persuasion rate but too many asset owners have Stockholm syndrome.

One last note – I always find it odd with accusations of “not getting it”. There is an implication that we don’t have experience with control systems and commenting from an academic perspective. We have been hands on with a variety of deployed vendor systems in a variety of vertical industries since 2000. This year has been so many assessments of power plants and transmission systems that I’m really looking forward to stepping back and carving out a large chunk of time for our research with Nessus and PI.

Getting to see all these control systems, with many asset owners who have made huge progress in their security program, I can tell you first hand that many of items people come back with and say won’t work are working, to the full credit of these market and thought leaders who we are fortunate to work with. It was not too long ago when people where saying Ethernet wouldn’t work in control centers, firewalls couldn’t be used to segment control system networks, anti-virus wouldn’t work, … Unfortunately this industry suffers from an acceptance of low expectations that we are determined to play a small role in changing.

Comment from Ron Southworth
Time: December 3, 2007, 1:30 am

Hi Dale,

Keep smiling.

I would not term my not “getting it” in quotes as a strong accusation, more just a feeling. This is where ewords don’t detect if it is an expression or comprehension problem resulting in miscommunication.

I think you have had a lot of experience in the power sector without question. I don’t see any “industrial” systems influences in your language, and hence why I framed it as some times and more a feeling… I did say sometimes, not all the time..

I think this is all productive and healthy, Dale.

Perhaps you mis interperate slow acceptance and uptake in this industry for what I consider is a general trend to be aconservative and cautious nature most of us have developed, out of the road of hard knocks.

I actually think our expectations are very high. 99.98% or better uptime is something I would love to see bleeding edge technology be capable of doing out of the box and from release version 1. The reality is that bugs take time to surface.
In broad brush generalisation, this stuff ideally has to be removed out of the box from new, screwed or bolted on the wall somewhere and forgotten for 15 years when someone may just maybe consider replacing it.

This takes product maturity and maturity takes time to substantiate. As you know it is all about knowing what technology will work and where it wont work and keeping up with the shifting target of product maturity.

Don’t give up It takes a good 20 years before people even start to listen to you serously and even then at times it can be a struggle.

Pingback from OPC Exchange Blog, Featuring Eric Murphy » Blog Archive » OPC Specification Overview
Time: December 3, 2007, 2:05 pm

[...] Here is a post with links to all the OPC DA 3.0 specification overview.   Thanks Dale for the link up, and the good suggestion for this post [...]