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.
SSL/TLS Certificates and Their Prevalence on the Dark Web
Here are six DevOps shortcuts that should make the hair on the back of your neck stand on end:
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.
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
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 has been updated. It was originally posted byScott Carter on October 26, 2017.)
Why Do You Need a Control Plane for Machine Identities?
Related posts