Some questions about migrating to new hardware with FIPS compliance

[markgarza]

Hi, we are currently running EPO 5.9.1 in mixed mode. We're planning on upgrading hardware, at which point we'll likely upgrade to 5.10 and operate EPO in FIPS mode. We use ENS and Drive Encryption in our environment. I have some questions regarding the migration:

I know that FIPS must be enabled in a clean-install fashion, and according to documentation we are unable to restore non-FIPS databases to a FIPS server . Does this mean we'd essentially be starting from scratch with EPO entirely, setting up all the policies and possibly re-deploying the EPO agent to all our active systems? 

For our encrypted systems, does this mean we should decrypt and deactivate these systems/uninstall DE software and agent before migrating over to the new server?

Does FIPS mode affect the DEETech tool at all?

Might post more as I think of them. Thanks for your help. 

[LKS]

Hi markgarza,

When you install McAfee ePO in FIPS mode, you can't restore a McAfee ePO database from a previous non-FIPS McAfee ePO server. 

You can't restore a McAfee ePO server that wasn't in FIPS mode as a FIPS mode McAfee ePO server. The McAfee ePO software and database must be reinstalled as a new instance of McAfee ePO.

The complete McAfee ePO reinstallation is required because all existing signed and encrypted content was signed with non-FIPS mode keys. Also, the database contains content encrypted with non-FIPS mode keys and can't be decrypted with the FIPS mode keys.

Indeed you have to redeploy the Agent to your entire environment. In regards to MDE , you have to put across this question to MDE team.

https://community.mcafee.com/t5/Encryption-EEM-Managed/bd-p/encryption-eem-managed

Was my reply helpful?

If you find this post useful, please give it a Kudos! Also, please don't forget to select "Accept as a Solution" if this reply resolves your query!

[cdinet · Accepted solution]

No, you don't have to start over with everything.  Here is how you can do this.

Set up your new server in fips mode, then you can export your system tree, policies, client tasks, tags, policy and task assignments, any custom queries, server tasks, and anything else needed that can be exported.  Import them into your new server then.

In the old server, you can set that up to transfer systems.  The first thing is to review the Drive Encryption transfer guide for transferring systems with drive encryption.

https://docs.mcafee.com/bundle/drive-encryption-v7-2-0-client-transfer-product/resource/PD26656.pdf

This is the KB for how to set up the transfer - https://kc.mcafee.com/corporate/index?page=content&id=KB79283

Once you have your system tree, policies, assignments, etc imported, you can then start transferring systems.  You basically will register the new server with the old (you will only be able to choose 5.9.1 as server version, but that is ok despite warning).  Then you export your agent-server communication keys from the old server and import them into the new.  You will only import the 2048 bit keys, not the 1024 since you will be in fips mode.  

Keep a list of your systems in the old server so if any fail to transfer, they can be remediated.  

[LKS]

I agree with cdinet as system transfer would allow you non-fips to fips environment.

[markgarza]

Hi @cdinet, this is finally gaining steam and I wanted to clear something up that I thought of while reading your reply again:

Regarding the exporting/importing of the ASCI keys, this is only if I intend to keep both in production correct? The current EPO server will be decommissioned after the migration is done to the new server, but there will be a period of co-existence as we are migrating the systems over. Should I still go ahead with this step?

[cdinet]

It is a necessary step for this reason.  The agents have that communication key and if the new server doesn't recognize it, it will reject the communication.  It doesn't matter if your other server won't be around anymore or not.

[markgarza]

Ah ok, that makes sense. And just so I understand, transferring the systems this way would have the same affect as just uninstalling the agent associated with the old server and replacing it with the agent installer from the new server, correct? I'll still have to move the machines around to ensure they get the correct policies from our system tree assignments?

[cdinet]

You can import your system tree and all policy/task assignments ahead of transferring systems.  System tree sorting isn't exportable, so if you are using that, you would have to set it up again.  But, having all that in place before transfer helps keep your systems where they belong with the right policies.  What transfer systems does is give the clients a new sitelist that has just that new epo server in it and the certificate.  Once they check in, they will get a new complete sitelist that would include any agent handlers and repositories, and get any other keys from the new server, including repository keys.  It isn't exactly the same as reinstalling the agent.  Keeping existing agent and using the transfer functionality has the benefit of not losing any encryption keys if you are using drive encryption or any other products with user based policies.

[markgarza]

Thank you for the information! One last thing:

We do have DE encrypted products, and it is to my understanding that in order for that to be FIPS compliant, we must decrypt/uninstall McAfee DE and then re-install using appropriate CMD line arguments and re-encrypt the drive (per https://docs.mcafee.com/bundle/drive-encryption-7.2.5-installation-guide-epolicy-orchestrator/page/G...). Will this process not generate new encryption keys anyway, or am I misunderstanding?

[cdinet]

That would be a drive encryption team question.  Our team in this group doesn't support drive encryption.  While we can answer basic questions, something like that should have a definitive answer from an expert in it.