Data egress

When it comes to data egress - when data leaves a network and is transferred to an external location - the actions (and consequences) usually fall under two camps: on purpose and accidental. Let’s say an employee saves data to a USB stick for genuine reasons and the USB stick isn’t encrypted by software or hardware methods. Then, let's say that USB stick falls out of a coat pocket and lands on a packed London Underground train. While the USB stick isn’t technically lost or stolen, once the data has left the company, it can be further egressed to home computers where it could be infected or not disposed of correctly. 

When you consider information egressed on purpose, you’re talking usually about an insider threat scenario. Perhaps an employee was asked by an OCG (organized crime group) or nation state to steal files. Rumors going back years suggest Russia and China have hundreds of agents planted into all sorts of organizations within the United Kingdom. Moving away from the likes of Mr. Bond, even genuine staff who move on can have a tendency to log into Salesforce, download client lists and load them on to a USB stick before serving their notice period.

Machine/network infection or exploitation

Write “staff salaries” or “pay rises 2023” on a USB stick and there’s a high likeliness that if someone finds it outside of an office entrance, they're going to insert it into a machine. Stuxnet, which targeted supervisory control and data acquisition (SCADA) systems at a nuclear enrichment/power plant in Iran in the late 2000s, used a similar infection method. A simple file that looks like a .DOCX file can be a executable file (.EXE) that can go on to infect a target computer. Similarly, actual Portable Document Format (.PDF) files, Word, Excel, and PowerPoint files can be rigged with zero days exploits. Just by opening an “innocent” file, it can exploit the application and download an .EXE from the network in seconds. If the file contains a zero-day vulnerability, software defenses may not be able to nab it in time.

What are the soft options to control USBs?

1. Nothing

Implement zero technical controls and perhaps have a policy saying do not use USB devices. As an example, consider speed limits. 70 MPH is the UK limit and while there may not always be cameras or traffic officers, there's nothing to physically stop you from driving over 70 MPH. It's just like how people don’t always explicitly follow data protection policies or laws.

2. Write Blocker

Permit USB storage devices from mounting and simply block write which means that files can be opened and copied but not written to disk. Here, data egress is not a problem but data ingress is, along with an increased chance of malware infections or application/operating system exploits running.

3. Mount blocker

The strictest of options. If an employee inserts a USB storage device, it does not get a drive letter, something which makes it invisible to the device its inserted into. No user access equals no data ingress/egress or infection chances.

4. Forced encryption

A compromise for employees. Allow USB storage read/write and enforce encryption on data written to the external drive. Depending on your organization's risk appetite, you can encrypt based on system generated key or allow the user to select a password which generates a key in the background. The latter option increases useability/portability by allowing the USB stick to be used on non-organizational devices without the requirement for special software to be installed on each device. That said, it could open up the device to password cracking since the authentication is done via the user rather than a transparent key.

USB Best Practices

Options number 2 & 4 are an improvement over number 1 but infections and exploits can unfortunately still be a concern for organizations. Software, such as endpoint data loss prevention solutions can block when applications are launched from removable media drives and block the copying/opening of certain file types like: Windows PowerShell script files (.PS1), Java ARchive files (.JAR), batch files (.BAT), Windows command files (.CMD), HTML application files (.HTA), and so on. Blocking by the hexadecimal file header is typically safer as attackers can easily rename the malicious file to trick users or bypass technical controls.