|
|
Data security (EFS, RMS, DPAPI, PKI) and other security rants
-
This may be deemed an exercise in WTF, but I thought I'd share the tools that I have installed on my system that I can't work without. Some of these help me deal with security issues, some are loosely related to security, and some are just downright Cool-But-Unrelated-To-Security. If you've already got them all, then you're probably more of a packrat than me, and I'd be worried ;) If you know of something else that you think I'd really like (aside: wouldn't it be cool if download.com made recommendations to you based on the tools you have, a la Amazon?), comment away! Enjoy, or skip it and do something useful. [more or less in order of how often I use 'em] I've got a ton of other stuff installed, but these are the ones I regularly use. [well, plus the usual array of MS software apps of course...]
[Comments feedback...] Robert: good point, I have all three of those tools installed, but I actually only rarely use them. For network diagnostics, I have spent way too many years poring over NetMon traces to get to the bottom of all the authentication issues I've encountered, as well as basically any other network or network security issues I've felt compelled to understand. Basically anytime I can't troubleshoot an issue with FileMon, Netmon or ProcExp, I'll fire up NetMon and capture two traces of a transaction: one of the failing operation, and another of the same (or very similar) operation that succeeds. Then I just pop open the captures, start comparing them packet by packet until I see a divergence, and then start digging into the data bits of the unique packets. If I can't figure it out from there, that usually means it's a code-level issue and I'm already drowning :) [few more tips here] I don't do a lot of remote scanning anymore - not that it isn't useful, but when I'm designing secure solutions (the majority of my consulting work these days), I want to know more than whether certain ports are remotely accessible or what vulnerabilities are currently identified on the box. The former I can figure out pretty much from within the box itself, and the latter is *always* changing, and the solution shouldn't depend on which unpatched holes are available, since they'll generally be fixed at some point [i.e. "install all current security fixes" is usually all I bother documenting in these solutions, not that anyone needs reminding]. Richard: thanks for the offer. I actually have three approaches to securely managing passwords that I need to protect from prying eyes: - Excel w/EFS - I have a spreadsheet that currently has 184 entries, of site, username, password. I encrypt the spreadsheet using EFS, which given my passphrase and the amount of time it'd take to brute force, gives me plenty of time to reset those passwords if someone ever stole my laptop.
- MSN Toolbar w/ form fill - if I'm getting prompted to fill in a forms-based username & pasword, these days I find it's reasonable to use the form filling application that comes with MSN Toolbar Suite (the beta that includes the really nice MSN Desktop Search). It's not perfect, but I believe that the form fill app uses DPAPI to protect my passwords, so it means an attacker needs my domain password before they can get any others.
- CodeWallet Pro: for storing my passwords on my smartphone, I use CodeWallet Pro.
Note two things: - I did not say I'm protecting all passwords to this degree; some of them are just for personalization on all the sites I visit, and frankly I don't care if someone else can spoof me there - not that most of them would bother - they probably would have a better reputation under their own name ;)
- I am generally avoiding the use of IE's "Save this password for future use" feature, as it stores your usernames & passwords using the Protected Store feature, rather than DPAPI. The former is LSA secrets-based, so any attacker with admin or LocalSystem can dump them out with tools you can find on the 'net; the latter is the basis for protecting all private keys and other sensitive application data on Windows 2000 and up, and depends on an attacker being able to guess my password to be able to decrypt the data that's protected via DPAPI. I know not everyone uses a really strong password/phrase, but personally I'm pretty safe against brute-force attacks - domain account, 15-20 character passphrase on average, hardly things you'd find in a dictionary. Heck, I'm pretty sure that factoring my RSA keys would take less time than brute-forcing the cached credential verifier for my domain passphrase.
|
-
Mike Howard kindly coded up a neat little tool called DropMyRights (follow this link) that lets us run an application in a "low-privileged" context - i.e. if you logon to your computer with an account that's a member of the local Administrators group, you can run certain apps that you'd like to restrict in a context that is less-privileged than your full logon context. There has been a raging debate lately about the scenarios in which DropMyRights doesn't work well, and there are two significant ones: -
using DropMyRights to run Internet Explorer in "C" or "U" mode, and access SSL-protected web sites -
using DropMyRights to run Internet Explorer in "C" or "U" mode, and access web sites that require SSPI-based user authentication (e.g. NTLM) In the former case, IE will merely fail to load the page, giving me the famous "Cannot find server or DNS Error" message. So, sick geek that I am, I wanted to know what exactly was being blocked in this context - what was IE being blocked from doing in Constrained or Untrusted mode. I first fired up Filemon from www.sysinternals.com, and watched both the successful loading of an example http: web page, and then the failed loading of an https: web page. Turns out there's nothing really interesting at the filesystem level. Well, that's not entirely true - IE failed to open the Temporary Internet Files folder about 200 times, and a few other folders in my profile once or twice, but this occurred whether IE was accessing the SSL'd or non-SSL'd site (in Constrained mode). Not to be so easily discouraged, I gave Regmon (sysinternals again - those guys…) a try, same scenario. This time, a very interesting set of differences arose: -
IE failed to CreateKey under HKCU\Software\Microsoft\SystemCertificate\MY [what is IE doing creating new keys related to digital certs? It's not that I think it *shouldn't*, but merely that I don't *get it*.] This occurred only in the IE-browsing-SSL case. -
IE failed to CreateKey under HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings. This occurred in both cases. -
IE failed to SetValue under HKCU\Software\Microsoft\Windows\Explorer\Shell Folders\History. This only occurred in the IE-browsing-SSL case. To me it's pretty clear that the primary cause of failure is the lack of permissions to write to the MY key in the registry. Makes me want to change the ACL on that key and see what happens, but ACL-muddling in HKCU is a fool's errand - at the very least, it's not a permanent solution. What's my advice? I've been struggling with this for a few weeks now, hoping some "magic bullet" would come through; at this point however, I think it's best to just continue to heed Aaron's wise words that he wrote when I first started down this road: "My experience has been that SSL just does not work when you’re running with a Constrained or Untrusted token, in our current implementation." I'll see about digging into the root cause on the latter case later on.
|
-
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.]
|
-
Customer asked me recently: "Are there any considerations to deploy both RMS/IRM and EFS? As far as I understand, RMS/IRM and EFS can work together." My response was this: No problems of which I'm aware - I've been running the two interdependently for months now, without any known or visible issues. My approach has been: - encrypt the %USERPROFILE%\Local Settings\Application Data\Microsoft\DRM folder (i.e. the location for the RAC, CLC and all ULs), so that only the person with the user's credentials (password or smart card) would be able to unlock the files that grant any access to the content.
- Don't worry whether the RM-protected files are EFS encrypted or not. Since the RM-enabled applications only see the file once EFS has decrypted it, there's no possibility of EFS and RMS "colliding" in memory, and since RMS doesn't operate at the filesystem level, they can't collide on disk.
Personally, all my documents are encrypted, whether they're RM-protected or not, so there's no *harm* in applying both to the documents. The benefit is in leveraging DPAPI (to protect each file from anyone who doesn't know the user's logon credentials) and the RM protections (to control the authorized use of the data once it's been unlocked by the user's logon credentials via DPAPI & EFS). I could go into more of the technical detail, and I intend to discuss things like "what if I only wanted to choose one of the two?" and "when is it better to use one or the other?". For now though, I just wanted to make sure that people have some idea that these two technologies won't *conflict* - at least at a technical level, and that in their current form they can complement each other. [Plus I didn't want to bog this down so early in the life of a nascent blog...] [EDIT: spelling error and expanded the path to the DRM folder]
|
-
I'm a security guy, driven by a long-standing paranoia, who happens to like the feeling that no one can get into my own files. So there. [BTW, the next time someone asks, this is coming to you live from Mike Smith-Lonergan, also known as Mike Lonergan.]
|
|
|
|
