“As organizations race to achieve a zero-trust security model, the uncontrolled sprawl of SSH keys and the access they grant creates a serious problem. Getting visibility to SSH keys is the first step to preventing exploits,” says Chris Hickman, Chief Security Officer, Keyfactor, in an exclusive interview with ITSecurityWire.
ITSW Bureau: Why are SSH keys considered to be ideal for automated processes?
Chris Hickman: The shift to cloud and infrastructure automation means that the number of privileged SSH connections has increased drastically. On average, a large enterprise has between 50-200 keys per server, with over a million keys across their environment. Key sprawl is a growing problem for businesses, especially as SSH keys lack governance and oversight of traditional privileged access tools like passwords.
Read More Interviews: Enterprises Leverage AI to Secure Sensitive Data
Public key infrastructure (PKI) is more secure than password logins. It does not require user interaction to grant access, allowing users to access a remote server multiple times without manually log in. This makes SSH keys ideal for IT process automation, where machines need to connect to one another without user interaction securely.
ITSW Bureau: How has the adoption of cloud, DevOps, and remote working changed the way enterprises view SSH key management?
Chris Hickman: SSH provides remote access for the administration of devices and servers. With the increase of work from home model, SSH keys have multiplied as remote server administration and configuration have become the norm during the Covid 19 epidemic. Simply put, there are more keys in use today than ever. However, management practices that are typically lacking to begin with, continue to be lacking, compounding the management issues associated with SSH keys.
ITSW Bureau: What, according to you, are the significant differences between X.509 certificates and SSH keys?
Chris Hickman: While they share many similarities, one of the most notable differences is that SSH keys do not expire. This means that once a key is generated, it remains valid and active in perpetuity. As these keys are not tied to a central identity store, disabling login does not necessarily remove access based on the SSH key. The two identities are not connected.
ITSW Bureau: What are the potential risks and their causes when enterprises implement SSH keys?
Chris Hickman: In DevOps, SSH is a fundamental tool for IT operations, developer build, and release processes. Giving developers unlimited and uncontrolled opportunities to create and copy SSH keys presents a security challenge. As organizations race to achieve a zero-trust security model, the uncontrolled sprawl of SSH keys and the access they grant creates a serious problem. Most public cloud workloads run on Linux; SSH is inherently secure, but the risk of exposing access or credentials is serious.
Read More Interviews: The Need for Safeguarding IT Infrastructure in the New Normal
Remote work leverages SSH to allow users to configure and manage systems from anywhere. Without regular visibility into who owns SSH keys, how they are being used, and what access they grant, they can become risk liability. Attacks leveraging SSH keys are growing in frequency and sophistication, using several vectors to access and exploit keys including brute force attacks, advanced malware, network backdoors and lateral movement within the network.
ITSW Bureau: How can enterprises reduce SSH key sprawl and mitigate SSH-based attacks?
Chris Hickman: Traditional approaches to SSH key management are typically manual, labor-intensive, and prone to error. Manual logins and scans are not practical. Workloads get spun up and torn down and employees come and go, making it impossible to have an inventory that is accurate and up-to-date of all SSH keys in the environment.
Getting visibility to SSH keys is the first step to preventing exploits. In order to manage keys effectively, teams need discovery tools to find keys and map trust relationships, monitoring and reporting capabilities to identify risks, centralized governance over key rotation and usage and automation, and self-service to provision and update keys.
These are six steps that teams can consider to get ahead of key sprawl and mitigate future risk:
- Discover and map keys:Start by discovering all existing keys within the organization and bring them into a central repository. Once keys are collected, your team can map user-key relationships to understand the level of network access that every key grants.
- Analyze the risk:It is important to analyze SSH keys for configuration or usage vulnerabilities. Ensure that keys are configured to allow limited access for the purpose they serve.
- Remediate vulnerabilities: Continuous monitoring and reporting are essential in identifying new risks as they emerge. Once the company has a complete and accurate inventory of all SSH key pairs, they can begin rotating or replacing weak and outdated keys. Duplicate keys that have unnecessary root access can be removed, and unused or orphaned keys can be cleaned.
- Create fresh key pairs and rotate them regularly:It is best to start by deleting all untracked keys, replacing them with freshly generated key pairs. Establish a clear process that allows for specific authorized users to create and deploy them through a controlled workflow.
- Control SSH keys and access:Define permissions for each key and control who has SSH-based access to specific systems.
- Continuously monitor: Achieving 100% control is not possible, but you can stay ahead of threats by conducting regular audits and continually monitoring your key inventory.
