27 November, 2006

DNS and SCADA

I just read this article on Howard Schmidt speaking to the House of Lords about cyber threats.

I don’t usually put much stock in what a government “expert” says about information security but this article outlined a flaw that exists in many DCS architectures.

In most of the control systems I have seen the naming architecture is horrible. Host files are still commonly used, direct entry of IP addresses is common and in some hodge podge systems a combination of Host files, IP addresses, and DNS lookups happen. This is an area that is ripe for improvement in the SCADA arena.
Posted by at

4 comments:

Anonymous said...

There are good reasons to avoid the use of Domain Name Services.

First, it is yet another service vulnerable to attack.

Second, despite redundancies and the like, it still represents an additional point of failure.

Third, DCS networks aren't so large that one is not able to use a host file effectively.

Fourth, the use of host files does not preclude the use of a DNS. One can configure nslookup to try host file addresses first, and then if not found, to try a DNS.

Fifth, the use of raw IP addresses can avoid the use of the nslookup latencies altogether. Thus, even if the name service infrastructure is compromized, you can still have other functional bits of software.

Just because a DCS has no DNS is no reason to hold your nose and proclaim that it stinks. I realize that larger systems are forced to rely on DNS technology to keep everyone up to date. However, within the limited confines of a DCS system a host file will work just as well.

This is yet another reason why IT folks should not make policy on Control System design.

27/11/06 4:31 PM
Anonymous said...

Jake I am glad you took the time to comment.

All of you points are essentialy right other than the implication at the end that I am only an IT guy.

If you took the time to read the article that I linked to you would see that one of the focuses of it was that DNS systems present many of the very same limitations that you pointed out. Of course the article was primarily focused on IT applications. One of the things I try to do is bridge the gap.

That said the naming status of many process control systems is in very bad shape and it should be an area of attention for anyone doing work in them. If the entire reason they were relying on host tables was to improve security then I am not that conserned. If it is due to a very small size (which is often but not always the case) then it really isn't a risk. In many cases however it is because they haven't taken the time or don't fully understand the full picture.

I have worked with control systems since the 80's and with IT since the mid 90's. I somewhat resent the implication that I am an "IT folk". I was doing instrumentation and control long before I started hacking into systems. The stay out of my park attitude is one of the reasons that so many of the security problems that plague automated control systems are not being addressed as quickly as they probably should. Of course the flip side of that is the "I know more than you attitude." Both sides seem to be guilty of that one.

Perhaps I misunderstood your comment and if that is the case I am sorry. Again thanks for taking the time to comment you make some very valid points and good recomendations.

27/11/06 10:35 PM
Anonymous said...

All of you points are essentialy right other than the implication at the end that I am only an IT guy.

My apologies. I was commenting on the comment that you presented. It was not my intention imply that you were only taking an IT view. I merely wanted to point out that many IT people point at designs on SCADA and DCS systems and ask why they don't use these wonderful features such as DNS.

The thing is that IT systems are often designed by habit. They use tools such as a DNS because they expect them to scale up rapidly. In DCS and SCADA systems scalability is not the same concern. In fact, they're quite static, at least until the next major process upgrade.

This is all the more reason why we need different policies from standard IT behavior. I liken this issue to comparing doctors and veterinarians. They both use the same tools. They both use the same medicines and techniques. But you can not expect one to work on the other's patients with any efficiency or effectiveness.

28/11/06 8:12 AM
Anonymous said...

Hi Jim
It is difficult to bridge the gap some times when the gap is created by "IT" people in a lot of enterprises. Like yourself and Jake a lot of us have been around long enough to remember a time when it was all just one form or another of engineering and everyone got along well with each other. I can share Jake's passion for not wanting "It Folk" setting policy on control system design. It does seem that the way the people were trained even as little as 15 years ago by comparison, nowadays seems to lack the real world understanding that I find is so lacking in the IT community at large.
The techniques of defense in depth do point to a lot of the methods we used to employ "by default" with our older style systems we all love and speak fondly of. I don't know if Jake was putting the IT folks label on you as such I think he was stating one of "Jake's Laws". The Key element I find is in having IT folk understand the "real meaning in a control system of "Availability" I think it would take an extremely large organization to not find the benefit at least on the control system of implement all of these defense in depth measure we are starting to really talk about and see being produced in various papers.

Ron Southworth

28/11/06 8:26 AM

Post a Comment

Subscribe to: Post Comments (Atom)