Accommodations for EOL'd Operating Systems
Introduction
UW System policy wisely prohibits the connection to the campus network of computers running operating systems with unpatched security vulnerabilities. OSes that have reached the vendor's end-of-life (EOL) date no longer receive security updates, and should be updated and removed from the network. However, this is not always practically possible. The Dept. of Chemistry has an assortment of laboratory instruments which also have reached their manufacturer's EOL date. The instrument control software, or the hardware drivers, often do not work on later OS versions. We replace instruments as funding allows, but until that's feasible, we need to keep the old equipment functional for our researchers.
The key concept in developing a compromise between policy requirement and practicality is to identify what vital connectivity these old computers need, and provide that, while restricting all other connections.
Restricted Network Access
Computers with EOL operating systems should not have access to the Internet. Web browsers, email, and malicious documents are among the main vectors of security exploits. Nobody should be browsing the web, or editing documents on lab instrument computers, so virtually all network connections are disallowed. In order to make this bar as simple and robust as possible, we have created a separate VLAN to which we connect these machines. The firewall policies simply disallow incoming and outgoing connections. This substantially complies with the UW System network policy.
File Servers
The primary requirement for network access on lab instrument computers is access to a file server to store data files generated by the instrument. Therefore, we have a firewall policy which allows access to the department's file server, and to ResearchDrive, specifically. But that's not the end of the issue.
Several of our research groups handle restricted data, which we must protect by using encrypted connections between client devices and the file server to prevent snooping and man-in-the-middle attacks. Microsoft added mandatory encryption to the SMB/CIFS file sharing protocol for version 3, but older versions of Windows only support up to version 2. In order to accommodate non-encrypted connections, we use the capability of the Samba file server software to enforce or disable encryption on a per-share basis. The global configuration for Samba includes server smb encrypt = required
. Then, for each research group that has EOL operating systems on lab instrument computers we:
- Create a service account in CADS for the group, following the CADS naming convention: svc-groupname-chem
- Create a dedicated (hidden) share on the file server with
server smb encrypt = desired
,browseable = no
,valid users = svc-groupname-chem
, andhosts allow
set to the restricted network. The share points to the group's existing data directory. - Connect to the hidden share from the lab instrument computer using the service account credentials.
The net effect is to create an unecrypted "back door" that only the lab instrument computers can use, with the added security benefit of not requiring researchers to sign in with their own credentials. They are then able to access those files from other computers using the usual, encrypted file share.
Supporting Services
We also have firewall policies which allow access from the restricted network to vital supporting services, such as DHCP, DNS, Windows Update, Qualys, BigFix, and Cisco Secure Endpoint servers.