Skip to main content
banner image
venafi logo

5 Cloud Catastrophes and How to Avoid Them

5 Cloud Catastrophes and How to Avoid Them

cloud security
June 16, 2020 | Michael Thelander

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.”    


But what’s that got to do with the cloud?

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:   

  • More than 50 percent of enterprise workloads are already in public clouds   
  • 93 percent of enterprises have a multi-cloud strategy   
  • Organizations use on average of 2.2 public and 2.2 private clouds  


And what’s that got to do with Venafi?

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. 


#5. Lack of Visibility

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.  


#4. Lack of Governance and Policy

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.  


#3. Unexpected Cryptographic Failures

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?       


#2. Identity and Key Sprawl

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, 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.] 


#1. Vendor Lock-in 

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. 



Visibility, Intelligence and Automation to the Rescue


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. 

  • Visibility: be able to discover certificates and keys wherever they are, in different public clouds, in your private clouds, or in various on-prem networks. 
  • Intelligence: When you find all your machine identities in real time, understand and catalog the intelligence you need to manage them. This means issuing CAs, expiry dates, organization data, and security configurations, all readily accessible and actionable. 
  • Automation: let’s face it, people can’t keep up with escalating numbers of machine identities in the cloud. Automating issuance, validation, renewal and revocation is the only way to overcome the challenges of cloud 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.





Related posts

Like this blog? We think you will love this.
Featured Blog

How to Stop Outages in Your Kubernetes Clusters [Case Study]

InfoSec vs platform development teams

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

TLS Machine Identity Management for Dummies

TLS Machine Identity Management for Dummies

Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Michael Thelander
Michael Thelander

Michael Thelander writes for Venafi's blog and is an expert in machine identity protection.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud

Venafi Cloud manages and protects certificates

* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
* Please fill in this field
* Please fill in this field
* Please fill in this field

End User License Agreement needs to be viewed and accepted

Already have an account? Login Here

get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more