A few years ago Boeing had a problem. Their biggest competitor, Aerobus, had secretly developed a head-to-head challenger to Boeing’s 737 to capture the $35 billion narrow-body jet market. The new airliner, the A320neo (where “neo” stands for “new engine option”), was so efficient it burned 6 percent less fuel than the competing Boeing jet. This meant billions of dollars in annual savings for the airlines that put them into service, and the message struck a chord: in one stellar week of 2011, Airbus sold more A320neos than Boeing had sold of 737s in all of 2010.
Boeing reacted fast, declaring it would build a fourth-generation 737 that bested this dramatic reduction in fuel consumptions and deliver it to their customers in record time. It would become the Boeing 737 Max.
Fast forward a few years: after catastrophic crashes in Indonesia and Ethiopia in 2018 and 2019, the FAA and other regulators around the world have grounded the 737 Max. A total of 387 airplanes, representing 59 airlines and serving 8,600 flights a week, have been grounded worldwide. The causes of failure are dense with physics and technology—which are captured well in this article from The Verge. But the bottom line is summed up best in this sentence:
“To beat Airbus, it [Boeing] would have to break the one unbreakable law of project management: that a development cycle can’t be fast, cheap, and good.”
We are no longer in a race to move our applications and services to the cloud. We are in the cloud. According to Flexera's State of the Cloud Report for 2020:
Machine Identity Management is what we do for our customers. And as our customers move those machines rapidly to the cloud (as well as the workloads and containers and service meshes that represent those machines) the identities of these machines need to go with them. Especially the TLS certificates and digital keys that secure not only the individual machines, but perhaps secure entire digital transformation strategies as well. What risks do we need to watch for and how do we avoid some of the bad decisions that can cripple us?
Here are the Top 5 potential cloud catastrophes our customers have been worried about and ways their security architects, cloud architects and PKI teams can prevent them.
With application and development teams rushing to move their workloads into the cloud, one of Venafi’s customers recently reported an interesting and disturbing pattern. Their inventory of developer accounts in AWS revealed unknown developer accounts created by company teams, most of which were supporting workloads and applications, services and databases.
To make matters worse, this was only one example. A subsequent inventory revealed another 2,500 developer accounts in Azure, also supporting unknown applications, services and containers. The company needed a way to discover TLS certificates in real time wherever they were: on-prem, in public clouds, or even in their private clouds.
Organizations are increasingly adding standards for machine identity management to their overall information security policies. This is becoming even more common with the impending release of NIST’s new guidance SP1800-16, Securing Web Transactions: TLS Server Certificate Management, which includes sample policy values for an organization’s TLS standards.
Once the aforementioned visibility problem is solved, an organization needs to answer “policy” questions: Which certificate authority issued the TLS certificates our cloud-based apps and services rely on for authentication and encryption? How were they configured? When will they expire? Did they use current protocols for hashing and encryption?
As an organization’s public key infrastructure implementation moves further and further away from the PKI Team that defined it, the finer details of “what makes it secure” can be lost in translation. Having a common policy that covers machine identity details, for both on-prem infrastructure and cloud and hybrid infrastructure, is the only way to mitigate this distance.
On January 9 of this year, a Threatpost headline made an ominous announcement: “Exploit Fully Breaks SHA-1, Lowers the Attack Bar.” The ensuing article detailed a proof-of-concept attack that “fully and practically” broke the code signing encryption method called Secure Hash Algorithm, or SHA-1.
Organizations like NIST and the multinational Internet Engineering Task Force (IETF) removed SHA-1 as a supported algorithm two years ago, issuing warnings for security practitioners to deprecate its usage in favor of newer, more robust algorithms like SHA-2 and SHA-256. But these things take time: It wasn’t until June of last year that Apple browser sessions in iOS 13 and macOS Catalina actively rejected SHA-1 signed certificates and warned its end users of these vulnerabilities.
What if a new cryptographic compromise arises? Or if a CA’s certificates are suddenly declared untrusted and need to be replaced by certificates from a different CA to maintain public trust, as happened to DigiNotar in 2011 and Symantec in 2018? Can these challenges be overcome in far-reaching cloud environments where the actual certificates are unseen or out of reach?
The Venafi customer cited in #5 whose developers had created thousands of cloud accounts represents only the tip of an “identity sprawl” iceberg. Consider that the components of modern cloud architectures, like service meshes, have fundamentally altered the ratio of machine identities in use today. A few years ago, a web application with a service-oriented architecture might have required a couple public-facing TLS certificates and a couple private-use certificates. Today, service meshes can requires dozens if not hundreds of frequently changing TLS certificates.
Christian Posta, field CTO at solo.io, puts it this way in his blog on modern architectures: “As we break applications into smaller services, we increase our surface area for attacks. … Do you secure your internal applications with SSL/TLS? All of the communication that we used to do inside a single monolith via local calls is now exposed over the network. The first thing we need to do is encrypt all of our internal traffic.” [Emphasis added.]
As cloud providers like Amazon, AWS and Google become critical to your digital transformation efforts they can also challenge your very existence. Being an online retailer and being “all in” on AWS, for instance, means you’re dependent on the world’s largest retailer for your survival. Delivering online apps can be a challenge when your platform provider—Google Cloud Platform—delivers more online services than any other company in the world.
Maintaining the ability to move from one cloud platform to another has to be seriously considered by the strategic thinkers in your company, from CIO to CFO to cloud architect to board.
The way to address all 5 of these potential catastrophes is by achieving and maintaining high degrees of visibility, intelligence and automation for all an organization’s machine identities at cloud-amplified scale.
Moving too fast into the cloud-first future—without bringing sound machine identity practices along—can back our customers into the same corner that trapped Boeing. Trying to be “fast, cheap and good” all at the same time resulted with the 737 Max grounded and over $25 billion lopped off Boeing’s market cap. (With another $30 billion hanging in the balance from the threat of canceled orders.)
The cloud can make sure you’re fast and cheap. But partnering with Venafi to simplify and automate machine identity management will make sure you’ve always got enough of the “Good” as well.
What does moving to the cloud mean for the security of TLS certificates? How 74% of the Global 5000 have a hybrid approach.