5 Infrastructure Security Advancements You May Have Missed in 2022

Linda Ikechukwu

Follow Smallstep

Whew! What a year. After the global upheavals of 2020 and 2021, 2022 marked the beginning of a return to some semblance of normalcy. However, while most things like in-person events and travel are making a comeback, remote work has remained a permanent fixture.

The widespread adoption of remote work means that the workplace has expanded outside the physical walls of an organization. This has admittedly created increased opportunities for phishers, hackers, scammers, and every other villain to wreak havoc. Therefore, now more than ever, it’s important for organizations to keep up with the latest security advancements in order to better protect their infrastructure.

That said, here are five security advancements from 2022 that you may have missed, but should consider implementing to enhance your security posture in the new year:

1. Apple MDA

During WWDC 2022, Apple announced Managed Device Attestation (MDA), and we at Smallstep haven’t been able to stop talking about it. We’re most excited that Apple’s MDA solution builds on ACME—if you’ve been following us closely, you know how crazy we are about ACME.

Employees can now easily self-enroll their newly received devices into their organization’s Mobile Device Management (MDM) solution and automatically obtain client certificates from the organization’s issuing Certification Authority (CA) ACME service for accessing internal infrastructure. But before that, the device has to obtain and present a device attestation certificate from Apple to the CA’s ACME service. This device attestation certificate proves, amongst several things, that the device's UDID and serial number are authentic and that the device hasn’t been altered or misused by an attacker. Upon successful verification of the device attestation certificate against Apple's attestation servers and/or the organization's device inventory, the ACME server issues a certificate.

Apple’s MDA increases the security and ease of device deployments and enrollment. You can be assured that only legitimate devices are enrolled; this has been a major shortcoming of the Simple Certificate Enrolment Protocol (SCEP) used by most MDM solutions.

We’ve written about Apple’s new ACME-enabled MDA in detail and how you can use Smallstep as your ACME server for Managed Device Attestation.

2. GitHub Actions OIDC

GitHub thinks it’s time to move away from hardcoded secrets in code, and so do we! With GitHub Actions OIDC, instead of the usual practice of hardcoding credentials for accessing cloud resources on GitHub, you can configure your workflows to request short-lived access tokens directly from your cloud provider. These tokens will only be valid for a single job and will also automatically expire after the job is finished, reducing the risk of abuse.

GitHub Actions OIDC is a useful feature for reducing the risk of secrets exposure and is especially important in this era where leaked or stolen credentials remain the most common cause of a data breach.

Here’s how you can use GitHub Actions OIDC tokens and Smallstep Certificate Manager to securely access protected internal resources like cloud services, databases, websites, or Kubernetes clusters using short-lived TLS certificates and no hard-coded secrets!

3. systemd-creds

systemd-creds was first announced/released in the last days of 2021 in version 250, and started gaining traction in 2022. It is a utility provided by the **systemd**system and service manager to improve the security of user credential management on a Linux system. It allows you to protect service credentials using a TPM, rather than storing them on disk in plaintext.

One of the many benefits of the systemd-creds utility is that user credentials can now be stored in a central location, rather than multiple locations throughout the system. This makes it easier to update and secure credentials, as well as to audit their usage. It also stores credentials in an encrypted format, making it more difficult for unauthorized users to access them. This makes the systemd-creds perfect for storing sensitive credentials, private keys, TLS certificates, or passwords!

We’re big fans of the systemd-creds utility, so we wrote about its magic and how you can use systemd-cred to secure the password for step-ca Certificate Authority server on a Google Cloud VM.

4. Passkeys

Passkeys, which are based on the FIDO and WebAuthn standards, was developed collaboratively by Apple, Google, and Microsoft to improve user authentication.

Passkeys replace traditional passwords with cryptographic keys, and are a much more secure alternative to passwords which can easily be guessed, stolen, or compromised. Passkeys are stored on your device and linked to the app or website for which they were created, preventing users from being phished.

Users can easily create and use passkeys using their native device security biometrics such as Touch ID, Face ID, or Windows Hello. Then, when they log into a website or app, the passkey on their device creates a unique signature that confirms their identity.

Passkeys are an emerging technology, and are gradually being supported across different device types and browsers. This is an invitation for more engineers to consider implementing passkey support in their apps and websites!

5. Identity-Aware Proxies

Identity-Aware Proxies (IAPs) allow organizations to control access to their cloud-based or on-premise applications and VMs running on Google Cloud, based on the identity of the users trying to access them, instead of relying on network-level firewalls or VPNs.

IAPs work by intercepting incoming traffic to a resource, such as a Google Compute Engine virtual machine or a Google Kubernetes Engine cluster, and verifying the identity of the user trying to access it. If the user's identity is not recognized or is not authorized — by virtue of having the correct Identity and Access Management (IAM) role — to access the resource, the IAP will block the request. In addition to user identity, IAPs could also be configured to make access decisions based on device identity or additional context such as IP/country user is connecting from, time the connection is created, etc.

IAPs are particularly useful for organizations that need to control access to sensitive resources or ensure that only authorized users can access certain resources. They can be used to secure access to various resources, including web applications, APIs, and other online services.

Looking to the future…

Taking a deeper look at the solutions on this list, you’ll find that there are certain commonalities. It’s clear that the top players all agree on three things:

• Shared secrets (usernames and passwords, API tokens, encryption keys, etc.) are no longer a reliable method of managing infrastructure access.
• Perimeter-based security is insufficient for preventing unauthorized access to infrastructure.
• The future of authentication is ‘secretless’ (i.e., no sensitive credentials shared between server and client during authentication) in conjunction with hardware-bound cryptographic credentials. And if sensitive secrets are shared, they should be ephemeral.

Here at Smallstep, we couldn’t agree more. We firmly believe you should use TLS (hence certificates) everywhere within your infrastructure.

And, in line with that, we’ve been thinking of ways to make it easier for everyone to use client certificates in all kinds of places for their day-to-day work. So far, users have mostly interacted with the Smallstep ecosystem via our CLI. This was all good and fine when we were only dealing with certs for internal infrastructure. But now that we’re starting to do more things involving humans getting certificates, it’s probably time to consider a different approach that is easier to use and more user-friendly.

Imagine a GUI application that will automatically obtain certificates from a Smallstep CA, and place them in the right places (e.g., browser stores, SSH key agents, environment variables, etc.) so that they can be used by systems that rely on client certificate or SSH certificates for authentication. Users would only need to authenticate into the app — say once a day — using a preconfigured method (like SSO with their existing identity provider) to kick off this process.

If a TPM (or another secure subsystem, like the Secure Enclave) is available on a user's device, the app should be able to interact with it and make use of it to store key material, thereby providing stronger assurances about the security of key materials. Additionally, an attestation server may also be used to securely attest the identity of a TPM , and optionally the integrity of the kernel and OS, so that the device containing the TPM can be issued an identity certificate (which might then be used as a means of authentication by the app). How does that sound?

We’re still fiddling with this idea and will wholly welcome any thoughts, feedback, or advice. Subscribe to our newsletter if you'd like to be kept in the loop.