passwords and security (was: Windows NT and System Clock Accuracy)

J

Thread Starter

Jiri Baum

Vladimir:
> Generally speaking as a matter of fact, Internet makes life too unsafe...
> and instable. The ability to control has reduced to the knowledge of
> password (think, it is just a short sequence of chars)...

Fortunately, these days systems can be configured to use better (or worse) authentication methods than that. Normally this means some sort of
challenge-response system based on some piece of hardware, either manual (type number into calculator, type back the response) or automatic (plugs into USB port or a special reader). Some of the ones that plug into a USB port even fit on a keyring with normal keys...


Obviously, this depends on the owner having it set up in the first place, and then ensuring that it stays set up that way.

Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sf.net
 
I agree with Jiri Baum and there is a bit of disagreement too.

1. There are several tools available like encryption and authentication methods like SSL on which large and secure transactions do occur.

But very few automation systems if any provide these features.

I could put up some basic recommendations on my web site at www.smbd.org in Automation section under security in Article 1 and 2, but there is
one serious lacunae in all such recommendations. This lacunae is still secondary as the recommendations do take care of basic needs today and the double encryption proposed does give each system a separate identity, thereby making exploits on a particular system unlikely to
result in exploits in other systems.

The lacunae which is a point where there could be some disagreement with some people on the list or where we may need newer standards and methods is:

It is a known fact that the secure encryption methods, the various security tools, the OS's develop bugs or both hackers and crackers find
means of breaking these safe and secure methods. Then you require an upgrade. But if you have had bad upgrade experiences, then you will understand why so many people do not say yes to upgrades easily. How do we ensure that the upgrades are essentially hassle free and also that upgrades do not result in plant or process interruptions?

Anand
 
One more issue that is not addresses by recommending to implement encryption and other standards for data protection is the additional
overhead of processing due to decryption of data.

In case the recommendations as made in www.smbd.org were to become a fact then this would mean billions or trillions of dollars (that is for finance side business managers to decide) in software and hardware upgrade and a large chunk going to US and Far -East businesses.
This is so because no matter where your HMI or Device Driver is running, these principles will become applicable. From America to Middle East to
China to Japan and from Anywhere near the Arctic to anywhere near the southern pole, all industries which have some hazard or operations that could become toxic need to upgrade.

I foresee that automation systems would have to have good hardware capabilities, with at least a P3 or p4 level architecture or even itanium with a half to a full GB of RAM or more and faster ethernet connections. Plus encryption-Decryption software, and others as recommended.

Anand
 
C

Curt Wuollet

The picture isn't that bleak. Since these are applications where you have control of both ends, profitable use could be made of simple private key encryption which would not only greatly reduce the resources needed, but would eliminate some of the danger that ensues with having thousands of identical platforms with identical schemes. With say a 2048 key sequence that changes every five minutes. it would be a royal pita to break the encryption and it would only
matter for the balance of the 5 minutes. This could be done in reasonable resources and would provide pretty good protection against all but the most sophisticated attacks. If they were good enough and determined enough to break this, chances are they are going to break anything you put out there.

Regards

cww
 
C

Curt Wuollet

Hi Anand

> I agree with Jiri Baum and there is a bit of disagreement too.
> 1. There are several tools available like encryption and authentication
> methods like SSL on which large and secure transactions do occur.
>
> But very few automation systems if any provide these features.

This is one of the major problems with closed systems. You can only have what they decide to let you have. And even if they were at all
concerned, it would be nearly impossible under the current model to rev often enough to stay secure. This is a fundimental problem with the cathedral approach.

> I could put up some basic recommendations on my web site at www.smbd.org
> in Automation section under security in Article 1 and 2, but there is
> one serious lacunae in all such recommendations. This lacunae is still
> secondary as the recommendations do take care of basic needs today and
> the double encryption proposed does give each system a separate
> identity, thereby making exploits on a particular system unlikely to
> result in exploits in other systems.
>
> The lacunae which is a point where there could be some disagreement with
> some people on the list or where we may need newer standards and methods is:
>
> It is a known fact that the secure encryption methods, the various
> security tools, the OS's develop bugs or both hackers and crackers find
> means of breaking these safe and secure methods. Then you require an
> upgrade. But if you have had bad upgrade experiences, then you will
> understand why so many people do not say yes to upgrades easily.
> How do we ensure that the upgrades are essentially hassle free and also
> that upgrades do not result in plant or process interruptions?

With black box and secret patches approach there is no assurance and no way to assess the risk. When you have source you can at least read the patches and see which functions may be affected. You could be much more confident and informed.

