The State of Certificates for Identity Based Security

Linda Ikechukwu

Follow Smallstep

Synopsis

We surveyed 155 professionals comprised of Security Analysts, IT Operators, Consultants, and Developers from both small (< 100 employees), medium (100 to 1000 employees) and large (> 1000 employees) companies on their plans around certificate usage in 2024.

The results reveal a significant focus on securing devices with certificates — over 51% of respondents have plans to use certificates for devices. Additionally, the vision of using certificates to provide device identity has also grown significantly by over 20% since we did our certificate management survey in 2021.

Introduction: The Dilemma of Identity

If the credentials used to validate identity can easily be stolen, how then can we be assured that a person or an entity is truly who they’re claiming to be?

Investigate any data breach, big or small, and you’ll often arrive at the same revelation: stolen user credentials — obtained via phishing, password spraying, credential stuffing, social engineering, or man-in-the-middle attacks — are always central to these incidents.

Interestingly, the internet was not originally designed with a need for trust. It began as a project among a group of scientists and engineers who wanted to exchange files and messages over a network. Since they likely knew each other personally, there was an inherent sense of trust.

However, as the number of internet users surged and the sensitivity of the data being exchanged increased, there was a rush to provide a way to identify who and what we were connecting with. This is probably why we ended up with shared credentials (starting with passwords and moving on to other credentials like OTPs, session credentials, personal access tokens, OAuth tokens, SSH keys, and so on) being the default standard for proving identity.

But using shared credentials to prove identity has one major flaw; the same flaw that has resulted in 79% of US companies experiencing an identity-related breach within the past two years.

The reason is fairly straightforward: to prove identity with a such shared credentials, secrets have to be transmitted from client to server, creating opportunities for hijack and impersonation. A shared secret is no longer a secret.

The future lies in secret credentials that never leave home, and are anchored to and attested by hardware, thereby making identity theft a much tougher job.

Given the current threat landscape, we’ve maintained that the best way to securely authenticate identities is with public key cryptography (powered by certificates). Unlike other authentication methods, the secret credential (private key) does not need to be shared to prove identity.

Statistics are proving that our head are in the right clouds.

You should read: The best secrets are the ones we keep to ourselves (a.k.a why passwords suck)

A Tale of Breaches

Including device identity (device credentials tied to a specific piece of hardware) in access decisions can prevent numerous breaches.

In correspondence with our survey results, many enterprises are realizing that they can no longer solely depend on shared user credentials to safeguard access to sensitive data.

On one end, the massive LastPass breach which took place last year happened because an engineer at the company logged into AWS from a non-managed personal computer which had an out-of-date Plex server installed on it. Attackers exploited the CVE-2020-5741 vulnerability in the outdated Plex version to install a keylogger on the engineer's device, which allowed them to steal vital credentials.

Incorporating device-bound identity/trust as a factor in access decisions would have:

1. Prevented the engineer from logging into AWS using a non-corporate owned device with out-of-date software.
2. Prevented the attacker from connecting to AWS from a different device using the stolen credentials.

On the other end, Figma has taken the proactive approach to enforce device trust on code changes to ensure that code changes merged into GitHub release branches come from trusted, company-managed devices and reduce the risk of malicious code reaching production.

Even the White House has device identity on their list of priorities to be achieved by the end of the year 2024. On their memorandum for moving the U.S. Government Toward Zero Trust Cybersecurity Principles, they state: ”The devices that Federal staff use to do their jobs are consistently tracked and monitored, and the security posture of those devices is taken into account when granting access to internal resources.”

With device bound credentials, authentication becomes a case of: user John Doe (identified through username/password, SSO IdP, or even Passkey), using Macbook X (identified through ACME DA issued credential), would like to get access to piece of data Y. This enriches the context for an access control decision and provides higher identity assurances.

Since identity for device-bound credentials is proven using cryptographic attestations from a TPM or Secure Enclave, it will be nearly impossible to impersonate a device and gain unauthorised access.

In summary, awareness is growing among CISOs and other security professionals about the need to evolve and augment security efforts with device-bound identity. You should get on the train too.

You should also read: All about TPMS and ACME Managed Device Attestation explained.

