As we all know, a digital certificate is a credential that ties the identity of a person (or organization, or a web service) to a pair of encryption keys – one public, and one private. If a person signs a document with their private key, the recipient of this document can verify their identity using a public key, which is available from the Certificate Authority (CA).
Digital certificates are used to transmit encrypted documents, so naturally they might be of interest to hackers, state-sponsored cybercriminals and other bad actors who want to steal your secrets. And while there have been many reported incidents of cyberattackers targeting digital certificates to launch man-in-the-middle attacks or proliferate the spread of malware, they are actually not as common as you might think. Your organization is more likely to suffer a certificate-related security breach from a disgruntled employee than from an organized group of hackers.
A Hypothetical Case Study
Consider this scenario. The company’s CEO uses a digital certificate to send and receive encrypted documents and emails. His keys are installed on his laptop. At some point, the CEO experiences an issue with his laptop and takes it down to the IT floor for support. A discontented tech support person takes advantage of an opportunity and exports the unsuspecting CEO’s keys. Now he can forge signed documents with the company’s executive’s digital signature (announcing his own promotion, perhaps?), without anyone noticing the difference. Or, more likely, he can use the stolen keys to access the CEO’s email to look for confidential information. This is one of the more popular channels that malicious insiders gain access to sensitive business data, which is being offered for sale in abundance on the dark web.
What could the CEO have done to protect the keys that are being stored on his machine from falling into the wrong hands? Storing the certificate and its corresponding keys on a smart card or an e-token would have definitely helped in this particular scenario. With a smart card or an e-token, the private key is not exportable outside the device. What’s more, if our CEO was using more than one computer, storing a certificate on a smart card or a token would have removed the need to create multiple copies of his certificate and keys, again, minimizing the risk of exposure and compromise.
Not just TLS Certificates
Another common form of insider fraud is when someone decides to compromise the code signing certificate. Code signing helps verify that an application is coming from a specific source. You have, no doubt, seen the warning messages issued by your browser when you attempt to download something from the web. It may caution you against the ‘unknown publisher’ and tell you about the dangers of downloading unverified content. Code signing removes these warnings, but if someone inside the organization gets ahold of these code-signing certificates and decides to use them for malicious purposes (or again, sell them on the dark web!), your users may still think that they are downloading trusted content, whereas in fact the code may have been altered or tempered with. To prevent this, every organization needs to have security policies in place to govern how certificates are used, distributed, stored, and shared. Without controlling and tracking who has access to certificates, you are not immune from a situation where an insider can compromise your company’s integrity.
Is there a permanent solution to managing PKI-related insider threats?
Yes, there is. AppViewX offers industry-leading protection to keys to prevent these scenarios from happening.
Our platform can act as a central, secure key escrow to enhance visibility across your private keys. The private keys are encrypted using AES-256 bit keys before storing and the master encryption key is stored in another secure vault. For added security, you can leverage the capabilities of your network HSMs such as Thales and Gemalto to either encrypt the private keys and have the master key stored in the HSM or store the entire private key content in the HSM. You can also choose to generate the private key and CSR on the HSM.
The AppViewX platform also comes with a built-in Hashicorp vault for securing your encryption keys. You can also leverage any third-party password vaults such as CyberArk Enterprise Password Vault to securely access the device. If your vault is set to auto-rotate your passwords periodically, our platform can retrieve the current, active device credentials from the vault to securely manage and automate the various functions of that respective device, without having to continuously update and troubleshoot credential-related issues.
Once your device credentials are securely set within AppViewX, you can use our low-code automation workflows to orchestrate certificate enrolment and provisioning across your devices. You can discover, push, renew and delete certificates from your devices on-demand or schedule them later as per convenience. When you launch a certificate provisioning workflow with all the necessary attributes such as CSR parameters, target devices and their SSL profiles, our platform submits the CSR to the respective CA, retrieves the issued certificate, pushes it to the target devices and automatically binds them to the SSL profiles without all while following your business workflows. These automation workflows can also be triggered from your DevOps tools.
Learn more about AppViewX secure key management here. Or sign up for a demo or to try our solutions in action.
Tags
About the Author
Muralidharan Palanisamy
Chief Solutions Officer
As Chief Solutions Officer, Murali is responsible for the overall product vision, development, and technical direction of AppViewX.
