Solutions Manager, Universal SSH Key Manager Roman has been with SSH Communications Security for over 10 years and has held various positions of increasing responsibility in R&D and product management. Currently, Roman is the Solutions Manager for the Universal SSH Key Manager product line and works hand-in-hand with Fortune 500 and Global 2000 IT security teams to ensure access to their critical data centers is secure and compliant. Prior to joining the company, he worked at Microsoft where he designed and developed software to automate scalability testing of the Passport (now Microsoft account) authentication service. Roman holds a Bachelor of Science degree in Computer Science from the Monterrey Institute of Technology and Higher Education in Monterrey, Mexico and a Master of Science degree in Telecommunications Software from Aalto University in Finland.
Breaches pertaining to SSH user keys are insidious. There are two primary reasons behind this. First, most organizations do not have comprehensive inventories of what trusts are valid for SSH user keys and do not carefully differentiate between those dedicated for interactive usage and those for service accounts. Secondly, most organizations do not engage in a continuous monitoring of key based authentication and lack a clear understanding from what source IP addresses SSH user keys may and should authenticate. Based on this alone it is difficult for organizations to ascertain whether a trust is rogue, and are usually chasing the breach rather than pre-empting it. So few security professionals are able to remediate against these type of breaches simply because the existing legacy trusts in the environment must be understood prior to being able to take any action.
Whereas, SSH user keys don’t have expiration dates on them for rotation, security ops and applications owners find themselves in a quagmire of not being able to easily differentiate between what are current and valid trusts and those that are truly obsolete. Hence rotation of keys is something that only helps us if we have a clear understanding of the trusts at hand and these trusts are what we called “locked down” and “remediated”. So what does this mean? Locked down? Remediated?
A locked down trust is a trust where we have the capability to determine if a new trust is being setup in an unauthorized fashion. One way enterprises can take a step towards locking down a trust is by ensuring that authorized keys are not sitting on user home directories and are rather placed to a centrally root owned directory. This restricts the ability of adding or modifying authorized keys on hosts down to system administrators.
A second step that enterprises can take to decrease their risk posture is to add source IP address restrictions and command restrictions on valid trust relationships. In our experience we have seen some enterprises engage in the policy that every key based trust which is accessing a production environment must have a source IP restriction, command restriction and tagging associated to it. This ensures that only valid trusts from a specific set IP addresses are able to access their intended destination and/or limited to only run the required commands.
Assuming that an enterprise does the following:
Has an inventory of their SSH user key based trusts
Is able to differentiate between the ones used by interactive and service accounts
Is monitoring the user keys and their usage on a continuous basis
Has locked down the usage of authorized keys away from users home directories
Has remediated the key material to force from what IP address it may originate from and what commands the session may run
Only when having implemented the above controls can then an enterprise consider key rotation on a periodic basis a valid and beneficial practice.
Without these precursors to key rotation, an enterprise will only be rotating their problem and essentially will be not decreasing their overall risk posture let alone have the capability to determine or prevent an SSH user key breach.