[FDE] Enterprise Right Management vs. Traditional Encryption Tools
Garrett M. Groff
groffg at gmgdesign.com
Tue May 8 12:29:35 MDT 2007
Not claiming to be an expert here, but I'd say it depends on the particular
organization's needs, including such factors such as price, ease of use,
ease of deployment, ease and flexibility of central management, etc.
Not sure if rights mgmt protects against the kinds of things that FDE
protects against (like protecting against juicy information appearing in the
page files), but the comprehensive nature of the security solution might
play a role as well. I'm thinking that RM would do a better job protecting
against people sending secret docs via email (due to carelessness or
malice), whereas FDE (or file-based encryption like EFS) protects the data
due to physical theft of a computer, external drive, USB flash memory, etc.
Above all, a data security solution must be convenient and extensible. If
not, people won't use it, or won't adhere to it. "Transparent" encryption
options (again, FDE, EFS, etc) provide a nice option for a lot of people.
I'm assuming there are RM suites that are reasonably transparent to
end-users. If so, adoption and greater security of business and consumer
data is more likely.
In conclusion, I'm not sure that it matters which data security solution an
organization chooses to adopt, provided that that solution provides
sufficient protection and a reasonable level of convenience for the
end-user.
- Garrett
----- Original Message -----
From: "Ali, Saqib" <docbook.xml at gmail.com>
To: "Cryptography" <cryptography at metzdowd.com>; <FDE at www.xml-dev.com>
Sent: Tuesday, May 08, 2007 1:16 PM
Subject: [FDE] Enterprise Right Management vs. Traditional Encryption Tools
>I was recently asked why not just deploy a Enterprise Right Management
> solution instead of using various encryption tools to prevent data
> leaks.
>
> Any thoughts?
> _______________________________________________
> FDE mailing list
> FDE at www.xml-dev.com
> http://www.xml-dev.com/mailman/listinfo/fde
>
More information about the FDE
mailing list