Re: [Fed-Talk] Army to Encrypt Computers
Re: [Fed-Talk] Army to Encrypt Computers
- Subject: Re: [Fed-Talk] Army to Encrypt Computers
- From: email@hidden
- Date: Sat, 26 Aug 2006 18:19:04 -0400
- Organization: Virtual School
I'll just mention one other reason from personal experience.
If a hard drive goes completely belly up, Apple will sell you a
self-replacement kit. Fine so far. Problem is, if they're broken in such
a way as to not mount, there's no way to erase them before sending them
on there way to the dumpster behind Apple's loading dock, or Maxtor's,
or who knows where they go from there?
Yet Apple *insists* that you return the failed drive, else incur a fee
comparable to the cost of yet another drive. Same applies if the *drive*
is damaged in any way.
As I explained to them on the phone, I had no problem returning the
drive but considerable problem sending them the data stored on that
drive. "Trust us, we're Apple" was the best they would do.
The best I could devise was to hire a honkin big bulk eraser from a
local company, hoping it wouldn't bend the metal too noticeably yet make
at least some dent in the data stored there. This wasn't drop-dead
secret information after all; just personal data I saw no reason to share.
Any Apple people here? Your return policy is seriously broken. Better
fix it before the world wises up.
PS: I only learned of this policy once the new drive arrived. In the
future I'll be smarter and not use Apple replacements. They're more than
3x the price anyway.
Grrrrr.
Amanda Walker wrote:
On Aug 26, 2006, at 3:38 AM, Wm. Cerniuk wrote:
Is there a benefit that outweighs the liability of encrypting the
entire disk?
I can't quote our security policy outright, but I can give some general
examples.
The biggest one, especially desirable to us for laptops (and other
machines to which an adversary could easily gain physical access) is
deniability--It would be extremely desirable if a lost or stolen machine
wasn't identifiable as belonging to our organization, even if you popped
out the disk and mounted it on another machine (the big threat that
full-disk encryption helps to counter). If a machine is lost or stolen,
we'd really like it to be *only* an inventory problem, not an
information or operational security problem.
As far as reliability goes, we expect machines to fail for all sorts of
reasons, so a slightly increased chance of failure from full-disk
encryption isn't a major problem as long as the incidence is low. The
odds of theft, covert physical access to the machine, or drive failure
appear quite a bit higher than the odds of whole-disk encryption eating
the disk.
Even my current (very Mac-positive) employer is having to make an
exception to our security policy for Macs, and there is a blanket
prohibition on using Macs outside of a physically secure area if they
have high-value data on them.
With AES 128 bit encryption seamlessly working on the user's home
directory and factor authentication with the inclusion of a CAC in the
Mac OS X system, there should not be any exceptions to be made. (?)
Not all sensitive information is stored in the home directory. For
example, we'd rather not disclose what software vendors we have site
licenses with (Applications), network setup details (VPN settings and
scripts), and so forth. FileVault doesn't protect any of that. But
even that aside...
Unfortunately, for the private sector there seems to be no third party
smart card or token system available that provides similar capabilities
to a CAC. CRYPTOCard comes closest, but doesn't live up to all of its
marketing claims.
I've tried loading a MUSCLE applet onto a Java card, which works for
Windows and Linux boxes, but MacOS X apparently no longer supports
MUSCLE in Tiger and above. I'm currently playing with OpenSC, which
looks very promising, but haven't quite gotten it to work.
If someone does know of a private sector equivalent to the CAC, please
drop me some email :-).
Amanda Walker
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
begin:vcard
fn:Brad Cox
n:Cox;Brad
email;internet:email@hidden
tel;work:703-361-4751
tel;home:703-368-1174
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden