As we begin to explore the pivotal role that automation will play in managing the soon-to-be-industry-standard 90-day TLS certificates, I began to look at the many ways that we’ve been advocating automation throughout the certificate lifecycle. Security is certainly one of the main objectives of shortening the certificate lifespan to 90 days. In the process of exploring that topic, I stumbled upon a great blog written by a previous colleague of mine, Larry Seltzer, that had been overlooked and was never published. I’d like to share that blog with you today.
In the words of Larry Seltzer:
Security is often seen as a burden because it usually is. That isn’t always the case anymore.
The experience of most computer users with security measures is generally an unpleasant one. At best, we get used to passwords and spam filters and updating software.
It’s not just a computer thing. Everyone who has flown on a plane in the last couple of decades knows how inconvenient flying has become because of security.
The law of inconvenience
Speaking of flying, in 1954, General Benjamin. W. Chidlaw, Commander in Chief, Continental Air Defense Command, was an expert in security issues of the day, having run more than one top-secret military project. That year, he spoke at a conference of local government officials about national security issues and said, “[s]imply put, it is possible to have convenience if you want to tolerate insecurity, but if you want security, you must be prepared for inconvenience.”
What General Chidlaw described seemed like a law of human nature: To make something secure, you have to make it harder to access. Visitors to a military base would have to show their credentials at the gate. Sensitive files (back then, in filing cabinets) had to be kept locked up and in areas inaccessible to unauthorized persons. To become one of those people, you need to go through a cumbersome background check.
This phenomenon translated seamlessly into computer security without anyone looking. Until recently, making systems secure almost assuredly made them less convenient for users and increased security administration costs.
In modern systems where the stakes are high enough, sensitive systems and data may be air-gapped, making them much less convenient and much more secure. Certain important operations may require the assent of some minimum number of a specific group of people (this is known as ‘k of n’).
The law is broken
Recently though, new developments have broken the law, to everyone's benefit. For example, the rise of Infrastructure as Code, in which even the computers on which our tasks run are virtualized, and their deployment automated, created the need to automate security as part of the scheme.
In fact, in modern architectures, such as cloud native systems, security operations must proceed at so fast a pace that any human involvement in them is impossible. Very often – too often – developers and administrators respond to this by not bothering with security, or by performing security only perfunctorily.
But with the right preparations, high-quality security measures can be programmed into the systems. These measures are automated and proceed at the same high velocity as business transactions. As a result, security becomes convenient.
There is no better demonstration of this change than in Machine Identity Security. There are two kinds of actors on a network: users and machines. Users are authenticated with usernames, passwords, and biometrics, operations managed by an Identity and Access Management (IAM) system. Machines are authenticated differently, typically with digital certificates and public/private key pairs as the credentials.
In a high-velocity environment, such as a busy cloud native web service, in which digital certificates from public and private Certificate Authorities (CAs) are issued, used for identification, and checked for authenticity on a constant basis, only a system designed to automate the process can keep up. This is called a Machine Identity Security system.
CIO Study: Automation Vital to Address Shorter Lifespans and Massive Growth of TLS/SSL Certificates
Rise of the machines
On the modern Internet, the number of machines has skyrocketed, mostly because most of them are virtual machines of different types, or different machine access methods, such as SSH keys used by administrators and system automation processes.
The infrastructure behind all these functions is designed as a control plane, servicing both management systems and applications. This design is one of the features that enables widespread automation of security.
Automation is growing in other areas besides security, principally DevOps and Continuous Integration/Continuous Deployment (CI/CD), which combine to automate the software development and deployment pipeline. These days, this often amounts to the deployment of infrastructure as well since it is all virtual.
Automation of these features enables automation of security in them. Programs can be scanned for malicious behavior before being run or deployed. All certificates can be checked for expiration or revocation. Log files can be saved. At all stages, policy can ensure that the most recent versions of tools are used.
Automation of virtualized systems also facilitates testing, a task often neglected. Does a new version of (for example) a database management system adversely affect your application? Does the new version have security issues? Setting up test systems that are identical to production, other than for the updated software is easy.
Why Do You Need a Control Plane for Machine Identities?
No excuses anymore
It’s a new era for IT security. With the right infrastructure and the will to use it, there is no runtime inconvenience from the best security. There is no excuse for not following best practices in security.
Obviously, not all systems are amenable to the levels of automation described here, and some situations just call for an excess of caution. For example, systems involved with nuclear weapons are air-gapped, and I think we can all agree that this is a good thing. But the cutting edge of Internet software development is almost all of a kind that can be automated.
But in almost all cases, the phenomenon of automated security has shifted the trade-off to one between security and automation. Simply put, you don’t need to automate if you want to tolerate insecurity, but if you want security, you must be committed to automation.