idnits 2.17.1 draft-ylonen-sshkeybcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2013) is 4086 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1231 -- Looks like a reference, but probably isn't: '2' on line 2678 == Unused Reference: 'FIPS199' is defined on line 2715, but no explicit reference was found in the text == Unused Reference: 'FIPS200' is defined on line 2719, but no explicit reference was found in the text == Unused Reference: 'NIST800-53' is defined on line 2723, but no explicit reference was found in the text == Unused Reference: 'KENT' is defined on line 2729, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS199' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS200' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST800-53' -- Possible downref: Non-RFC (?) normative reference: ref. 'KENT' -- Duplicate reference: RFC4251, mentioned in 'RFC4120', was also mentioned in 'RFC3280'. -- Duplicate reference: RFC4251, mentioned in 'RFC4251', was also mentioned in 'RFC4120'. -- Possible downref: Normative reference to a draft: ref. 'SFTP' Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft-ylonen-sshkeybcp-00.txt 3 Network Working Group T. Ylonen 4 Internet-Draft SSH Communications Security 5 Expires: August 22, 2013 G. Kent 6 SecureIT 7 M. Klein 8 Bank of America 9 M. Souppaya 10 NIST 11 February 18, 2013 13 Automated Access Using SSH Keys - Current Recommended Practice 15 Abstract 17 This document presents current recommended practice for configuring, 18 managing, auditing, and associated policies around automated access 19 to information systems, with particular emphasis on SSH user keys as 20 authentication and authorization tokens but also looking into other 21 automated access mechanisms, such as Kerberos. 23 Starting with a review of authentication methods that can be 24 configured for automated access, the document describes the risks 25 involved when the management of automated access and SSH keys is 26 neglected. It scopes the extent of the problem in particular 27 organizations, provides a detailed roadmap for bringing automated 28 access and SSH keys under control, and presents recommendations on 29 continuous monitoring and ongoing management of automated access in 30 information systems. 32 Various remedial actions are presented and mapped to the problems 33 they address and residual risks in the event the recommendations are 34 not implemented. 36 Guidance is also provided on how to organize management of automated 37 access with the objective of reducing the system administration 38 burden and organization operational cost, and on tools for automating 39 the process. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on August 22, 2013. 58 Copyright Notice 60 Copyright (c) 2013 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Purpose and Scope . . . . . . . . . . . . . . . . . . . . 3 77 1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.3. Structure of This Document . . . . . . . . . . . . . . . 4 79 1.4. Words Signifying Level of Requirement . . . . . . . . . . 5 80 1.5. Impact Levels for Information Systems . . . . . . . . . . 5 81 2. The Basics of SSH Protocol and Implementations . . . . . . . 7 82 2.1. The SSH Protocol . . . . . . . . . . . . . . . . . . . . 7 83 2.2. User Authentication in SSH . . . . . . . . . . . . . . . 8 84 2.2.1. Password Authentication . . . . . . . . . . . . . . . 8 85 2.2.2. Public Key Authentication . . . . . . . . . . . . . . 9 86 2.2.3. Kerberos Authentication . . . . . . . . . . . . . . . 9 87 2.2.4. Host-Based Authentication . . . . . . . . . . . . . . 10 88 2.2.5. Comparison of the Authentication Methods . . . . . . 10 89 2.2.6. Dangers of Unverified and Shared Host Keys . . . . . 11 90 2.3. Common Use Cases . . . . . . . . . . . . . . . . . . . . 12 91 2.3.1. Interactive Use . . . . . . . . . . . . . . . . . . . 12 92 2.3.2. Automated Access . . . . . . . . . . . . . . . . . . 13 93 2.3.3. File Transfers . . . . . . . . . . . . . . . . . . . 13 94 2.3.4. Point-to-Point Tunneling . . . . . . . . . . . . . . 14 95 2.3.5. Telecommunications Network Management . . . . . . . . 14 96 2.3.6. Additional Use Cases . . . . . . . . . . . . . . . . 14 97 3. Threats Arising from Poorly Managed Automated Access and SSH 98 Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 3.1. Virus Spread Threat . . . . . . . . . . . . . . . . . . . 15 101 3.2. Unaudited Backdoor Threat . . . . . . . . . . . . . . . . 17 102 3.3. Leaked Keys May Provide Access for Extended Periods . . . 18 103 3.4. Keys Are Never Changed . . . . . . . . . . . . . . . . . 19 104 3.5. Lack of Proper Termination of Access . . . . . . . . . . 20 105 3.6. Use for Unintended Purpose . . . . . . . . . . . . . . . 21 106 3.7. Accidental Data Transfers and Human Errors . . . . . . . 21 107 3.8. Problem Under Radar . . . . . . . . . . . . . . . . . . . 22 108 4. Scoping and Auditing the Threat and SSH Key Management 109 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . 23 110 5. Key Remediation Solution Planning and Deployment . . . . . . 26 111 5.1. Discovering SSH Keys and Trust Relationships . . . . . . 28 112 5.2. Moving Authorized Keys to Protected Locations . . . . . . 32 113 5.3. Monitoring Use of Trust Relationships and Keys . . . . . 32 114 5.4. Removing Trust Relationships That Are No Longer Used . . 34 115 5.5. Associating Trust Relationships with Application and/or 116 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 35 117 5.6. Implementing Approval Process for Setting Up New Trust 118 Relationships . . . . . . . . . . . . . . . . . . . . . . 36 119 5.7. Rotating Existing SSH User Keys . . . . . . . . . . . . . 38 120 5.8. Configuring Command Restrictions on Authorized Keys . . . 39 121 5.9. Configuring IP Address Restrictions on Authorized Keys . 40 122 5.10. Considerations for Software Tools . . . . . . . . . . . . 40 123 6. Continuous Monitoring and Management of SSH Keys and 124 Automated Access . . . . . . . . . . . . . . . . . . . . . . 45 125 6.1. Continuous Monitoring of Automated Access . . . . . . . . 45 126 6.2. Creation of New Trust Relationships . . . . . . . . . . . 48 127 6.3. Removal of Trust Relationships . . . . . . . . . . . . . 48 128 6.4. Periodic Rotation of Trust Relationships . . . . . . . . 49 129 6.5. Facilitating Audits . . . . . . . . . . . . . . . . . . . 49 130 7. Reducing Cost and Improving Security by Automating Trust 131 Relationship Setups . . . . . . . . . . . . . . . . . . . . . 49 132 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 133 9. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 51 134 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 137 1. Introduction 139 1.1. Purpose and Scope 141 This document focuses on risks related to poorly managed automated 142 access in information systems and particularly SSH user keys, and how 143 to reduce the risks. It documents current best practice of managing 144 SSH keys for cost-effectively minimizing the risks, and provides 145 security policy recommendations and auditing guidelines relating to 146 SSH keys and other automated access. It introduces the need for 147 auditing the use of these automated mechanisms. 149 1.2. Audience 151 This document is intended for information security policy makers, 152 auditors, security managers, IT operations managers, system 153 administrators, and others who are responsible for specifying, 154 acquiring, testing, implementing, maintaining, and auditing identity 155 and access management and SSH solutions. Portions of the document 156 may be of interest to technically advanced end users and systems 157 programmers involved with SSH and other automated access 158 technologies. 160 1.3. Structure of This Document 162 Section 1.4 specifies what certain words indicating level of 163 requirement for compliance with this standard mean. 165 Section 1.5 defines impact levels for information systems, including 166 some important definitions relating to information systems having low 167 impact themselves but having automated access to high-impact 168 information systems. 170 Section 2 summarizes the basics of the SSH protocol and 171 implementations, with particular emphasis on authentication methods 172 for automated access and typical use cases for automated access. 174 Section 3 describes threats arising from poorly managed SSH user 175 keys. Most of the threats are also relevant for other kinds of 176 automated access. However, because of the ubiquity of SSH keys and 177 the acuteness of addressing them the discussion focuses on SSH keys. 179 Section 4 introduces simple metrics and questions that are useful in 180 scoping the risks related to SSH user keys and gaining basic 181 understanding of the size of the problem in an organization. The 182 approach is suitable for both IT auditors responsible for verifying 183 compliance with security policies as well as government and other 184 policy makers wanting to measure the overall state of compliance and 185 security across agencies. 187 Section 5 introduces the process for detailed analysis of existing 188 automated trust relationships and risks (with an emphasis on SSH user 189 keys), as well as recommended steps for remediating the risks by 190 relatively simple reconfiguration of existing keys, without 191 necessarily having to install any new software (though use of 192 software tools to assist the process will reduce the amount of manual 193 work significantly, especially in larger environments). This section 194 also discusses the specific threats addressed by each remediation 195 step and risks involved in not implementing a particular step. 197 Section 6 provides recommendations for continuous monitoring and 198 management of SSH keys and other automated trust relationships, as 199 well as for auditing steps to be taken for ensuring that an 200 organization keeps automated access under control after an initial 201 remediation phase. 203 Section 7 presents ways of reducing cost of managing SSH keys and 204 improving security by reducing the number of system administrators 205 who need root access for SSH key setups. 207 Section 8 summarizes security considerations. Most of this document 208 is about security and managing elements of security and access, and 209 this section serves as a conclusion and summary of this document. 211 Section 9 provides a glossary of technical terms used in this 212 document. 214 1.4. Words Signifying Level of Requirement 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in RFC 2119. 220 1.5. Impact Levels for Information Systems 222 The appropriate level of security and effort expended on security 223 often depends on the level of impact from a failure or compromise of 224 an information system. FIPS Publication 199 provides designations 225 for impact levels on organizational information systems and a process 226 for categorizing information systems. This document makes reference 227 to the impact levels described therein (please see FIPS Publication 228 199 for exact definitions, this is just a simplifying summary): 230 Low impact: Unauthorized disclosure, modification, destruction, or 231 disruption of access have limited adverse effect on organizational 232 operations, organizational assets, or individuals. 234 Moderate impact: Unauthorized disclosure, modification, destruction, 235 or disruption of access could be expected to have a serious 236 adverse effect on organizational operations, organizational 237 assets, or individuals. 239 High impact: Unathorized disclosure, modification, destruction, or 240 disruption of access could be expected to have a severe or 241 catastrophic adverse effect on organizational operations, 242 organizational assets, or individuals. 244 FIPS Publication 199 analyzes impact levels separately for 245 confidentiality, integrity, and availablility. For the purposes of 246 the current specification, the impact level of access to an account 247 on an information system is taken to be the highest level of these 248 three principles for the information system, since this specification 249 primarily relates to operating system level access to information 250 systems, and operating system level access can often be used to 251 breach all three objectives simultaneously. Furthermore, experience 252 has shown that once an attacker has operating-system level access to 253 one user account on a computer, in a lot of cases various attack 254 vectors (including bugs in system software and misconfigurations) can 255 be utilized to escalate the access to high-level administrative 256 access. That definitely compromises all three principles of 257 information security. 259 Configured trust relationships for automated access (e.g., using SSH 260 user keys) may permit access from low-impact information systems to 261 high-impact information systems without providing a password or other 262 authentication credential from a user. This is particularly relevant 263 if the authentication credential or authorized key permits access on 264 the high-impact information system without restrictions on the 265 commands that can be executed on the high-impact information system. 266 In this case, access to the low-impact information system implies 267 access to the high-impact information system. The information system 268 owner inherently accepted this risk by allowing a low-impact system 269 access to a high-impact system with providing compensation controls. 271 Therefore, whenever a low-impact information system has a configured 272 trust relationship permitting it to access a high-impact information 273 system without a restriction on the commands that can be executed on 274 the high-impact information system, the low-impact information system 275 MUST be treated as having the impact level of the highest-impact 276 information system that it can access using automated trust 277 relationships. 279 This implies that to avoid treating low-impact information systems as 280 high-impact systems, there must be a well-defined boundary in the IT 281 environment that trust relationships can only cross in the the 282 direction allowing access from higher-impact systems into lower- 283 impact systems, but not vice versa. If such boundary is relied on, 284 it MUST be audited and continuously monitored to enforce its 285 existence. Such a boundary could exist, for example, between 286 development and production systems. 288 It should be noted that several current SSH implementations 289 (including OpenSSH) only permit configuring command restrictions for 290 access based on SSH user keys. It is currently not possible to 291 configure command restrictions for Kerberos-based authentication, 292 host-based authentication, hard-coded passwords, or passwords coming 293 from password vaults, which has implications for the above 294 requirement. 296 Command restrictions are a compensation control that can be leveraged 297 to minimize the exposure to the additional risks exposed to a high- 298 impact system from allowing limited access to the hosted resources 299 from a low-impact system. Command restrictions used for this purpose 300 should be designed to be effective in limiting what actually can be 301 done with the access, and should prevent interactive access and port 302 forwarding. 304 Furthermore, if a trust relationship has a command restriction that 305 limits its use to file transfers but the directories from which files 306 can be read or modified using it have not been restricted, it exposes 307 the server to a more limited risk. The trust relationship may be 308 used to read any file or directory on the server accessible to the 309 user account used for file transfers, also outside the intended 310 directories. It may also be used to write any file writable to the 311 user account; it is fairly common to have configuration files on 312 servers that are inappropriately world-writable. 314 If a trust relation is restricted to file transfers but does not 315 limit the directories that can be accessed, the originating 316 information system SHOULD be considered as having at least the impact 317 level of the highest-impact information system to which it has such 318 access. 320 2. The Basics of SSH Protocol and Implementations 322 SSH (Secure Shell) is a protocol and software tool for logging into a 323 remote machine, executing commands remotely, and transferring files 324 with a remote machine over a computer network. SSH can also be used 325 for implementing a protected tunnel for delivering other services. 327 SSH is very widely used for administering Linux and Unix systems, 328 virtual machines, routers, firewalls, and other network devices. It 329 is also embedded in many leading file transfer solutions, systems 330 management solutions, identity management solutions, and privileged 331 access management solutions. It is widely used for integrating IT 332 systems and automating their operation. 334 2.1. The SSH Protocol 336 The SSH protocol is an IETF standards track protocol and is described 337 in RFC 4251 [RFC4251], RFC 4252 [RFC4252], RFC 4253 [RFC4253], and 338 RFC 4254 [RFC4254]. 340 Many independent commercial and open source implementations are 341 available, including Tectia SSH, OpenSSH, and many others. SSH is 342 available from nearly all platforms, including Linux/Unix, Windows, 343 mainframes, routers, telephone exchanges, mobile devices such as 344 smartphones and tablets, various embedded devices, and many 345 industrial automation systems. 347 In the SSH protocol, an SSH client application initiates a TCP/IP 348 connection over a network to a destination server, authenticates the 349 remote server, and then sends a destination user name and 350 authentication credentials to the server. Server authentication is 351 done using host keys, and its primary purpose is to prevent man-in- 352 the-middle attacks; however server authentication is beyond the scope 353 of this document. 355 2.2. User Authentication in SSH 357 The SSH protocol supports several mechanisms for authenticating 358 users, including passwords, public key authentication, Kerberos, and 359 host-based authentication. 361 2.2.1. Password Authentication 363 There are two kinds of password authentication mechanisms in SSH: 364 basic password authentication and keyboard-interactive 365 authentication. The basic password authentication can only be used 366 for traditional passwords, whereas keyboard-interactive 367 authentication supports an interactive dialogue with a server-side 368 authentication module, and can support various types of challenge- 369 response systems and generally a broad range of authentication 370 mechanisms. 372 Keyboard-interactive authentication can implement any authentication 373 method supported by PAM (Pluggable Authentication Modules) on Unix/ 374 Linux/Mac servers, such as one-time password mechanisms and 375 challenge-response systems. It could, for example, be used to 376 implement SMS-based authentication as a second factor. 378 Password authentication is commonly used for interactive users, but 379 less commonly for automated access (through it is sometimes seen with 380 hard-coded passwords in scripts and management systems, especially 381 for managing routers and file transfers). 383 2.2.2. Public Key Authentication 385 Public key authentication in SSH uses user keys to authenticate/ 386 authorize the connection. The SSH client has an identity key, 387 typically an RSA or DSA private key, and the server must have the 388 corresponding public key configured as an authorized key for the 389 destination user. The private key may be protected by a passphrase, 390 in which case it is encrypted by a key derived from the passphrase 391 (passphrases are common for interactive users but rarely used for 392 automated access; experience has shown that the bulk of SSH user keys 393 in most organizations are for automated access). 395 Different SSH implementations use different file formats for 396 configuring identity keys and authorized keys. 398 Many widely used SSH implementations support configuring restrictions 399 for SSH keys, including a forced command and/or a source restriction. 400 These may be used, e.g., for limiting what can be done on the server 401 using the key (command restrictions), and for limiting the source 402 hosts from which the key can be used (source restrictions). 404 Public key authentication is by far the most frequently used method 405 of configuring automated access using SSH at the time of this 406 writing, and represents best current practice. 408 Identity keys and authorized keys are typically configured in a 409 user's home directory under the ".ssh" or ".ssh2" subdirectory. 411 2.2.3. Kerberos Authentication 413 Many organizations use Kerberos or Active Directory authentication 414 with SSH. (Active Directory uses Kerberos internally.) 416 Use of Kerberos (usually together with LDAP) or Active Directory 417 usually serves several objectives: 419 storing (interactive) user accounts in a centralized directory; 421 sharing (interactive) user accounts on multiple operating systems; 423 specifying access to resources based on Active Directory groups; 424 and 426 eliminating use of host keys. 428 In practice, Kerberos is rarely used for non-interactive accounts. 429 While there are some ways of configuring it, including keytab files, 430 caching tickets, and using service processes to obtain tickets for 431 functional accounts, these approaches rely on having long-term 432 credentials stored on the host or at least accessible to the process 433 on the host that is obtaining tickets. These credentials can be 434 exploited by an attacker largely in the same way as SSH keys, e.g., 435 by using them to obtain a ticket granting ticket (TGT) for the 436 functional account and using the ticket to gain access to other hosts 437 or accounts that the functional account can access. 439 One problem with Kerberos for automated access is that it is 440 frequently used for implementing single sign-on automatically, and 441 getting a Ticket Granting Ticket for one host implies the ability to 442 log into many other hosts (often all hosts) in the domain without 443 having to provide a password again. This means there are implicit 444 trust relationships between the same account on all such hosts. 446 2.2.4. Host-Based Authentication 448 Host-based authentication uses the source host's host key to 449 authenticate the source host and to vouch for the identity of the 450 user on the client side. At the same time, the host key securely 451 identifies the source host. The private host key is only accessible 452 to "root" (special privileged user) on the server, and ability to 453 generate a digital signature by the private host key demonstrates the 454 client process having access to the private host key of the host. 456 Host-based authentication is rarely used and does not permit 457 configuring command restrictions. 459 2.2.5. Comparison of the Authentication Methods 461 All these authentication methods, when used for automated access, 462 fundamentally rely on there being some information that is not 463 accessible to anyone but a legitimate source user or root on the 464 source host. For public key authentication this is demonstrated by 465 reading the private key file; for Kerberos authentication by reading 466 a keytab or ticket; and for host-based authentication by generating a 467 signature including the client-side user name and host name using the 468 client's host key. 470 That said, public key authentication does allow encrypting the 471 identity keys using a passphrase, which provides an extra layer of 472 security. In practice, passphrases are rarely used for non- 473 interactive access due to the complexity of configuring passphrases 474 in scripts and the need to still store the passphrase somewhere. 475 Also, the mechanism in public key authentication is simpler, which 476 reduces the likelihood of programming errors. 478 Security of Kerberos authentication relies on the security of 479 credentials between the host and the KDC as well as on the security 480 of the KDC (Key Distribution Center). In non-interactive use, 481 Kerberos authentication merely demonstrates access to a keytab file 482 or a cached ticket (similar to public key authentication, even though 483 the technical details are very different). KDCs are generally 484 replicated and multiple KDCs usually synchronize information between 485 themselves. It is thus fairly complex and involves a lot of code, 486 which increases risk of programming and configuration errors and 487 mismanagement. In interactive use, key loggers may be used to steal 488 passwords used for obtaining Kerberos tickets (key loggers are common 489 in malware that attacks laptops and desktops). 491 A major advantage of public key authentication over the other methods 492 is that it allows configuring a command restriction. The command 493 restriction can be used for preventing virus spread and other 494 attacks, as described in Section 3. For this reason, public key 495 authentication SHOULD be used as the authentication mechanism for 496 automated access with SSH. 498 In practice, since public key authentication has been by far the 499 easiest to configure and understand, and supports command 500 restrictions, it has become the most widely used and current best 501 practice method for configuring automated access. 503 Use of password authentication (with hard-coded password) for 504 automated access SHOULD NOT be used, because such hard-coded 505 passwords may be obtained by attackers and used for furthering an 506 attack to other systems. Generally it is very hard in practice to 507 enforce proper rotation for hard-coded passwords. Also, even if 508 passwords are stored in a password vault in a way that makes them 509 accesible to a script, an attacker might modify the script to extract 510 the password(s) from the vault for furthering an attack. 512 2.2.6. Dangers of Unverified and Shared Host Keys 514 Many file transfer and systems management applications do not check 515 host keys for hosts that they connect to and authenticate to using 516 passwords. This permits a man-in-the-middle attack to be performed 517 in the network (many tools are available for this and any device 518 connected to a network through which the connection goes can be used 519 for the attack - including, e.g., reprogrammed smart switches). A 520 man-in-the-middle attack can be used by an attacker for obtaining the 521 authentication passwords in such cases. 523 With Kerberos authentication, the Kerberos ticket can also be 524 obtained by a man-in-the-middle attack, and together with IP address 525 spoofing as the destination host be used to obtain a ticket granting 526 ticket for the source user. 528 Man-in-the-middle attacks are a risk regardless of authentication 529 method if hosts keys are not properly verified. The attack permits 530 injection of arbitrary commands into the session, and reading and 531 modifying any transferred files (including injection of bogus file 532 transfers). A successful man-in-the-middle attack from the network 533 is as good as being able to use a trust relation leading to the 534 destination host. 536 Such man-in-the-middle attacks are practical, and are exploited in 537 freely available attack tools, malware, as well as security software 538 from multiple vendors for co-operative auditing purposes. 540 Besides some applications not checking host keys, there are also some 541 large enterprise that share the same host key on thousands of 542 machines (for example, one Fortune 500 company is known to use the 543 same host key on 14000 computers at the time of this writing). If 544 any of the computers is compromised, they all become vulnerable to 545 man-in-the-middle attacks. 547 Therefore, while this document is not really about host keys, the 548 destination host MUST be properly authenticated by the client for all 549 automated access. An exception may be made for the very first 550 connection to the server to simplify system administration. 552 2.3. Common Use Cases 554 2.3.1. Interactive Use 556 SSH has become the standard used by system administrators for 557 configuring and managing Unix and Linux computers, routers, and 558 various other equipment remotely. It is also widely used by software 559 developers, and in some organizations by ordinary end users for 560 running applications remotely (particularly text-based legacy 561 applications). 563 Public key authentication is also sometimes used by system 564 administrators and advanced end users (e.g., developers) for 565 legitimate purposes in interactive use. Sometimes it is used as a 566 single-sign-on mechanism. Sometimes it is used to control access 567 rights among a large pool of system administrators to access, e.g., 568 systems at retail locations through a number of jump accounts. 570 2.3.2. Automated Access 572 SSH is very frequently used for automated access between systems. 573 Such automated access is necessary for cost-efficiently managing 574 large IT environments, for integrating applications, and for cost- 575 effectively provisioning virtual machines in cloud services. 577 Automated access refers to accessing a computer from another computer 578 in an automated fashion. Automated access may be unrestricted, 579 allowing any commands to be executed, or may be limited to specific 580 commands or operations, such as file transfers (perhaps limited to a 581 specific directory). 583 Automated access is most commonly used with functional accounts, 584 system accounts, service accounts, and other non-interactive user 585 accounts (sometimes also called non-user accounts; they all mean more 586 or less the same with some local variation from organization to 587 organization). Such accounts are used by operating systems, 588 middleware, databases, and applications for running processes and 589 allowing automated system components to communicate with each other. 590 System or service accounts are likely to have sensitive levels of 591 access to system resources and are subject to compliance 592 requirements. SSH is very frequently used for automated access 593 between such accounts. 595 Automated access using SSH is common also in Windows and mainframe 596 environments, especially for file transfer applications. There are 597 also various native mechanisms on Windows that can be used for 598 automated access, but such mechanisms are beyond the scope of this 599 document. 601 Automated access has been largely ignored in Identity and Access 602 Management. It is illustrative that in a large international bank 603 with about 100,000 employees more than 1,5 million automated trust 604 relationships were found. There were about 15 times more entry 605 points to production systems based on automated access than there 606 were traditional user accounts. It has been found that many 607 organizations have many more entry points for automated access than 608 they have interactive users. It is clear that such entry points 609 cannot be ignored. 611 Most trust relationships for automated access today are configured 612 using SSH user keys. 614 2.3.3. File Transfers 616 SSH is frequently used as a file transfer tool in itself, using the 617 "scp" and "sftp" tools. The SFTP [SFTP] protocol is gaining 618 popularity in commercial and open source file transfer products, and 619 a substantial fraction of the world's file transfers now use the SFTP 620 protocol. 622 Automated file transfers using SSH typically use public key 623 authentication or hard-coded passwords. It is very common that 624 access on the server is not in any way restricted to file transfers, 625 and the authentication credentials could also be used for other 626 purposes, including running arbitrary commands. Thus, the internal 627 databases of file transfer applications (including scheduling 628 applications) often contain access credentials for production 629 servers. 631 SFTP file transfers are increasingly used between organizations using 632 automated trust relationships that cross organizational boundaries. 633 It is extremely important to control what can be done on the server 634 using such trust relationships! 636 2.3.4. Point-to-Point Tunneling 638 SSH is frequently used for point-to-point tunneling for simplifying 639 PCI DSS compliance. This usage case is usually fully automated, and 640 typically uses public key authentication. 642 2.3.5. Telecommunications Network Management 644 SSH is used massively for managing telecommunications networks and 645 Internet infrastructure. Many if not most core routers in the 646 Internet are configured using SSH. Many operators configure also 647 edge routers and even customer premises routers and xDSL equipment 648 using SSH. Lots of telecommunications equipment for LTE (Long Term 649 Extension) and other telecommunications technologies also relies on 650 SSH for configuration. 652 Both public key authentication and passwords are used for 653 authentication in telecommunications networks. Often, the 654 authentication credentials (e.g., device passwords) are stored in one 655 or more management system databases. Often, such management systems 656 are also connected to office, customer service, and retail partner 657 systems for provisioning access in real time and diagnosing problems. 659 2.3.6. Additional Use Cases 661 SSH with automated access is also widely used for the following and 662 many other purposes: 664 systems management tools that automatically configure and monitor 665 various systems; 666 logging into end hosts from privileged access management systems; 668 configuration and vulnerability management systems; 670 provisioning user accounts in identity management systems; 672 various backup tools; 674 disaster recovery systems and their control; 676 emergency response systems; 678 incident response systems; 680 license audit tools; 682 various IT audit tools; 684 various tools for executing scripts on multiple servers; and 686 IPMI and other BIOS-level management interfaces. 688 3. Threats Arising from Poorly Managed Automated Access and SSH Keys 690 This section outlines some of the threats that have been identified 691 with poorly managed SSH keys. The guidelines and recommendations of 692 this document are intended to address these while minimizing the 693 administrative burden from managing the keys. 695 Several of the problems are present with many technologies for 696 automated access. The issues must be addressed regardless of 697 technology. 699 3.1. Virus Spread Threat 701 A cyber weapon or virus can be engineered to use SSH keys to spread 702 to nearly all servers within an organization once it has penetrated 703 one server. This ruins layered defense, and experience has shown 704 that viruses frequently manage to penetrate individual servers in an 705 organization. A cyber weapon would likely use multiple attack 706 vectors to penetrate an organization, and could use SSH keys (or 707 other trust relationships such as Kerberos) to spread throughout the 708 organization's server infrastructure in minutes after penetrating the 709 first server. 711 With this attack, a virus scans the system for all accessible SSH 712 private keys (identity keys), and tries to log into other servers 713 using these keys. Once in an account, the virus may try to escalate 714 privileges using "sudo" or vulnerabilities it identifies with the 715 system. Once root or "Administrator", the virus can read private 716 keys from all user accounts on the system. 718 The virus can scan the local network for SSH servers and try each key 719 with each server in turn. It may also first scan all scripts on the 720 host (e.g., cron jobs and daily scripts), and extract a set of hosts 721 to try first. 723 The Morris worm in 1988 utilized automated trust relationships for 724 automated access to spread in a similar manner (at that time based on 725 ".rhosts" authentication). This attack vector can be very powerful, 726 and its importance is increasing as systems management becomes more 727 automated. More broadly, a recent IBM X-Force study found most 728 attacks against Unix/Linux servers utilize SSH. Many computer 729 forensics experts are aware of cases were SSH keys have been used to 730 spread an attack from one server to another, and several high profile 731 incidents in the last year have used SSH keys as an attack vector. 733 Experience has shown that most large organizations have on the 734 average 3 to 100+ SSH keys configured granting access to each Unix/ 735 Linux server. Some keys grant high-level administrative access or 736 access to sensitive accounts, such as those storing database files or 737 critical software. The mesh of automated access relationships is so 738 dense in many cases that it is likely that an attack can spread to 739 nearly all servers in an organization after penetrating the first few 740 servers, especially if other attack vectors are used to escalate 741 privileges. 743 Implementing SSH keys as an attack vector in a virus is quite easy, 744 requiring only a few hundred lines of code. Once inside a server, a 745 virus may open a backdoor, steal, alter, or corrupt data, subvert 746 encryption systems or databases, or outright destroy the server. 748 In the worst case, a virus or cyber weapon using multiple attack 749 vectors could spread globally, Internet-wide, enterprise-wide in a 750 matter of minutes. Combined with destruction technologies it could 751 wipe out on-line data, hot/warm stand-by disaster recovery systems, 752 and backups accessible via tape robots and render most servers in 753 enterprises inoperable by wiping their operating systems, storage 754 (including network drives), and reprogramming flash memories, device 755 firmware, and configuration memories. 757 The worst case could mean life with no functioning banks, retail 758 chains unable to process payments or supply inventory, logistics 759 companies unable to operate effectively, most government agencies 760 down, gas stations without gas with refineries having shut down and 761 logistics being very inefficient, no or limited telecommunications, 762 and significant parts of power generation and distribution networks 763 down, for weeks, months, or even years. 765 Of course, SSH keys would likely only play a small part in such an 766 attack, but poorly managed automated access removes much of the 767 defense in depth that is critical in limiting attacks, and thus can 768 vastly expand the impact of such an attack. 770 The virus spread threat can be reduced by combining several 771 approaches: 773 Mandating forced command restrictions for as many trust 774 relationships as possible. 776 Removing trust relationships that are no longer needed. 778 Minimizing the number of trust relationships leading to root 779 accounts (directly or indirectly). 781 Minimizing implicit trust relationships arising from privilege 782 escalation (e.g., "sudo"), single-sign-on (e.g., Kerberos), and 783 host equivalence. 785 3.2. Unaudited Backdoor Threat 787 Many large organizations mandate that all provileged access to their 788 servers take place through a privileged access management system that 789 frequently also records privileged access. However, widely used 790 privileged access management solutions are based on a gateway host 791 that an administrator logs into, and then logs into the end server. 792 Key-based access (and other automated trust relationships) can be 793 used for creating backdoors that bypasses such privileged access 794 management systems. 796 System administrators regularly gain access to various accounts in 797 the course of legitimate administration work. An administrator may 798 add a new authorized key to an account with a single command (e.g., 799 "echo ...keydata... >>~/.ssh/authorized_keys"). As of this writing, 800 most organizations never audit authorized keys for their user 801 accounts, and thus the added key may remain unnoticed for years. 802 Such a key can then be used to log into the account using any SSH 803 client, bypassing the privileged access management. It thus provides 804 a relatively permanent unaudited backdoor. 806 Key-based backdoors can also circumvent password vaults and systems 807 that change root (or other privileged account) passwords regularly. 809 Experience has shown that many organizations have no control or 810 tracking of trust relationships for automated access. Any system 811 administrator can create and install a user key pair as needed 812 without any reporting, logging, or authorization. Needless to say, 813 such practice undermines traditional controls for privileges access. 815 The unaudited backdoor threat can be reduced by the following: 817 Prevent non-root/non-Administrator users from granting automated 818 access to accounts without proper approval. For example, move all 819 authorized keys files to root-owned directories that are not 820 writable by normal users. 822 Continously monitor the environment to detect unauthorized trust 823 relationships configured by someone having root access. 825 Require proper explanation and valid purpose for the existence of 826 every trust relationship and remove any unused trust 827 relationships. 829 Use privileged access management systems that capture SSH and 830 other protocols using automated access on the network level or at 831 the server. Enforce privileged access management also for 832 connections using automated trust relationships. 834 3.3. Leaked Keys May Provide Access for Extended Periods 836 At the time of this writing, most large enterprises, government 837 agencies, and healthcare providers do not track which SSH keys their 838 users, administrators, backup operators, and cleaners may have had 839 access to and copied over the years, and never change their SSH keys. 841 This means that anyone who may have obtained a copy of a key (e.g., 842 by copying it from a host, accessing a backup, or having acquired 843 some decommissioned equipment that was not securely wiped) may gain 844 access to production servers in the organization. 846 Identity keys can easily be taken out from an organization on a 847 single piece of paper, or by taking a photograph of a screen using a 848 cellphone. 850 The problems created by leaked keys can be reduced by: 852 Rotating all keys regularly. 854 Configuring source restrictions for authorized keys, making it 855 more difficult to exploit copied identity keys. 857 Using certificate-based authentication, which can provide 858 revocation and expiration, but is cumbersome to manage (and still 859 does not protect from some of the other threats). 861 Using Kerberos autentication, which allows terminating access to 862 the account; however, Kerberos authentication does not in itself 863 prevent leaking keys that have not been changed to be used. 865 No audit or discovery process can ever guarantee to find all copies 866 of identity keys, as they are small files that could be hidden 867 anywhere, and there could be copies on laptops, tablets, USB sticks, 868 offline, and even on paper (they are small enough to be typed in). 869 Even if source restrictions are configured for authorized keys, an 870 attacker could later copy the identity key to one of the allowed 871 hosts (possibly to a user account that is not permitted). Still, 872 source restrictions can reduce the potential for abuse of leaked 873 identity keys. 875 Rotating all keys regularly is the primary guarantee of eventual 876 termination of access using copied keys. 878 Using Kerberos for automated access is sometimes proposed as a 879 solution. However, it comes with several problems; with Kerberos, 880 some kind of long-term authentication token is still stored on the 881 host (e.g., a credential or cached long-term ticket in a keytab 882 file). A ticket or credential in a keytab file is no more secure 883 than a private key in a file; either must be readable to the user 884 account using them and either is readable for root. 886 3.4. Keys Are Never Changed 888 Most security policies and regulations mandate that all passwords 889 must be changed regularly, e.g., every three months. Some security 890 standards mandate that encryption keys must also be changed 891 regularly. 893 However, very few security policies at this time make it explicit 894 that authentication/authorization keys should also be regularly 895 changed. In a sense, authentication keys are even more critical than 896 encryption keys, because once access to a user account has been 897 gained, it is generally possible to access and modify any data for 898 that user account - including reading and modifying memory of 899 processes running under that user account and/or modifying any 900 executable programs owned by that user account, thus subverting 901 encryption systems and other critical applications. 903 Most environments at the time of this writing do not use source 904 restrictions on authorized keys. Therefore, a leaked key may be used 905 from any computer or network within the organization (unless limited 906 by internal firewalls). 908 The problem of keys never being changes can be addressed by: 910 Rotating all keys (and other authentication credentials) 911 regularly, especially those used for automated access. 913 Configuring source restrictions or authorized keys (this somewhat 914 reduces the risk without really addressing the issue). 916 Besides rotating keys at regular intervals to avoid their leakage and 917 to limit the duration of the exploitation window should they leak, 918 this also applies to credentials for used for obtaining actual 919 authentication credentials; for example, it is not enough to 920 periodically obtain a new Kerberos ticket - one must also regularly 921 change the authentication credentials used for obtaining an initial 922 ticket. It is also not enough to issue a new certificate for the 923 same private key - the private key must also be replaced by a new 924 generated private key. 926 3.5. Lack of Proper Termination of Access 928 At the time of this writing, most organizations do not track what 929 each key is used for. Most organizations do not systematically 930 remove keys when they are no longer needed, because they don't know 931 what application each key is related to, and they don't know what 932 might break if they remove a key. Removing a key that is needed 933 could break critical production systems, and so system administrators 934 generally don't do it and auditor's haven't been auditing them. 936 Many organizations have used manual spreadsheets for tracking key 937 usage. However, experience has shown that such spreadsheets are 938 frequently out of date and inaccurate, have not been maintained 939 throughout the organization. Many organizations have no monitoring 940 of automated access whatsoever. 942 Practically no organizations track which automated credentials each 943 system administrator may have had access to. An administrator may 944 have copied any such access credentials, and may continue to have 945 access through such credentials even after termination of his/her 946 normal user account. If keys are never changed, such access can 947 continue for years after termination of employment. 949 Proper termination of access can be ensured by: 951 Preventing creation of backdoors. 953 Regularly rotating keys (ensures termination of access by copied 954 keys latest at next key change). 956 Optionally triggering immediate key rotation for private keys on 957 accounts accessible by the person whose access is being 958 terminated. 960 3.6. Use for Unintended Purpose 962 Holes are commonly made in firewalls for file transfer purposes. 963 When the file transfer is using SSH (or SFTP), it is important that a 964 forced command be used on the server to ensure that the hole in the 965 firewall cannot be used for other purposes, such as executing shell 966 commands on the server. 968 Another related use case is employees creating their own backdoors 969 into the enterprise to circumvent corporate policies against 970 uncontrolled remote access by opening an SSH connection from the 971 office to their home machine with a port forwarding from the home 972 machine back to the office machine. Such backdoors may provide 973 hackers an entry point into the company intranet, especially if the 974 home machine is compromised and the user's password obtained using, 975 e.g., key logger malware. 977 Various commercial products are also available for auditing SSH 978 connections at a firewall to enforce that such holes are not used for 979 unintended purposes regardless of server configuration. 981 Various SSH implementations also permit port forwarding even when 982 forced commands are used. Therefore, a trust relationship that is 983 configured for file transfer only may actually be used to obtain a 984 connection to any port at any host on the internal network (or 985 external network, for hiding the source of an attack). 987 The threat of uninteded use can be minimized by: 989 Allowing SSH/SFTP through a firewall only when required and 990 restricting sources and destinations to fewest systems required. 992 Configuring forced commands for authorized keys used by external 993 parties. 995 Implementing tools to audit SSH connections at the firewall and 996 monitoring use to ensure that access was not misused. 998 3.7. Accidental Data Transfers and Human Errors 999 Not all risks associated with unmanaged automated access arise from 1000 malicious behavior. If there is automated access from non-production 1001 systems to production systems, data may accidentially be copied from 1002 non-production systems into production systems, where the incorrect 1003 data may cause substantial loss of money. This actually happened at 1004 a major bank and was one of the triggers behind their key remediation 1005 project. 1007 People are also known to make human errors when manually setting up 1008 new trust relationships. For example, it is fairly easy for a 1009 security administrator to accidentally copy an authorized key to the 1010 root account on a host instead of some other account that was 1011 intended. Such errors can go undetected for years. 1013 It is also known that some key setups involve thousands of hosts. It 1014 is easy to miss one or more hosts when copying an authorized key to 1015 so many hosts manually. Debugging such errors can be very time 1016 consuming. Also, when manually fixing such problems, security 1017 administrators are likely to just copy the missing keys to the proper 1018 accounts, without, for example, checking whether they have 1019 accidentally been copied to the root account. 1021 3.8. Problem Under Radar 1023 The SSH key management problem has been recognized in various circles 1024 for some time. The scope of the problem, and its relation to 1025 automated access overall, however, has not been widely understood. 1027 The problems have remained under the radar because they are deeply 1028 technical and obscure, in the domain of system administrators. Each 1029 system administrator typically only sees a small corner of the IT 1030 environment, and does not have a full picture. Administrators and 1031 their managers are often so busy that while they may recognize that 1032 there is a problem, they simply have not had time to analyze the 1033 scope or possible implications of the problem. There have also been 1034 no guidelines or training materials on how to address it. 1036 Most IT auditors do not have SSH key management or automated access 1037 more generally on their checklist, yet it is central to identity and 1038 access governance given the prevalence of automated access entry 1039 points to systems. 1041 SSH keys, or control of credentials for automated access more 1042 generally, has not been sufficiently highlighted in implementation 1043 and auditing guidelines for FFIEC, SOX, PCI, FISMA, HIPAA, NERC, or 1044 COBIT. Even many CISOs are only vaguely aware of the problem, and 1045 many CIOs and IT risk management professionals have never heard of 1046 it. 1048 Training, books, and systems in the identity and access management 1049 space have largely only dealt with actual human users and control of 1050 interactive access by people. Automated access by machines has been 1051 largely ignored, despite many organizations now having many times 1052 more credentials for automated access to their systems than they have 1053 interactive accounts. 1055 Yet, at the same time, poorly managed SSH keys represent an 1056 existential risk for many major banks and enterprises and a systemic 1057 risk for the banking system and developed countries as a whole. 1059 To get addressed, the problem needs to be brought into the attention 1060 of IT security auditors, IT operations managers, security architects, 1061 CISOs, and IT risk management professionals. It must be addressed in 1062 security regulations, guidelines, standards, and internal security 1063 policies. A lot of education and training will be needed. 1065 4. Scoping and Auditing the Threat and SSH Key Management Situation 1067 Addressing threats related to automated access and SSH keys begins 1068 with understanding the extent to which automated access and SSH keys 1069 are used in an organization, understanding how they are managed, and 1070 identifying areas likely to require further attention. 1072 SSH key management is generally relevant for organizations where at 1073 least one of the following is true (the list is not exhaustive, and 1074 other automated access technologies affect other organizations): 1076 significant number of Unix or Linux systems; 1078 significant use of SSH or SFTP on Windows or Mainframe; 1080 virtualization or cloud services that are internally managed using 1081 SSH (possibly inside automated scripts/tools/frameworks); 1083 web server farms that are managed over SSH; 1085 network devices (e.g., routers, switches, xDSL models, firewalls) 1086 configured and managed using SSH and/or automated management 1087 systems; 1089 significant number of automated file transfers using SFTP; 1091 password management or privileged access management tools using 1092 SSH to connect to end servers; or 1094 systems management tools using SSH to communicate with managed 1095 systems. 1097 Many organizations have uncontrolled trust relationships for 1098 automated access between their development and test environments 1099 (often thousands of hosts) and their production servers. Often test 1100 and development systems are threated as low-impact systems, yet they 1101 may be able to access production systems without interactive 1102 authentication, or may be used to product code and software 1103 distributions that will be copied to production systems for 1104 execution. 1106 Results of the scoping phase help estimate risk exposure and 1107 compliance with mandatory regulations, and help evaluate whether a 1108 more detailed discovery and remediation project is warranted. 1110 Certain types of relatively easily obtainable information are useful 1111 in understanding the scope of the problem in an organization. The 1112 information may easily be obtained as part of an audit or regular 1113 review. 1115 The following metrics generally give insight into whether an 1116 organization is affected by the issue: 1118 total number of authorized keys in the environment; 1120 total number of authorized keys in the environment that grant 1121 access to a root account (any account with user id 0); 1123 total number of authorized keys in the environment that grant 1124 access to a system account or service account; 1126 total number of authorized keys without a forced command 1127 ("command" option in OpenSSH) (relates to virus spread risk); and 1129 total number of non-root service accounts or system accounts where 1130 a system administrator logging into the account can add new 1131 authorized keys for the account. 1133 There are also a number of scoping questions that where the answers 1134 can give insight into the severity of the problem: 1136 Does installing a new authorized key require approval from a 1137 second person 1) for keys granting root access 2) for keys 1138 granting access to non-root service accounts or system accounts 3) 1139 for keys granting access to interactive user accounts? How such 1140 approvals enforced? (Rationale: Is there any control in place? 1141 Might ask separately for high-impact, moderate-impact, and low- 1142 impact systems) 1143 Are non-root users technically prevented from installing new 1144 authorized keys, e.g., by moving the authorized keys files to 1145 root-owned locations? Has this been verified to be the case 1) on 1146 all high-risk systems 2) on all moderate-impact systems? 1147 (Rationale: this is basically asking "Can users leave key-based 1148 backdoors?" - and a policy without enforcement is not effective) 1150 Is a continuous monitoring process in place for detecting 1151 authorized keys that are added for a user account without proper 1152 authorization 1) for root accounts 2) for service and system 1153 accounts 3) to interactive user accounts? (Rationale: root users 1154 cannot be technically prevented from adding new keys to any 1155 account, and thus continuous monitoring is needed to detect such 1156 violations) 1158 Is a policy in place for rotating SSH user keys? Has it been 1159 verified that all user keys have actually been rotated in 1160 accordance with the policy (and the private keys actually 1161 changed)? (Rationale: without rotation, copied keys remain valid 1162 forever, and some people have been known to recertify or reuse the 1163 same private key because it may pass audit and saves trouble, 1164 without actually addressing the problem) 1166 Has the reason of existence for every authorized key, including 1167 the application or business process it relates to, been documented 1168 1) on high-impact systems 2) on moderate-impact systems 3) on low- 1169 impact systems? (Rationale: access to sensitive data should be 1170 controlled. Authorized keys provide access to systems and data. 1171 Thus their existence should be justified and controlled. 1172 Furthermore, without proper documentation it is difficult to know 1173 when to remove a key, such as when an application is 1174 decommissioned or a business process changed.) 1176 Are SSH keys systematically removed when they are no longer 1177 needed? (Rationale: very few organizations currently ever remove 1178 SSH keys, and copied keys may continue to provide access for many 1179 years to anyone who has had access to the systems. Furthermore, 1180 the more keys there are, the higher the virus spread risk.) 1182 Are SFTP file transfers used between the organization and other 1183 organization? Do all authorized keys used for external file 1184 transfers have a forced command restriction? (Rationale: such 1185 keys involve high risk of attack spread/virus spread between 1186 organizations) 1188 Are routers, telecom equipment, or other network devices in the 1189 organization managed using SSH (perhaps using a management system 1190 tool)? How are access credentials for routers managed? 1192 The scoping information can be obtained relatively easily and scoping 1193 questions can be answered without having to install new software on 1194 servers. However, the answers are only approximate, and experience 1195 has shown that many organizations do not have any single person with 1196 a clear answer to the questions and that sometimes management 1197 perceptions do not match reality. Therefore the answers are best 1198 obtained and analyzed as part of a regular audit that actually 1199 verifies the answers, at least by representative sampling. 1201 In Unix/Linux environments, it is often possible to get a rough 1202 understanding of the scope of the problem by counting authorized keys 1203 in authorized keys files for every user and answering the above 1204 questions based on readily available information. 1206 A very quick way to estimate the total number of authorized keys on 1207 every Unix/Linux server is to use something like the following (as 1208 root) on all hosts and summing up the results: "find / -name 1209 authorized_keys -print | xargs cat | wc -l". 1211 If the outputs of the above are stored in a file, one per line, they 1212 can be easily summed by: "awk '{sum += $1;} END {printf("Total 1213 authorized keys: %d\n", sum);}' 2022 security risk). 2024 Some software tools may support a combination or mix of these 2025 approaches. 2027 Will it run as root on managed hosts, or can it use a non-root 2028 account and "sudo" (or equivalent) to perform limited operations 2029 as root? 2030 Using non-root account and "sudo" allows the operations 2031 performed on hosts to be controlled and monitored, and reduces 2032 risk from management system compromise. 2034 Is the solution able to retry discovery, key setups, etc. on 2035 hosts that are down or unreachable at the time of the initial 2036 attempt? How does the solution cope with poor network 2037 connectivity? 2039 Does the solution support limiting updates on hosts or groups of 2040 hosts to maintenance windows for those hosts (e.g., based on host, 2041 host group, application, or business process)? If there are lock- 2042 down periods in the organization when changes are not allowed 2043 (e.g., before Christmas), is this supported by the solution? 2045 Does it support user accounts stored in LDAP or Active Directory? 2046 How does it prevent crashing LDAP or Active Directory servers by 2047 reading directory contents from all servers simultaneously? 2049 Can it discover keys from directories that are not readable by 2050 root (e.g., NFS directories using the "root_squash" option)? 2052 Does it work with SELinux, if such support is needed? 2054 Will key management be needed for devices other than general- 2055 purpose computers (sometimes called non-OS devices), such as 2056 routers, BIOS management ports - and are such devices supported by 2057 the solution? 2059 Will the solution copy private keys? Various security standards 2060 forbid making multiple copies of cryptographic keys. 2062 How can the solution save operational costs in SSH user key 2063 management in the organization? Have existing user key management 2064 costs been estimated on an annual level? 2066 Has the solution actually been used to manage SSH user keys in a 2067 sufficiently large production environment? What references are 2068 available for the SSH user key management functionality? 2070 What kind of support/assistance can the vendor provide for 2071 scoping, planning, implementing, and operating an SSH key 2072 remediation project and ongoing operation of automated access? 2074 What is the vendor's roadmap and how does it tie to the overall IT 2075 strategy of the enterprise (SSH environment, broader management of 2076 automated access, other identity and access management systems, 2077 and auditing of privileged access)? 2079 6. Continuous Monitoring and Management of SSH Keys and Automated 2080 Access 2082 Ongoing operations for management of automated access include: 2084 continuously monitoring the environment to detect unauthorized 2085 changes to trust relationships used for automated access and other 2086 suspicious activity; 2088 creating new trust relationships (with proper approvals and 2089 restrictions); 2091 removing trust relationships that are no longer needed as the IT 2092 environment evolves; 2094 periodic rotation of credentials (e.g., SSH user keys) used for 2095 trust relationships; and 2097 providing information needed for audits. 2099 6.1. Continuous Monitoring of Automated Access 2101 Proper management of automated access required continuous monitoring 2102 of the IT environment, because system administrators operating as 2103 root may add new trust relationships for any user account. 2104 Continuous monitoring is also prudent for detecting keys that are no 2105 longer used, identifying external keys, and identifying changes in 2106 the patterns of usage of automated access. 2108 Ideally, continuous monitoring is a real-time or near-realtime 2109 process. For some aspects of it, hourly or daily analysis would 2110 generally be perfectly sufficient. On the other hand, if implemented 2111 manually using audits, cost constraints may limit continuous 2112 monitoring to annual audits. 2114 Even when continuous monitoring is performed using software tools, 2115 auditors SHOULD do some random sampling and testing annually to 2116 verify that the continuous monitoring tools are working properly. 2118 In some respects, continuous monitoring resembles discovery. 2119 Configured SSH user keys and trust relationships need to be discoverd 2120 throughout the environment, and various checks need to be performed 2121 on them. Alerts, audit findings, or reports may be produced based on 2122 the results of the checks. 2124 Continuous monitoring MUST discover every trust relationship and 2125 authorized key throughout the managed IT environment. 2127 For each found authorized key: 2129 if it is on a moderate-impact or high-impact host, it MUST be 2130 verified that properly authorized trust relationship exists 2131 justifying the existence of the authorized key, or a special 2132 authorization exists for just the authorized key indendent of 2133 trust relationships (such special authorizations SHOULD be listed 2134 in annual audit findings and their continued existence SHOULD be 2135 rejustified annually); 2137 have a command restriction (also when a pseudo-tty is requested) 2138 that matches the command specified approved for them (for trust 2139 relationships leading into low-impact systems it is sufficient to 2140 just check the existence of a command restriction), unless 2141 sufficient approval is found to waive the requirement for a 2142 particular authorized keys/trust relationships. 2144 For each identified trust relationship, including those involving 2145 authorized keys, the following must be done: 2147 if the trust relationship leads from a lower-impact host to a 2148 higher-impact host and has no command restriction (or the command 2149 restriction is deemed ineffective in what can be done with it), 2150 then the lower-impact host must be reclassified as having the 2151 impact level of the higher-impact host; 2153 for trust relationships leading to moderate-impact or high-impact 2154 hosts, it MUST be verified that a proper approval exists for the 2155 trust relationship and that a proper justification, application, 2156 or business process is specified for it; 2158 if the trust relationship crosses a specified internal boundary in 2159 a manner that requires special approval, existence of such special 2160 approval MUST be verified (such bounrary-crossing trust 2161 relationships SHOULD be listed in annual audit findings and their 2162 continued existence SHOULD be rejustified annually); and 2164 it MUST be checked whether the trust relationship has been used 2165 for a configured amount of time (at most 12 months), and if not, 2166 the trust relationships MUST be removed unless special 2167 justification for their continued existence is provided (any trust 2168 relationships that have not been used for 12 months SHOULD be 2169 listed as audit findings and their continued existence SHOULD be 2170 rejustified annually). 2172 The age of every authorized key MUST be verified, and key rotation 2173 MUST be triggered for all authorized keys that exceed a maximum age 2174 specified by policy that are not used for external connections (the 2175 same SHOULD be done for authorized keys used for external 2176 connections), unless a special waiver is recorded for not rotating a 2177 particular key. Such special waivers SHOULD be listed in annual 2178 audit, and should be rejustified annually. Keys used for external 2179 connections that have not been rotated in the last 12 months SHOULD 2180 be listed in annual audit reports. 2182 As part of an annual audit, for moderate-impact and high-impact 2183 systems, if use of privileged access auditing systems are otherwise 2184 required for such systems, it SHOULD be verified that privileged 2185 access auditing cannot be bypassed by bypassed using SSH user key 2186 based access. 2188 The main rationale for the continuous monitoring of the environment 2189 and annual audits and requiring reporting and revalidation of certain 2190 aspects of automated access annually is to enforce proper policy 2191 (policies usually do not get implemented if their implementation is 2192 not controlled or if waivers are available). However, IT 2193 environments are complex and sometimes there is a need to have 2194 automated access relationships for special purposes that would not 2195 otherwise be advisable. Special approvals can be used for 2196 implementing such special cases, but they should be revisited 2197 annually. 2199 Failure to use forced commands risks the organization to virus spread 2200 and loss of defence in depth. Incidents involving viruses or 2201 cyberweapons could involve many thousands of hosts, and even if they 2202 are individually low-impact hosts, the overall impact could be very 2203 significant. Therefore command restrictions should be enforced even 2204 for low-impact systems in most cases. They should especially be 2205 enforced on high-impact systems as well as for trust relationships 2206 used with external connections. 2208 Failure to enforce approvals for incoming trust relationships allows 2209 creating unaudited backdoors, and if there is no continuous 2210 monitoring for unapproved trust relationships, such trust 2211 relationships are essentially permanent. 2213 It is recognized that in some organizations, developers and testers 2214 need to configure test systems dynamically and may not have support 2215 from dedicated system administrators to do so. However, such 2216 practice is not acceptable in production environments, particularly 2217 not on moderate-impact and high-impact systems. And even on low- 2218 impact systems, command restrictions should be used to reduce virus 2219 spread threat. 2221 While continuous monitoring can be implemented manually using 2222 periodic audits, a lot of effort will be saved by using software 2223 tools for it. Automated tools can also do a much more thorough job 2224 and perform the monitoring much more frequently. 2226 6.2. Creation of New Trust Relationships 2228 New trust relationships leading into moderate-impact or high-impact 2229 systems MUST NOT be created without proper approval as specified in 2230 the policy and MUST be associated with a proper justification for 2231 their existence, and SHOULD be associated with an application or 2232 business process. New trust relationships leading to low-impact 2233 hosts SHOULD have proper approval and justification for their 2234 existence. 2236 New trust relationships leading into moderate-impact and high-impact 2237 hosts MUST have a command restriction, unless a special approval has 2238 been obtained for not having a command restriction. New trust 2239 relationships leading into low-impact hosts SHOULD have a command 2240 restriction to limit virus spread possibilities. 2242 New trust relationships breaching a defined internal boundary MUST 2243 have special approval and justification. 2245 Special approvals SHOULD also be required for trust relationships 2246 leading to root accounts or other highly privileged accounts on 2247 moderate-impact or high-impact systems. 2249 A higher level of approval MAY be required for trust relationships 2250 leading to high-impact systems. 2252 Note that in some organizations tens of thousands or even hundreds of 2253 thousands of new trust relationships are set up annually, and setting 2254 them up may represent a substantial fraction of system administrator 2255 time and root access needs. Section 7 provides some ideas for 2256 reducing associated costs and root access needs. 2258 6.3. Removal of Trust Relationships 2260 Trust relationships MUST be removed when they are no longer needed. 2262 Sometimes a trust relationship may be removed by express request, 2263 e.g., when a business process is changed so that it is no longer 2264 needed. 2266 Sometimes a trust relationship may be removed because the application 2267 or business process it relates to is decommissioned or replaced by 2268 another application. 2270 Sometimes a trust relationship may be removed because continuous 2271 monitoring detects that it is no longer being used. This basically 2272 implies that some change made it unnecessary, but it was 2273 inadvertantly not removed at that time. (This scenario appears to be 2274 very common in practice). 2276 When trust relationships are removed, the associated authorized key 2277 (if it is key-based) MUST be removed from the authorized keys file of 2278 the destination server. 2280 When there are no trust relationships remaining using a particular 2281 identity key, the identity key SHOULD be removed. 2283 6.4. Periodic Rotation of Trust Relationships 2285 XXX 2287 6.5. Facilitating Audits 2289 XXX Making information easily available 2291 XXX Regular auditing of automated access management as part of normal 2292 IT audits. 2294 7. Reducing Cost and Improving Security by Automating Trust 2295 Relationship Setups 2297 XXX discuss how key management costs can be reduced by automation and 2298 triggering key setups automatically when approved in a change control 2299 system 2301 XXX discuss how automation can reduce the number of system 2302 administrators who need root access and the frequency of root access 2304 XXX should this go under the planning section? 2306 8. Security Considerations 2308 This document is all about security, including how to evaluate the 2309 impact of disruption or compromise of information systems, how to 2310 reduce the risk to information system from automated access, how to 2311 remediate current unmanaged base of SSH user key based trust 2312 relationships for automated access, and how to manage and 2313 continuously monitor automated access as an ongoing process. 2315 Section 1.5 defined information system impact levels based on FIPS 2316 199, but expanding on it by considering information systems having 2317 automated access to higher-impact information systems as also having 2318 the impact level of the higher-impact information system. 2320 Section 2.2.6 briefly discussed unmanaged host keys and how they can 2321 be used to compromise authentication and integrity protection using 2322 active network-level man-in-the-middle attacks. 2324 Section 3 discussed various threats arising from poorly managed 2325 automated access and SSH user keys, including virus spread threat, 2326 unaudited backdoor threat, leaked keys granting near-permanent 2327 access, and lack of proper termination of access when an employee 2328 leaves or changes roles. It also discussed how holes made in 2329 firewalls may be used for unintended purposes, including command 2330 execution, access to internal services, or for hiding source of 2331 attacks, if not properly controlled. 2333 Section 4 discussed scoping the threats and exposure of an 2334 organization to them as a quick precheck during audit, before 2335 engaging in a full discovery and remediation project. 2337 Section 5 provided recommendations on how to bring existing trust 2338 relationships for automated access, particularly SSH keys, under 2339 control. 2341 Section 6 provided recommendations for continuous monitoring and 2342 management of automated access and SSH user keys. 2344 As a summary, automated access between systems MUST NOT be 2345 overlooked. It has become so prevalent that many orgazations have 2346 many times more credentials for automated access to their information 2347 systems that they have user accounts for employees. 2349 Management of SSH keys is about managing access, with strong ties to 2350 identity and access management, security architecture, privileged 2351 access management, IT change control, and security audits. 2352 Cryptographic properties of the keys are in practice of little 2353 importance, as all keys generated with default settings by most 2354 commonly used SSH implementations are still cryptographically 2355 reasonably strong. 2357 Virus spread threat using automated trust relationships may remove 2358 defence in depth against attacks and malware. Automated access may 2359 provide pathways for bypassing existing privileged access management 2360 systems. Rogue administrators may use SSH user keys to create near- 2361 permanent unaudited backdoors, and leaked keys may be used for 2362 breaking into production servers. Even accidental access using 2363 poorly configured trust relationships has in the past caused 2364 substantial financial losses. 2366 Risks of unmanaged, unaudited automated access are sufficiently high 2367 and the state of their management in some of the largest 2368 organizations in the world so appalling that all organizations should 2369 evaluate to what extent they use automated access within and between 2370 their information systems, how it is managed and audited, and whether 2371 they are exposed to the risks. 2373 IT security auditors, policy makers, and security architects are 2374 urged to take automated access and related issues on their agenda. 2376 9. Glossary 2378 account: A user account on a computer. An account may belong to an 2379 actual person (interactive user) or may be used internally in a 2380 system (in which case it is sometimes called a functional account, 2381 process account, system account, or non-user account). 2383 Active Directory: A directory service created by Microsoft for 2384 Windows domain networks, providing a central repository for user 2385 information, user groups, and various other kinds of configuration 2386 information. Active Directory makes use of the LDAP and Kerberos 2387 protocols, among others, and can serve as an LDAP directory and 2388 Kerberos Key Distribution Center (KDC). 2390 Advanced Persistent Threat (APT): A group, such as a government, 2391 with the capability and intent to persistently target an entity 2392 using a variety of cyberwarfare techniques, such as espionage, 2393 social engineering, custom malware, and sophisticated hacking and 2394 evasion techniques. 2396 authorized key: A public key that has been configured as authorizing 2397 access to an account by anyone capable of using the corresponding 2398 private key (identity key) in the SSH protocol. An authorized key 2399 may be configured with certain restrictions, most notably a forced 2400 command and a source restriction. 2402 automated access: Access to a computer without an interactive user, 2403 generally machine-to-machine access. Automated access is often 2404 triggered from scripts or schedulers, e.g., by executing an SSH 2405 client or a file transfer application. Many programs may also use 2406 automated access using SSH internally, including many privileged 2407 access management systems and systems management tools. 2409 automated trust relationship: A trust relationship for automated 2410 access. 2412 command restriction: See forced command. 2414 CIFS: Common Internet File System, a protocol used on Windows for 2415 file sharing. The protocol is unencrypted and may be read and 2416 subverted by a network-level attacker. The protocol is extremely 2417 widely used in Windows environments, less frequently with Unix/ 2418 Linux. 2420 CISO: Chief Information Security Officer. A person responsible for 2421 IT security in an organization. 2423 COBIT: Control Objectives for Information and Related Technology, a 2424 framework created by ISACA (Information Systems Audit and Control 2425 Association) for information technology (IT) management and IT 2426 governance. 2428 CryptoAuditor: A product from SSH Communications Security for 2429 controlling and auditing content of SSH sessions and other 2430 encrypted communications, including file transfers. Can also be 2431 used for auditing use of SSH/SFTP connections at a firewall and 2432 for privileged access auditing for key-based access. 2434 destination account: In an SSH connection or trust relationship, the 2435 user account for which authentication is provided and under which 2436 any commands or other operations performed by the connection are 2437 executed (acknowledging that some commands, such as "sudo", may 2438 further escalate privileges). 2440 destination host: In an SSH connection or trust relationship, the 2441 destination host of the connection. A destination host would 2442 typically run an SSH server. 2444 DSA: Digital Signature Algorithm. An algorithm for public-key 2445 cryptography, particularly digital signatures. It is a United 2446 States government standard, specified in FIPS 186-3. 2448 external key: An authorized key that is used from outside the 2449 organization (or outside the environment considered for SSH user 2450 key management purposes), or an identity key that is used for 2451 authenticating to outside the organization (or outside the 2452 environment considered for SSH user key management purposes). Key 2453 rotation can break external keys, and therefore it must be ensured 2454 that the other side of trust relationships involving external keys 2455 is also properly updated as part of rotation. Alternatively, 2456 rotation of external keys may be prevented, but that is not a 2457 sustainable solution long-term. 2459 fingerprint: A hash value of a (public) key encoded into a string 2460 (e.g., into hexadecimal). Several fingerprint formats are in use 2461 by different SSH implementations. 2463 FISMA: Federal Information Security Management Act of 2002, a United 2464 States law that mandates how US government agencies must implement 2465 their it security. 2467 forced command: A restriction configured for an authorized key that 2468 prevents executing commands other than the specified command when 2469 logging in using the key. In Tectia SSH and OpenSSH, forced 2470 command can be configured by using a "command=" restriction in an 2471 authorized keys file. 2473 functional account: An account used for running applications or 2474 other processes, as opposed to an interactive account normally 2475 used by a person. Functional accounts are sometimes also called 2476 process accounts, system accounts, or non-user accounts (with 2477 slight nuances in meaning). 2479 host: A computer or other device on a network. A host may be a 2480 physical computer, a virtual machine, or any other logical or 2481 physical device that can communicate on a network, typically using 2482 one or more IP addresses. Some hosts may be multi-homed, meaning 2483 that they have more than one IP address. 2485 host certificate: A certificate for a host key for host 2486 authentication in the SSH protocol (typically an X.509v3 2487 certificate). Host certificates can eliminate the need for 2488 distributing host keys to all communicating hosts, greatly 2489 simplifying management and rotation of host keys. Widely used 2490 with Tectia SSH to avoid copying host keys and to make rotating 2491 them easier. 2493 host credential: A Kerberos credential that is used for 2494 authenticating to a Kerberos KDC as a host principal. 2496 host key: A public key used for authenticating a host in the SSH 2497 protocol to hosts that want to communicate with it (each host also 2498 generally has its own private host key). Some hosts may have more 2499 than one host key (e.g., one for each algorithm). Host keys are 2500 used for autenticating hosts (machines) themselves, not users or 2501 accounts, whereas identity keys and authorized keys relate to 2502 authenticating users/accounts and authorizing access to accounts 2503 on hosts. 2505 identity key: A private key that is used for authentication in the 2506 SSH protocol; grants access to the accounts for which the 2507 corresponding public key has been configured as an authorized key. 2509 indirect trust relationship: A sequence of trust relationships that 2510 indirectly leads to another account. For example, account A may 2511 be able to log into account B, which may be able to log into 2512 account C; then, account C indirectly trusts account A (and B 2513 directly trusts A and C directly trusts B). Indirect trust 2514 relationships may involve many kinds of trust relationships (e.g., 2515 SSH keys, Kerberos and privilege escalation). 2517 interactive user: A person (human) that uses a computer (and may 2518 type passwords or provide other authentication credentials as 2519 needed), as opposed to a computer that performs operations on 2520 another computer in an automated fashion. 2522 KDC: Key Distribution Center, a component of Kerberos. 2524 Kerberos: A centralized authentication and single-sign on system. 2525 Also used as part of Active Directory. See RFC 4120 [RFC4120]. 2527 key: A cryptographic key. In this document, keys generally refer to 2528 public key cryptography key pairs used for authentication of users 2529 and/or machines (using digital signatures). Examples include 2530 identity key and authorized keys. The SSH protocol also uses host 2531 keys that are used for authenticating SSH servers to SSH clients 2532 connecting them. 2534 Key Distribution Center: A component of Kerberos and Active 2535 Directory infrastructure that verifies credentials and issues 2536 tickets to principals (e.g., users and hosts). An Active 2537 Directory server includes a KDC. Frequently multiple KDCs 2538 synchronize information for redundancy. 2540 known host: A host whose host key is known (to a particular SSH 2541 client). 2543 LDAP: Lightweight Directory Access Protocol, a protocol for 2544 accessing and maintaining distributed directory information 2545 services. See RFC 4511 [RFC4511]. 2547 locking down keys: This refers to moving authorized keys to root- 2548 owned (or otherwise protected) locations, so that non-root users 2549 cannot add new authorized keys to themselves. This helps prevent 2550 system administrators and users from creating key-based backdoors 2551 that may survive the termination of their account and bypass 2552 privileged access management systems. See Section 5.2 for more 2553 information. 2555 NERC: North American Electric Reliability Corporation, an 2556 organization that, among other things, maintains the Critical 2557 Infrastructure Protection (CIP) standards that set minimum 2558 security requirements for protecting power generation and 2559 distribution infrastructure. 2561 NFS: Network File System, a file sharing protocol widely used in 2562 Unix/Linux environments in enterprises and universities. The 2563 protocol is unencrypted and may be subverted by a network-level 2564 attacker, permitting modification of any file. (NFS4 adds some 2565 security but is rarely used at the time of this writing, or is 2566 used with the security features disabled.) 2568 OpenSSH: An open source implementation of SSH based on Tatu Ylonen's 2569 original free version of SSH from 1995 and further developed by 2570 the OpenBSD group. 2572 password logger: A software or hardware module for recording 2573 keystrokes, especially user names and passwords, typed by an 2574 interactive user. Password loggers are nowadays commonly included 2575 in various malware and used as part of Advanced Persistent Threat 2576 (APT) attacks. Hardware-based key loggers may used in conjunction 2577 with physical access to a desktop or laptop (perhaps using a 2578 social engineering attack, such as getting hired as a cleaner) to 2579 obtain passwords for entry into information systems. 2581 PCI DSS: A set of Data Security Standards defined by the Payment 2582 Card Industry Security Standards Council, an organization 2583 originally formed by major credit card companies. 2585 PKI: See Public Key Infrastructure. 2587 privilege escalation mechanism: A means for escalating a user's (or 2588 processes) privileges from those of one account to those of 2589 another account (particularly a root or Administrator account). 2590 Examples of privilege escalation mechanisms include intentional 2591 provilege escalation tools such as "sudo" and unintentional 2592 privilege escalation possibilities based on vulnerabilities and 2593 configuration errors (experience has shown that it is very often 2594 possible to find vulnerabilities or misconfigurations on that 2595 enable privilege escalation once inside a host). An attacker 2596 having access to an account can generally change the configuration 2597 of the account to cause the user to unknowingly run the attacker's 2598 programs that may, e.g., steal the user's password and then use 2599 the password to spread the attack. Also, having high-level access 2600 on one host on a network may effectively imply access to every 2601 user account on every host whose home directory is in networked 2602 storage accessible through the same network as the compromised 2603 host. Against advanced attackers, even vulnerable embedded 2604 devices such as switches, printers and copiers can be used to 2605 perform network-level active attacks against other hosts. Some 2606 limit will have to be put on what theoretical possiblities are 2607 considered, however. Privilege escalation possibilities 2608 effectively imply additional trust relationships that may in turn 2609 imply a multitude of indirect trust relationships. 2611 Public Key Infrastructure: An arrangement that binds public keys 2612 with respective user identities using digital signatures issued by 2613 a certificate authority (CA). See RFC 3280 [RFC3280]. 2615 Putty: An Open Source SSH client for Windows. 2617 Reflection for Secure IT: A commercial version of SSH from 2618 Attachmate. 2620 root account: In Linux/Unix, a privileged account that is usually 2621 able to do anything in a computer (including reading any files and 2622 modifying any programs). In Windows, Local Administrator and 2623 Domain Administrator have similar or even broader power. (This 2624 document mostly talks about root access as SSH is mostly used on 2625 Linux/Unix and embedded devices, but the same issues often also 2626 apply to other technologies and the Windows environment.) 2628 rotating a key: Key rotation means changing the key, i.e., replacing 2629 it by a new key. The places that use the key or keys derived from 2630 it (e.g., authorized keys derived from an identity key, legitimate 2631 copies of the identity key, or certificates granted for a key) 2632 typically need to be correspondingly updated. With SSH user keys, 2633 it means replacing an identity key by a newly generated key and 2634 updating authorized keys correspondingly. See also external key. 2636 RSA: An algorithm for public-key cryptography based on the 2637 difficulty of factoring large integers, invented by Ron Rivest, 2638 Adi Shamir and Leonard Adleman. 2640 SELinux: Security-Enhanced Linux, a Linux feature that provides 2641 mechanisms for supporting access control security policies. 2642 SELinux is enabled by default on several Linux distributions (at 2643 least in what is called "targeted" mode, where it protects 2644 selected services). 2646 SFTP: SSH File Transfer Protocol, a file transfer and file sharing 2647 protocol typically used with the SSH protocol and originally 2648 developed by Tatu Ylonen for ssh-2.0. The protocol is 2649 unofficially described in SFTP [SFTP]; there is no normative 2650 reference available at the time of this writing. 2652 source account: In an SSH connection or trust relationship, a source 2653 account is the user account on the host initiating the connection, 2654 typically the user account under which an SSH client runs. 2656 source host: In an SSH connection or trust relationship, a source 2657 host is the host initiating the connection (typically by running 2658 an SSH client). 2660 source restriction: A restriction configured for an authorized key 2661 that limits the IP addresses or host names from which login using 2662 the key may take place. In OpenSSH, source restrictions can be 2663 configured by using a "from=" restriction in an authorized keys 2664 file. 2666 SOX: Sarbanes-Oxley Act of 2002, also known as the Public Company 2667 Accounting Reform and Investor Protection Act, a United States law 2668 that, among other things, sets requirements for protecting certain 2669 sensitive information in listed companies. 2671 SSH: SSH (Secure Shell) is a protocol and tool for remote system 2672 administration, file transfers, and for tunneling TCP/IP 2673 communications securely, originally developed by Tatu Ylonen. 2675 SSH Communications Security: A company founded by Tatu Ylonen, the 2676 inventor of SSH, with products improving security and operational 2677 efficiency of large IT environments, particularly for large SSH 2678 environments. See http://www.ssh.com [2]. 2680 sudo: A privilege escalation mechanism/tool on Unix/Linux that can 2681 be used for executing commands as root from a non-root account. 2682 The operation of "sudo" depends on its configuration. In some 2683 configurations, certain accounts may perform any command as root 2684 using "sudo". In some other systems, certain users, such as 2685 members of a "wheel" group can perform commands as root by 2686 confirming the operation with the user's password. Several 2687 commercial tools also exist for the same purpose. 2689 Tectia Manager: A product for managing SSH host keys and 2690 configurations, from SSH Communications Security. 2692 Tectia SSH: A commercial version of SSH servers and clients for 2693 Windows, z/OS (IBM mainframes), Unix, and Linux from SSH 2694 Communications Security. 2696 trust relationship: Something that permits a source account to log 2697 in to a destination account (possibly on a different computer). 2698 In a sense, the destination account trusts the source account, and 2699 if the source account is compromised, so is the destination 2700 account. An example is an authorized key (and corresponding 2701 identity key) configured for public key authentication in SSH. 2702 See also indirect trust relationship and privilege escalation. 2704 Universal SSH Key Manager: A product from SSH Communications 2705 Security for managing and monitoring SSH keys and other trust 2706 relationships for automated access. 2708 user key: A key that is used for granting access to a user account 2709 in the SSH protocol (as opposed to a host key, which does not 2710 grant access to anything but serves to authenticate a host). Both 2711 authorized keys and identity keys are user keys. 2713 10. References 2715 [FIPS199] Evans, D. L., Bond, P. J., and A. L. Bement, "Standards 2716 for Security Categorization of Federal Information and 2717 Information Systems", FIPS Publication 199, February 2004. 2719 [FIPS200] Gutierrez, C. M. and W. Jeffrey, "Minimum Security 2720 Requirements for Federal Information and Information 2721 Systems", FIPS Publication 200, March 2006. 2723 [NIST800-53] 2724 Locke, G. and P. D. Gallagher, "Recommended Security 2725 Controls for Federal Information Systems and 2726 Organizations", NIST Special Publication 800-53 (revision 2727 3 with updates as of 05-01-2010), August 2009. 2729 [KENT] Kent, G. and B. Shrestha, "Unsecured SSH - The Challenge 2730 of Managing SSH Keys and Associations", SecureIT White 2731 Paper, 2010. 2733 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2734 X.509 Public Key Infrastructure Certificate and 2735 Certificate Revocation List (CRL) Profile", RFC 4251, 2736 April 2002. 2738 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 2739 Kerberos Network Authentication Service (V5)", RFC 4251, 2740 July 2005. 2742 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 2743 Protocol Architecture", RFC 4251, January 2006. 2745 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 2746 Authentication Protocol", RFC 4252, January 2006. 2748 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 2749 Transport Layer Protocol", RFC 4253, January 2006. 2751 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 2752 Connection Protocol", RFC 4254, January 2006. 2754 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 2755 (LDAP): The Protocol", RFC 4511, June 2006. 2757 [SFTP] Galbraith, J. and O. Saarenmaa, "SSH File Transfer 2758 Protocol", draft-ietf-secsh-filexfer-13.txt (work in 2759 progress), June 2006. 2761 Authors' Addresses 2763 Tatu Ylonen 2764 SSH Communications Security 2766 Email: ylo@ssh.com 2767 URI: http://www.ssh.com 2769 Greg Kent 2770 SecureIT 2772 Email: gkent@secureit.com 2774 Mitchell Klein 2775 Bank of America 2777 Email: mitchell.p.klein@bankofamerica.com 2779 Murugiah Soyppaya 2780 NIST 2782 Email: soyppaya@nist.gov