Regards

cww
 
Hi Curt Wuollet,

I agree that open source is the solution to several problems.

Software upgrades to security should be external to the main running logic so that these are not affected by security issues.

The funny part is that, though closed systems are closed to users, they are open to attacks by crackers (simple DDE commands, simple communication protocols etc.)!

Anand
 
R

Ralph Mackiewicz

> 1. There are several tools available like encryption and
> authentication methods like SSL on which large and secure transactions
> do occur.
>
> But very few automation systems if any provide these features.

There is good reason for that: very few companies (or people) are willing to pay anything for information security.

The technology to provide completely private and secure communications over the Internet has existed for many years using commonly available (even open source) software. In fact, Internet E-
Mail can be a lot more secure than paper sent via the US Post office or Fedex using these tools.

This is accomplished using strong authentication (using digital signatures that can only be generated by the holder of a private encryption key) to ensure that both parties in the communication are talking to exactly the party they wish to talk to and no one else, and then encrypting the data that is exchanged.

You can download an add-in from FTP for PGP for free that will encrypt 99% of all the emails transmitted with a penalty of less than 1 second of CPU time on the average computer that is involved in the sending and receiving of short email messages (very little additional overhead to transmit the message). I'll grant that there is some additional CPU overhead in doing this with automation protocols but that is not the reason it isn't used. It is not used because the
value equation is just not there for the typical IA user because they perceive no threat (very little cost does not justify zero benefit). (There are also significant "hidden" costs in key management in large organizations.) There are numerous companies that transmit highly confidential data, including process data using IA protocols, over the Internet or via modem lines that anyone with a little knowledge and phone number could access without using any protection. They rely on the fact that access is obscure (not secure) and that nobody is apparently interested in them enough to bother using the access against them.

The good news is that the cost of Virtual Private Networking is coming down to the point where there is much less cost needed to justify. The downside is that VPN products do not typically
interoperate with each other so you must carefully match VPN drivers to each individual site accessed.

Regards,

Ralph Mackiewicz
SISCO, Inc.
 
It won't be as easy as it appears and neither will it be impossible. There are probable thousands of protocols, and hundreds of hardware
communication configurations. All these including the older systems will have to be revamped to include security measures. For new systems, the task may be easy, but it is daunting in established setup's.

We are talking about big business here!
Anand
 
R

Ralph Mackiewicz

Never meant to imply that it was easy. Just that the technology to do this is well known, publicly available, and has been around a long time. Key management is a particularly troublesome aspect of
implementing highly secure systems on a large scale basis.

My main assertion was to point out that the reason this stuff sits on a dusty shelf instead of in most computers is because users do not
perceive increased communications security as being worth very much. With VPN technology decreasing in price it is possible that solutions
that won't require thousands of protocols to be re-engineered will become available at a low enough price to garner some serious interest.

Regards,

Ralph Mackiewicz
SISCO, Inc.
 
I don't exactly know about what kind of users you have in mind here. I am yet to meet an automation end user who is eager or enthusiastic about
changing anything in his automation setup, once it is working and even accepts minor glitches, but would be very skeptical about upgrades.
There are thousands of companies that are still using equipment manufactured in the eighties connected to PC's running software's made in the eighties and nineties of the last millennium.

And due to the enormous numbers of options in automation, there is also an inconsistency in programming techniques etc.

last year i commissioned a plant using three different protocols and two systems where the communication option was not utilized and all at com ports. Ethernet is still to come in a big way!

Anand
 
Actually, the biggest "problem" with SSL and friends is the huge hardware resources they require. SSL is not a useful security protocol by itself - it is a wrapper for a kitchen drawer full of negotiable encryption tools. So while a 128-bit AES like Ryhndahl may only require 20K of code and RAM, a "standard" SSL arsenal is looking for 256K or more. Of course you can implement a non-standard SSL which only supports 1 or 2 smaller encryption tools & hope the remote end can negotiate down to one of these.

SSL is no problem if you're using fat-resource tools like Linux or Windoz, but difficult if you're doing an effective embedded job. We run
TCP/UDP/IP/HTTP/Telnet/etc in under 64K of RAM - we cannot afford to bloat that by 400% just gain "standard security" protocols.

Software-based VPN also exists for the fat-resource tools like Linux and Windoz, but for a PLC or other device you'll need a rather expensive, low-volume external VPN box.

Best Regards

Lynn August Linse, [email protected] http://www.linse.org/lynn
3 Rue Monet, Foothill Ranch CA 92610
Ph: 949-300-6337 Fx: 612-677-3253
 
Top