In this interview with Help Net Security, Oded Hareven, CEO at Akeyless, explains how organizations manage secrets, particularly how this practice has changed and evolved amid the rapid shift to hybrid/remote work and how it benefits organizations security wise.
We have seen great changes in the last couple of years in how companies operate and organize their workflow. How have these changes altered the way they manage secrets?
Indeed the way companies operate workflows has changed dramatically. The sad truth is that secrets–which, can be anything from standard username/password or credentials, to SSH keys, API keys, and certificates–as we know them today, were not centrally managed until the rise of secrets management solutions in very recent years.
Key Management Services (KMS) were focusing on keys, while Privileged Access Management (PAM) and Password Management tools focused on human credentials. As long the organization didn’t yet implement any of the new cloud trends such as DevOps, Automation, and Containerization, everyone was happy inside the so-called perimeter.
Companies are shifting their services to the cloud, but on-premise workloads are going to be around for many years to come. Then there is the fact that there is not just one cloud, obviously. And large organizations have different teams and business units that all choose different platforms. So the hybrid multicloud organization is quickly becoming the norm. This is a great thing as now all organizations can be agile and choose the platforms and support tools that not only work best for them but also provide the most value to the overall organization. These trends create challenges, which we call ‘secret sprawl’.
The challenge associated with interconnecting and providing the right level of access to disparate workloads introduces a host of new security and compliance challenges. For instance, the sheer number of secrets used by machine-to-machine and human-to-machine interactions has proliferated dramatically due to automation, containerization, DevOps initiatives, and so on.
In this hybrid multicloud environment I explained above, there is a risk of having separate islands of secrets. It is difficult for security teams to see how many secrets are in use overall, who uses them, and where. And if they can’t see them, how can they ensure they are safe?
Another challenge associated with the automation/DevOps trends is how secrets are used. It is too often that we see secrets hardcoded in source code or configuration files, in plain text, which are then uploaded to public repositories such as GitHub.
These secrets, and especially the ones used by privileged users such as network or security admins, and DevOps engineers, have traditionally been managed by Privileged Access Management (PAM) solutions. However, these solutions were not designed for machine-to-machine communications, something we now see ballooning. Rather, they were designed to provide security around humans accessing machines. There was no element that would validate machine identities and facilitate appropriate access to other machines.
This is a recipe for disaster. From the perspective of a corporate security team when we bring these two things (hybrid multicloud + M2M access) together, they face quite a challenge, as they are ultimately responsible to ensure the organization adheres to security and compliance guidelines. Meanwhile, they also don’t want to be the department of ‘NO’ and inhibit the organization’s agility and ability to remain competitive.
Another change that is a bit more technical but has important implications: securing your secrets with cryptography, requires a master key. Typically, these are kept safe by hardware-based cryptographic solutions known as Hardware Security Modules, or HSMs. This chainlink of using a new secret to protect a secret is known as the Secret Zero Problem.
Unfortunately, when using cloud-based secret vaults, organizations have to relinquish their master keys to them. This means CSPs have access to the organization’s secrets, and therefore their data. They can be accessed by rogue administrators, or the cloud provider can be subpoenaed under the cloud act for example, and the government then has access to their data, and perhaps without the organizations’ consent. This is not what cryptography is intended to do. This approach introduces an enormous amount of unnecessary risk, a risk the organization cannot control.
What do you think is the optimal way to do secrets management?
Secrets management should be done in a way where both users and machines have a secure, transparent, and scalable way to obtain, issue, and revoke secrets. This means secrets management should be centralized, agnostic to the location of the user or machine, or which flavor of cloud platform the service they need access to is running on.
Secrets management is a critical component of an organization’s automation strategy to ensure secure access and communication for humans and machines. It plays a vital role in enabling the business to adopt modern workplace technologies while remaining both secure and agile. Secrets management, therefore, needs to be available wherever the organization’s workloads and users are, and able to scale automatically, based on demand.
Why is secrets management important?
Secrets management is critical because it allows organizations to be more agile and more secure at the same time. It allows them to move on from the classic world of static secrets, secrets with long-standing privileges, to a more dynamic and real-time approach to authenticating and accessing the services they need. It is too often that we see secrets hardcoded in source code or configuration files, which are then posted publicly to GitHub for example.
We can now use dynamic secrets instead, which provide what the industry calls Just-In-Time (JIT) access. This is a term borrowed from the manufacturing industry, where they don’t order goods or parts until they are actually needed. In this case, the key reason for JIT is when you use ephemeral resources in the cloud. When these resources are revoked, the associated keys need to be revoked automatically as well.
In addition, if you dynamically create secrets with just enough privileges that the human/machine identity is authorized for, and revoke access after a reasonable/predetermined time period, you greatly reduce the opportunity that an attacker has to compromise that secret. If you can’t use dynamic secrets, for example for administrator-level accounts on servers or network devices, you can at least automatically rotate them and stop relying on humans to update their passwords. And finally and somewhat obviously perhaps, secrets management solutions keep secrets safe and secure, so only authorized identities can have access to them, and nobody else.
Could you explain a secret’s lifecycle?
It starts with the creation or generation of a secret, which again can be a credential, key, certificate, or password used by either a machine or human to access a workload. The creation of a secret can be done manually, or automatically. Automatically is the preferred way because humans are typically not good at creating strong passwords.
Then, in the case of static secrets, there’s the option to rotate it and change the secret at a set interval. How frequently you do this can be mandated by security policy standards such as PCI DSS (90 days max). Finally, at the end of the cycle, the secret is revoked and can no longer be used to access your intended target. This can be triggered by the expiration time of a dynamic secret (we call that the TTL or time-to-live) or manually, for example when an employee or contractor is no longer with the company.
What is the state of secrets management nowadays and how do you think it will evolve in the future?
The current state of secrets management is that there is a rapidly growing awareness of the importance of securing machine-to-machine and human-to-machine interaction, among security professionals as well as DevOps teams, especially as organizations transition to hybrid multicloud infrastructure and containerized workloads. Today, there’s a mismatch, where organizations are running more and more of their workloads in the dynamic cloud environments, while their secrets management strategy does not exist yet. And in the case of CSP offerings, they are too proprietary, primarily designed for workloads operating within their specific cloud environment.
In the future, I see secrets management and secure remote access converging and allowing for even more seamless secure communications between disparate systems, and with more integrations into other security systems. I also foresee secrets management solutions incorporating elements of machine learning and artificial intelligence to help define policies and revoke access when necessary based on external security incidents.
Credit: Source link
