Identity and Access Management & SSH Keys

Identity and access management (IAM) is the foundation of information security. IAM addresses the basic need of any organization to be able to reliably identify users, and to be able to control which users get access to which resources.

These two basic controls - identity and access - lay the foundation of security in the corporate environment. Every regulatory system in cybersecurity starts from the requirement to control who has access to which systems and data and having a well-defined process for granting and revoking such access. It is the basis of information security. The rest is mostly just about enforcing this access.

SSH Keys Grant Access

SSH keys are access credentials that are typically used for provisioning operating system-level access to servers for automatic processes, file transfers, and system administrators. The basic idea is to configure a private key on a client machine, and the corresponding public key on a server machine. Possession of the private key grants access to the server. In SSH, this is called public key authentication.

Most existing identity management frameworks focus on access control for normal end users. Service accounts used for running application software generally receive much less attention, yet such accounts can provide much more powerful access.

Many identity and access management projects focus on privileged access, typically meaning access by system administrators to root accounts and service accounts. Privileged access is typically controlled by forcing users to log into a jump server that logs all their access. This is generally achieved by having the passwords for controlled accounts stored in a password vault and changed frequently by an automatic process.

It is common for system administrators to install SSH keys on privileged accounts or root accounts that they regularly use, so that they can bypass going through jump servers. While this may be convenient, it violates policy and compliance, and eliminates accountability.

SSH Keys Can Be Self-Provisioned and Never Expire

SSH keys are special that they allow self-provisioning and never expire. A user who logs into an account can install new authorized keys that permit that user (or anyone in possession of the key) to log into the account in the future, as long as the authorized key remains configured. This can be combined with port forwarding to allow access to the internal network from the outside and is a very common way for hackers to create backdoors into the corporate network.

It is possible to configure SSH to prevent self-provisioning by moving keys to root-owned locations. This generally involves modifying SSH configuration files to change the location of the authorized_keys files, and is often called lock-down. This is usually one of the first steps in managing SSH keys.

SSH Keys Are Surprisingly Common

SSH is used for managing routers, server hardware, virtualization platforms, operating systems, and inside systems management and file transfer applications. It is present in every data center and ships by default with every Unix, Linux, and Mac server.

System administrators have been using and installing SSH keys for the last 15-20 years. They were a very technical concept, in the system administration domain, and very few people realized they had access management implications. Even most CISOs weren't aware of SSH keys or grossly underestimated their usage. We still frequently encounter organizations that initially say they don't use SSH, or that they don't use SSH keys, but upon closer examination turn out to use it massively with hundreds of thousands of SSH keys in place.

In large Fortune 500 companies, we generally find anywhere from several hundred thousand to over four million SSH keys. The number is generally 5-200 keys per server, and typically about 5-20 times the number of employees in the organization. The bigger and more complex information systems, and the more Unix/Linux usage, the bigger the problem with unmanaged SSH keys tends to be. SSHerlock is a self-service software that helps understand the extent of SSH and SSH key usage in an organization.

In many cases, more than 90% of all access credentials are SSH keys. Typically, the identities are existing accounts, but SSH keys can be used to add more access credentials for them. It is analogous to having multiple passwords for each account.

It is typical to find SSH keys granting access from one data center to another, including to disaster recovery data centers. Access from test and development systems into production is very common in unmanaged environments, violates separation of duties, and allows passwordless access to critical systems from systems that are not as well protected. We frequently see access to credit card payment processing environment using SSH keys that crosses the PCI boundary in violation of the PCI-DSS.

Gaping Hole in Identity and Access Management Strategy

IDC published a white paper A Gaping Hole in Your Identity and Access Management Strategy in 2013 on SSH key management, and a Technology Spotlight SSH Governance Is Needed to Reduce Risk and Bridge the Trusted Access Gap in 2016.

NIST published Security of Interactive and Automated Access Management using Secure Shell (NIST IR 7966) in 2015, which provides guidelines for managing SSH keys and maps compliance requirements into the US Government Cybersecurity Framework and NIST SP 800-53.

There is ample evidence of malware and hackers leveraging SSH keys. SSH keys have been used as system level backdoors in attacks that have been made public, and there are likely to have been many attacks that have not been publicized. They can be combined with SSH back-tunneling to get inside corporate networks from the public Internet.

Unmanaged SSH keys expose organizations to grave, even existential risks. The risk is as grave as not managing user accounts and passwords. Given the government and analyst attention and the hundreds of articles written on SSH key management, nobody can claim ignorance anymore.

Compliance Requirements for SSH

Unmanaged SSH keys frequently lead to access that is in violation of the compliance regimes that require controlling who can access what systems and data, segregation of duties, and enforcing boundaries. It is common to see configured key-based access from test and development systems into production environments, access from personal system administrator accounts into critical Oracle database accounts bypassing privileged access controls (e.g., bypassing Cyberark, Powerbroker, Xceedium, or Lieberman installations that are supposed to provide visibility into privileged access) and violating PCI, Sarbanes-Oxley, or NIST 800-53 boundaries.

SSH Key-Based Access to Financial Data Environments

Of particular concern is access into financial data environments in public companies, in violation of Sarbanes-Oxley. Sarbanes-Oxley involves potential civil and criminal penalties for top management. For example, Section 302(a)(4)(B) requires the CEO and CFO to certify that they "have designed internal controls to ensure that material information relating to the issuer and its consolidated subsidiaries is made known to such officers by others within those entities, particularly during the period in which the periodic reports are being prepared." A knowing or willful misrepresentation can result in fines of up to $5 million and/or up to 20 years in prison.

If SSH keys allow access to the service accounts holding the databases and applications related to financial systems, financial data may be modified by an attacker to hide evidence of fraud, botched deals, theft, or injection of fraudulent or manipulative data. Clearly internal controls must reasonably prevent resulting misrepresentation. Given the ubiquity of SSH keys, it would be reckless not to control SSH key based access to financial systems.