SSH: Practitioner Considerations

1 SSH: Practitioner Considerations

AUDIT 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

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.

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 technology 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

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

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. For exam- forms ship with SSH available (and often enabled) out ple, it is useful to consider integrating these processes, of the box. This means that for these operating system controls and methods into broader risk management platforms SSH is ubiquitous. As such, the protocol is and leveraging resources like internal audit to validate often the primary choice for system administrators as their operation. a management tool for those environments. Moreover, it is also one of the most frequent mechanisms cloud Last, there is the question of executive oversight for the service providers employ to manage Linux instances in use of SSH. As might be imagined, SSH is every bit as an Infrastructure as a Service (IaaS) context. For exam- important a consideration from a security and assurance ple, SSH is supported natively by Amazon Web Services perspective as any other technology area. However, it is (AWS),6 Google Cloud Platform7 and most other service generally invisible from a business perspective. That is, it providers that offer virtual Linux hosts. is a key component in allowing system administrators to perform their duties, but how well it is (or is not) man- As these hosts proliferate—both physical devices as well aged does not often directly impact business processes. as virtual instances on premise and in the cloud—the This can make it challenging to gain executive level inter- complexities associated with key management increase est in ensuring issues are systematically addressed in all nonlinearly. Each SSH server has its own key used for areas of the organization and that SSH is included in risk the purposes of authenticating the device to clients. management activities and audit planning. Moreover, hosts that employ SSH to conduct automated

6 Amazon Web Services, “Connecting to Your Linux Instance Using SSH,” http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

7 Google Cloud Platform, “Connecting to Linux Instances,” https://cloud.google.com/compute/docs/instances/connecting-to-instance

Assurance Considerations From the point of view of the auditor or assessor, these Keys and Key Usage challenges and complexities make validating the use of The first area of consideration for an assessor is the SSH a difficult exercise. The ubiquity and transparency life cycle of the cryptographic keys employed by SSH, of SSH make the surface area for consideration very specifically, the keys that are used by users for authen- large, while the underlying mechanics of operation, tication purposes (user keys) and keys employed by including the technical implementation and the required the SSH server (the sshd daemon, process or service understanding of foundational concepts such as the depending on platform) for the purposes of server cryptographic primitives employed and the protocol authentication. These are not the only keys that are itself, make it specialized and potentially complex. used by the underlying protocol and implementations

There is a subset of core areas that auditors should of that protocol. For example, there are session keys consider, whether they are evaluating SSH usage in associated with symmetric ciphers used to protect the aggregate or a system that may employ SSH as part of data stream itself, password derived keys used for the normative operation. These specific areas bear consid- protection of private key data files (should a password eration regardless of specific usage as they apply to be used to protect that key) and ephemeral keys for the most environments. Beyond this subset, there are, of purposes of session key establishment. While these course, considerations that might result from specific other keys are critical to the operation of SSH and can, usage or requirements. For example, a requirement for in some circumstances, be relevant for auditor exam- validation compliant with US Federal Information Pro- ination, their properties are not such that examination is cessing Standard (FIPS) 140-2, Security Requirements required in a normative assessment. for Cryptographic Modules, in a given organization (e.g., a US federal agency or contractor) would require Note: With both user keys and server keys, the key specific assessment tasks. Some of those tasks might itself is part of an asymmetric key pair: a private include use of a specific set of ciphers or a product key and a public key that are mathematically that has been validated under the auspices of the US related. The properties of these keys are such National Institute of Standards and Technology (NIST) that only the associated key can decrypt data that cryptographic module validation program (CMVP). As have been encrypted by the other key in the pair. such, the following list is only a starting point. Specifical- For example, only the private key can decrypt data ly, from an assurance point of view, practitioners should enciphered under the public key and vice versa. consider the following:

• Keys and key usage For these keys, there are several areas to consider from • Privileged identity an assessment point of view across the entirety of the • Logging key life cycle. That life cycle spans the period from key

• Compliance creation/provisioning, to usage and storage of keys (including online or offline storage, maintenance and The following subsections outline each of these areas in archival), to decommissioning or expiry of keys to the greater detail. eventual destruction of key data. First and foremost, this involves protection of the key data. Not only is it

