Re: [Fed-Talk] FileVault and Data Encryption Feedback
Re: [Fed-Talk] FileVault and Data Encryption Feedback
- Subject: Re: [Fed-Talk] FileVault and Data Encryption Feedback
- From: Amanda Walker <email@hidden>
- Date: Tue, 5 Sep 2006 17:40:53 -0400
On Sep 4, 2006, at 11:50 PM, Shawn Geddis wrote:
Since on Mac OS X systems, the Standard user is very limited to
where they can store data on their machine (Home Directory, Group
Shared Folder, etc) FileVault is actually able to protect the
important PII that is the key reason for the OMB Guidelines to
begin with.
That's fair, and covers a large proportion of users. For developers,
things get a little more complicated, but security policies on
development machines are their own can of worms.
Those that are focusing on complete disk encryption are trying to
address the concerns of data being written all over the drive which
happens on Windows, but is not in accordance with the Permissions /
ACLs on Mac OS X.
This is true, but there's another social/organizational factor at
work: being able to define short, simple (and therefore
understandable) security policies that have as few platform-specific
details as possible (yes, this constitutes tilting at windmills, but
that doesn't stop security offices from trying). Most such policies
are not written by very Mac-savvy people. Now, I'll agree that this
is a bug :-), but I've several times been presented with an already-
approved policy with embedded assumptions about how Windows worked,
by a security authority who was not interested in revisiting it just
because the Mac works differently. I'm not in that situation right
now, thankfully, but ... how to put this delicately ... the military
services can be awfully Windows (2000!) centric.
Any external drive that is platform agnostic, typically employes an
external token that provides the single factor authentication used
for Hardware Encryption. You have the token inserted into the
device which allows for the device to be accessed by the computer
in question.
Correct. I've also had great success with the "external/removable
hard drive and a safe" approach. This tends to make security
officers very happy, but users a bit annoyed. There's just no
pleasing people.
It is unfortunate that the real security value of Mac OS X is
getting overlooked while people are scrambling to meet good
security requirements that they should have been meeting long
before OMB issued their recommendations.
Oh, absolutely; this is another thing which carries over into the
private sector as well.
The unfortunate aspect of that is that several agencies apply an
Agency Asset Tag to the laptop which visibly indicates exactly who
it belongs to.
Yes, well. That's up to those agencies, I suppose.
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...
You can create an EDI for the Applications and have the system
automatically mount the encrypted image upon successful login to
the machine.
User Settings are in ~/Library/Preferences which would indeed be
part of the encrypted protection.
That's an excellent suggestion. Thanks, I'll take a closer look at
that!
CRYPTOCard is a OTP Token-based solution and is for authentication
and does not provide the encryption protection you are looking for
here. Their claims are right on and so I would ask what claims you
are referring to.
http://www.cryptocard.com/index.cfm?pid=440&pagename=SC-1 Technical%
20Specifications
"Storage of third-party digital certificates"
"Encryption and digital signature support"
These capabilities, as far as I've been able determine so far, were
copy/pasted from the Axalto Cyberflex docs, and are not actually
usable on CRYPTOCard smart card tokens. As I've recently discovered,
the CRYPTOCard applet doesn't seem to co-exist well with other
applets which do provide PKCS11 or PKCS15 capabilities--I can load
another Applet onto the card, but then get "Corrupt container" when I
try to use the CRYPTOCard OTP applet.
However, this isn't a complaint aimed at Apple, and for OTP use, they
work really, really well. I didn't mean to fault CRYPTOCard for the
fact that I drew incorrect conclusions about what I could use their
tokens for. I'm a happy CRYPTOCard user--I'm just still looking for
a bigger set of capabilities from a single token.
There are *Several* commercial Smart Card vendors providing support
for Mac OS X 10.4.x. Since this is a "Federal" mailing list, it
typically does not come up, since Federal Agencies are basically
forced to use Federal Smart Cards.
Understood, and I didn't mean to go too far off-topic. My experience
as a contractor has been that I've been required to meet Federal
(specifically military) operating guidelines (particularly when it
comes to information security) without being able to rely on all of
the infrastructure that my government customers have been able to use.
To use an analogy, I can go out and buy a Class 5 safe, or a cipher
lock for a door, or other types of security equipment. I may not get
GSA pricing on them, but I can buy them, and they'll work as well for
me as they will for my government counterparts. I'd like to do
something similar with AAA tokens; they may store certificates rooted
at commercial or internal CA, but I'd like the same operational
capabilities.
MUSCLE is a Framework and not an Applet.
Sorry for the shorthand. I've loaded the CardEdgeII.ijc applet using
the Cyberflex 64K loader; this is recognized by ID Ally under windows
and MUSCLE under Linux, but does not appear to be recognized as a
PKCS15 token under MacOS X. But I'm getting off into the weeds again...
If someone does know of a private sector equivalent to the CAC,
please drop me some email :-).
Now that you know there are several that provide commercial Smart
Card support on Mac OS X, drop me a line! :)
I'll do that :-). Thanks for the elaboration.
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