Secure deployment

Communication between components of BMC Discovery is secured using TLS, and authenticated using certificates. The communication is:

Between appliance and Windows proxy
Between scanning appliance and consolidator
Between members of a cluster

For information about securing communication between the user's browser and the appliance web user interface, see Configuring HTTPS settings.

When one part of BMC Discovery connects to another, each end of the connection checks that the other end is approved. The certificate can be thought of as the public key half of a public-private key pair — if the endpoint's private key details match the expected public certificate details, the connection is approved. Note that although the underlying protocols are the same, the trust model in use in BMC Discovery is different to the trust model involved in HTTPS used on the public web. For more information, see Technical details.

Certificates are small text files containing an ugly jumble of letters and numbers. To enable visual comparison of certificates, they are reduced to a fingerprint, which is a somewhat shorter sequence of ugly hexadecimal digits, for example '7D:0B:13:54:4B:F1:39:87:A0:AB:4E:FA:3D:A0:A2:0C:2F:0A:A1:BA'. Certificate fingerprints are shown in various parts of BMC Discovery so that the identities of the endpoints can be confirmed.

The following topics are provided in this section:

Maximum security

The most secure way to deploy the components of BMC Discovery is for each component to have its own unique key and certificate. This is the default scheme for new deployments. In this scheme, each connection between components must be approved; any connections that have not been approved are denied.

In versions of BMC Discovery prior to 10.1, a single default certificate was used in all deployments. That default certificate is referred to as the legacy certificate. For added security, the recommendation was to deploy custom keys signed by a private certificate authority. Upon upgrade from an earlier version, the existing keys and certificates are retained, so that existing communication links are not broken. To increase security of existing deployments, we recommend that once all parts of the deployment have been upgraded to version 10.1 or later, unique keys and certificates are generated for each component.

Approving connections

When connecting components of BMC Discovery, the components' certificates must be exchanged. The actual certificate exchange is performed automatically, but the connection must be confirmed via the user interfaces on both ends of the connection.

Between scanner and consolidator, the scanner connects to the consolidator and the connection must be approved on the consolidator.
Between the BMC Discovery appliance and the Windows Proxy, the link can be established from either end, and must be approved at the other end.
In a BMC Discovery cluster, the cluster is considered a single component and all members share the same key and certificate details. When a new member joins the cluster, it automatically receives the key and certificate details.

Once a connection has been established, if either end changes its key and certificate details, the communication link will fail, and must be re-approved.

Upgrade considerations

Upon upgrade from a release prior to 10.1 the existing keys and certificates are retained, so that existing communication links continue to function. To increase the overall security of the system we recommend that once all parts of the system have been upgraded to 10.1 or later, the old keys are replaced by new unique ones for each component. Components can be upgraded one at a time — there is no need to switch all components from legacy keys at the same time.

If the upgraded appliance or Windows proxy was previously using the default legacy keys, then when the switch to unique keys is made, appliances automatically approve the new certificate. If the default keys had been replaced with custom site-specific keys, a switch to new unique keys will disable the existing communication links until they are re-approved. When an appliance key and certificate is changed, the Windows proxy always requires approval of the new certificate.

If it is necessary to add a newly installed appliance or Windows proxy to a system involving older version components, communication will not immediately succeed because the newly installed component will have unique keys that are not known to the old components. In this situation, the newly-installed component should be switched to use the legacy key and certificate via the certificate management interface.

Managing keys and certificates

Within the BMC Discovery user interface, details of the appliance's own key and certificate, and the certificates of other components that it trusts are visible within the Administration tab, in Security > Appliance Certificates. The page permits the generation of new keys, and the installation of the legacy keys for successful interaction with older-version components.

On the Windows proxy, access information about the proxy's own key and certificate in the Proxy Manager via Edit > Key and Certificate Management. As with the Appliance Certificates page, the dialog permits the generation of a new key and certificate and the installation of the legacy key. Certificate details of the connected appliances are available via Edit > Known Appliances.

Unless switching from the legacy keys to unique ones after an upgrade, generating a new key and certificate will break all existing communication links to other components, until the links are re-established.

Technical details

The TLS (Transport Layer Security) protocols used in BMC Discovery make use of both public-key and symmetric-key cryptography, and secure hashing. This section explains the effects of these cryptography techniques, how they are used in TLS, and how BMC Discovery uses the features of TLS to achieve authentication, authorization and end-to-end encryption.

