Michael Thelander at Venafi explores the dilemma organisations have between allowing rapid development and adhering to security standards.
All too often, application development teams and IT security teams are at odds with each other. Development teams are typically fast-moving, focused on rapid SLAs, continuous delivery and compressed timelines. IT security teams often struggle to match their tempo, meaning that developers may start to view IT security as a barrier, rather than an enabler.
In theory, development teams should be following two core rules: production data can’t be used in a test environment, and developers shouldn’t have access to production systems. As such, development/testing environments should be separated from production. The issue is that in practice, the lines are often blurred. For instance, different certificates should be used for each environment, yet existing security processes often restrict developers from getting the right certificates at the speed they require them.
Cutting corners in development
As a result, developers will look for a faster way to obtain certificates. The processes for procuring SSL/TLS certificates are often antiquated, requiring manual steps such as submitting a ticket. To get around this, fast-moving developers often use certificates without the security team’s approval. They create their own security infrastructure, issuing certificates using a combination of OpenSSL, secrets management tools, DevOps platforms and scripts, enabling them to issue certificates as fast as they need them.
In doing so, development teams’ certificate management processes often don’t comply with the organisation’s enterprise-wide security policy. Inadvertently, developers may create a false sense of trust in unauthorised certificates, whether by issuing self-signed certificates, or spinning up their own internal certificate authorities (CAs) that are outside of corporate security policy.
The current state of certificate provisioning within modern application environments also poses a variety of challenges:
- Certificate provisioning is not embedded into software-defined infrastructure
- Development teams are unable to easily comply with policy
- Information security, risk and governance teams have little visibility into certificates
- Certificate-related outages continue to plague organisations
Machine identities in test and production
Machine Identities meant for ‘Test’ environments pose a huge risk in ‘Production’. A lack of visibility, accountability and ownership over the certificates an organisation has can be disastrous, whether due to the increased risk of outages it brings, or due to the security vulnerabilities it creates.
Yet many organisations still underestimate the number of active certificates in use on their systems. For example, one major retail organisation estimated it had 5,000 active certificates, when in reality it had 20,000. In fact, 5,000 certificates had no owners, and no-one knew what they did or what they allowed. This lack of insight often results from the use of certificates issued without the security team’s approval.
The reality is that development teams create new certificates faster than security can keep track of them, and often fail to replace ‘test’ certificates when code moves into production. Not only does this expose organisations to an avalanche of certificates that they are not aware of and they cannot discover, it makes it difficult to distinguish between the identities of trusted machines that are safe to place in production, and untrusted machines that should stay in a testing environment.
A balance between speed and security
Organisations face a dilemma. On the one hand, they can force development teams to adhere to proper security policies for certificates, raising the risk that SLAs won’t be met. On the other, they allow developers to cut corners through the use of self-signed or unauthorised subordinate CA certificates, allowing them to move as fast as possible, yet simultaneously growing their population of rogue certificates. Neither is sustainable. The only solution is to provide development teams with a safer process that ensures the organisation has visibility into every certificate, while also enabling developers to procure certificates quickly and easily.
By “shifting security left” into the continuous integration/continuous delivery (CI/CD) pipeline, enabling the security team to prevent vulnerabilities early in the development process. Security should be ‘baked in’ to the policies of the certificate PKI team, enabling them to provide as many machine identities as the development team needs, when and where they need them, across every environment from development to production.
Doing this relies on automating the entire certificate management process, via a platform that integrates with the tools in use. Ultimately, security policy should be treated the same as any application code—it should be defined as code, versioned as code and tested as code.
‘Baking in’ security in this way has never been more important, particularly in light of the increased pressure to digitise that many organisations face, which compels development teams to move faster and faster. Automated certificate management is therefore the gold standard and blueprint for protecting machine identities in modern applications, enabling development teams to move as fast as they can, without drawing the ire of IT security.
Michael Thelander is Director of Machine Identity Strategy at Venafi.
Main image courtesy of iStockPhoto.com.