Introduction

BigFix is a systems and security management product that allows you to fully control all of the endpoints in your organization. This level of access, and the automation it brings, provides exceptional power and visibility into all of the computing endpoints managed by the system. Logically, one must also ensure that the management system itself be managed securely and audited regularly. BigFix provides strong security out-of-the-box but even a natively secure system still requires proper deployment, oversight, and configuration to ensure that it is protected from outside attackers or malicious operators. This document describes the overall security of the system and the attack vectors that each security feature is designed to counter for BigFix v9.0 and above.

 

Installation: Site Administrator Key

This private key, generated during install is critical to the security of BigFix. This key should be created with a high-complexity password, copied to removable media, and stored in a locked safe. The original system on which the key was generated should have its free space wiped securely after the site key has been deleted from the system. Note that if this key is lost the entire BigFix deployment must be re-deployed, there is no "back door" or key recovery mechanism.

HCL recommends a 4096 bit key over a 2048 bit key when creating the Site Administrator key. The latter is still secure (as of 2018) but each year there is slow but steady progress in factoring improvements and computing power, each of which slowly chips away at the relative cryptographic strength of RSA asymmetric keys.

The Site Administrator Key is used to create an X.509 certificate chain that is the basis for the security of the BigFix system (discussed below). Note that there are no default accounts or passwords created during the BigFix installation; this makes BigFix secure from simplistic attacks that target products that use well-known defaults.

 

Operation: Fixlets and Actions

All Fixlets and Actions managed by BigFix are protected by digital signatures using strong authentication: all signature hashes are created using SHA-256. Any time a Fixlet is received from HCL in a site update – such as a Windows patch definition or SCM check – the site includes a full directory listing of its contents including the name, size, sha1 and sha256 of each file.  The directory listing is digitally signed and the signature is verified against a public key distributed in the product binaries.

Any time a custom Fixlet is created by the customer it is protected in the same way and the directory listing is signed using the BigFix Server key which is part of the certificate chain created during installation. The BigFix components will reject any Fixlet that is inconsistent with the directory listing. This protects against data corruption and man-in-the-middle attacks.  Custom Fixlets are also individually signed when first created and stored in the database, which prevents a database administrator (who is not an BigFix operator) or an attacker from inserting bogus Fixlets into the system.

Actions follow the same rule and are validated against a site’s signed directory list. All actions – there are no exceptions to this rule – sent from the BigFix Server to BigFix Agents are also digitally signed. Again, this prevents against data corruption and, more importantly, prevents an attacker from masquerading as the BigFix Server or inserting malicious actions at any point in the Relay network architecture.

Not only will an BigFix Agent reject any content that fails the signature check but it will also reject properly signed messages that were created in another BigFix deployment. If your organization has two deployments (say, test and production) you can not accidentally control BigFix Agents that are from the wrong deployment since those Agents do not share the same certificate chain credentials.

 

Data in transit, Data at Rest

All communication between Relays and Agents can be encrypted using TLS. This prevents an eavesdropper from performing any analysis on the type of instructions being sent to endpoints or reading the reports sent from an Agent to the Server.

If you choose not to use TLS between Relay and Agent you can still choose to encrypt the report payload that an Agent sends back through the Relays to the Server. These AES-256 encrypted reports ensure that an attacker is unable to read information such as the list of patches or vulnerabilities that exist on an endpoint. This also means that for the brief period of time these reports are “at rest” in a Relay’s cache they are secure from anyone who has access to a Relay computer.

Relays can also be configured to only communicate with Agents that can successfully authenticate using TLS based on a previously distributed certificate. This optional behavior ensures that internet-facing Relays will not expose any information – such as a list of available Fixlets – to attackers masquerading as an BigFix Agent trying to innocently gather instructions from your Relay infrastructure.

 

Notes

 

Certificate Lifecycle

The site_admin_cert and private key are generated at deployment creation time. The site_admin_cert is signed by the license server, but HCL does not have access to the private key. The site_admin_cert only needs to be used in order to rotate the server_cert or for infrequent system configuration changes (e.g. upgrades), and so it can be kept offline in a protected place.

The server_cert is generated at server installation time and signed by the site_admin_cert certificate. The server_cert is bundled into the agent installer and is included on the endpoint in order to provide a chain of trust back to the root server. The server_cert can be rotated if compromised by using the site_admin private key.

The client_cert is generated on the endpoint at agent installation/registration time. Endpoint certificates are signed by the root server via a certificate signing request (CSR) process. The root server stores all client certificates in its database.

The relay_cert is generated and signed in the same manner as the client_cert.

Endpoint certificates can be revoked in order to prevent them from connecting to the deployment.

All certificates used in these various internal operations ultimately derive from an internal BigFix Root CA, and are trusted based on public keys included in the product binaries. As a result, BigFix certificates will appear as self-signed certificates to vulnerability scanners, but they are not actually self-signed certificates (which could be easily spoofed). The product will only function with valid BigFix certificates generated by our licensing process, and cannot be configured to use 3rd-party certificates signed by external CAs. This allows product security to be seamlessly built-in to its functionality from the start, eliminating external dependencies on certificate management and distribution. It also enables the BigFix Root Server to automatically manage product certificates, so BigFix or Server administrators do not need to manually maintain or renew endpoint certificates.

Note: The above statement only applies to internal communication and digital signature usage between BigFix components. External interfaces (WebUI, Web Reports, BCA, BFI, and the REST API) can be configured to use 3rd-party certs.

 

Communication Security & Certificate Trust

 

Private Key Protection

Private keys are protected in the following ways:

            - on Windows: limit access to Administrator users via file permissions and use the Windows CryptoAPI to encrypt the private key on disk

            - on Mac/Linux/Unix: limit access to root users via file permissions

Implication: the only way to compromise the server_certificate is to be an administrator/root on the root server machine itself.

 

 

Related: