Strict government compliance with FIPS and Common Criteria standards is not formally conveyed across release upgrades. Continued formal compliance technically requires the appliance to remain on the same compliant release until a newly certified release is available. It may further require wiping existing critical security parameters (CSPs), including all passwords and all keys, by running the FIPS zeroization function before reasserting compliance configuration on the new image.
Zeroization wipes CSPs from all running system configuration, and deletes all saved system configuration files, leaving the appliance system configuration either with CSPs missing or with a default value for any CSPs that are part of the factory default configuration, such as the admin password. Zeroization does not delete things other than CSPs.
Although it is required for strict formal compliance, zeroization is a destructive procedure that can cripple an appliance and require significant work to generate new CSPs and restore a working environment. Also, since some CSPs may be used for access to other systems, changes may be required not only on the system that was zeroized, but across the ecosystem.
Zeroization is never performed automatically. You must choose to execute it by running the CLI command compliance declassify zeroize.
Types of CSPs include:
Local passwords
The system self-signed certificate (regenerated)
An installed web certificate and private key
Any certificate that has a private key
Certificate signing requests generated by the appliance
SSH host keys and all user keys
CMS passwords and SSH keys used to manage other appliances
IPSec peer configuration
NTP auth keys (new in 2020 releases)
HX Agent PKI Certificates (CAUTION: replacement requires visiting every agent)
VX submission queue keys
Important
When you upgrade to a newly certified release you must reapply the compliance command to be fully compliant.
Divergence from strict formal compliance
Zeroization is not practicable in many cases. Your organization may choose to deviate from strict formality at its own risk and discretion. For example, it may be necessary to run interim releases, or to upgrade to a new formally compliant release without zeroizing existing CSPs. Divergence requires understanding of the formal and technical risks, and a more detailed understanding of the standards compliance criteria.
Although Trellix cannot formally condone, guarantee, or attest to compliance continuity across upgrades, the engineering team makes a best effort not to alter any pre-existing formally certified functions between certification release cycles, with the exception of security vulnerability patches to those components, should they be necessary. Your organization may study the standards and the compliance criteria that are in scope, and may choose to assert at its own risk that all CSPs in use under the previously compliant standard are still compliant under the newly upgraded FIPS or CC criteria, with its new cryptography and security standards, and that pre-existing CSPs created under prior compliance do not need to be zeroized and replaced.
Note that maintenance releases primarily tend to contain bug fixes, and minor release upgrades tend to contain new features that would not be formally compliant. Trellix can advise but cannot guarantee anything about functional divergence from the standard.
Achieving informal compliance continuity
Follow these steps to achieve informal compliance continuity:
Verify that all CSPs used by your system are compliant under the new standards.
Run the command show compliance standard all and note any criteria that are not compliant.
Run the command
compliance apply standard {fips | cc-ndcpp | all}.Delete from the configuration any CSPs that were created while the system was out of compliance on the current release or a previously certified release.
Save the configuration and upgrade the appliance to the new compliant release.
On the new release, run the command
show compliance standard {fips | cc-ndcpp | all}.Run the command
compliance apply standard {fips | cc-ndcpp | all}and specify the same standards previously under compliance.Note
Running compliance apply after upgrade ensures that all new criteria or modified criteria are enforced. Upgrade does not automatically reapply compliance.
Run the command
show compliance standard {fips | cc-ndcpp | all}again to verify full compliance.
Important
Formal compliance requires continuity of all criteria in force throughout the release. It is your responsibility to maintain compliance with all criteria you require. Verify compliance periodically and whenever you make configuration changes that relate to compliance criteria.
Endpoint Security Agent (HX) certificate compliance
In Endpoint Security (HX) release 5.0.1 and later, when compliance is applied, no agent certificates are deleted. In previous releases, the compliance apply command silently deleted all agent certificates. This action caused communication between endpoint agents and the endpoint server to be disrupted and required new certificates and keys to be deployed to all the managed agents. Deleting agent certificates is not required for compliance, because agent certificates and private keys are not within the scope of the certifications.
It is nonetheless good practice to generate agent certificates while the Endpoint Security (HX) server is in compliance mode, using the hx pki regenerate family of commands. This will ensure that agent certificates are generated under FIPS and CC-NDcPP cryptographic standards.