Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Passwords are everywhere. Sometimes they are obvious — hardcoded in the code or laying flat in the file. Other times, they take the form of API keys, tokens, cookies or even second factors. Devs pass them in environment variables, vaults mount them on disk, teams share them over links, copy to CI/CD systems and code linters. Eventually someone leaks, intercepts or steals them. Because they pose a security risk, there is no other way to say it: passwords in our infrastructure have to go.

Hardware security modules (HSM) and trusted platform modules (TPM) seemingly do the same thing: they manage secret keys and enable data protection. But what does “managing secrets” mean, and what’s the difference between the two? Before diving deeper, let’s explore why computers need help with managing their secrets.

Customers are increasingly looking for just-in-time access to infrastructure. Imagine there is a production outage and a senior SRE needs to login to a production server to diagnose and fix the issue. In this organization, on-call SREs have elevated access to production systems, but when they are off-duty, their privileges are reduced. When the Pager Duty alert goes off, our on-call SRE ssh’s into the server but after several minutes of looking, can’t diagnose the issue.

Over the last few years, the term DevOps and DevSecOps (which stand for Developer Operations and Developer Security Operations respectively) have become synonymous with companies trying to become more agile and less monolithic.

This blog post started as a seasonal message from our Newsletter. We’ve expanded it to be appropriate for the rest of the year. With more employees changing jobs in 2021 than ever before, there are likely to be a few skeletons in the closet.

Before I joined the security industry, I was an end user. Coming in with that first-hand experience equips me to talk about secure remote access from multiple perspectives: as a vendor and as a practitioner. This lets me see the technologies available and also understand the drivers and issues engineering orgs face adopting them, particularly with onboarding engineers. I’ve been a support engineer for over 20 years, across Operations and System & Database Administration.