1 2 Previous Next 15 Replies Latest reply on Jan 27, 2012 5:32 PM by SafeBoot

    MEE 6.2 Post-Boot Encryption and FIPS/NIST


      I really want to get us out of the pre-boot world. The last hurdle I have is proving that post boot authentication is secure enough. A major hurdle on this is FIPS and or NIST certification.


      Does anyone know if this scenario is FIPS Certified or going to be FIPS Certified ?




        • 1. Re: MEE 6.2 Post-Boot Encryption and FIPS/NIST

          EEPC is in progress http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140InProcess.pdf


          You MUST use pre-boot though, all post-boot encryption solutions rely on copying the key to the disk in some plainly accessible way. That will never pass on any regulation.


          The only secure way to encrypt a drive, is to ask the user to supply the key before you need access to the data, anything else is just an open door.

          • 2. Re: MEE 6.2 Post-Boot Encryption and FIPS/NIST

            Ok, Thanks, even the new Mcafee 6.2 with the encrypted mini-os that gets you to the Windows login? That will never be NIST or FIPS Complaint ? I hear of hospitals deploying this way and I wonder how they comply with HIPAA standards using post-boot.


            On a side note, post boot auth would make our world 100 x easier. We estimate we could reassign 2 or more people to other tasks if they didnt have to deal with the headaches of preboot synch problems and assigning users to pcs.

            • 3. Re: MEE 6.2 Post-Boot Encryption and FIPS/NIST

              NIST only require the cryptographic module to be certified, everything else is not considered, so the whole product will get Certification.


              Yes, post boot is easier, but then again, so is leaving the keys in your front door - neither though offer any security.


              As for people working in post-boot mode, they are relying on the "letter of the law" saying the data has to be "encrypted", but not mentioning appropriate key management controls. That's why newer regulations, like MAS, HITECH etc, mentions things like NIST 800-111, and the concept of loosing the key with the data not resulting in a protected situation.


              The bottom line is, with any product you choose, if there's no authentication, then there's no protection - the key must be stored with the data, and thus, easy for an attacker to find.


              Passware already released products for Bitlocker and others which proove this.


              If pw sync is a problem, just make everyone pick two different passwords? Others have done this fine. Re user sync - does the "automatically add domain users" option not work for you? In 6.1.2+ you can script user assignment as well remember.

              • 4. Re: MEE 6.2 Post-Boot Encryption and FIPS/NIST

                Our current deployment is way too manual and there are way too many problems with sync. I dont think asking people to have 2 passwords is the right solution. This current preboot deployment is not maintainable and we are moving away from it. I'd like to still use Mcafee.


                When a laptop is stolen we need to be able to say "The machine was encrypted with a NIST certified solution" and thats all we care about. If NIST cares not about the authentication method then we are golden. If you have any documentation on this I'd appreciate it.


                Is post-boot really like leaving the keys in the front door ? From what I understand with the new version, the system is encrypted until you log in to Windows. I'll try lopht crack and some other tools, but I'm fairly certain I wont see the drive unless I first login with EETECH. Where is the vulernability ? 


                Message was edited by: jickfoo on 12/6/11 11:49:15 AM CST
                • 5. Re: MEE 6.2 Post-Boot Encryption and FIPS/NIST

                  How did windows boot, if the drive was not being decrypted?   The challenge is that it's easy to break through the Windows password and get access to the files - any network attack would work, firewire attacks, pcmcia attacks, etc - any DMA bus attack, plus if you were really keen you could just pull the memory and read the decryption key straight out of it. You could even just step through the boot sequence to a point the drive was being decrypted, then pipe the disk off somewhere else.


                  Certainly annoying, but secure? No. Any of my dev team, or anyone who's worked for my team could suck the data off such a machine in a few minutes. Anyone with any nonce could do it for any product in a few hours, as proven by Passware releasing a hack for Truecrypt and Bitlocker.


                  NIST 800-111 is the doc you need to read - to be compliant with industry "best practice" that's the doc most commonly quoted.



                  1 of 1 people found this helpful
                  • 6. Re: MEE 6.2 Post-Boot Encryption and FIPS/NIST

                    Thanks for the reply.


                    With all due respect, I think if you had to support the product for a large organization on a day to day basis you would have a different opinion. We have to balance security with usability. I would also venture to say that you're oversimplifying how easy it is to bypass windows security on a fully patched machine with strong passwords and an up to date security package. The exploits you are talking about are still open to other network users once the machine logs past the preboot authentication. The same risks exist when the user jumps on the Starbucks network.


                    We're trying to protect against the stolen laptop scenario from the average bad guy. They are going to steal it and F-Disk it. Obviously there are super-geeks out there that can hack through and get at the data, preboot auth or not. Our data isnt the variety that would cause any mission impossible style conspiracies.

                    • 7. Re: MEE 6.2 Post-Boot Encryption and FIPS/NIST

                      I'm just relaying my reading of the regulations - but in the words of "Ask Gary" - I'm not a lawyer.


                      It's not about the likelyhood though - it's about the possibility - And, at the end of the day, it's mine (and your) personal data at risk, so though professionally I understand and appreciate your pain, personally, I want you to protect my data beyond a shadow of a doubt.


                      I agree that most lost laptops are wiped and recycled, but would you take a chance of that with your personal info, your home banking details, your social security number? I am guessing that like everyone in this industry, your professional direction differs from your personal.


                      If you got a letter from your bank telling you that they had lost a laptop with all your data on it, but it was ok, there was a Windows password which the user said was pretty strong, and that there was encryption (but the key was on the drive), how would that change your opinion of that bank?


                      As for bypassing Windows though - look at the Passware software. It's really, really easy.


                      Finally, I'm playing devils advocate with you of course, just throwing out things to think about, not trying to be rude or anything.

                      • 8. Re: MEE 6.2 Post-Boot Encryption and FIPS/NIST

                        Agreed. It's a healthy debate and there is nothing wrong with that. I'd hope the bank would not store personal info on a laptop. I dont store personal info on any of my machines. I fear spyware and trojans way more then I fear the risk of theft.


                        We've spoken to a hospital in our same situation that recently did this same conversion and they're much happier. Perhaps less secure but they are still complying with the required regulations.


                        I'll give Passware a shot. I'm also going to try Lophtcrack and some other tools. We also have the option of leaving pre-boot auth on certain machine deemed to be higher risk. Personally though, I think our goal should be no customer information on any laptop. Thats what secure file servers are for.




                        • 9. Re: MEE 6.2 Post-Boot Encryption and FIPS/NIST

                          I totally agree - stick it in the cloud and give everyone iPads or Chromebooks - problem solved pretty much.

                          1 2 Previous Next