ITL BULLETIN FOR JANUARY 2016 SECURING INTERACTIVE AND AUTOMATED ACCESS MANAGEMENT USING SECURE SHELL (SSH) Murugiah Suppaya, Karen Scarfne, 1 and Larry Feldman, 2 Editrs Cmputer Security Divisin Infrmatin Technlgy Labratry Natinal Institute f Standards and Technlgy U.S. Department f Cmmerce Intrductin ITL has released an imprtant new guidance dcument n access management: NIST Internal Reprt (NISTIR) 7966, Security f Interactive and Autmated Access Management Using Secure Shell (SSH). The SSH prtcl prvides a way t authenticate the identity f users and hsts befre allwing them t execute cmmands n ther hsts in either an interactive r an autmated fashin. This access is necessary fr many purpses, including file transfers, disaster recvery, privileged access management, sftware and patch management, and dynamic clud prvisining. Unfrtunately, the security f SSH key-based access is ften verlked by rganizatins, and misuse r cmprmise f SSH keys culd lead t unauthrized access, ften with high privileges. Therefre, rganizatins need t imprve their management f SSH user keys, including key prvisining, terminatin, and mnitring. This publicatin prvides the basics f SSH interactive and autmated access management, fcusing n explaining hw rganizatins shuld manage their SSH keys. SSH Client Authenticatin Methds SSH client authenticatin refers t the authenticatin f interactive users (administratrs and ther human users) and autmated prcesses perating thrugh SSH clients. Each user r prcess authenticates t a particular accunt n the hst running the SSH server. The SSH prtcl supprts several methds fr client authenticatin, including passwrds, hst-based authenticatin, Kerbers, and public key authenticatin, and ne r mre f these methds can be enabled n each SSH server. NISTIR 7966 discusses each methd in detail, describing the prs and cns f each in terms f security and flexibility. Organizatins shuld carefully evaluate and select the client authenticatin methd r methds that are acceptable fr use, and disable the use f all ther methds. NISTIR 7966 recmmends the use f public key authenticatin fr autmated prcesses. Public key authenticatin uses SSH user keys r certificates, typically user keys, t authenticate a cnnectin. This authenticatin methd ffers a cmbinatin f security features that the ther methds d nt prvide, making it particularly well suited fr autmated prcesses. Examples f these features include cmmand 1 Karen Scarfne is a Guest Researcher frm Scarfne Cybersecurity. 2 Larry Feldman is a Guest Researcher frm G2, Inc. 1
restrictins, which limit what can be dne n the server, and surce restrictins, which limit which Internet Prtcl addresses can establish cnnectins with the server. Public key authenticatin is als recmmended fr interactive users, with smartcard-based slutins being preferred because f their superir security characteristics. The smartcard is used t stre and prtect the user s identity key. An alternative is t keep the identity key in a passwrd-prtected file n the client device. The passwrd is used t decrypt the key, s the strength f the passwrd has a majr impact n the security f the key and the SSH access t ther hsts that it enables. Vulnerabilities in SSH-Based Access SSH is widely used t manage servers, ruters, firewalls, security appliances, and ther devices thrugh accunts with elevated privileges. This makes SSH keys a particularly attractive target fr attackers. Unfrtunately, many rganizatins are nt aware f the vulnerabilities inherent in SSH use if prper prvisining, terminatin, and mnitring prcesses are nt perfrmed, especially when the SSH use includes autmated access. NISTIR 7966 describes seven majr categries f vulnerabilities: Vulnerable SSH implementatin. The SSH client r server implementatin culd have explitable vulnerabilities, including sftware flaws, cnfiguratin weaknesses, and SSH prtcl weaknesses. Imprperly cnfigured access cntrls. The SSH sftware r cmpnents that the SSH sftware integrates with may nt be cnfigured crrectly, which culd allw unauthrized access t privileged accunts, unauthrized elevatin f privileges fr standard accunts, and ther unintended access. Stlen, leaked, derived, and unterminated keys. Anyne wh has acquired access t an SSH identity key, such as by having malware harvest keys frm an rganizatin s laptps r using an ld key that shuld have been terminated, may be able t use that key t gain unauthrized access t ne r mre f an rganizatin s systems. Backdr keys. Organizatins ften mandate use f a privileged access management system fr all privileged access t their servers. Hwever, SSH public key authenticatin can be used t create a backdr. It can be dne by generating a new key pair and adding a new authrized key t an authrized keys file that circumvents the privileged access management system and its mnitring and auditing capabilities. Unintended usage. Users may use SSH identity keys fr unintended purpses, such as tunneling traffic instead f perfrming autmated file transfers. This usage intentinal r unintentinal culd cause activity t be hidden frm netwrk security cntrls. Pivting. Pivting is the prcess f an attacker traversing an rganizatin s systems by repeatedly mving frm ne server t anther, ften using credentials acquired frm servers 2
alng the way. When autmated SSH access is allwed, malware n a client system may be able t steal an SSH key and use it t gain access t a server, where it steals mre keys and uses them t gain access t ther servers. Lack f knwledge and human errrs. SSH management is cmplex, making it mre prne t errrs, and many administratrs have insufficient knwledge f secure SSH cnfiguratin and management practices. A single mistake culd prvide privileged access t unauthrized users and g undetected fr years. Recmmended Practices fr Securing SSH Access Effectively securing SSH access cnsists f defining clear plicies and prcedures, and implementing management, peratinal, and technical security cntrl prcesses supprting these plicies and prcedures. The rganizatin shuld address nt nly the security f already-deplyed SSH systems, privileges, and user keys, but als the security f new SSH systems and user keys. Examples f practices that shuld be addressed in an rganizatin s plicies and prcedures include the fllwing: Only enable SSH server functinality n systems where it is abslutely required; Keep SSH server and client implementatins fully up t date n all systems; Harden all SSH server and client implementatins; Enfrce least privileged access fr all SSH-accessible accunts; Ensure that all SSH user keys (identity and authrized keys) meet minimum requirements, including the fllwing: Use f an apprved algrithm and sufficiently lng key with an acceptable maximum cryptperid (lifetime); Access cntrls fr bth identity and authrized keys; and Specificatin f cmmand and surce restrictins fr authrized keys used fr autmated prcesses. Prvisining and cnfiguring SSH access t an accunt shuld balance the need fr access against the risks and shuld include cnsideratin f the level f access required. Organizatins shuld fllw a cntrlled prvisining and life cycle prcess. The initial phases f this prcess are: the Request phase, where smene submits a frmal request fr establishing SSH access; the Apprval phase, where change cntrl prcesses are used t review and apprve r deny the request; and the Prvisining phase, where the apprved request is implemented by deplying SSH sftware and generating and deplying keys. Once the keys are available fr use, there is an extended Usage Lgging phase, during which all use f the keys is recrded in lgs fr cntinuus mnitring, auditing, and frensic purpses. Peridically, the rganizatin shuld review and reauthrize each instance f SSH key-based access. When a system r applicatin is decmmissined, an applicatin n lnger needs t be administered 3
remtely, r anther change ccurs that eliminates the need fr SSH usage, the crrespnding SSH access shuld be terminated. Remediatin and Autmatin Remediating weaknesses in existing SSH implementatins and keys can be a daunting task. Many rganizatins have thusands f untracked SSH keys granting access acrss a large number f missincritical systems. Existing legacy keys pse a substantial security risk. An inventry f the lcatin f all existing keys and an inventry f trust relatinships invlving these keys shuld be created and evaluated against defined plicies. All issues shuld be crrected ver time thrugh key replacement/rtatin r terminatin, cmmand and surce restrictin implementatin, mandatry identity key authenticatin, and ther means. Remediatin f existing SSH weaknesses and preventin f new SSH weaknesses can bth be significantly imprved by autmating prcesses. Fr example, manually discvering and inventrying all SSH identity and authrized keys, then mapping all the trust relatinships, is practically impssible; autmatin is essentially a requirement. The use f autmatin is als strngly recmmended fr prvisining purpses, where a single request culd affect keys n thusands f hsts. Autmatin fr prvisining eliminates manual steps, reduces privileged administrative access, reduces r eliminates cnfiguratin errrs, and tracks all changes fr use in future audits and in cntinuus mnitring. Cnclusin NISTIR 7966 explains the vulnerabilities assciated with pr management f interactive and autmated SSH access, as well as the ptential impact f misuse r cmprmise f SSH keys used fr client authenticatin. SSH access management is ften ad hc, lacking plicies and requirements, and lacking standardized prcesses and autmated tls. Planning and implementing sund management f SSH keys shuld be addressed in a phased apprach fllwing a clear step-by-step prcess. An example f the phases is identifying needs, designing the slutin, implementing and testing a prttype, deplying the slutin, and managing the slutin. SSH key management shuld be as autmated as pssible. Managing the slutin invlves general security activities, such as maintaining and enfrcing the plicies, testing and applying patches, perfrming cntinuus mnitring t identify peratinal and security issues, and cnducting regular vulnerability assessments. It als invlves several activities particular t SSH access, including perfrming SSH key management duties and adapting the SSH plicies as requirements change (such as switching t a strnger encryptin algrithm r a lnger minimum key size). Organizatins that acquire and use autmated SSH key management prducts shuld be able t significantly decrease their risks related t SSH access with a reasnable amunt f effrt. Withut autmatin, mst rganizatins will struggle t remediate the existing SSH envirnment and t prperly secure new SSH usage. Finally, NISTIR 7966 prvides the fllwing lists t assist rganizatins in implementing SSH security measures: 4
NIST Special Publicatin (SP) 800-53 Revisin 4 security cntrls that are mst pertinent fr securing SSH-based interactive and autmated access management; Selected Cybersecurity Framewrk subcategries with their implicatins t SSH-based interactive and autmated access management; and Criteria fr selecting SSH key management tls. ITL Bulletin Publisher: Elizabeth B. Lennn Infrmatin Technlgy Labratry Natinal Institute f Standards and Technlgy elizabeth.lennn@nist.gv Disclaimer: Any mentin f cmmercial prducts r reference t cmmercial rganizatins is fr infrmatin nly; it des nt imply recmmendatin r endrsement by NIST nr des it imply that the prducts mentined are necessarily the best available fr the purpse. 5