Whether your organization is trying to prevent machine identity attacks, there is a lot riding on the effectiveness of your machine identity management strategy. But to create an effective program, you need in-depth insight into the strengths and weaknesses of each of your machine identities. Some of that you can learn from the certificate itself, but much of the intelligence you need just isn’t part of the certificate, it’s situational.
To gain the intelligence necessary to enforce policies and detect machine identity anomalies and vulnerabilities, you need to be able to discover and collect information on the critical attributes of each of your machine identities. To do that successfully, you’ll need access to additional intelligence beyond what you can retrieve from the keys and certificates themselves. Let’s dive into the vital information that you can’t learn from the keys and certificates themselves, and how you can learn to keep track of what you need to know.
1. Where your keys and certificates located
Visibility of certificates to the application team is one of the cornerstones of machine identity management. Do you have an expired certificate or suspect misuse? Machine identity problems are notoriously difficult to diagnose and impossible to solve when you don’t know where the certificate in question is located.
Accurate, up-to-date information is the only way to effectively create incident response tactics. Location information includes the machine address, file location, Hardware Security Module (HSM), if applicable, and account (in the case of SSH keys).
2. Who owns the certificates?
Users can request machine identities across countless systems and different groups, but central Public Key Infrastructure (PKI) and security teams rarely have the permissions necessary to manage these systems directly. Consequently, updates to machine identities often must be performed locally.
When a security vulnerability is detected, such as a weak algorithm, operational risk, or impending expiration, your PKI or security team needs to be able to rapidly contact the appropriate owner to solve the problem.
3. Are the certificates using strong ciphers?
Each machine that uses a machine identity is configured to use ciphers suites, or sets of instructions on how to secure a network through TLS, such as Advanced Encryption Standard (AES). With advancements in technology, the strength and weaknesses of a cipher is often relative. It depends on factors, such as client compatibility, key size, faulty random number generators, cipher vulnerabilities, and including side channel attacks.
Weak ciphers undermine the strength of encryption and can facilitate compromises by cybercriminals. A weak cipher is an algorithm that uses keys that aren’t long enough to ensure the encryption scheme can’t be cracked by malicious actors.
4. Which protocol version are the certificates are using?
New vulnerabilities are regularly found in protocols like SSH and TLS. To reduce the chance of compromise, ensure that you’re using only approved protocol versions. For example, a critical vulnerability was found in the TLS heartbeat extension of the popular cryptography library OpenSSL. Dubbed Heartbleed, this vulnerability required all impacted certificates to be replaced with those using an updated protocol.
5. How are the certificates configured?
Misconfigured servers, applications, or keystores may leave otherwise secure keys and certificates open to compromise. For SSH, configuration information can include source restrictions, force commands, whether port forwarding is allowed, and other security-critical requirements.
6. Are the certificates being misused?
The relative security of machine identities relies on variety of factors, and because there are so many rapid changes to machine identities, it can be difficult to quickly identify and assess risks.
Reputation scores combine multiple machine identity attributes into a single numeric value that quickly indicates the risk associated with a specific certificate. One example of certificate misuse would be an SSL certificate being used as part of a phishing scheme or to gain unauthorized network access.
These 6 pieces of certificate intelligence for all machine identities inside and outside your will allow you to identify machine identity vulnerabilities, anomalies, risks, and trends. This is important because each of your business groups need in-depth intelligence on the relative strength of machine identity for the systems they control. Otherwise, they won’t be able to follow the best practices required to effectively manage machine identities or take rapid remedial action when needed.
While certificate visibility is one of the most important parts to machine identity management, the other side of the coin is certificate automation. Keeping track of all this certificate information across an entire enterprise is far too big of a job to handle manually and attempting to do so inevitably leads to human error. The Venafi Trust Protection Platform combines certificate visibility and automation protect your machine identities.
(This blog has been updated. It was originally posted by Scott Carter on August 27, 2019.)