No one wants a poorly managed SSH deployment to create the perfect threat surface for adversaries. If you are not properly protecting SSH connections, they can lead to very costly incidents. But what are the ingredients for this ticking time bomb?
When evidence is found of a stolen SSH client key, a security event can quickly become a serious incident. How can it get this far? Or, to be more specific, what are the shortcuts organizations are taking that may lead to severe SSH threat risks?
5 signs that your SSH environment may have a ticking SSH bomb
1. The Fuel: A toxic growth in trusted connections
SSH is known for its encryption and built-in automation. By using a single command and a key, a script or automation tool can reach out to another SSH identity, send a command and receive system information back. This type of SSH connection is often based on a high level of trust. Today, cloud migration or digital transformation can push resource-stretched organizations toward a toxic growth in these automated machine-to-machine connections — especially when IT productivity is given a high priority.
2. The Blindside: Outdated or bypassed observation
Traditional controls may not be able to cope with new environments and new growth. As connections grow outside the traditional perimeter, legacy controls — like jump or proxy servers — may get bypassed. Even worse they may become bottlenecks because they can no longer deal with the volume and intensity of the machine-to-machine connections. Also, deep PAM (privilege access management) controls like full-session recording may become irrelevant as DevOps processes continuously change the IT environment and programmatic sessions becomes hard to decipher.
3. The Catalyst: Unassigned ownership of SSH identities
This step is often the biggest tipping point. Once a cloud model is adopted, virtual machines and containers are created on a continuous basis. Venafi’s home grown risk assessments have indicated that SSH host keys and even private keys are often copied between machines and their clients. The underlying reason for this is the lack of ownership of these machine identity keys. Specifically, as IT Infrastructure, Operations and Security Teams all have their own priorities, lifecycle ownership of the SSH identities (or keys) literally falls between the cracks and highly trusted keys get lost, making them easy targets for adversaries.
4. The Concealer: Weak audits or assessments
Today, most organizations audit their SSH environment on a regular basis. Best practices have been defined by industry or governmental instances. However, once an audit has passed, there is a false sense of security that can take over—especially if the compliance mandate focuses on human interaction and a full audit of the machine identity lifecycle has been skipped.
5. The Ignition: Malware or human error
The last step that may indicate an active SSH bomb is a stolen SSH credential. This can happen in many forms, such as humans getting tricked by a phishing attack or day-one malware slowly extracting data. Once an SSH key has left the organization, limiting the exposure can become a challenge. And very quickly, a very expensive response may need to be put in place.
In an effort to stay left of the boom, security engineering teams often focus exclusively on this last step. When they do this, they are tempted to forget that their organization is still producing the fuel and catalysts for an SSH bomb. It’s important to protect the entire chain of exposure for SSH keys. To learn more about how you can shift more to the left and detonate a potential SSH time bomb, see our article on six steps for managing SSH keys.