Pro & Con discussion about: Data Loss Prevention: Protecting Company's data

iunknown21 posted on 09.06.2009 at 05:08PM CEST, ID: 25270201

By blocking read access to Windows Explorer, cutting/pasting/dragging/dropping of files would also be blocked.

As for cutting and pasting of data and not files, we dont deal with clipboard operations at all but instead took the approach that ultimately whatever program accepted the paste would have to save the data, which we could block. The same thing is true for screenshot tools,like SnagIt. In my opinion, while FileSure can do this, it seems cumbersome.

FileSures magic revolves around a rules model that allows easy classification of files (and the data in them) for processing. Data that isnt in a file, i.e. clipboard, print jobs, so the we cant classify it. We didnt want to block entire classes of functionality like block all clipboard operations or stop all printing because they have legitimate functions in day to day operations.

Thankfully, typical evildoers dont steal data slowly, but instead try to get the evil deed over as quickly as possible&so they do a bulk copy of the files.

We did create a new protect called StopCopy-Vault that is targeted at protecting certain files from theft. When a file is placed in the Vault it gets encrypted and a built in viewer doesnt allow printing or saving and clipboard operations are controlled. This product was designed for companies that needed to let their employees use data but were worried about it leaking out. StopCopy-Vault work well for sales people who need to show Vidoes or Powerpoints in the field.

The problem with StopCopy-Vault is that, like all DRM-styled systems, it has to have its own viewer which means it only supports certain types of data. We get the biggies, PDF, Office, Flash, images, etc&

richrumble 09.07.2009 at 02:12AM CEST, ID: 25272113

Never the less OCR is the "analog hole" for these types of blocking... you can't block a screen shot from a RemoteDesktop user, VNC, GoToMyPC etc... I doubt you could block a screen shot from much without looking for the applications via some kind of blacklist. Find and replace can be effective at getting around DLP solutions, replace all a's with 1's, all e's with 2's, all i's with 3's all o's with 4's and u's with 5's, then copy paste the text. rot-13 is also very effective at getting around clipboard monitoring.
While it is true that most won't go through the trouble to rot-13 files, they will follow the path of least resistance which if it were me I'd use a boot disk, or hd->usb cable so I could grab the content "off-line". Again physical presence negates most security efforts and other factors like encryption should be used to mitigate those risks. The bottom line remains, if it can be read, it can be copied it's the nature of the digital beast.
-rich

iunknown21 09.07.2009 at 03:51AM CEST, ID: 25272354

I've never been a fan of signature checking since there are so many ways to get around it. Rot-13 is just one method, an easier way is just zipping it with a password.

How our customers do it, is to block Read Access to all programs that aren't 'authorized' so they can't zip it with a password or use a encryption program or anything else. Then address the security holes in the 'authorized' program by doing things like 'Block file writes by the authorized program'. (As an aside, one customer denied read access to Mapi32.dll so Excel couldn't do a 'Send to' <grin>)

You're exactly right...if it can be read...it can be stolen. The example I use during demos is someone reading a confidential document over the phone to his answering machine.

You're never going to be able to stop someone sufficiently skilled and motivated, but that's a small percentage of people. I mean, how many non-IT people even have a boot disk, let alone how to use something other than graphical UI.

What we're considering right now is adding encryption to FileSure. If we do this, we'll be able to stop 'off-line' access and restrict 'on-line' access. But real-time file system encryption is a scary thing!

richrumble 09.07.2009 at 01:59PM CEST, ID: 25274403

I'm sure the other hurdle is identifying all the documents that need protection, if your clients are like mine, they have no idea where things are, who can access them and ... it's a nightmare. Granted also, I'd be a motivated attacker ;) What about simple "hacks" like going to a cmd prompt...
type c:\some_folder\protected.doc >c:\hax_r_us\gotcha.doc
to the same effect echo and ADS streams...
type c:\some_folder\protected.doc >c:\hax_r_us\pool.jpg:gotcha.txt

Also try using more or less commands from the cmd prompt...
more c:\some_folder\protected.doc ... or less c:\some_folder\protected.doc
I've got a few other tricks to get past DLP but I'm motivated, I just like to see HOW motivated I'd have to be...
-rich

Putting Data in ADS is sooo old ;-)

http://utilitymill.com/utility/Steganography_Decode

Denying read access to cmd.exe would block type and echo.

I think the approach we took of denying read access to everything except the authorized problem is the right one since whatever program is it that builds the ADS has to read the file.  If I deny read access to *.txt to everything but Notepad.exe, only notepad.exe could create an ADS.  

Since it takes a program to do Steganography, it would also be blocked.  Still Steganography is just plain cool. :)

How about this for an issue?

We have a potential customer testing out our product call in; and he discovered a way to steal data that we missed!

Everything was going swimmingly, but then, he decide to use Volume Shadow Service ('Previous Versions' in Vista) to copy the data.  

What made it a fun issue was that VSS basically uses a sparse file of changed blocks so all we could really do was block access to the entire file, which would basically turn off the entire feature.  Not good.

Thankfully, we figured out that VSS was mounting a dynamic drive and that FileSure was working correctly but since the path was 'coming from a file', there wasn't really a drive letter and the rule that they were using had a folder path on it, including a drive letter.

We were able to fix the problem by just adding a new 'Drive type filter' called 'Driveless'.  

Still, it's something I've never thought off.  

But I guess stealing an old versions of a file is more desirable than NOT stealing the file all all.

Interesting. Windows 7 comes with so many features but all blogs etc. are reporting is "shake the window frame" to minimize all other frames. Bitlocker to go is shortly mentioned. Direct access ignored (VPN tool). I guess most users still don't know shadow copy. Today you need some 600 pages windows inside book to get an impression of opportunities.  hackers know these of cause.

Regarding file access to you apply the access policy also to automatic backup and recovery versions of e.g. an excel file?

Automatic backup and restore is also based on Shadow copy so we would probably catch it and block the restore. But if they backed the data up to a removable drive, they could restore it on another computer.

The only way I can think of to handle this is to add encryption to our product.   Something akin to decrypt this file if it's being opened by excel and use the key.   That would mean that the file would always be encrypted.

No I'm not talking about saving the files to different media but did you consider to secure  the backup files from excel like http://www.fileinfo.com/extension/xlk

Some more extensions

http://en.wikipedia.org/wiki/Microsoft_Excel#Standard_file-extensions

http://en.wikipedia.org/wiki/Microsoft_Excel#Office_Open_XML

Oh!  We don't define what files or types or locations to protect.  FileSure uses a wildcard based rules model so the user can define whatever they want.  

So a file rule of  '*.xl*' and catch the excel types anywhere on the machine/network/VSS.  

Zapping the clipboard sounds good. This should keep the data in e.g. Excel. Preventing a screencopy should be also possible if you monitor that API? call. I wonder though if a user might be able to export the data to a database by odbc?