Whitepaper

A Practical Guide to TLS Machine Identity Management

Whitepaper

Posted on June 3, 2021

Topics

Executive Overview

With the acceleration of digital transformation and a security trend of shorter validity periods, the number of SSL/TLS keys and certificates organizations need to ensure secure machine-to-machine (M2M) communication is skyrocketing. TLS certificates act as machine identities to protect all of these connections, and so their rapid proliferation has made it much more difficult to safeguard them. The dangers posed by insufficiently protected TLS keys and certificates range from costly certificate related outages to cyberattacks that can damage businesses in numerous ways. Several trends are driving the surge in the use of TLS keys and certificates, including the increase of IoT and mobile devices, the growing reliance of cloud initiatives and DevOps methodologies to build online applications and services, and the use of APIs and other protocols to facilitate communications and share data among multiple services. New research by Coleman Parkes shows that CIOs are worried about the many security and operational risks posed by the growing number of TLS keys and certificates their organizations are using.

  • 75% expressed concern about security risks connected with the proliferation of TLS certificates.
  • 56% said they worry about outages and business interruptions due to expired certificates.
  • 97% estimated that the number of TLS certificates used by their organization will increase 10– 20% over the next year.

As organizations require more TLS keys and certificates to manage a wide range of business processes, PKI Administrators and Systems Administrators need a better way to discover and handle these essential machine identities. In addition to evaluating the results of the Coleman Parkes study, this white paper provides a list of best practices and first steps organizations can take today to address the growing security risks posed by insufficiently protected TLS machine identities.

Introduction

In today’s digitally connected world, IT infrastructures extend well beyond physical and virtual servers in data centers to distributed environments that typically are global in scope. These networks often include public and private clouds, IoT devices, and artificial intelligence (AI) algorithms that help organizations respond rapidly to changing business goals and customer needs. As a result, the definition of machines that require unique machine identities to authenticate and communicate securely has broadened to include:

  • Cloud instances
  • Websites
  • Online applications
  • APIs and SDKs

These machine types can be physical (servers, load balancers, web servers) or virtual (virtual machines, APIs, cloud applications); are used in countless ways; and have widely disparate lifespans. However, every one of these machines needs the ability to authenticate each transaction so they can communicate securely. Machines use machine identities to do this.

SSL/TLS keys and certificates are arguably the most common type of machine identities used by organizations. TLS is used in most, if not by all, external connections to the internet to ensure safe connections. Seemingly simple tasks, such as customers checking their bank balance, require multiple M2M connections to transmit transaction data to the bank and back to the customer. Once customers make requests to see their balance, the mobile banking app must authenticate itself to the web server that hosts it. But it then needs to go through several more steps and many more machine identities—authenticating through load balancers and back-end databases and in many cases, additional third-party services companies and their platforms— before the transaction is completed securely.

Of course, this is just one of the hundreds of ways TLS machine identities are used. Over the last few years, the use of TLS certificates has grown exponentially—a trend that shows no signs of abating. Let’s Encrypt, a certificate authority (CA) that provides free TLS certificates, offers one indication of how quickly TLS certificate use is growing. In March 2016,1 six months after issuing its first certificate, Let’s Encrypt issued its millionth TLS certificate. Less than four years later, on February 27, 2020, Let’s Encrypt issued its billionth certificate.2 Let’s Encrypt’s explosive growth over such a short period reflects only a small fraction of the total number of TLS machine identities now in use. And TLS certificate use can be expected to grow dramatically as companies continue to deploy and expand digital transformation across their enterprises.

The unprecedented expansion in the number of machines requiring TLS identities, the increasing speed at which these identities are being created and changed, and the growing variety of machine types that need identities to communicate securely make it increasingly difficult to manage and protect M2M communication. According to a recent study, not only is the share of M2M connections expected to jump from 33% of all connections in 2018 to 50% in 2023, M2M connections are the fastest-growing category of secure connections, “growing nearly 2.4-fold (19% CAGR)” between 2018 and 2023.3

