Page tree
    Skip to end of metadata
    Go to start of metadata

    UI security

    The passwords used to access the BMC Discovery UI (such as for the system user) are salted, hashed with SHA-256 and stored in a file.

    Credential vault security

    The credentials used to log in to discovery targets, synchronize to the CMDB, and export data using adapters are stored in a vault that is encrypted with a default passphrase when the appliance is built. The vault provides a secure mechanism for storing credential information. Only users with Discovery or Administration privileges have read/write access to the vault, with read access limited to non-sensitive information only (passwords can never be seen in the UI or at the command line). The content of the vault is secured using 256 bit AES encryption in CBC mode.

    The default vault passphrase is persisted on the appliance, and is common to all appliances, therefore it is highly recommended, and considered security best practice, to secure the vault with a manually entered passphrase. When the passphrase is set, the vault is automatically in a locked state when the appliance starts, and requires the passphrase to be unlocked. The encryption key used for encrypting the vault is derived from the passphrase. The passphrase can be stored on the appliance, which enables you to perform scans when the credential vault is open, without re-entering the passphrase. If the passphrase is saved, it is stored in the vault. If the vault is closed, you must enter the passphrase manually to open the vault.

    If the passphrase is lost, the contents of the vault cannot be recovered. Without a manually entered passphrase the vault is only guarded against casual inspection, in which case vault security is dependent on Linux command line security.

    The default passphrase used is a random string of 64 characters/512 bits to generate a 256 bit key. If you decide to use a manually entered passphrase you should ensure that it is of at least a similar complexity, or that it is changed at regular intervals.

    A "Security Best Practice" may be to defer credential management to the in house security team who would manage credentials according to their own requirements. Permission could be granted for the security team to update the passwords stored in the vault, and for other users to run discovery using the stored passwords.

    Sensitive data filters

    Data returned from discovery targets can contain sensitive data. For example, the command used to start the process might contain a clear text password. This data is stored in a DiscoveredProcess node and could be viewed through the UI. This can be prevented using sensitive data filters.

    A sensitive data filter is a regular expression to define data that you do not want displayed. When matched, the sensitive portion of the data is encrypted using an MD5 hash. The encrypted data can be compared with earlier versions to determine whether it has changed, while the actual data remains hidden from users.

    2 Comments

    1.  

    2.