A bad case of worms. A little arsenic would not hurt.
The issue of the actual worm in question aside, in my opinion, the main points we must observe is the following:
1. It is madness to connect an industrial system directly to the Internet without some sort of professionally administered protection e.g., it must go through a firewall and port-blocking routers. Better still use a VPN if you have to get to point A from point B and there is not a dedicated line
2. When you use NT, 2000, Linux, Unix et cetera you must pay attention to the patching of the OS and all the applications especially if you are using e-mail (e.g., to inform other people of alarms) or some sort of web server (e.g., to put up graphic pages of your process). You do not want your bandwidth compromised by a worm or some idiot tuning your loops from Andorra. Some PLCs even have web servers built in now -- we have to make sure that their web engine is secure. If the manufacturer is blase about security then we must have help from the security blokes to put up firewalls if, for some reason, the PLC is on the Internet. When I have seen these devices demonstrated there is no mention of security whatsoever, what happens if someone attacks the PLC remotely (either from within on an intranet or from the outside via the Internet) and a firmware bug causes the PLC to go into stop mode
3. We must also recognise that many attacks come from within -- denial of service, sabotage, espionage, Luddites and so on
4. If you need security help, then http://www.sans.org/ and http://www.incidents.org/ are good places to start. SANS have an e-mail news letter service that is quite good. They cover Windows, Linux, BSD, Unix and cross-platform security threats. SANS themselves have been hacked which shows you just how insecure the Internet is
5. Many of the patches needed to protect systems against common forms of attack have been around for an Internet eternity i.e., over a year in some
cases
6. Windows and Windows IIS are horribly insecure. In my opinion anyway. I do not think that when some of the industrial stuff was originally ported from Unix to Windows or written for Windows from the ground up that the authors really thought about security. On a lot of systems it is hard enough protecting the factory-floor workstation from direct tampering let
alone remote tampering for the server if it is on an intranet or the Internet. These systems just keep adding functionality, sort of like Monty
Python's The Search for the Holy Grail where the castle is built on a swamp -- when it sank they just built another one. Also the systems are
always playing catch up with Microsoft's operating system du jour
7. We need to look at the big picture and patch, secure, patch, secure ... not just individual incidents. Correctly patched systems according to my reading on SANS and at Incidents.org would not be affected by this worm (except for a noticeable increase in port probing). I have read articles about administrators putting up systems on the Internet with nothing on the
backside yet and seeing incoming probes at a fantastic rate as soon as they plugged in the front side to the Internet
8. Attacks such as this as well as traditional disasters (and of course the terrible incidents in New York) highlight the need for back-up regimes, spare hardware and so on -- a disaster recovery plan. Also, all systems need a how-do-we-build-this-from-scratch plan -- I just saw a system with a tiny VB application that will not work on a new machine -- all the normal stuff is installed, even VB itself -- why? missing DLL? missing VXD? who knows. I like to handover any backing up responsibilities to the IT boys
and girls as soon as I get a system installed -- a built-in scheme never works -- no one EVER swaps the tapes or checks the back-up logs after the initial excitement is over
