How "Safe" Is Your Software?

[ShaunR]

Being a programmer that mainly deals with automation machines (some of which could take limbs off) I have always been aware that if my software wasn't working perfectly, or, if some malicious person fiddled with the code. The effects could have extreme consequences both in terms of injury and hardware failure. So it was no surprise to me when I read How Digital Detectives Deciphered Stuxnet.

Since LabVIEW is extremely hardware oriented and specifically targeted at the sorts of applications that Stuxnet and the later Flamer could target. I thought I would post some of my thoughts.

Writing automation systems has made me a bit of an amateur virus enthusiast, not least because if a virus gets onto a machine; I'm the one that has to sort it out. As I have considered the scenarios over the years it, I have done what I can with my limited knowledge to make it as difficult as possible for a virus to get onto a machine and, if it does, that it does limit it ability to spread to others. We all know that Windows is a hot target for any "script kiddie" and, whilst not a silver bullet and certainly not protection form the most determined malicious user. The items below are simple to achieve and go some way to making it more difficult for accidental infection and limit the scope of the propagation.

• Turn off "Autoplay" - The easiest way to for a virus to propagate via USB.
  
• Enable Extensions to be visible - It won't stop a virus, but it may prevent someone (including yourself) from clicking on one.
  
• Change the "*.vbs" extension from "Open" to "Edit" - Make the default action for visual basic scripts open in a text editor rather than run. Most "script kiddies" rely on this and the extension hiding to trick the user into executing malicious code..
  
• Place USB ports and CD drives behind "Locked" panels - Use USB ports that are at the rear, not exposed and that are internal to the cabinet of the machine and disconnect those on the front at the motherboard. Only allow USB/CD access to "trusted" and knowledgeable staff and use USB drives specifically set aside for the machines (one per machine). Insist they must be scanned before use (use the maintenance log!).
  
• Boot into your program as the shell - This will remove all the tools that people are generally used to when dealing with windows (like the task bar) and only enable the access you program into the software. If you also disable "CTRL+ALT+DEL", not even explorer will be available (if they know how to get to it without the explorer shell).
  
• Run your software under a User account and not under an Administrative account - Once installed and operational, your software should not require admin privileges to operate (as a design goal). Use a User (or if you can-a guest) account and specifically grant privileges that your software requires. Auto-login to this account.
  
• Take a "Disk Image" of the vanilla install of the machine when the machine is isolated from others. Aside from backup, this is a convenient way of completely removing a virus once infected. Make sure you don't have a virus first!
  
• Run the machines off of a separate, isolated network - Connect the machines on their own network with their own routers. If a virus gets onto your systems, or, if the IT dept gets a virus (more probable), then the other network will not be affected. If access must be provided to the office infrastructure, use FTP access (preferable) or dedicate a "dirty" machine (not one of the production machines) to act as a sentry.
  
• Don't let the office IT dept anywhere near the machines. - From experience, most IT departments will not support the machines but they will still insist on pushing a load of corporate profiles and updates that may bring the system to halt (there have been a couple of exceptions, but the vast majority won't have anything to do with something they neither have the knowledge for or control over). Most network propagated virii are introduced via the office networks and usually IT just shrug their shoulders and leave you to sort it out with one hand tied behind you back due to their security policies. Production machines going down due to a virus actually cost money and a lot of it. So submitting a help ticket that they might get round to eventually is not an option. It is far better just to close off that attack vector and not involve them at all (if you can. )
  

I view virus scanners as the last line of defense and, for some machines, a scanner cannot be installed.Therefore, these are a few of the simpler things I routinely implement.

So how do you try to mitigate malicious code?

[Aristos Queue]

A friend in high school compiled his own operating system kernel that assumed all EXEs were encoded with an extra byte after each byte and when it loaded the EXEs into memory, it dropped every second byte from the file. The result was that only EXEs that he had deliberately salted with pad bytes could run on this machine. This was a major line of defense in the war to keep the high school computer lab running despite all variations of malware being tracked in by various parties. If a program hadn't gone through his specific blessing tool, it wouldn't run when loaded on those machines.

