Companies that use SSH on a large scale need to follow overarching SSH protocols to maintain security. Below are 6 important steps outlining how your company can use SSH keys:
1. Establish a Baseline
2. Vulnerability Remediation
3. Regular Rotation of Keys
4. Policy Enforcement
5. Environment Monitoring
6. Securely Configured Systems
Establish a Baseline
Organizations must understand where keys are deployed and used, who has access to them, and what trust relationships have been established within the network. Only once this information is readily available can any organization start to establish a baseline of key usage in the enterprise network. After establishing this baseline, organizations can reduce their risk profile simply by identifying and investigating any deviation from the baseline. They will then be able to easily detect any rogue keys that are inserted into the network.
After an organization has an accurate inventory of all keys used and deployed within the environment, it needs to establish and enforce a security policy. To strengthen the organization’s security posture, system administrators must look at the configuration of their SSH key and remove any vulnerable keys. Specifically, they should follow the NIST recommendation to replace keys with a length of 1024 bits or shorter with 2048-bit keys.23 Weak hashing algorithms, like MD5 that is considered obsolete, should be replaced by stronger algorithms.
Regular Rotation of Keys
Many organizations, having poor key and certificate management processes, generate keys once and then use those keys for many years. Like passwords, SSH keys grant access to sensitive information and enhanced privileges. Keeping the same key for years is like setting a password and then never changing it. Traditional fixed password policies force users to change their passwords every 30, 60, or 90 days, depending on the account type. Organizations should enforce the same policies for SSH keys. Automated policies should rotate keys periodically to proactively prevent attacks if a key is lost or stolen. These measures will significantly reduce the organization’s threat surface.
A central policy should specify how SSH keys are generated and dictate valid key configuration attributes (such as key length, hash algorithm, and more). Above all, the organization needs a plan for enforcing this policy to comply with regulations, best practices, and NIST guidelines. Key generation should be centralized and controlled; users should be granted access rights for generating specific keys. Policies should also control which clients can access a host using an SSH key and the level of access granted to those clients. For example, policies can specify valid IP addresses or hostnames for clients. They should also dictate which commands can be executed on the host. Such policies will help increase the overall security posture of SSH.
After obtaining an accurate inventory of SSH keys and their usages and then taking control of the trust relationships, the organization must maintain that control. It must monitor the environment on an ongoing basis in order to detect changes that could lead to attacks and breaches. Organizations should track applications that leverage SSH for authentication, authorization, and communication to establish a baseline of SSH key usage and a map of valid trust relationships. System administrators can then easily and continuously detect and remediate any anomalous usage of SSH keys.
Securely Configured Systems
Servers only remain secure if the measures that control access to them comply with strong security policies. Therefore, public-private key authentication is recommended for all SSH servers. When the server permits password-based authentication, attackers can more easily gain unauthorized access to the system. On the other hand, private key authentication, or even certificate-based authentication, dramatically increases the expense for an attacker to gain access. In fact, as the examples earlier in this paper demonstrated, these measures make breaches nearly impossible—as long as the private key is properly protected from compromise.