Policy Compliance

Proactively prepare for a CA compromise by assessing the current encryption environment and establishing a relevant remediation plan.

Analyst Coverage

"Admittedly this is a complex topic, but the most important takeaway is this: the risk-based evaluation your company needs to make right now is not about your vulnerability to the Flame virus; it is about your vulnerability to MD5-signed certificates. If you are confident in knowing how many of these there are, and where they are, and what systems are potentially at risk as a result – well done." Full Report

"Organizations with roughly 200 or more documented X.509 certificates in use are high-risk candidates for unplanned expiry and having certificates that have been purchased but not deployed." Full Report

"To support the broader deployment of encryption, organizations with top performance have looked towards increased automation and centralized, heterogeneous approaches to key lifecycle management. Venafi is well-aligned with this Best-in-Class approach."

"Venafi's primary differentiator is its broad entity support for systems that utilize asymmetric keys and certificates. In addition, it implements flexible key lifecycle policies and administration functionality and automated discovery of keys and certificates in systems that support such activity."

"Venafi offers compelling advantages, such as being the early mover in this market, with proven deployments at marquee customers demonstrating its ability to scale and provide breadth of integration."

"When there are many hundreds of certificates from a variety of certificate authorities, the only ecumenical [universal], nonproprietary provider of a certificate management solution is Venafi. Other CA management systems are biased toward the particular CA by, for example, only supporting renewals from that specific CA." Full Report

"The emphasis on orchestration, in tandem with its scalability and interoperability, is tied to the evolution of Venafi's competitive landscape, and to the potential to frame its value in the context of risk management."

Creating an Inventory

Establish a comprehensive inventory of all keys and certificates, including their common names, expiration dates, location(s), owner(s), metadata (key length, CA, keystore type, etc.), and other information.

What is this?

An inventory is a repository of information about keys and certificates that are in use across an enterprise. It may include copies of the keys and certificates or just data about them—sometimes holding a copy of a key in a central inventory can increase the risk of compromise. A good inventory includes but is not limited to the following information:

  • Name of the Key and/or Certificate
  • Locations
  • Key Length
  • Algorithm
  • Creation Date
  • Validity Period or Expiration Date
  • Issuing CA (for certificates)
  • Owners/Contacts/Custodians
  • Business Need (what is the business driver for using the key/certificate)
  • Applicable Policies or Regulations
  • Processes Used to Manage

Why should I care?

Encryption keys and certificates are used to secure critical data and systems, and therefore must be properly managed. If you do not have a list of keys and certificates that are deployed in your environment, it is difficult to ensure they are being managed in compliance with policies, regulations, and/or best practices. A critical starting point in any certificate and private key management strategy is to create a comprehensive inventory of all certificates and their locations. If you do not, you are risking a security breach or system outage.

Developing an inventory is not a trivial matter. In most organizations, certificates have been deployed over a period of years by a variety of different administrators in all sorts of locations. Often, the individuals who deployed the keys and certificates have been reassigned or have left the organization. Requesting a list from your certificate authority may be a good starting point to develop an inventory, but it is not a reliable method for identifying all keys and certificates and their locations.

What should I do?

Take a multi-pronged approach to ensure that no certificates are missed. The diagram below summarizes the recommended approach:

  1. Import from Certificate Authorities: The first step is to import certificates from all known CAs. There are two primary reasons for this:
    1. It can typically be done quickly and
    2. It helps in building a list of contacts (see Managing Contacts/Ownership).

It is very dangerous to assume that an import from your known CAs will provide an accurate inventory of all certificates. Invariably, organizations find additional certificates during discovery (the next two steps) that were not accounted for by the CA. These certificates are typically certificates from other CAs that are not approved by your organization or self-signed certificates generated by the applications where they are deployed. These culprits can cause some of the most serious downtime.

  1. Network Discovery: The next step is to perform a network discovery to discover any server-side certificates—certificates that are present on a listening port. For this step, it is important to coordinate with your network team, intrusion detection group, and any other groups that might be impacted. The network team can typically help in providing IP addresses that should be scanned. However, if you already have a solution in place to regularly scan IP addresses and ports (e.g. for vulnerability scanning), this solution may be able to provide certificates to import into the certificate inventory database. Alternatively, it can provide a list of known IP addresses and ports which can be scanned by your network discovery solution. Firewalls invariably play into any network discovery strategy. In some cases, you can have the necessary ports opened up in all firewalls for a central discovery system to perform operations. Alternatively, you may need to deploy discovery engines on the other side of firewalls in each network zone and configure each discovery engine to pass the discovery results into the central certificate inventory database.
  2. Agent-based Discovery: Many certificates are not discoverable via network ports, such as client-side certificates used for mutual authentication on SSL. In-service expirations of these types of certificates can be as damaging as server-side certificates so it is important to include them in your inventory. Unless you can confidently count on administrators to tell you about all of these certificates, finding these certificates typically involves performing file system scans on server and client systems with an agent.
  3. Individual Import by Admins: Network and agent-based discovery can take time and it may not be possible to perform discovery in all corporate locations. That makes it critical to educate administrators and make sure they are proactively reporting any certificates they are aware of and adding them to the inventory. (See Defining Roles and Responsibilities for more on this.)

In performing the above steps, it is important to have a system that can correlate the results of each inventory method so you do not end up with duplicate entries. Also, performing an inventory is not a one-time event. You have to regularly repeat the steps above to update the inventory. Here again, it helps to have a system that helps you correlate the results of, for example, newly discovered certificates and only show you new certificates and not every certificate that was discovered during a run.