1 SSH: Practitioner Considerations AUDIT SSH: PRACTITIONER CONSIDERATIONS © 2017 ISACA. All Rights Reserved. 2 SSH: Practitioner Considerations CONTENTS 4 Introduction and Objectives 13 Conclusion 4 What Is SSH? 14 Appendix A: 5 / Security Architecture Control Selection and Validation 6 SSH Background and Usage 17 Appendix B: Control Crosswalk 7 Assurance Considerations 7 / Keys and Key Usage 19 Acknowledgments 8 / Privileged Identity 8 / Logging 9 / Compliance 9 Practitioner Impact and Suggested Controls 9 / Usage Procedures 10 / Actions to Consider 10 / Configuration Management 11 / Actions to Consider 11 / Ownership and Accountability 11 / Actions to Consider 11 / Deployment 12 / Actions to Consider 12 / Provisioning 12 / Actions to Consider 12 / Governance 13 / Actions to Consider © 2017 ISACA. All Rights Reserved. 3 SSH: Practitioner Considerations ABSTRACT Ask any technology practitioner, and they’ll tell you that there are as many unique, completely different technology footprints as there are enterprises themselves. Meaning, each organization is unique in how it employs technology: It is likely to have its own set of operating systems, its own networking infrastructure and support components, its own set of business applications, its own mix of cloud environments, its own footprint of mobile devices, and numerous other organization-specific technology artifacts in play. It’d be akin to a digital “fingerprint” if it didn’t evolve as rapidly as the organization itself does. Given this situation, it can be said (with a high degree of confidence) that very few technology products are used by most – if not all – of the organizations deploying IT solutions. One such technology is Secure Shell (SSH). It is in frequent use – likely on a daily basis - in nearly every organization. However, only rarely is that usage appropriately secured, routinely assessed, documented, and managed in a systematic and risk-aware way. With that in mind, it is important that practitioners are mindful of their enterprise’s SSH usage: Both in terms of how they can ensure its robust security, as well as how their continued usage will ensure that it remains uncompromised. © 2017 ISACA. All Rights Reserved. 4 SSH: Practitioner Considerations Introduction and Objectives Technology practitioners are likely to confirm that there are as many unique technology footprints as there are Note: Capitalization within this publication may enterprises themselves. Each organization is different in appear inconsistent to those not familiar with how it employs technology. Each is likely to have its own SSH usage. Throughout this publication, the set of operating systems, its own networking infrastruc- capitalized “SSH” is used to refer specifically ture and support components, its own set of business to the SSH protocol, while the lowercase “ssh” applications, a unique mix of cloud environments with refers specifically to the SSH client executable as which it engages, a unique footprint of mobile devices employed in command-line syntax. Also, “sshd” and numerous other organization-specific technology refers to the server daemon. artifacts in play. A technology footprint would be akin to a digital “fingerprint” if it didn’t evolve as rapidly as the organization itself. This publication outlines the considerations that tech- nology risk professionals, technology auditors, security Given that this is the case, there are only a few technol- practitioners and technology governance professionals ogies that can (with any degree of confidence) be said should have in mind as they approach the use of SSH to encompass most, if not all, organizations’ needs. technology in their enterprises. It will cover both crit- One such technology is Secure Shell (SSH). It is used ical elements that ensure that SSH usage is secured frequently, potentially daily, in almost every organization and the additive controls that should be considered today. However, only rarely is that usage appropriately to further protect that usage. Moreover, it provides secured, routinely assessed, documented and managed guidance to assess SSH usage including items to in a systematic and risk aware manner. With that in mind, incorporate in the audit plan for SSH technology it is important that practitioners become aware of their evaluation when necessary. own SSH usage: how they can ensure that it is employed in a robust and secure fashion, and how they can assess their own usage to ensure that it remains so. What Is SSH? To begin the discussion of ensuring appropriate and protocol itself is defined in IETF RFC 42532 and is built secured use of SSH, it is important that practitioners around a client-server paradigm, meaning that an SSH understand what SSH is, how it operates and how it is client connects to an SSH server that is in a “listening” typically employed. state over a particular Transfer Control Protocol (TCP) port. While it is possible to tunnel SSH over protocols SSH is, at its core, a cryptographic protocol designed to other than TCP (e.g., User Datagram Protocol [UDP]), provide secure remote communications. The architecture practical usage is almost always TCP because stateful- is defined in the Internet Engineering Task Force (IETF) ness is important to correct processing of the protocol. 1 Request for Comments (RFC) 4251, while the transport The default TCP port used by SSH is port 22, though 1 IETF, Request for Comments 4251, January 2006, https://tools.ietf.org/html/rfc4251 2 IETF, Request for Comments 4253, January 2006, https://tools.ietf.org/html/rfc4253 © 2017 ISACA. All Rights Reserved. 5 SSH: Practitioner Considerations specific usage can override the default and allow • Serpent operation on an arbitrary port. • ARCFOUR Developed as a secure alternative to telnet and rsh/ • IDEA rexec, the most common use case in which SSH is • CAST employed is to allow a remote command shell—for example, the Bourne shell (bash) or the C shell (csh)— Note that, of these, only three key triple-DES in cipher over a network connection. In fact, this is the primary block chaining mode (CBC) is explicitly required; 128-bit purpose for which SSH was originally developed. While AES in CBC mode is recommended. this usage in today’s world is both extremely prevalent and an important component in enabling remote The protocol defines a keyed-hash message authentica- administration of Unix systems and other command- tion code (HMAC) to provide message integrity, utilizing line driven environments, SSH provides capabilities SHA-1 and MD5 as the underlying digest algorithms. 4 beyond this as well. In particular, SSH also allows IETF RFC 6668 adds SHA-2 to the supported digest list. port-forwarding capability. Port-forwarding allows SSH Key agreement is provided via the Diffie-Hellman key to encapsulate and tunnel most stateful or nonstateful exchange protocol and public key/certificate formats protocols between hosts (e.g., the X Window System using DSS (Digital Signature Standard) or RSA (named [X11], Hypertext Transfer Protocol [HTTP], or any from the mathematicians that developed it Rivest, other proprietary or standard protocol). SSH further Shamir and Adelman). implements secure file transfer protocol (SFTP) to allow Authentication for SSH is defined in IETF RFC 4252. secure access, manipulation and transfer of files. This RFC defines three authentication methods:5 Security Architecture • Public key—This is the only required authentication method as defined by the RFC. This method employs A number of cryptographic primitives are employed asymmetric cryptography to provide authentication to ensure that messages exchanged are confidential, (proof of possession of the private key serving as the authenticated and not modified in flight when employing vehicle for such). SSH. IETF RFC 4253 defines the following symmetric ciphers for this purpose:3 • Password—An implementation may optionally support password-based authentication. • 3DES (Triple-DES) • Host-based—An implementation may optionally • Blowfish support verification of the originating host only • Twofish whereby proof of possession of the host private key (by the remote host, though not necessarily the user) • AES is sufficient to allow access. 3 Ibid. 4 IETF, Request for Comments 6668, July 2012, https://www.ietf.org/rfc/rfc6668.txt 5 IETF, Request for Comments 4252, January 2006, https://www.ietf.org/rfc/rfc4252.txt © 2017 ISACA. All Rights Reserved. 6 SSH: Practitioner Considerations SSH Background and Usage As should be evident, SSH was designed with security transactions, such as file transfers, are also likely to have in mind. As one might expect, therefore, the security of their own key(s) for that purpose. Individual users, such the connection between a given user and a given host is as system administrators, also have their own keys. With relatively robust. The security and assurance challenges just these few examples, it is easy to imagine how rapidly start to arise when one looks not at individual connec- the number of keys can proliferate in an environment of tions between clients and services, but instead at the any complexity. overall management of SSH in aggregate. In addition to key management, there is often a question It is worthwhile to consider some of the practical of organizational ownership for SSH keys, specifically, challenges involved with managing SSH usage at scale. who in the organization is responsible for them. Often, First and foremost, there is the challenge associated responsibility for “key hygiene”—tasks like maintaining a with managing and tracking cryptographic keys. Given key inventory, tracking usage of keys and ensuring that that SSH is one of the default mechanisms for remote keys adhere to robust configurations including expiry administration of Unix and Unix-like environments, it and (if needed) revocation—can be a gray area when it should come as no surprise that it is shipped by default comes to who is responsible. This underscores the need on those platforms. In practice, most modern Unix, to integrate controls, processes and other aspects of Linux and Berkeley Software Distribution (BSD) plat- operation into broader control management.