Recently I was asked to assist a customer in trying to prevent their sensitive data from walking out on unencrypted media:
"By default, encrypted data on NTFS will be decrypted when copied/moved to non-NTFS media. We want a solution so that EFS encrypted data cannot be copied to non-NTFS removable media."
There are no known solutions that *only* target this problem - solutions are typically too narrow or too broad for what you're trying to achieve:
-
Once a user can decrypt an EFS-encrypted file, they are authorized to do *anything* with the file that the shell (or application calling shell functions) allows them to do.
-
If the user is blocked at the shell (or device driver) level from being able to write to certain types of media, that could help to prevent copying this sensitive data - but it will also prevent them from writing non-EFS'd files to the same "blocked" media.
-
- It's also possible to prevent all access to USB storage devices using the setting Start under the USBStor key (see this KB article).
- There is also the older Group Policy function "Prevent access to drives from My Computer" that blocked the user's ability to access drives by their specified drive letters:
- This would allow the administrators to block access to non-permanent drive letters (e.g. E: through Z:), so that even if the user could add a new removable drive, they'd have a hard time accessing them.
-
You can find this setting under User Configuration > Administrative Templates > Windows Components > Windows Explorer > "Prevent access to drives from My Computer". -
While the GPO UI only lists the ability to "block all drives" and not "all removable drives" or "all drives *except* C: and D:", you could manually edit the registry value that controls this Group Policy setting, and name specific drive letters that you want blocked - see for example this article for detailed instructions. -
Even if these options are what you're after, keep in mind that a determined user, who understands how to use NTBackup & cipher /X (or the Certificates MMC), also may try to backup the encrypted files + export their private key off the system, and import them later to a different system (where such restrictions may not be in place).
However, I like to think that most organizations would prefer to take reasonable steps to reduce the overall incidence of these issues from occuring - prefer that over not doing anything until a "bulletproof" solution became available. I'll agree that it's forseeable that some users will actively try to work around these kinds of measures, and some might succeed in copying encrypted data onto removable media. However, in my experience this is far removed from "what's likely or typical from most users", and I will assert that you would still achieve a measurable decrease in risk of data exposure if *most* of the users were effectively discouraged by the above approach.
Also keep in mind that, if an individual really wants to take copies of encrypted data off-premises, there are plenty of ways a creative person could do that - from uploading the files to a home-based web or FTP server, to emailing files to themselves (or attaching them to emails in a web-based email account they use); accessing their email via web-based access (e.g. Outlook Web Access) from a home computer, burning the data to CD, or even (ugh) the old "spanning floppies" technique.
The next logical stage of controlling what people can do with data is to use technology (as well as well-thought-out processes, and effectively communicated policies) to limit what people are authorized to do once they receive a copy of the data:
-
only allowing access to the data via applications that run only on Terminal Servcies systems - so that the most a user can do is print screen from their Terminal Services session. [I'd recommend setting IPSec rules that only allow incoming requests from the TS servers and block other computers; then you could further set up rules that only allow 3389/tcp access to the Terminal Services systems, so that users couldn't copy their data from the TS system to their client, and only allow users - e.g. using Software Restriction Policies or appsec.exe - to use the authorized applications on the TS servers.]
-
deploying ever-controversial rights management technologies (e.g. RMS, IRM, ERM, DRM) that make it difficult to perform unauthorized activities with the data, and/or require authorized/restricted software and/or hardware to be able to view this restricted data.
These kinds of approaches often cost a great deal more in terms of effort to configure/operate/support/train, and can also cost significant money to acquire the software/hardware. Trade-offs between how much you're willing to invest, and the sensitivity of the data you're trying to protect, are the inevitable final stage of this line of thinking.
Til next time.
[Please note: these ideas haven't been fully tested by me nor the product teams at Microsoft, and as such can't be officially supported by Customer Support Services - aka PSS.]
