Search the Community

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?