Design, deliver, and run enterprise blockchain workloads quickly and easily.
All servers and systems
While we all accept the need for security management systems that reach into all parts of the network, there always seems to be one more complex security product to handle something you’ve dealt with casually over the years.
Digital certificate management systems should be at the forefront of addressing potential security flaws. Digital certificates are everywhere on your network, or at least they should be. They implement numerous security standards that need periodic advancement, and at such times, changes will be made in systems you thought were stable. Such is life in the world of crypto.
Unfortunately, public key cryptography is complicated enough that it isn’t accessible to many of the people responsible for its proper implementation. Even if the security landscape is stable (as if that’s ever the case), implementing crypto is tough to do right.
But almost by definition, the normal state of public key cryptography is an unstable one. Real-world applications of cryptography involve numerous standards, the point of which is to ensure strength of encryption and the interoperability of applications. Assuming an application implements the appropriate standards correctly, it still may be vulnerable if there are vulnerabilities in the standard itself.
This is an important distinction that shows up all the time. The infamous Heartbleed bug in the OpenSSL library, used by almost everyone as the basis for most encryption, was an implementation problem. Other implementations, such as Microsoft’s Schannel, GnuTLS, and Mozilla's Network Security Services, were unaffected.
When a standard is affected, such as with the POODLE vulnerability in SSL 3.0, all implementations of SSL are affected, which means just about everyone on the Internet. POODLE-like events happen from time to time, but they are recognized as emergencies and the industry leaps into action to provide updates to customers.
But Internet standards face slow-motion POODLEs much more often. We’re in the middle of one right now with the SHA-1 hash protocol. Maybe you’ve just heard of it, but it’s a really, really big deal.
A hash function takes a file or other string of data as input and creates a value, called a hash or digest, of a fixed size. With a good hash function, several things can be said:
SHA-1 met all of these criteria for a long time, and it served us well. But for years, crypto experts have been warning that a method of reliably generating SHA-1 hash collisions was just a matter of time. That time has come. At the Black Hat Europe conference, researchers from Google and CWI Cryptology Group in the Netherlands described how they created a reliable method for generating SHA-1 hash collisions.
This development means an attacker could effectively impersonate your digital certificate with one of their own creation.
Hashes are used widely for a variety of applications. They are used to ensure integrity in backups. They are used by source code revision control systems to check for changes. But their most important applications are in cryptography. Best practices dictate that you don’t store a user’s password but instead store a hash of that password (in fact, you use a "salted" hash, a subject you can study for extra credit). And digital signatures, which are used to ensure the authenticity of an entity on a network, such as a website, use hashes of the entity’s identifier.
SHA-1, which supplanted an earlier standard called MD5, was designed by the National Security Agency and first released in 1993, so we definitely got our money’s worth out of it. The first hints of weaknesses in SHA-1 were revealed more than 10 years ago, and work began on new standards. SHA-2, the current state of the art, is the same algorithm as SHA-1 with a range of larger key sizes, also known as SHA-256, SHA-384, and SHA-512. NIST held a competition for SHA-3, a new algorithm—the winner of which was crowned in 2015—but it is not in real-world use.
It’s certainly not the first time customers have had to abandon a security technology, even one they should have abandoned years ago just as a matter of best practice. The more important point is that, even now, many large organizations have no central management of digital certificates and therefore no ability to assess their risk accurately.
For the past decade, major players in the industry—most important, Google and Microsoft—have pushed customers and other vendors to move on to SHA-2. Google especially has used its market power to drive the industry to adopt more modern and secure cryptography standards and practices, such as certificates with shorter lifetimes.
In fact, SHA-1 certificates are increasingly rare, but the need to worry about problematic certificates continues. For instance, in case you hadn’t heard, both Google and Mozilla announced recently that they will be removing all trust of Symantec certificates in the coming months. (Symantec’s issuance process demonstrated too many problems, and it has sold its certificate business to DigiCert, whose certificates are trusted.)
Are you relying on Symantec certificates? If so, you need to get new ones soon. Do you have a system for tracking these? Is there a system for ordering new ones?
It’s not uncommon for important digital certificates in an enterprise to be completely untracked and unmanaged. The management system may be an Excel spreadsheet on someone’s desktop. Frustrated by normal purchasing channels, employees may have used their own credit card and arranged reimbursement unofficially. It happens.
And then things like SHA-1 collisions and the end of trust of Symantec happen, and you need to be able to make changes in your network more quickly than you are normally set up for.
For this you need a central system for tracking certificates in your enterprise and all of their important characteristics, including obvious things like expiration dates and less obvious things such as which systems rely on that certificate. It needs to manage critical things like private keys.
Don’t confuse these systems with PKI toolkits for implementing cryptography on particular devices, like routers, or platform-specific solutions like Active Directory Certificate Services, important as such products are. Don’t confuse these systems with in-house certificate authorities (CAs), important as those are. Rather, an enterprise certificate management system tracks the use of internal CAs and allows you to make rational decisions about where their use is appropriate, as opposed to using an outside trusted certificate authority or even a self-signed certificate.
When choosing such a product, consider comprehensiveness. The major cloud providers, such as Amazon Web Services, provide management services for certificates used within their clouds. You are probably not one of the few companies that can run their entire infrastructure in a public cloud, so you have to consider certificates you may have in your own infrastructure or other outside services. It may still make sense to use these cloud services, but they won’t be a complete solution for you.
You may also want to be wary of solutions provided by outside certificate authorities. Part of the idea has to be that you can extricate yourself from reliance on them when necessary.
There are many vendors that offer such services, including Venafi, CSS (Certified Security Solutions), and SolarWinds. There are many open source projects in this general product line, but they are mostly developer-oriented, such as Netflix’s open sourced Lemur certificate management framework. If you wanted to go to the trouble, such open source systems could be the basis of an in-house solution.
In practice, the number of people with permission to make requests of the certificate management system—for instance, to purchase one from a trusted CA or generate and sign one internally—might be large. The number of people with administrative access to the certificate management system to view private keys, for instance, should be small and the individuals highly trustworthy.
These products may attempt to find certificates, but they can’t do a theoretically complete job, meaning you really should do a survey to ask employees about all known certificates. Make it part of a general education campaign promoting the new service and how it will improve overall security and make security easier for users.
As with many other aspects of security, best practices for certificates are often too much work for normal humans to do. But once you automate the work, doing it securely becomes easy. A good example for certificate management is that certificates with short life spans become practical. Check out the TLS certificates for Google.com and you’ll see they expire after about 90 days. It’s another example of Google being especially aggressive, but it does that because it’s the right thing to do. One year is the longest term you should allow for a digital certificate.
Imagine you found out back in July, when the information first came out, that Google Chrome would be ending trust of Symantec certificates. You might want to construct a plan to address the problem so that it could be avoided in time to prevent users and customers from experiencing any scary errors and loss of functionality. But step 1 of any such plan would be an inventory of all Symantec certificates. Do you actually have that information?
If you have that kind of information on all your certificates, you can recognize problems in advance, and in fact, the software will likely recognize it for you. You can satisfy security audits more easily, and when the inevitable incident happens, you can respond quickly and completely. In a world full of devices and servers communicating with encryption, you can’t be secure without a management system for your certificates.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.