[Tim_S]

We have a production control, SPC, reporting and analysis package that we sell that requires a server to run. Given the option (plants and plant IT have interesting ideas of how things should be at times), we set up the server as a gateway with as many roadblocks as possible. One customer has a variation on this where there is a 1U rack-mount PC that serves as a gateway. This customer also removes all USB ports and keyboard and mouse (the system has a touchscreen). One other thing I've seen is dual-boot the PC (or use a bootable memory stick) with Windows as the test system and a flavor of Linux to perform system maintenance and repair, and (re)imaging of the hard drives.

[ShaunR]

We have a production control, SPC, reporting and analysis package that we sell that requires a server to run. Given the option (plants and plant IT have interesting ideas of how things should be at times), we set up the server as a gateway with as many roadblocks as possible. One customer has a variation on this where there is a 1U rack-mount PC that serves as a gateway. This customer also removes all USB ports and keyboard and mouse (the system has a touchscreen). One other thing I've seen is dual-boot the PC (or use a bootable memory stick) with Windows as the test system and a flavor of Linux to perform system maintenance and repair, and (re)imaging of the hard drives.

Yup. this is the "dirty" PC that I mentioned.

The goal is to provide isolation (or gateway as you put it) where you can limit exposure and run all your virus and malware scanners et al.

In the past, I have set up servers using two PCs. One that the production line stores and gets it's configuration from (SPC database) and a mirrored one for access from the offices (a read-only copy, if you like). This means that changes can only be made on the configuration machine, but anyone (who needs it) has access to the data (usually via a web interface and a web API). Periodically, each will scan the other (and sometimes the production machines dependent on the topology) for viruses , malware and any anomalies as well as their own drive. If something does get on either machine, there is an intrinsic back-up of the data and a high probability that at least one of the machines will detect it. Additionally (although nothing to do with virii), if one machine goes down, you have a ready replacement that you can just hook up in minutes whilst you wait for a new one to arrive (I have also managed to automate this with alerts to the admins, telling them of the fact, meaning seamless transition - 0 downtime). The hard part is getting them to order the new PC since it all still works....lol.

[Tim_S]

If something does get on either machine, there is an intrinsic back-up of the data and a high probability that at least one of the machines will detect it. Additionally (although nothing to do with virii), if one machine goes down, you have a ready replacement that you can just hook up in minutes whilst you wait for a new one to arrive (I have also managed to automate this with alerts to the admins, telling them of the fact, meaning seamless transition - 0 downtime). The hard part is getting them to order the new PC since it all still works....lol.

We tend towards a RAID system with hot-swap and (on the server) a hot spare rather than a mirrored system (it's interesting, though). The issue we run into is the plant won't even look at the lights on the RAID, look at the monitor (which, admittedly, we try to keep hidden from overly curious users), or listen to the persistent beeping that lets them know things have gone south and they need to pull a spare hard drive out of storage and switch with the bad drive.

[ShaunR]

We tend towards a RAID system with hot-swap and (on the server) a hot spare rather than a mirrored system (it's interesting, though). The issue we run into is the plant won't even look at the lights on the RAID, look at the monitor (which, admittedly, we try to keep hidden from overly curious users), or listen to the persistent beeping that lets them know things have gone south and they need to pull a spare hard drive out of storage and switch with the bad drive.

Indeed. But that is more to do with recovery than isolation. All machines (production included) that we spec nowadays are raid (invariably Raid 10 depending on chassis) and that's irrespective of the topology. Hard drives are cheap!

Getting production to check stuff is really a maintenance issue. The only way it can be practically resolved is with training and procedures. I work closely with customers' maintenance departments and supply checklists and procedures along with [preventative] maintenance schedules. This however is insufficient and unless entries into maintenance logs are a requirement - always skipped. A maintenance log is the first port of call and the second is shift "handover" procedures (the latter usually being a mixture of hardware and software checklists). But unless you get someone to sign or initial something (make them feel responsibility for the equipment) then you are on a hiding to nothing.