6 Scariest Ways Your Developers Can Use Digital Certificates
6 Scariest Ways Your Developers Can Use Digital Certificates
It’s hard to argue that that all web services and applications should not be secured using HTTPS. However, securely obtaining and deploying the certificates needed for securing web services is a challenge, especially for developers.
Simply put, there is no easy way for developers to request certificates that comply with corporate policy. First, they need to know where the internal CA is, then they must be granted access to it and possess the proper credential to authenticate. Once they pass those hurdles, they need to know how to request a certificate with the proper characteristics, including who’s using it, what it will be used for and how long it should be valid. All of these delays will tempt developers to sidestep security to meet their SLAs.
Here are six DevOps shortcuts that should make the hair on the back of your neck stand on end:
- Not using TLS/SSL to secure connections
When much of the DevOps process is automated, manual certificate processes will disrupt the workflow—something developers would rather avoid. In fact, many developers find it easier to ignore certificates than to allow security to delay the release. Deploying web services without securing them with HTTPS leaves end users vulnerable.
- Spinning up their own certificate authorities
Even if they do use certificates, developers often look for shortcuts to simplify typically arduous security processes. They need look no further than to their DevOps platforms, which provide a script or instructions that allow developers to spin up their own internal certificate authority (CA). This allows developers to issue as many certificates as they need as fast as they need them. The challenge is that these “test” certificates are not always replaced by corporate-compliant certificates when the application moves to production. If that happens, your organization will be exposed to a veritable avalanche of certificates that you can’t see or that you may not even know about.
- Introducing self-signed certificates
You should also be wary of how your in-house developers are using self-signed certificates. Rather than purchasing CA certificates, developers can download an open source implementation of SSL and TLS called OpenSSL. They can then create the certificates they need in order to develop and test software. When used in production versions of applications, these self-signed certificates can make you vulnerable to unforeseen attacks. If not properly monitored, self-signed certificates can allow cyber-criminals to conduct man-in-the-middle attacks that impersonate banking, e-commerce, and social media websites.
- Creating certificates with weak signature algorithms
Dismissing or implementing keys and certificates poorly not only exposes your organization to unnecessary security vulnerabilities, but it can also lead to chaos by inserting inconsistent, manual steps into an increasingly automated environment. If you don’t maintain control over the security of your certificates, you may inadvertently enable attackers to use a compromised, stolen, or forged certificate to impersonate, eavesdrop, and monitor your infrastructure and decrypt communications you thought were private.
- Sidestepping or completely ignoring security policies
Finally, developers are typically not security experts and most do not aim to be. They are less likely to consider anything but the most basic security measures to meet their objectives, especially given past struggles with the error-prone manual nature of certificate provisioning. The result is that security policies are either ignored completely or minimized to maintain the velocity of DevOps. This oversight can create blind spots in your security posture that allow cyber criminals to hide in your encrypted tunnels.
The speed of DevOps does not have to come at the expense of security. There are ways that you can centralize, standardize, and automate the process of procuring keys and certificates as part of your end-to-end DevOps environment. Automating certificate acquisition will enable your DevOps teams to deliver applications and IT services more effectively and more securely. But to do this, your DevOps practitioners need to understand that they share important responsibilities for security; it isn’t just someone else’s job.
- Circumventing traditional code signing policies
Traditional code signing processes set up by InfoSec may not fit well with DevOps CI/CD development pipelines. They may require manual effort, take days (or longer!) to fulfill, not able to be automated, etc. Does this mean that DevOps teams stop code signing their apps? No! Instead, they may find ways to sidestep current processes. This could involve obtaining their own code signing certificates (which may not be up to InfoSec policy standards) or storing private code signing keys on a build server without adequate protection. Either of these practices contributes significant risk to the entire business. Your business’ reputation depends on the fact that your customers can trust that the apps come from you and that a third party hasn’t inserted malware into them. With poor code signing policies or unsafe storage of code signing private keys, cybercriminals can easily circumvent this.
When much of the DevOps process is automated, manual certificate processes will disrupt the workflow—something developers would rather avoid. In fact, many developers find it easier to ignore certificates than to allow security to delay the release. Deploying web services without securing them with HTTPS leaves end users vulnerable.
Even if they do use certificates, developers often look for shortcuts to simplify typically arduous security processes. They need look no further than to their DevOps platforms, which provide a script or instructions that allow developers to spin up their own internal certificate authority (CA). This allows developers to issue as many certificates as they need as fast as they need them. The challenge is that these “test” certificates are not always replaced by corporate-compliant certificates when the application moves to production. If that happens, your organization will be exposed to a veritable avalanche of certificates that you can’t see or that you may not even know about.
You should also be wary of how your in-house developers are using self-signed certificates. Rather than purchasing CA certificates, developers can download an open source implementation of SSL and TLS called OpenSSL. They can then create the certificates they need in order to develop and test software. When used in production versions of applications, these self-signed certificates can make you vulnerable to unforeseen attacks. If not properly monitored, self-signed certificates can allow cyber-criminals to conduct man-in-the-middle attacks that impersonate banking, e-commerce, and social media websites.
Dismissing or implementing keys and certificates poorly not only exposes your organization to unnecessary security vulnerabilities, but it can also lead to chaos by inserting inconsistent, manual steps into an increasingly automated environment. If you don’t maintain control over the security of your certificates, you may inadvertently enable attackers to use a compromised, stolen, or forged certificate to impersonate, eavesdrop, and monitor your infrastructure and decrypt communications you thought were private.
Finally, developers are typically not security experts and most do not aim to be. They are less likely to consider anything but the most basic security measures to meet their objectives, especially given past struggles with the error-prone manual nature of certificate provisioning. The result is that security policies are either ignored completely or minimized to maintain the velocity of DevOps. This oversight can create blind spots in your security posture that allow cyber criminals to hide in your encrypted tunnels.
The speed of DevOps does not have to come at the expense of security. There are ways that you can centralize, standardize, and automate the process of procuring keys and certificates as part of your end-to-end DevOps environment. Automating certificate acquisition will enable your DevOps teams to deliver applications and IT services more effectively and more securely. But to do this, your DevOps practitioners need to understand that they share important responsibilities for security; it isn’t just someone else’s job.
Traditional code signing processes set up by InfoSec may not fit well with DevOps CI/CD development pipelines. They may require manual effort, take days (or longer!) to fulfill, not able to be automated, etc. Does this mean that DevOps teams stop code signing their apps? No! Instead, they may find ways to sidestep current processes. This could involve obtaining their own code signing certificates (which may not be up to InfoSec policy standards) or storing private code signing keys on a build server without adequate protection. Either of these practices contributes significant risk to the entire business. Your business’ reputation depends on the fact that your customers can trust that the apps come from you and that a third party hasn’t inserted malware into them. With poor code signing policies or unsafe storage of code signing private keys, cybercriminals can easily circumvent this.
The speed of DevOps does not have to come at the expense of security. There are ways that you can centralize, standardize, and automate the process of procuring keys and certificates as part of your end-to-end DevOps environment. Automating certificate acquisition will enable your DevOps teams to deliver applications and IT services more effectively and more securely. But to do this, your DevOps practitioners need to understand that they share important responsibilities for security; it isn’t just someone else’s job.
This blog was originally posted by Scott Carter on October 26, 2017.
Related posts
- Accelerate DevOps by Offering a Certificate Service for CI/CD Pipelines
- How Can You Be More Successful in a Compliance Conversation with DevSecOps?
- X.509 Certificate Issuance: Too Slow for DevOps?
Like this blog? We think you will love this.
See Popular Tags
- {[{item.name}]} {[{item.uuid}]} tags
About the author
Eddie Glenn
Eddie is the Product Marketing Manager over Code Signing at Venafi. A product marketing professional in SaaS, Enterprise, and Embedded Software, he has a strong technical background and experience with inbound and outbound marketing, business and marketing strategy, and marketing operations.
Read Posts by Author
Sign up for Venafi Cloud
Sign Up For Our Newsletter
Get monthly updates on relevant topics that impact encryption, cryptographic keys and digital certificates
Thank you for signing up for our newsletter!
Please whitelist Venafi.com so that you can be sure to receive our emails.
In the meantime, please explore more of our solutions