Using Dynamic Cloud Secrets to Achieve a Zero Trust Model

Cloud Secrets

The following article originally appeared in Dark Reading.

If every application, device, and bot need access and authentication at some point, the need for managing and controlling the confidential data that allows those functions gets staggeringly large.

In today's digital businesses, we rely on commercially procured or internally developed applications.

Because of the need for more speed and more routes to market a variety of things, we have an increasingly automated IT infrastructure that is fundamentally built upon a potentially weak security posture.

While application needs and capabilities and IT environments vary significantly among organizations, one thing remains true everywhere: Every application, script, automation tool, and other non-human entity relies on some form of a "secret" — or privileged credential — to access other tools, applications, and data.

Those secrets and access are quite literally rocketing around our infrastructures and networks at the speed of light and are also a single point of failure.

Before we get too far down this rabbit hole, let's be clear about what a secret is. A secret is a non-human, privileged credential and refers to a private piece of information that is a key, whose sole purpose is to unlock a protected resource or sensitive information in a tool, application, container, or cloud-native environment.

Some of the most common types of secrets include:

• Privileged account credentials
• Passwords
• Certificates
• SSH keys
• API keys
• Encryption keys

Humans also have secrets (aka passwords) to manage and maintain, and statistically those secrets are the most compromised asset for any infrastructure — period.

Every time you or someone else log in to a system, endpoint, or cloud asset, you rely on a secret to gain access to that resource. Even if you log in with something that is not a password — such as biometrics, or a token — an exchange is taking place that is reliant on that secret to be shared and validated for that access to occur.

Now think how often that happens with just your access and your network, then multiply it by 100. The number is mind boggling, and that is a conservative estimate.

If you consider that every application, device, and bot all have needs for access and authentication at some point, and that in many enterprises there can be tens of thousands of those assets — each with its own access — the need for managing and controlling those secrets gets staggeringly big exceptionally fast.

This is a problem for most organizations. Anything that is a problem for the security teams means that it's an advantage for the bad actors in cyberspace.

How Do We Fix the Issue of Secrets?

The sheer scale of the problem means that we cannot address it with Excel files, spreadsheets, and manual systems of control — it simply will not work. Logic would suggest that we turn to a technology solution to help us.

We need a vault for our secrets, but what should that vault be able to do?

To put it simply, a vault or solution should enable three basic tenants of a good zero-trust access access paradigm:

• Just in time, only grant access when it is needed
• Just once, not continual access using the same method or tokens
• Just that asset, no carte blanche access to an environment's assets

Additionally, the solution should be able to work across infrastructure and across the solutions we are already using. We should not have a need or requirement to "rip-and-replace" to make this work — therefore, easy implementation and wide integration are critical.

A vault that provides just-in-time secrets supports users and machine IDs with the ability to quickly check out a role-based elevated privilege profile for a specific cloud service, either for the duration of a session or task, for a set amount of time, or until the user checks the profile back in manually. Once the task is complete, privileges would be automatically revoked.

It is also important that organizations rotate passwords when users leave. Sharing accounts is not the best practice from a security standpoint, but it is becoming increasingly common with the growing use of cloud resources within DevOps organizations. If an individual leaves the organization, that permission/privilege then becomes a potential vulnerability.

Finally, the ability to investigate who has access to which secrets would improve security incident remediation. Being able to tie secrets back to identities for proactive monitoring and post-incident investigation would uncover identities or individuals that have been exploited, and highlight access changes, policy drift, and risky activities.

In summary, one of the most important questions to ask here is, "What does the adversary want?" In other words, what does a hacker need to be successful? They need an organization not to enable this type of approach. Inaction helps an attacker win more, move faster, and dig deeper into the infrastructure.

Explore ways to remove avenues of compromise and keep attackers away from your secrets.