Build and Operate Your Own Certificate Management Center of Mediocrity
Download as PPTX, PDF2 likes4,990 views
The document discusses the creation and management of a Center of Mediocrity for a Certificate Authority (CA), emphasizing the importance of understanding certificates, their security roles, and best practices. It warns against poorly implemented CAs which can lead to significant security risks, especially when relying on internal and partner certificates without proper controls. The document also highlights the need for adequate training and awareness to safeguard against compromises in security due to cost-cutting measures.
Build and Operate Your Own Certificate Management Center of Mediocrity
- 1. How To Build And Operate A Certificate Authority Center of Mediocrity (CACOM) T.Rob Wyatt Managing Partner, IoPT Consulting 704-443-TROB (8762) t.rob@ioptconsulting.com https://ioptconsulting.com Capitalware's MQ Technical Conference v2.0.1.4
- 2. This presentation reflects… My current opinions regarding WMQ security The product itself continues to evolve (even in PTFs) Attacks only get better with time This version of the presentation is based on WebSphere MQ v7.1 & v7.5 This content will be revised over time so please be sure to check for the latest version at https://t-rob.net/links Your thoughts and ideas are welcome
- 3. What is a Certificate Authority? The role of a CA in the security model Why run your own CA? Some example CA Best Practices CA Second-Best (and lesser) Practices The CA Maturity Model Wrapping up
- 4. A disinterested 3rd party A stable, long-lived entity A pool of specialized and deep security skills An implementation of strict physical controls An implementation of strict human processes An investigatory service A revocation service Part of a consortium that provides a consistent set of well-defined services
- 5. Oh yeah… They sign certificates once in a while.
- 6. What is a Certificate Authority? The role of a CA in the security model Why run your own CA? Some example CA Best Practices CA Second-Best (and lesser) Practices The CA Maturity Model Wrapping up
- 7. First need to understand the certificate. Bound to An identity A key Pair = A certificate
- 8. First need to understand the certificate. The identity and key are bound using a cryptographic Identity Bound to Key Pair = Certificate signature.
- 9. First need to understand the certificate. Self-signed means that the key in the certificate is the same one used to sign the Identity Bound to Key Pair = Certificate certificate.
- 10. First need to understand the certificate. Special Note: Self-signed does NOT mean “signed with our internal CA.” Self-signed has a specific technical meaning describing the relationship between the identity and the key used to bind it. Identity Bound to Key Pair = Certificate
- 11. First need to understand the certificate. When the certificate is signed by an external key, it is Identity Bound to Key Pair = Certificate said to be CA-signed.
- 12. Signs the certificate. Validates the claimed identity. Enforce policy on the Distinguished Name fields. Ensures unique names within its namespace. Provides revocation services. Maintains key lifecycle for root, intermediate and signed certificates. Disinterested 3rd party provides bilateral trust.
- 13. Relying parties typically need much less security than the CA. Generate the cert signing requests securely. Review and approve requests at the CA. Keep the keystore files private. Most of the heavy lifting is offloaded to the CA.
- 14. What is a Certificate Authority? The role of a CA in the security model Why run your own CA? Some example CA Best Practices CA Second-Best (and lesser) Practices The CA Maturity Model Wrapping up
- 15. Cost savings. Convenience. The trick is to fully account for all of the service and security provided by the CA. Replacing those services internally is expensive. Omitting them is dangerous. How do you find the balance?
- 16. What is a Certificate Authority? The role of a CA in the security model Why run your own CA? Some example CA Best Practices CA Second-Best (and lesser) Practices The CA Maturity Model Wrapping up
- 17. SAS70 key ceremony used to generate roots. Root certs stored in an offline HSM. Dual-knowledge access controls for roots. Multiple intermediate signers. Secure, robust provisioning process for certs and revocation entries. Highly available and separate provisioning and revocation infrastructure.
- 18. ISO 21188:2006 Public key infrastructure for financial services – Practices and policy framework ETSI TS 101 456 v1.2.1 ETSI TS 102 042 V1.1.1 Webtrust Program For Certification Authorities
- 19. What is a Certificate Authority? The role of a CA in the security model Why run your own CA? Some example CA Best Practices CA Second-Best (and lesser) Practices The CA Maturity Model Wrapping up
- 20. To run a true Center of Mediocrity, one must first determine which CA Best Practices to omit. The quickest way to begin is to omit all of them right off the bat. Then add back in those that give the appearance of security at little or no cost. The CACOM is your BFF. Once you have it, you’ll never get the money to build a CACOE. Why? Because what we have seems to work just fine.
- 21. The stories you are about to hear are true. Only the names have been changed to protect the (not so) innocent. My name is T.Rob. I carry a laptop.
- 22. All of the items in the following pages were observed in Production somewhere. Banking, finance, insurance, healthcare, govt. These are your vendors!
- 24. Hundreds of thousands of entries explain which commands to issue in order to “set up a Certificate Authority.” Try to find even one that tells you the commands and describes some of the physical and procedural controls commercial CAs use and why running an internal CA without these controls is a bad idea.
- 25. Hardware Security Modules are so expensive! And vaults? Don’t even go there! Most CACOM’s today store the root cert on an administrator’s workstation or laptop. If you start out this way, eventually moving it to a server in a locked datacenter will appear very secure by comparison and nobody will ask about an HSM, a vault or a key signing ceremony. Booyah!
- 26. Certificate provisioning and revocation must be highly available to support critical business apps. So if the CA is run off of administrator’s workstations, it stands to reason that each administrator must be able to manage certs independently. Give each admin their own copy of the root cert. Or if a central server is used, give a copy of the root to each admin for emergencies.
- 27. Intermediate signers provide classes of service, isolation, higher security for the root cert, etc. But someone has to manage those things, and we do that with Notepad. We plan to evaluate several PKI products someday and we will start using intermediate certs then.
- 28. Certificate extensions can specify policies that control the ways that a certificate can be used. Understanding and checking certificate policies requires deep skill. Certs with no policies set can be used for many purposes, such as encryption, code signing or signing other certificates. These are very versatile. What could go wrong?
- 29. Security certified administrators who understand X.509 certificates, TLS/SSL and all of the PKCS standards are expensive! Formally building skills in house is less expensive, but takes time. Fortunately, your average administrator can pick up all they need to know with a few Google searches! Certifications and formal training are SO overrated, right?
- 30. A certificate represents an identity. Because the Center of Mediocrity is concerned mainly with cost, it is common to re-use the same personal certificate across multiple, even unrelated, systems. A QMgr is a QMgr is a QMgr, right? Generate a single cert called QMgr and be done with it.
- 31. Anyone who can read the configuration files and keystores can use your personal cert. Fortunately, only authorized admins ever have access to the filesystem in a CACOM so filesystem controls are redundant. What’s that you say? Layered defense is good? Not when aspiring to mediocrity!
- 32. Credentials need to be both provisioned and revoked. Sometimes they need to be revoked prior to their natural expiry. A primary characteristic of a mediocre CA is that a revocation responder service is planned for later. A revocation service that is not highly available is just as bad, possibly worse.
- 33. Ideally, personal certs are generated where they will be used and not moved. Central management and key backup is possible but difficult to do securely. In a CACOM, centrally generated certs are distributed over FTP, email, shared drives, etc.
- 34. Sometimes it isn’t your CA that places you at risk, but rather your business partner’s CA. A CACOM will assume the partner’s certificates are trustworthy without question. The next slides are examples of this.
- 35. The root cert is the thing that controls who can bind an identity to a key pair. Any trusted root can generate a cert claiming any identity. Now that the internal CE Center of Mediocrity has become so popular, you will have occasion to trust the internal root CA certificates of your business partners. Go ahead and drop these right into the trust store. What could go wrong?
- 36. If you are using AMS with Privacy (encryption) then you will need to trust the personal cert of the app, user or business partner. A commercial CA will have set the IsCA=No and PathLength=0 flags to ensure that personal certificates cannot also sign other certificates. The typical CACOM does not know or care about such things and will place any certificate from any source into the trust store. What could go wrong?
- 37. What is a Certificate Authority? The role of a CA in the security model Why run your own CA? Some example CA Best Practices CA Second-Best (and lesser) Practices The CA Maturity Model Wrapping up
- 38. Baseline S e c u r i t y L e v e l Skill Level Best!
- 39. Baseline S e c u r i t y L e v e l Skill Level Best! Worse than doing nothing
- 40. Possibly, yes! Because… • People take more risks when they believe it is safe to do so. • Poor implementation can make it easier Baseline S e c u r i t y L e v e l • You rarely get a second chance to implement security. Skill Level Best! to break in. Wore than doing nothing
- 41. What is a Certificate Authority? The role of a CA in the security model Why run your own CA? Some example CA Best Practices CA Second-Best (and lesser) Practices The CA Maturity Model Wrapping up
- 42. Running a robust internal CA is expensive. Can be cost justified, given enough certs. Cost savings almost always correspond to some loss of effective security. Know what you are omitting and the offsetting risk. Deep skill is essential! Formal training is highly recommended. Beware of other people’s CACOM!
- 43. Capitalware's MQ Technical Conference v2.0.1.4 Questions & Answers
- 44. Thank you! T.Rob Wyatt Managing Partner, IoPT Consulting 704-443-TROB (8762) t.rob@ioptconsulting.com https://ioptconsulting.com