|
Responding to lots of points:
There are lots of cases where the key server is not what gets compromised. There’s a disgruntled employee who makes a copy of the institutional key. There’s an employee who loads the institutional key onto a thumb drive for ease of use and then
loses it. There’s the key logger that’s been installed on your incident response laptop because the new IR intern used it to look something up on WordPress. Having one key that decrypts all your drives does not scale safely, even if you can revoke that key
within x number of hours or days.
Along the lines of revocation/changing of encryption keys, what about lost devices? Let’s pick on IBM for the sake of argument and that they lost .5% of laptops annually. I think they’re aiming to deploy 300k Macs. So that’s 1,500 lost laptops
a year. Not to mention the ones that fail to go through disposal properly. Even if you revoked a key, those lost or disposed of laptops would never get the message. Someone could amass a collection of computers to decrypt and peruse with the model of one compromised
institutional key.
Good escrow, which includes separation of duties, and least privilege concepts I think is best with a separate key per device. And software to help manage that is necessary to scale.
Paul
--
Paul Campbell | Senior Macintosh Systems Administrator
ASRC Federal Research and Technology Solutions
NASA Ames Research Center
Moffett Field, CA 94035
email@hidden
W: 650.604.4014 | C: 408.401.9114 | F: 650.604.3323
ASRC Federal | Customer-Focused. Operationally Excellent.
On Feb 25, 2016, at 10:26 AM, Evans, Frazier [USA] < email@hidden> wrote:
Both valid points. Another to consider is depending on the size of your Macintosh installation you may already have JAMF or something similar which helps to manage the keys. Injecting the Enterprise key as well as escrowing the machine specific
FileVault2 key.
Frazier
Sent from my iPhone
On Feb 25, 2016, at 1:16 PM, Campbell, Paul Madison (ARC-TH)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS] < email@hidden> wrote:
Walter,
There you go spawning thoughtful discussion again.
If the organization maintains an institutional key, then I would say they do have an escrow of the key, but is that really a better approach than an escrow where each device has it’s own key? If that institutional key gets compromised, you now
have thousands of devices to update, whereas if an individual key is compromised than only one device is potentially compromised.
Paul
--
Paul Campbell | Senior Macintosh Systems Administrator
ASRC Federal Research and Technology Solutions
NASA Ames Research Center
Moffett Field, CA 94035
email@hidden
W: 650.604.4014 | C: 408.401.9114 | F: 650.604.3323
ASRC Federal | Customer-Focused. Operationally Excellent.
On Feb 25, 2016, at 9:38 AM, Rowe, Walter < email@hidden> wrote:
Shouldn’t setting an institutional FileVault2 Master Key mitigate the key escrow issue?
--
Walter Rowe, Application Hosting
Infrastructure Services / OISM / NIST
US Department of Commerce
Email: email@hidden
Office: 301.975.2885
On Feb 25, 2016, at 12:18 PM, Campbell, Paul Madison (ARC-TH)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS] < email@hidden> wrote:
NASA’s largest support contract is switching to FileVault 2 from Symantec PGP, and many of the smaller contracts have used FV2 for years. The primary hurdle as I understood it was that FV2 didn’t natively escrow a key within control of the organization and
so NASA Ames resolved that with a Cauliflower Vest server controlled by our IT Security group. I think the escrow requirement is part of NIST 800-53, which would also apply to the VA I’m guessing.
Paul
--
Paul Campbell | Senior Macintosh Systems Administrator
ASRC Federal Research and Technology Solutions
NASA Ames Research Center
Moffett Field, CA 94035
email@hidden
W: 650.604.4014 | C: 408.401.9114 | F: 650.604.3323
ASRC Federal | Customer-Focused. Operationally Excellent.
On Feb 25, 2016, at 7:50 AM, Alan Lesse < email@hidden> wrote:
Has
anyone been able to use a Mac in the VA or other Federal environment with File Vault?
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
|