Weak and improperly managed machine identities have become a primary security risk for many organizations. People rely on usernames, passwords and two-factor authentication to gain access to data and services. Machines, in contrast, rely on cryptographic keys and digital certificates to accomplish the same thing. Ensuring secure, reliable authentication requires strong, protected machine identities—but this is increasingly difficult to achieve as the number of machine identities climbs.

That’s why cybercriminals are targeting machine identities to use in cyberattacks more than ever before. As of February 2020, nearly one-fourth of malware that connected via the internet used TLS encryption to communicate.4 And the financial damage of a cyberattack involving machine identity misuse can be severe. In early 2020, catastrophe modeling and risk assessment firm AIR Worldwide demonstrated that unprotected machine identities have already caused worldwide economic losses of between $51 billion and $72 billion, which with proper management of TLS machine identities could be eliminated.5

Given these circumstances, it’s not surprising that CIOs and other IT Directors and executives are increasingly worried about the security risks related to TLS keys and certificates.

The Most Visible Symptom of Weak Machine Identity Management Programs: Outages

There is no surprise that CIOs and Directors of IT are concerned about the risk that outages pose. According to leading analysts, the average cost of a critical infrastructure outage in Global 5000 organizations averages $5,600 a minute, or more than $300,000 per hour. These concerns are supported by a December 2018 Vanson Bourne study of 500 CIOs that showed almost two-thirds of CIOs experienced at least one certificate outage on business-critical infrastructure over the previous 12 months, with three-fourths of CIOs experiencing the same problem over the previous 24 months.

The overwhelming majority had multiple worries in all nine areas, ranging from supply chain disruptions (42% of U.S. CIOs) to facing an angry board of directors (29% of U.K. and French CIOs). The top five concerns were similar from country to country.

Statistic on Business with Certificate Outages

What most CIOs and Directors of IT don’t seem to realize is that outages caused by expired or revoked TLS certificates are one of the most visible signs of a weak TLS machine identity management program. Outages are typically the first indication that an organization lacks the tools or telemetry to know how many machine identities they’re using, where they are being used and who has access to them.

Comprehensive Visibility Minimizes TLS Security Risk

The problem facing most CIOs and Directors of IT is that the rapidly changing number of TLS keys and certificates their organizations are using makes managing and protecting them unworkable without the help of automation. Tools traditionally used to manually manage TLS certificates, such as spreadsheets, databases and CA dashboards, fail to provide organizations with a complete and comprehensive inventory of all TLS machine identities both internal and external to the network. This problem will only get worse as the number of machines relying on these machine identities continues to skyrocket and shorter validity periods are required forcing renewals more frequently.

Prescriptive Guide: NIST 1800-16

The National Institute of Standards and Technology (NIST) supports the argument that organizations no longer can rely on manual processes to protect TLS machine identities in its 2019 publication NIST SP 1800-16, Securing Web Transactions: TLS Server Certificate Management. NIST’s new SP 1800-16 framework gives organizations prescriptive guidance for developing policies and processes for securing and managing TLS certificates and private keys—with automation being fundamental to the effective management and security of these machine identities.

In SP 1800-16, NIST describes how many organizations fail to “leverage available automation tools to support effective management of the ever-growing number of [TLS] certificates. The consequence is continuing susceptibility to security incidents.”6 Put simply, the increased reliance on TLS keys and certificates has rendered “manual certificate management impractical,” with risks often being “the result of errors made while manually managing certificates.”7

According to SP 1800-16, organizations must have automated processes in place to effectively discover manage and perform actions on TLS certificates across their IT environments. For example, the ability to effectively rotate expired or compromised TLS certificates with minimum (if any) human intervention requires several steps that necessitate automation:

  • Complete TLS certificate inventory: Having visibility into all TLS certificates across a network in real time
  • Complete information about each TLS certificate: Knowing the location, owner, issuing CA and expiration date of every certificate managed by the organization
  • Rotation and replacement: Ensuring that expiring certificates are replaced before they lapse and cause a potential security event

