Meeting the InCommon Assurance profile criteria using Active Directory

[Ron Thielen <>]

Sorry I didn’t see this until this morning.  Well okay, not really sorry.  I was in Nice France all last week, getting away from Chicago.  Should have stayed at least one more week though.

 

I’m wondering if we can’t address this problem in another way.  Let’s call it an “alternative means.”  J

 

As we know, disk encryption was proposed to address the requirement to encrypt the credential store with an approved algorithm (or use a salted hash).   As I see it, this mitigates against just one type of risk.  That being the risk of physical compromise so that a disk can’t be misappropriated and the data accessed in an offline attack.  BitLocker addresses this as would several other types of disk encryption.  I also think that an alternative means of having rigid and audited media handling and destruction processes within the data center can address this risk.  We have these, so I am considering proposing that as part of an alternative means statement.

 

The other type of risk that some people believe encryption or salted hashes address is someone stealing the data off of a live running system.  Microsoft says that BitLocker offers no protection for a live running system.  The same is true for most any encryption system, perhaps not for a salted hash.  So by recommending the use of BitLocker we are discounting the risk of someone stealing the data off a running system.  If that’s the case, I think I can make my argument for media handling and data destruction processes as an alternative. 

 

Now for the VMWare, Hyper-V, or whatever flavor of VM technology questions that were raised.  I guess the idea that isolating the DCs to a separate set of hypervisors must be based on the notion that this mitigates against another VM attacking the DC.  Using PCI DSS are an example, they say that PCI DSS managed systems can be on hypervisors as long as the hypervisor is also managed for PCI DSS.  I guess you could say the same thing for Silver managed DCs on a hypervisor.  The reason being related to the security notion of Mandatory Access Controls in that the security level of an object would be lowered to the lowest security level of any other object interacting with it.  So the hypervisor container would have to have as good or better security than the Silver managed virtual DCs running within it.  I’d think then that as long as the other VMs running on that hypervisor were also managed to the same security controls as your Silver managed DCs, then it would be okay to mix other VMs with your DC VMs.

 

Ron

 

From: [mailto:] On Behalf Of Brian Arkills
Sent: Friday, January 24, 2014 1:53 PM
To:
Subject: [AD-Assurance] RE: BitLocker operational issues

 

I don't think it defeats the purpose. One worthwhile strategy is to virtualize all your servers, even in cases where you only have a single VM on the host. The value added by doing this is:

-enables easy transitions (hardware end of life doesn't affect the server, can dodge planned network outages by migrating the VM to another host with capacity, etc.)

-can reclaim lost server capacity, e.g. UT-Austin didn't have money for another DC, but needed one. They noted one of their existing DC physical servers had lots of capacity, so they virtualized it on the same box, and added a 2nd DC VM on that box.

 

Of course, you have to evaluate this in the larger perspective of your goals.

 

From: [] On Behalf Of Capehart,Jeffrey D
Sent: Friday, January 24, 2014 11:44 AM
To:
Subject: [AD-Assurance] RE: BitLocker operational issues

 

Yes, exactly.  Thank you.

 

Although I was wondering if that defeats the purpose behind using VM’s?  I suppose it should make for simpler/common operating system management for the servers hosting the DC’s, at least.

 

From: [] On Behalf Of Brian Arkills
Sent: Friday, January 24, 2014 2:35 PM
To:
Subject: [AD-Assurance] RE: BitLocker operational issues

 

I think you meant:

 

Would it work to add additional physical servers (HyperV hosts) and then perhaps restrict the DC’s to the subset of HyperV hosts that have Bitlocker full disk encryption, and not host other VMs on those HyperV hosts?

 

From: [] On Behalf Of Capehart,Jeffrey D
Sent: Friday, January 24, 2014 10:53 AM
To:
Subject: [AD-Assurance] RE: BitLocker operational issues

 

Ron,

 

[resurrecting discussion from last summer…]

 

Any update on BitLocker operational issues when using VM’s for Domain Controllers?  Would it work to add additional physical servers and then perhaps restrict the DC’s to the subset of VM’s that have Bitlocker full disk encryption, and not share other tenants?

 

Jeff

 

From: [] On Behalf Of Ron Thielen
Sent: Friday, June 07, 2013 8:15 PM
To:
Subject: [AD-Assurance] RE: BitLocker operational issues

 

Let me also be clear.  I am not saying that we shouldn’t point out that BitLocker may be reasonable for some institutions.  However as we used to say when presenting performance and capacity planning studies, YMMV (Your Mileage May Vary).  We should point that out as well.

 

Ron

 

From: [] On Behalf Of Ron Thielen
Sent: Friday, June 07, 2013 7:09 PM
To:
Subject: [AD-Assurance] RE: BitLocker operational issues

 

That depends on the risk you’re mitigating and how BitLocker on the Hyper-V host actually worked, regarding which I have no clue.  For example, would that still means that sectors were only decrypted when the virtual machine when to read a VHD sector which needed to be brought in from physical disks.  It is sort of analogous to the question of whether using TPM protected disks is sufficient.  The answer is “it depends.”

 

In my case, since we have a sort of site license for VMWare, it isn’t relevant.  We aren’t going to use Hyper-V.  We actually found the links I cited by going to VMWare first and checking whether they supported BitLocker on VMs.

 

Ron

 

From: [] On Behalf Of Michael W. Brogan
Sent: Friday, June 07, 2013 4:40 PM
To:
Subject: [AD-Assurance] RE: BitLocker operational issues

 

This link has a doc from MS that describes how to install Bitlocker on a Windows 2008 Hyper-V host.

http://www.microsoft.com/en-us/download/details.aspx?id=6416

 

The link you cited below says

 

“BitLocker does not support the encryption of VHDs, but does permit storage of VHDs on a BitLocker-protected drive.”

 

and

 

“BitLocker is not supported for use within a virtual machine. Do not run BitLocker Drive Encryption within a virtual machine. You can use BitLocker in the virtual machine management operating system to protect volumes that contain configuration files, virtual hard disks, and snapshots.”

 

So, just to understand better, is it the case that you can’t install Bitlocker in the tenant OS but it can be installed on the Hyper-V host? And, if the latter is true, wouldn’t the tenant benefit from the disk encryption provided by the host?

 

--Michael

 

 

From: [] On Behalf Of Ron Thielen
Sent: Friday, June 07, 2013 11:59 AM
To:
Subject: [AD-Assurance] BitLocker operational issues

 

I raised the question about BitLocker operational issues, because something was  nagging at the back of my mind.  I asked the Windows admins and they pointed me in the right direction.

 

It turns out that there is a significant issue that may affect some institutions.  BitLocker is not supported in virtual environments by either Microsoft or VMware.  We run some of our domain controllers on VMware VMs, so this is certainly an issue for us.

http://technet.microsoft.com/en-us/library/hh831507.aspx#BKMK_VHD

and

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2036142

 

I guess we have to decide whether to move our VMs to physical hardware and lose the advantages that virtualization provides or submit an alternative means statement for RC4.

 

Ron