Key Survey Findings

More organisations will use certificates for device identity this year

In response to a query about their 2024 plans for using certificates, 55% of respondents indicated mutual TLS, while 51% planned to use certificates for device identity.

We also posed a variation of the first question, asking about the certification-related projects respondents were prioritizing for the year 2024. The results are consistent with previous findings, with devices remaining one of the top three plans.

It’s also interesting to see the contrast between how certificates were planned to be used in 2021 (the last time we conducted this survey) and how they are anticipated to be used in 2024.

The growing interest in using certificates for different purposes indicates that more organizations are recognizing the advantages of certificate-based authentication. This means that more organizations will require well-established CLM (certificate lifecycle management) processes and a strong PKI to effectively manage the multitude of certificates.

Many organisations are still relying on perimeter security (primarily VPNs) alone to keep the bad guys away

When it comes to how organisations are securing internal access, it turns out that VPNs are still the primary way of securing internal services, with about half of the respondents using VPN tunnels. Regardless, it’s encouraging to see that a close number of respondents also use mTLS.

Interestingly, 29% of respondents mentioned leaving their internal services insecure, which raises concerns about potential vulnerabilities within their internal networks.

14% respondents indicated that all their services are on one platform, which might suggest a reliance on platform-specific security measures, assuming inherent security within the platform or accepting the risk associated with intra-platform communication.

These are weak security practices which could be readily exploited.

Over two-thirds of surveyed organisations have an internal PKI, yet challenges such as PKI complexity, cost, and automation issues hinder CLM maturity, particularly in small companies with fewer than 100 employees.

To effectively use certificates, a robust Public Key Infrastructure (PKI) is necessary. Given the increased interest in using certificates for a varying number of endeavours, we surveyed participants to determine if their organizations have an internal PKI.

More than 66% of respondents answered affirmatively.

Notably, the respondents who either lacked an internal PKI or were uncertain of its existence came from smaller companies with fewer than 100 employees. This is understandable, as implementing a robust PKI can be challenging for smaller organizations with limited manpower and resources.

If you are working on internal PKI and feel a bit overwhelmed, you are not alone. Respondents cited various challenges that prevent them from adopting PKI. We were able to categorize all the responses into three main categories:

• PKI complexity (lack of simplified education on the topic),
• Cost, and
• Operational challenges related to Certificate Lifecycle Management (issuance, keeping up with expiring certificates, renewal, revocation, as well as the setup and management of internal CAs, which are crucial for issuing and verifying certificates within an organization).

We do our best to educate people on certificate management and PKI. We often hear that our blog posts are ‘the best resource available’ on these topics (you can subscribe below to receive new educational articles straight into your inbox). If you are just getting started check out our Everything PKI blog post.

While more organisations adopt automated certificate management, many still cling to manual processes which could inevitably lead to certificate related outages.

There continues to be room for improvement when it comes to internal certificate management with over 31% of respondents relying on manual processes to distribute certificates, which is usually more expensive and error-prone.

While legacy automation tools like SCEP continue to exist, it’s heartwarming to see the market moving to the newer and more secure certificate automation protocol ACME. We predict that the usage of ACME will continue to rise exponentially as more organisations embrace device identity with ACME Device Attestation.

You should read: Why you should never DIY your PKI

Recommendations & Conclusion

Threats are always lurking in the dark, so our vigilance must never waver. As attackers continue to relentlessly employ sophisticated tactics, our security measures must evolve with equal ingenuity.

1. Augment perimeter security with proper application level security too.
2. Get curious about device bound identity, test it out and see how it can be of benefit to your organisation

Now of course I’m going to try to sell Smallstep to you. Smallstep is the currently the only solution that uses device attestation and hardware-backed credentials to eliminate impersonation, session hijacking, and credential exfiltration in order to deliver strong evidence of a device’s identity for trust evaluation.

With Smallstep, if a device isn’t company-owned or company-approved, it can’t access sensitive apps and data. Now, you can protect financial data, code repositories, public SaaS websites, PII, Wifi, VPN and other sensitive resources by restricting access to company-managed devices. Take it for a spin today!