You have Javascript disabled. While you will be able to browse this site without Javascript, some functionality on this site will not work without it. We strongly recommend enabling Javascript in your browser. This site uses cookies and collects data about visitor behavior for improving user experience, identifying returning visitors, and providing personalized offers. Your continued use of this site indicates your consent to this. See Privacy Policy for details or if you wish to disable cookies.

Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

This site uses cookies and collects data about visitor interaction for improving user experience, identifying returning visitors, and providing personalized offers. Your continued use of this site indicates your consent to this. See Privacy Policy for details or if you wish to disable cookies.

Identity and Access Management

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. SSH Risk Assessment is a packaged service 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.

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.

Solutions

CryptoAuditor can prevent SSH tunneling at the firewall or in front of servers. It can also provide session recording transparently to users, without jump servers, in a way that cannot be bypassed using SSH keys. CryptoAuditor is fully network based and requires no changes to the connection endpoints.

Universal SSH Key Manager is the leading product for managing SSH keys and implement a controlled provisioning process, termination process, and helps in discovery and remediation of existing keys. It is non-intrusive, fits into application-oriented enterprise workflows, and does not require changes to existing scripts and file transfers.