Security for Instrument Controllers

Computers that are used to control scientific instruments can pose a particularly difficult security problem.  These systems typically have a very fragile configuration that is easily disrupted by updates or changes, while also being extremely vulnerable to attack.  Below are some recommendations for reducing the chances of having your work interrupted by a security incident involving an instrument controller.


Management:

Assign a person or group to be responsible for the management of this computer, and to act as a technical point of contact.  

Make regular backups of all data files.  These will be tremendously helpful in the event of inadvertent deletion or overwriting of files by a legitimate user, hardware failure, or malicious software infection.

Once the system has been fully configured, make a backup image of the hard drive in case of disaster using a disk cloning utility.  This image will save time and effort in the event that the system suffers a problem that necessitates wiping or replacing the hard drive. 

Unless there is a specific reason the operating system and applications cannot be kept up to date on patches, make sure the system is kept up to date on patches.  If the system cannot be kept up to date on security patches, isolate or restrict it from the network (see Firewall and Access Controls below).

Make it a lab policy not to use this computer for routine or personal computing.  No web browsing/searching, email, instant messaging, etc.  Users should use a separate computer for routine computing purposes.  

Unless absolutely required by the nature of the software running on the instrument controller, do not install Java or Flash on this computer.  Both are subject to frequent discovery of new security vulnerabilities, which are typically exploited very rapidly.

Make sure event logging is enabled.  Linux systems should be logging to syslog by default, while Windows systems have a default event log policy that should be adjusted to capture more information.  Consider centrally syslogging log data rather than relying solely on local logs, which can be lost or damaged if a hardware or security problem occurs.  If you would like to send syslog data to IMSS log servers, please contact Information Security.

Firewall and Access Controls

If the computer requires a network connection, request a static ip address for it from the IMSS Hostmaster.  Provide a contact address for the responsible person or group, the location of the computer, and a suggested name.

Make sure the local firewall supported by your operating system is enabled.

If remote access to the instrument controller is required, restrict it to campus only, and have off-campus users access the system by connecting to campus via the Caltech VPN first.

Consider implementing two-factor authentication for remote access.  Caltech has a site license for Duo Security.  Contact Information Security for more details.

If the system cannot be kept up to date, don't allow direct connections from the Internet to any of its services, and consider keeping it off of the network entirely.

Ensure that remote out-of-band management (IPMI, Active Management Technology, etc) is not accessible remotely, preferably by assigning IPMI a non-routable, static IP address.   There are numerous security concerns with these management technologies, many of which can lead to complete remote compromise of the affected system.


Principle of least privilege

Does the account used by lab members on the instrument controller require administrator privileges?  If the software will function without requiring use by an Administrator account, create an unprivileged user account for routine use, and reserve Administrator or Administrator-privileged accounts for solely for those operations that require elevated privileges (e.g., software installation, creation of new users).

Physical security

Consider using a cable and lock to physically secure the computer.

Enable an automatic screensaver lock that requires a password after a reasonable amount of idle time.  A reasonable amount may be 15 minutes or more than an hour depending on how busy and/or accessible the lab area is.