In symmetric-key cryptography, a message is encrypted with a key, and can only be decrypted with the same key.
In public-key cryptography, a pair of keys is used. A message that has been encrypted with the private key can only be decrypted with the public key; conversely, a message that has been encrypted with the public key can only be decrypted with the private key.
Secure hashing takes a message and reduces it to a short hash value. Changing the message changes the hash, and it is computationally infeasible to generate another message with the same hash value.

As a simple example of how these techniques can be used, suppose Alice wishes to communicate with Bob. They each have a public-private key pair, and each knows the other's public key. Public-key encryption algorithms are computationally expensive, so they wish to use a symmetric-key algorithm to exchange messages. The interaction is as follows:

Alice invents a new key to use with a symmetric-key algorithm. This is the session key.
Alice encrypts the session key first with her private key, and then with Bob's public key. She sends the doubly-encrypted message to Bob.
Bob decrypts the message with first his private key and then Alice's public key. Only Bob can do that because only he possesses the correct private key. He is sure that the message really came from Alice because her public key can only decrypt messages encrypted with her private key.
Alice and Bob communicate for as long as necessary using the exchanged session key.

TLS negotiates communication in a similar manner, except that it adds an extra layer of indirection that is useful on the public web. Suppose that Alice and Bob do not know each others' public keys, but they do both trust Charlie, and they know his public key. Charlie can act as a certificate authority (or CA). Alice and Bob each ask Charlie to sign their public keys:

Alice sends her public key to Charlie.
Charlie uses a secure hash algorithm to generate a hash of the public key.
Charlie encrypts the hash with his private key. This is the key signature.
He sends the combination of public key and encrypted hash back to Alice. Now the public key has been signed, it is called a certificate.

Since Charlie's public key is public, anyone can confirm that Alice's certificate was signed by Charlie, because they can decrypt the encrypted hash using his public key and check that the hash value is correct. Bob can similarly have his public key signed by Charlie or another trusted certificate authority.

Now, Alice and Bob can negotiate a session key to communicate as before, with an additional interaction at the start:

Alice sends her certificate to Bob.
Bob checks that the certificate was signed by a trusted certificate authority (Charlie).
Seeing that it was, he now trusts that the public key does indeed belong to Alice, so he sends Alice his certificate.
Alice can also check that Bob's certificate was signed by Charlie, or any other certificate authority she trusts.

Alice and Bob now have each others' public keys, so they can proceed as before. This is, in a somewhat simplified form, how TLS works.

TLS on the public web

On the public web, a number of companies have established themselves as certificate authorities. Browser manufacturers have chosen to accept these certificate authorities, and embed their public keys within the browsers. Web sites that wish to use HTTPS pay a certificate authority to sign their public keys. Now, when Alice wishes to use her web browser to connect to Bob's Bank Inc's web site, her browser can see that the Bob's Bank Inc certificate was signed by Charlie's Certificate Authority Ltd, and it is happy to proceed. End users on the web do not have certificates signed by a certificate authority, so Alice's browser does not have a signed certificate, and the Bob's Bank server does not attempt to verify one — the TLS protocol is configured to only authenticate the server-side certificate, and not require a client certificate. Hopefully Bob's Bank uses another mechanism to verify that Alice really is who she claims to be.

The trust model on the web is only intended to allow browsers to verify that web servers are who they claim to be. It relies on there being a small number of public certificate authorities that are trusted by all browsers.

TLS in BMC Discovery

The way TLS is used in BMC Discovery is different from the public web. Both client and server wish to authenticate each other, and all connections are individually approved so there is no need to have a single trusted certificate authority. The TLS protocols require the use of certificate authorities, however, so when each BMC Discovery component (appliance or Windows proxy) generates a unique public-private key pair for itself, it also generates a unique certificate authority key pair for itself, and signs its own certificate with it. The certificate authority public key is also signed with its own private key, so it is referred to as a self-signed CA Certificate. After generation, the system discards the CA's private key so it can never sign any more certificates with that CA.

Each component in BMC Discovery therefore has a unique single-use CA with its own CA certificate. It is these CA certificates that are exchanged between components, and must be approved for communication to be permitted.