To deploy effective TLS management that will protect TLS certificates from security risks, organizations need a comprehensive framework with commonly accepted parameters to follow. It’s not surprising that SP 1800-16 has been one of the most downloaded publications in NIST history, given the overwhelming need for guidance in this area. That’s because, until recently, guidance for protecting TLS machine identities from major standards bodies was vague at best.

The impact of SP 1800-16 is just now being felt, with many CIOs only beginning to absorb the ramifications of its recommendations, particularly with regard to automation. What follows is a brief overview of what the NIST framework encompasses.

Putting NIST 1800-16 to Practice

NIST SP 1800-16 provides detailed guidance for medium and large enterprises leveraging TLS to verify and authorize internet-facing and internal machines. Here are a few examples of best practices that relate to the policies driving TLS management:

  • Clear identification of roles and responsibilities around securing TLS keys and certificates
  • Defined operational and security policies specific to TLS keys and certificates
  • Parameters around certificate procurement, including authorized CAs
  • Maintaining certificate validity periods
  • Appropriate key lengths and signing algorithms with specific minimal standards provided by NIST
  • Rotation policies based on a certificate owner’s reassignment or renewal
  • Crypto-agility planning and bulk certificate replacement
  • Continuous monitoring of a TLS certificate’s operational and security status
  • Automation of the TLS certificate lifecycle, including procurement, issuance, and renewal or revocation
  • Reporting for audit purposes

NIST SP 1800-16 also specifies which processes are prime candidates for automation, such as:

  • Keeping an accurate inventory of all deployed certificates, including relevant metadata
  • Tracking ownership of each deployed certificate and revoking the ownership of anyone who has been reassigned or terminated using the principle of least privilege
  • Controlling ownership and access to private keys based on the principle of least privilege
  • Maintaining controlled access and policy enforcement including self-service permissions
  • Streamlining vulnerability remediation

Seven Steps: A Practical Guide to TLS Machine Identity Management

Managing TLS machine identities is not inherently easy. We will continue to see names in the news you might not have anticipated. In February 2020, Microsoft Teams had one expired TLS certificate that precipitated an outage lasting several hours and impacting 20 million users.8 In February 2021,Google Voice experienced an outage that, according to an incident report, caused a 4-hour and 22-minute disruption for “new inbound or outbound Voice over Internet Protocol (VoIP) calls” to fail to connect.9

Fortunately, solutions are available that can help organizations gain insight into all TLS certificates on their network and automate multiple steps related to discovering, monitoring and managing these certificates across their lifecycles. The best tools usually take a holistic, CA- or platform-agnostic approach rather than solutions that may not monitor certificates issued by other CAs or used on other platforms.

To eliminate TLS security risks, organizations must be able to discover, track and continuously monitor all TLS certificates in real time across the entire enterprise network, including those externally accessible on the global internet and those used in virtual and DevOps environments. In complex, rapidly changing networks, this is a tall order.