important that SSH users employ keys (not always can be a way to potentially increase the overall security a given, depending on existing processes), but for profile of administrative account usage. many implementations, that the actual key data are stored in a file located on the host. In a Unix or Linux That said, there are also situations in which the use of environment, this is typically /etc/sshd/ for sshd system SSH for remote administrative access can act to the keys and ~/.ssh/ for ssh user keys. These files should be detriment of privileged account management, logging/ appropriately protected, such as in root owned folders, auditing and appropriate governance of administrative to ensure that unauthorized users cannot gain access access. The default configuration in some situations is to them. While a password-protected private key does to allow a remote root shell (i.e., PermitRootLogin Yes). have intrinsic protection against theft (specifically, the For example, versions of OpenSSH prior to 7 had the password-based key derivation function itself), a key default set to allow remote root logins. file can be corrupted should appropriate protections From an audit point of view, remote root login can not be applied to these files. Likewise, exposure of the be problematic. For example, how would the auditor password-protected private key does potentially enable reliably track the activities of a given root session back a dictionary or other brute force attack that would to the actual user that conducted that activity when all otherwise be more challenging to conduct had the file the auditor knows is that “root” accessed the server via been appropriately protected. SSH at a given point in time? Yes, it would be possible to

Beyond this, there is the question of expiry associated correlate log files and hope that the system from which with user and host keys. Not all authentication methods that individual logged in had the information, or could specifically support expiration on every platform and be tracked down through some other mechanism, but every implementation of SSH. For example, the open this relies on having logging enabled and a mechanism source OpenSSH implementation does not directly to correlate log entries to each other such as a SIEM or support expiration of SSH user keys using the key log aggregation tool. Even if it is possible to associate authentication method. Best practice, for example, the the activities with a given named user account, doing guidelines recommended by NIST Interagency Report so is much more complicated than would be the case if (NISTIR) 7966, recommends that organizations require root logins had been disallowed. Thorough access attes- the expiration of keys.8 Effecting this expiration requires tation should include all types of access to production use of a certificate instead of key authentication. environments. Ignoring SSH keys and focusing solely on other access and credentials represents a control gap. Privileged Identity The use of SSH can, in many cases, be used as a Logging strategy to help enforce appropriate protections for Logging is also an important consideration in an SSH remote administrative (e.g., root) access. Not only does context. In most cases, SSH access is considered use of SSH enable a protected channel to a remote privileged, hence requiring all activities to be logged host (a useful protection mechanism, compared to and auditable. In addition to concerns about tracking a nonprotected channel such as telnet or rsh), but it administrative activity back to an individual user as can also be used as a mechanism to directly disallow outlined previously, it is important to note that sshd has remote root access (i.e., users must log in as a named its own set of logging levels. Specific configuration may user and then either su to a root shell or use a root be required to ensure logging is enabled. execution utility like sudo). Use of these techniques

8 NIST, NISTIR 7966, “Security of Interactive and Automated Access Management Using Secure Shell (SSH),” USA, October 2015, http://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf

Compliance being “what you know” and the key being “what you have”). In practice, though, an auditor may choose to view While, in some cases, the original driver for the use of this argument with suspicion for two reasons. First, the SSH is compliance (e.g., mandates that require encrypted configuration of the client key password parameter is access for remote administrative access), there are also optional, and second, the key file is portable and can be compliance considerations that should be accounted for copied (therefore not necessarily a “what you have” in the in SSH usage. For example, Payment Card Industry Data same way that, say, a one-time password would be). Given Security Standard (PCI DSS) requirement 8.3 requires this, configuring sshd to require two-factor authentication two-factor authentication for administrative access in a manner that passes sufficient muster is a more originating outside the network.9 Given that SSH private complicated endeavor than it might appear on the surface. key access can be configured on the client side to require So, from a compliance point of view, configuration options, a password, some might argue that the authentication parameters and specific usage constitute an area of process in aggregate requires two factors in the case that interest to an assessor. the password is enabled and employed (the password

Practitioner Impact and Suggested Controls There are several areas where specific controls, Usage Procedures configuration options and other techniques can assist Procedures related to usage should be evaluated to a practitioner in ensuring that his/her usage of SSH is ensure that SSH is employed in an appropriate way. robust. Specifically, these areas should be considered There are a few different considerations to evaluate for from a security and audit standpoint: this. An assessor will want to ensure, for example, that • Usage procedures appropriate authentication is required. It is useful to re- call that SSH may support host authentication only. This • Configuration management provides a great deal of flexibility in the situation where • Ownership and accountability an automated process may need to perform an auto-

• Deployment mated task without user intervention (e.g., uploading a file) but may not be appropriate for remote administra- • Provisioning tion. Likewise, this functionality may be appropriate in a • Governance lower-security, low potential risk environment where a more robust authentication process is not required. As The following subsections outline each of these areas in such, the appropriateness of the authentication model greater detail. employed should be evaluated in the context of what the system does and the model by which such access is provided and employed.

9 PCI Security Standards Council, PCI Quick Reference Guide: Understanding the Payment Card Industry and Data Security Standard version 1.2, USA, 2008, https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf

Beyond this, it is likewise important to ensure that in There are also other configuration related considerations situations where SSH is employed for remote administra- to address beyond the question of the cryptography tor access, the procedures for access are appropriately employed. An assessor may wish to consider: documented and defined, and logging is in place • Root login—SSH can be configured in such a way as where required. to disallow direct access to the administrative (root) account and instead require that a specific user log in Actions to Consider first (subsequently using either su or sudo to accom- A practitioner may wish to consider the following plish administrative tasks). controls or review activities to help support this area: • Port forwarding—SSH can either allow or disallow • Perform a periodic review of documented procedures the forwarding of ports. As outlined earlier in this to ensure they are extant and complete, and reflect publication, the forwarding of specific ports can allow the environment accurately. an unsecured protocol such as X11 to occur over a protected channel. It can also enable less desirable • Ensure that organizational policy is comprehensive consequences such as the circumvention of filtering enough to support SSH. For example, ensure that rules, thereby inadvertently allowing exfiltration of the cryptographic key usage policy or other relevant information. This functionality can be disabled as a policies address SSH keys and usage. configuration option. • Align policies and procedures to IT controls to support • Agent forwarding—A helper application called “ssh- continuous compliance. agent” is often used as a convenience mechanism to keep track of a user’s passwords, keys or certificates. Configuration Management Forwarding allows this agent to be used in subsequent There are a few different options to consider when it connections made and can be disabled. comes to how SSH is configured in the field. The first • Chroot—A “jail” file system can sometimes be consideration relates to the ciphers and cryptographic employed in situations where user access is to be primitives employed. SSH supports a number of possible restricted after login. This may be appropriate, algorithms (some stronger than others) for encipher- depending on the type of access required, when a ment, integrity verification and authentication of the user directly interfaces with a shell environment. hosts and (if applicable) the user. It is important that the appropriateness of the algorithms selected be evaluated • Port—This is relevant whether the server employs a just as an assessor would for any other usage involving default or custom TCP listening port. cryptography. Where specific regulatory or other require- • LogLevel—This indicates the amount of debug or log ments need to be met, for example, in an organization information to record. that has a requirement to use only FIPS 140-2-approved cryptographic modules, the organization should take It is appropriate to evaluate these configuration related steps to ensure that SSH implementations are only those issues not only on a per host basis, but also as the that have undergone review (i.e., those on the approved enforcement of a defined configuration in aggregate. list) and are operating in FIPS mode. As such, an assessor may choose to evaluate the mechanisms by which these configurations are defined and documented, and how they are enforced across a larger number of hosts.

Actions to Consider role decentralized. An organization may employ either A practitioner may wish to consider the following an automated approach to these tasks or a manual one. controls or review activities to help support this area: These decisions will likely be made on an organization- specific basis according to what makes the most sense in • Create a hardened configuration that reflects the the context of the organization’s size and usage. That said, goals of the organization. Where possible, ensure one thing that is important regardless of who specifically that configuration scripts or other automated performs these tasks, and how they perform them, is to system provisioning tools employ the robust, ensure that there is an accountable party responsible for hardened configuration. these tasks occurring. When ownership is unassigned or

• Periodically review the configuration to ensure that when responsibility is not clear organizationally, the result SSH client and server software is configured in line can be a lack of appropriate maintenance and upkeep and with the defined, hardened configuration. control activity deficiencies.

• Consider automated tools to technically enforce the Actions to Consider desired configuration or to discover and report upon inappropriate configuration (e.g., legacy versions or A practitioner should consider the following controls or inappropriate cipher use). review activities to help support this area:

• Consider file integrity monitoring tools to validate that • Ensure that ownership and accountability are administrators are alerted to changes in critical files. explicitly assigned.

• Ensure that named parties are aware of their roles Ownership and Accountability and responsibilities. From the point of view of ongoing maintenance and system hygiene, an auditor should consider how the Deployment organization is ensuring that these tasks are performed, Ensuring both an appropriate configuration and appropri- specifically, who in the organization is accountable to ate and secure usage is both integral and challenging in ensure that appropriate action is taken in response to: SSH software deployment. This is, to some degree, made

• Software patches and updates—Updates to the SSH more complex by the fact that a default installation (and, software client and server software are applied (e.g., thereby, a default configuration) is typically provided in response to security issues or other critical patches on any number of platforms where SSH is supported. and alerts). These default configurations can have subtle differenc- es between them. For example, the default SSH server • Key management—Keys are appropriately managed, and client configuration on a fresh Debian install may be expired, revoked, inventoried and documented. different from that supplied with OpenBSD, Solaris, Mint, • Usage monitoring—Administrative and other access OpenVMS, Cygwin or any other distribution, operating is monitored. system installation or other usage. Moreover, in all but the most typical installations, the configuration param- The decision about who is responsible for these activities eters for SSH may already have been modified either by will, of course, vary according to the needs of the administrators (e.g., to accomplish specific tasks like X11 organization. One organization may employ a centralized port forwarding) or by automated installation or deploy- approach whereby these considerations are managed ment scripts such as those used to deploy or configure by the same group(s) owning the accounts provisioning specific application software. process. Another organization may choose to have this

As a consequence, the logistics of deploying a hardened First, having a consistent and defined process for and trustworthy configuration are potentially significant. provisioning is important. This is because user and key An assessor or auditor may wish to consider how robust management, particularly at scale, can become very configuration is ensured—and, more important, pre- complicated, very quickly. The first item to note is that served—throughout the entire ecosystem. For example, any given user could potentially have more than one are there tools in place to accomplish deployment in key. The process to create a key is straightforward, as an automated way? Are there mechanisms such as file anyone who has done so can attest. In fact, there are integrity monitoring or configuration management tools situations where it might be advantageous for a user to flag and alert should an unexpected modification to an to have multiple keys across different machines. The important file (e.g., sshd_config, ssh_config, ssh_known_ mechanics of the SSH login process are transparent hosts) occur? enough that an administrator might even forget having done so after some time has gone by. There are also Actions to Consider multiple mechanisms to distribute SSH keys from machine to machine. These include directly copying the A practitioner may wish to consider the following key data (e.g., using a command like “cat”), using ssh- controls or review activities to help support this area: copy-id or applying any number of other approaches. In • Consider using automated tools during the deploy- a situation where no procedure or accepted process is ment process to ensure security goals such as: defined, meeting specific objectives for management of those keys can become complex and burdensome. • Known good configuration

––Creation of a standard configuration to apply Actions to Consider to automated deployments A practitioner may wish to consider the following ––Enforcement of configuration standard to controls or review activities to help support this area: deployed services • Use an automated key inventory or discovery tools • Appropriate authentication to locate unexpected or rogue keys, or keys that are • Restricting SSH services and allowing otherwise outside appropriate usage. configuration parameters • Use automated key management tools to track ––Setting of strong protocol versions key usage.

––Cipher/algorithm configuration • Establish technical measures for key protection (e.g., hardware security modules [HSMs]). ––Establishing key restrictions and authorizations • Review administrative processes to ensure that SSH Provisioning keys are addressed as part of user and account provisioning. Implement controls as needed to support A related issue to deployment is provisioning of users, these processes and controls. specifically, the generation, storage and potential distribution of cryptographic keys (including the files that contain them), certificates or other information that may be Governance germane to a particular user. While this may sound like Governance considerations are important to the a trivial issue on the surface, there are many potential practitioner. Specifically, it is important that governance issues of which an assessor or auditor should be aware. tasks that apply to other areas of the business and the technical ecosystem apply to SSH usage in equal

measure. This can be accomplished by ensuring that Actions to Consider SSH is accounted for in the risk assessment and A practitioner may wish to consider the following management process, expectations for outcomes controls or review activities to help support this area: are defined and communicated and appropriate compliance goals are met. • Incorporate SSH into risk management processes. Consider conducting a risk assessment of SSH usage As organizations pursue true governance over IT, it is throughout the organization. apparent that compliance attestations are incomplete • Include SSH in audit planning, potentially including without considerations for SSH-based access. Industry the use of technical tools to automate portions of the trends reflect that organizations are assigning gover- audit where possible. nance ownership to board level members to ensure overarching control and oversight. It also supports increased visibility of risk areas and communication of the risks identified.

Conclusion In summary, the use of SSH is ubiquitous. The security However, the information in this guide is only a starting profile of most organizations depends on this critical point. As with any key element of the organization’s service. That said, it is also transparent in how it is used. security posture and risk mitigation, care should be It becomes sublimated into the technical ecosystem taken to ensure that usage is robust, controlled and and thereby can be easy to overlook in terms of the (most important) used with due care, knowledge and in specifics of how it is used within an organization. a manner conformant to organizational policy. As can sometimes be the case with technologies that become Because of this, it is important that practitioners sys- embedded in the fabric of the technical landscape (as tematically address, assess and periodically reevaluate SSH certainly can be), making sure usage is controlled the mechanics of SSH usage in their environments. This and appropriate requires careful consideration to ensure is important from a broad governance point of view and it continues to happen. to the specific technical parameters determining how the tools are employed. This publication has exam- Attesting to the state of access compliance is potential- ined the specific usage considerations for audit, risk, ly incomplete without incorporating SSH keys. Ramifica- security or governance practitioners. It detailed specific tions of poorly managed SSH keys environments may steps practitioners can take to ensure that they are not lead to audit infractions and possibly a security breach. ignoring SSH usage, that they have appropriate controls around it and that they are setting themselves up for ongoing secure usage.

APPENDIX A: Control Selection and Validation This appendix contains a table of controls that prac- which controls make the most sense in light of their titioners may wish to consider for their environments environment, risk tolerances, culture and other organi- to ensure secure initial and ongoing usage and zation-specific factors. Moreover, the assessment steps configuration of SSH. Not every control will fit every listed are only suggestions. The manner that the control circumstance. Practitioners should evaluate carefully is implemented may necessitate differing approaches.

DESCRIPTION/ IMPLEMENTATION CONTROL ASSESSMENT CRITERIA PURPOSE GUIDANCE

Key distribution and Some (though not all) SSH serv- • Examine configuration settings for key hygiene can be ers and clients can employ certif- a sample of SSH server and client challenging at scale. icates as part of the authentica- installations. Integrating existing tion process. Utilize (or deploy) • Observe settings related to authen- SSH PKI PKI services into SSH certificate authorities (CAs) that tication mechanisms required or Integration usage can help allevi- conform to a certificate policy in supported to validate that settings ate those issues in a line with organizational security require (if mandated) certificate vali- large population. requirements. dation and trusted CAs extend only to those explicitly approved for this use.

Ensure that proce- Establish a review process • Obtain and review existing adminis- dures relating to involving appropriate managerial, trative procedures to ensure that they: SSH use exist, are technical and other personnel of • Exist periodically reviewed the policy, procedures, guidance Periodic and are reflective of and standards that support SSH • Are periodically reviewed by Procedure actions performed by use throughout the organization. appropriate personnel Review personnel in the field. Ensure that administrative and • Reflect appropriate use other run books (e.g., in-depth usage manuals) extend to and include SSH.

Address SSH spe- Review existing organizational • Obtain and review organizational cifically in guidance, policy, procedures, guidance policy documentation. procedures or and standards documentation. • Assess SSH usage to ensure that technical standards. Document any areas where SSH usage in the organization is in line Incorporation For example, if there usage, as it exists in practice, is with existing corporate policy. of SSH Into is a published list in conflict with existing policy Policy, of approved cryp- or situations in which existing • Review documented exceptions (if Assessment tographic software, policy is not reflective of SSH any) for areas where usage is not in of SSH SSH should be on it. usage. Update policy documen- line with policy. Ensure that: Usage to Likewise, cryptograph- tation as needed to reflect usage, • Appropriate personnel have That Policy ic key usage policies, document usage exceptions and signed off. key inventories and address areas of policy noncom- other similar guidance pliance in actual usage. • A mitigation plan is in place. should include SSH. • Exception is time-bound for re- review once a given time elapses.

DESCRIPTION/ IMPLEMENTATION CONTROL ASSESSMENT CRITERIA PURPOSE GUIDANCE

Create a hardened Document a configuration base- • Either through review of documen- configuration that line that enforces the behaviors, tation or interview with appropriate reflects the policies settings, ciphers, acceptable administrative personnel, ensure that of the organization. authentication mechanisms, configuration standards exist and Where possible, en- port-forwarding allowances and are reflective of security goals for Creation of sure that configuration other specific settings desired SSH usage. Hardened scripts or other auto- by the organization. Use man- Configuration • Review a sample of SSH server and mated system provi- ual or automated methods to client configuration to ensure they sioning tools employ deploy those settings across the are in line with documented hardened the robust, hardened organization. Periodically validate configuration requirements. configuration. adherence to the settings.

Consider automated Create a known good configura- • Review settings in the automated tools to technically tion target in the automated con- configuration management tool to enforce desired figuration management according validate that they are in line with configuration or to to the hardened SSH server and acceptable hardened configuration discover, and report SSH client configuration settings. standards. upon, inappropriate Utilize the configuration manage- • Review a sample of SSH server and configuration (e.g., ment tool to deploy that configu- Automated client configuration to ensure appro- legacy versions ration and, if the functionality is Configuration priate operation of the configuration or inappropriate provided by the tool, validate that Management management tool. cipher use). configuration on a periodic basis. • Observe tool logs, output or operating parameters to ensure that unauthorized modifications to configuration settings are flagged and reviewed or cannot be effected without authorization.

Consider file integrity Deploy a file integrity monitoring • Observe tool logs, output or operating monitoring tools to tool and/or extend file integrity parameters to ensure that unautho- validate that adminis- monitoring capability to SSH serv- rized modifications to configuration File Integrity trators are alerted to er and client configuration files. settings are flagged. changes in critical files. Monitoring • Interview system administration personnel to ensure that, should changes occur to these files, reviews of those file changes are undertaken.

DESCRIPTION/ IMPLEMENTATION CONTROL ASSESSMENT CRITERIA PURPOSE GUIDANCE

Ensure that ownership Identify and formally assign • Review RACI charts, procedures and accountability responsibility for SSH manage- or other organizational artifacts to are explicitly assigned ment, provisioning, updates and ensure that responsibility for SSH ad- Assignment and named parties are other duties. ministrative, hygiene and other main- of Ownership aware of their roles tenance tasks is formally assigned. and responsibilities. of SSH • Interview named parties to ensure that they are aware of duties and expectations associated with those responsibilities

Consider automated Deploy a key discovery tool or • Observe operation of the key discov- key inventory or dis- ensure that key discovery tools ery tool or service to ensure that SSH Key Inventory covery tools to locate already in use are configured to keys are included in the tool’s scope and Key unexpected or rogue find and flag SSH keys. of operation. Discovery keys, or keys that are otherwise outside appropriate usage.

Consider automated Deploy key management tools • Observe operation of the key key management such as HSMs or other tools management tool(s). tools to track key where applicable and where the Key usage. Consider risk mitigation is commensurate Management technical measures with potential negative impacts. for key protection (e.g., HSMs).

Incorporate SSH into Conduct a risk assessment of • Review the results of the SSH risk risk management SSH usage utilizing a quantitative assessment to ensure it has been processes. Consider or qualitative risk review meth- conducted and is current. SSH Risk conducting a risk odology. Develop an action plan Assessment assessment of SSH based on the results. usage throughout the organization.

Include SSH in audit Ensure that ongoing compliance • Review results of the SSH audit to planning, including and audit sampling methodolo- verify that it has been completed. the potential use of gies incorporate SSH keys in SSH Audit technical tools to au- the population. tomate portions of the audit where possible.

APPENDIX B: Control Crosswalk The suggested controls listed in appendix A can be this material, assumptions about the environment have used to support overall organizational compliance. This been made. As always, these tables are suggestions appendix includes some of the specific requirements only and are intended to be reviewed and adapted to an that could potentially be applicable to these controls organization’s unique needs before being incorporated and that these controls might help support. To create into compliance efforts.

NIST CONTROL HIPAA PCI (SP800-53)

SSH PKI Integration AC-3, SC-17 §164.312(a)(2)(i), §164.312(d)(1) 2.3

Periodic Procedure Review SC-1 3.7, 4.3

Incorporation of SSH Into Policy, As- AC-17 §164.312(a)(2)(iv), 3.6, 12.3 sessment of SSH Usage to §164.312(e)(2)(ii), That Policy §164.312(e)(2)(i)

Creation of Hardened CM-2 §164.312(a)(2)(iii) 3.7, 4.1 Configuration

Automated Configuration CM-1, CM-6 4.1, 6.1 Management

File Integrity Monitoring CM-3, CM-6 11.5

Assignment of Ownership of SSH PS-1 §164.308(a)(2)(i) 2.5, 4.3

Key Inventory and Key Discovery SC-12 3.5, 3.6

Key Management SC-12 3.5, 3.6

SSH Risk Assessment RA-3, RA-6 §164.308(a)(1)(ii)(A) 12.2

SSH Audit CA-2 §164.308(a)(8)

The following table maps COBIT 5 process to the SSH controls.

CONTROL COBIT® 5

APO13 Manage Security SSH PKI Integration BAI10 Manage Configuration DSS05 Manage Security Services

Periodic Procedure Review APO13 Manage Security

EDM02 Ensure Benefits Delivery Incorporation of SSH Into Policy, Assessment of SSH BAI10 Manage Configuration Usage to That Policy DSS05 Manage Security Services

Creation of Hardened Configuration BAI10 Manage Configuration

BAI06 Manage Changes Automated Configuration Management BAI07 Manage Change Acceptance and Transitioning BAI10 Manage Configuration

BAI06 Manage Changes File Integrity Monitoring BAI07 Manage Change Acceptance and Transitioning

APO13 Manage Security Assignment of Ownership of SSH DSS05 Manage Security Services

Key Inventory and Key Discovery APO13 Manage Security

Key Management APO13 Manage Security

SSH Risk Assessment APO12 Manage Risk

MEA01 Monitor, Evaluate and Assess Performance and Conformance SSH Audit MEA02 Monitor, Evaluate and Assess the System of Internal Control

Acknowledgments ISACA would like to recognize:

Lead Developer ISACA Board of Directors Tichaona Zororo CISA, CRISC, CISM, CGEIT, COBIT 5 Ed Moyle Theresa Grafenstine Certified Assessor, CIA, CRMA, EGIT | ISACA, USA CISA, CRISC, CGEIT, CGAP, CGMA, Enterprise Governance of IT (Pty) Ltd, CIA, CISSP, CPA, U.S. House of South Africa, Director Expert Reviewers Representatives, USA, Chair Christos K. Dimitriadis, Ph.D. Ian Gorrie Robert Clyde CISA, CRISC, CISM, Intralot, S.A., CISA, CISM, CCSA, CEH, CISSP, GIAC, CISM, Clyde Consulting LLC, USA, Greece, Past Chair Locked Networks, USA Vice-Chair Robert E Stroud Luciano Johnson Brennan Baybeck CRISC, CGEIT, Forrester Research, Inc., CRISC, CISM, MSc, MFOU, Asyg CISA, CRISC, CISM, CISSP, Oracle USA, Past Chair Informatica, Brazil Corporation, USA, Director Tony Hayes Fouad Khalil Zubin Chagpar CGEIT, AFCHSE, CHE, FACS, FCPA, CISA, SSH Communications Security, CISA, CISM, PMP, Amazon Web FIIA, Queensland Government, Australia, USA Services, UK, Director Past Chair

Cyrus Makalinaw Peter Christiaans Matt Loeb CISA, ARMUS Corporation, USA CISA, CRISC, CISM, PMP, Deloitte CGEIT, FASAE, CAE, ISACA, Consulting LLP, USA, Director USA, Director Dave Newell Loptr LLC, USA Hironori Goto CISA, CRISC, CISM, CGEIT, ABCP, Five-I, Katherine Teitler LLC, Japan, Director MISTI, USA Mike Hughes CISA, CRISC, CGEIT, Haines Watts, UK, Director

Leonard Ong CISA, CRISC, CISM, CGEIT, CPP, CFE, PMP, CIPM, CIPT, CISSP ISSMP-ISSAP, CSSLP, CITBCM, GCIA, GCIH, GSNA, GCFA, Merck & Co., Inc., Singapore, Director

R.V. Raghu CISA, CRISC, Versatilist Consulting India Pvt. Ltd., India, Director

Jo Stewart-Rattray CISA, CRISC, CISM, CGEIT, FACS CP, BRM Holdich, Australia, Director

Ted Wolff CISA, Vanguard, Inc., USA, Director

About ISACA ISACA® (isaca.org) helps professionals around the globe realize the positive potential of technology in an evolving digital world. By offering industry-lead- 3701 Algonquin Road, Suite 1010 ing knowledge, standards, credentialing and education, ISACA enables Rolling Meadows, IL 60008 USA professionals to apply technology in ways that instill confidence, address Phone: +1.847.660.5505 threats, drive innovation and create positive momentum for their organizations. Established in 1969, ISACA is a global association serving more than Fax: +1.847.253.1755 500,000 engaged professionals in 188 countries. ISACA is the creator of Support: support.isaca.org

® the COBIT framework, which helps organizations effectively govern and Web: www.isaca.org manage their information and technology. Through its Cybersecurity Nexus™ (CSX), ISACA helps organizations develop skilled cyber workforces and enables individuals to grow and advance their cyber careers. Provide feedback: www.isaca.org/SSH DISCLAIMER

ISACA has designed and created “SSH: Practitioner Considerations,” (the Participate in the ISACA “Work”) primarily as an educational resource for professionals. ISACA makes Knowledge Center: no claim that use of any of the Work will assure a successful outcome. The www.isaca.org/knowledge-center Work should not be considered inclusive of all proper information, proce- Follow ISACA on Twitter: dures and tests or exclusive of other information, procedures and tests www.twitter.com/ISACANews that are reasonably directed to obtaining the same results. In determining the propriety of any specific information, procedure or test, professionals Join ISACA on LinkedIn: should apply their own professional judgment to the specific circumstances www.linkd.in/ISACAOfficial presented by the particular systems or information technology environment. Like ISACA on Facebook:

As an audit and compliance practitioner, you know better than anyone the ramiﬁcations of a technology “loop-hole” or gap which allows for privileged access to critical systems, especially if that access is not controlled, logged, or able to be easily terminated. This is evident with how SSH keys have been historically used and deployed.

Understanding there are potential compliance and security issues relating to SSH keys is the ﬁrst step in starting a project. A fundamental element to this process is understanding that access control attestations are incomplete unless they include SSH Keys based access:

The next question is to try and address is the scope of SSH key usage and to assess the risks and vulnerabilities resulting from poorly managed SSH keys environments.

To help you get started, we oer enterprises an SSH Key Risk Assessment which allows you to get detailed visibility into the use of SSH keys within your organization. Assessment results provide you with actual SSH key control gaps within your environment(s) plus recommendations on how best to mitigate but yet remain compliant with regulations and standards.

To further assist with your compliance and access needs, we oer organizations our Universal SSH Key Manager solution to manage the entire life-cycle of SSH keys and the access they provide. Lastly, we also oer our CryptoAuditor solution that enables the logging and auditing capabilities of all SSH Keys based activities.

Regardless of industry or type of technology employed in your environment, we are here to help. To learn more about our solutions or to answer any questions, please contact us!

SSH Communications Security www.ssh.com