So, how does your organization start to address the problem? Here are seven steps Venafi recommends you take to implement an effective TLS machine identity management program for your organization:

  1. Discover all certificates. Choose a discovery tool that leverages automation to continuously discover all TLS certificates across your entire extended network—including cloud and virtual instances, as well as various CA implementations. This will help you locate every certificate that can impact the reliability and availability of your organization’s critical infrastructure.
  2. Catalog a complete inventory. Group certificates according to the technology, applications, teams and business units they support; recognizing one certificate may be represented in multiple locations. This can be used for reporting and dashboards to add emphasis to certificates that matter most. A complete inventory will manage status, details and location details making it easy find and rotate certificates.
  3. Assign Ownership. Inform the right people at the right time by assigning ownership of certificates according to their impact to applications or business units. Ownership can achieve various purposes either to inform or to prioritize workload. A well-maintained inventory will make it easy for owners to rotate certificates before they expire.
  4. Verify security compliance. Invest in a solution that will ensure all certificates have the proper owners, attributes and configurations no matter which CA issues them. This will guarantee all certificates meet key security regulations.
  5. Continuously monitor certificates. Conduct nonstop surveillance of all certificates so that you’ll know well in advance if a certificate is going to expire, giving you ample time to replace it. This approach also helps detect and prevent certificate fraud and misuse, addressing critical security concerns.
  6. Automate renewals. Eliminate the risk of human error by automating certificate renewals, so you can install, configure and validate certificates in seconds. You’ll not only improve availability, but you’ll be able to do it in a fraction of the staff hours previously required.
  7. Ensure crypto-agility. If you discover that any of your TLS certificates have been compromised or untrusted, you need a way to quickly identify, locate and replace these certificates.

Conclusion

Organizations now rely on a large number of machines to drive their businesses—and this growth is rapidly starting to accelerate. As a result, everyone from senior-level IT executives to system administrators, need to reevaluate the ways in which they secure the identities of these machines to keep sensitive data secure. This is arguably one of the greatest security challenges they face, particularly as the number and types of machines continue to surge, along with the increased industry pressure to use short-lived certificates to improve the security of TLS communications across the internet.

Although IT executives worry about the security risks posed by weak or ineffectively managed TLS keys and certificates, many of them are overconfident that they have a handle on these risks. The research discussed in this report shows the scope of the problem is not well understood and often underestimated among executives within organizations.

For senior IT executives looking to gain control of their TLS certificates, NIST SP 1800-16 provides a prescriptive framework that describes how to implement an effective TLS certificate management program. Perhaps the most important takeaway from SP 1800-16 is the importance of leveraging automation to harden TLS machine identity management processes. Manual certificate management and patchwork programs that depend on CA dashboards is no longer an option. Without the intelligence and automation necessary to deliver comprehensive, real-time visibility into every machine identity in use across the organization and detailed intelligence on where and how they are being used, IT teams will not be able to reduce the growing security and operational risks connected with the vast population of machine identities their organizations are using. This is the only approach that makes it possible to dynamically issue and replace certificates before they expire or are compromised and to minimize security and operational risks.

TLS Protect Cloud is the only SaaS-native solution on the market that can help organizations tackle TLS security challenges—even in complex, global networks. Try it for free today.


References

  1. Aas, Josh. Let’s Encrypt. Our Millionth Certificate. March 8, 2016.
  2. Aas, Josh and Gran, Sarah. Let’s Encrypt. Let’s Encrypt Has Issued a Billion Certificates. February 27, 2020.
  3. Cisco. Cisco Annual Internet Report (2018-2023). 2020.
  4. Sophos News. Nearly a quarter of malware now communicates using TLS. February 18, 2020.
  5. AIR Worldwide. The Economic Impact of Machine Identity Breaches. February 2020.
  6. Akram, Mehwish; Barker, William C.; Clatterbuck, Rob; Everhart, Brandon; Gilbert, Jane; Haag,
    William; Johnson, Brian; Kapasouris, Alexandros; Lam, Dung; Pleasant, Brett; Raguso, Mary; Souppaya, Murugiah; Symington, Susan; Turner, Paul and Wilson, Clint. NIST Special Publication 1800- 16: Securing Web Transaction, TLS Server Certificate Management. July 2019. NIST SP 1800-16B, iii.
  7. Ibid. 26.
  8. Fisher, Christine. Engadget. Microsoft Teams went down because of an expired certificate. February 3, 2020.
  9. Gatlan, Sergiu. Bleepingcomputer. Recent Google Voice outage caused by expired certificates. February 18, 2021.

This site uses cookies to offer you a better experience. If you do not want us to use cookies, please update your browser settings accordingly.
Find out more on how we use cookies.