SSH User Keys and Access Control in PCI-DSS Compliance Environments

Secure Shell User Keys and Access Control in PCI-DSS Compliance Environments

Emerging trends impacting PCI-DSS compliance requirements in secure shell deployments

A Secure Shell Key Management White Paper

TABLE OF CONTENTS:

Abstract............................................................................................................................1Compliance Risks Related to Unmanaged Secure Shell User Keys...............................................2The Current vs. Modernized PCI-DSS Requirements for Key Management Authentication........2Universal SSH Key Manager Connects SSH Keys and Access Control...................................4Conclusion....................................................................................................5

About SSH Communications Security:

Founded in 1995, SSH Communications Security is the company that invented the SSH protocol - the gold standard protocol for data-in-transit security solutions. Today, over 3,000 customers across the globe, including 7 of the Fortune 10, trust our Information Assurance Platform to secure the path to their information assets. Our platform enables businesses of all types and sizes to protect their information assets by providing the gold standard data-in-transit security solutions that prevents data loss in both internal and external environments, hardened perimeter security through our multi-channel two-factor authentication and internal security control management solutions that enables organizations to more easily manage user keys and monitor administrator traffic across your networks

© 2012 SSH Communications Security

SSH User Keys and Access Control in PCI-DSS Compliance Environments

Abstract:

As the Payment Card Industry Data Security Standard (PCI-DSS) evolves to include requirements to manage secure shell user keys as carefully as passwords, the current tools many organizations use for secure shell user key management will become ineffective and create a compliance issue. This white paper analyzes how emerging key management and access control technologies will likely impact PCI compliance mandates and presents SSH’s Universal SSH Key Manager as a solution that can be implemented today to both increase security controls and meet the coming, common sense changes to compliance mandates.

The secure shell protocol is the de facto gold-standard for securing data transfers and remote system access in enterprises of all types and sizes. To automate the authentication process of application-to-application data transfers and interactive administrator access over secure shell, it is an industry best practice to use public-key authentication, which relies on the use of secure shell user keys.

As a result of the secure shell’s widespread adoption and that secure shell keys are typically used in a non-systematic, inadequately documented manner, many enterprises today lack visibility into their secure shell user key environments, and more importantly, into how and when the keys are utilized and by whom. Sufficient documentation and robust, systematic practices around secure shell key inventories: key deployment, removal, rotation and maintenance policies remain exceptions rather than the rule in organizations.

Current compliance mandates focus on key encryption and key storage management. There has, however, not yet been sufficient attention to secure shell user keys, certificates and other user authentication keys and their relationships to access management standards within the PCI-DSS.

This white paper analyzes the current PCI-DSS compliance mandates on key management and related access control measures and proposes issues that should be addressed in an effort to modernize the standard and enhance the security of organizations’ secure shell environments and overall access management infrastructures.

1 SSH User Keys and Access Control in PCI-DSS Compliance Environments

2

Compliance Risks Related to Unmanaged Secure Shell User Keys:

The use of the secure shell is ubiquitous in most enterprise organizations. Every Unix and Linux box is shipped with a version of the secure shell, and SSH Communications Security and OpenSSH make up the vast majority of the millions of secure shell deployments currently in place worldwide. In stark contrast to other data-in-transit methodologies, the secure shell is considered the most secure method for moving information across the enterprise. Despite the secure shell being generally recognized as the gold-standard for data-in-transit security, enterprises that do not adequately manage access to their encrypted pathways run the risk of giving malicious insiders and external bad actors access to their most critical information assets - and a secure, encrypted pathway in which to exploit the environment.

Because trust relationships that are formed through setting up key pairs (a public key and a private key) provide access to such critical information assets, management of those keys should always reflect the enterprise’s access control strategy and conform to both internal and external compliance mandates. Unfortunately organizations that do not manage their secure shell keys place their organization at considerable risk.

For instance, a user who has rights to add or modify secure shell keys on a trusted host, such as an SAP or Oracle server, could allow a system or application user to introduce additional secure shell keys. Without secure shell key management, that user and those people or applications they have shared the private key with can bypass the controls in place on the trusted host. Another common concern is cases where application users can introduce keys which would allow session based access to a production environment from a non-production environment. These key chains are virtually impossible to track without a centralized universal secure shell key management solution.

The Current vs. Modernized PCI-DSS Requirements for Key Management and Authentication:

The current PCI-DSS requirements on key management (chapter 3, Protection of cardholder data) are limited to encryption keys for data storage purposes and for securing access. As highlighted in points 3.5.2 and 3.5.3, keys should be accessible to as few custodians as possible, and stored securely in as few locations as possible.

Section 3.6 of the PCI-DSS standards addresses how key management practices should be documented and implemented and also touches upon how to securely generate, distribute, and store encryption keys. In sections 3.6.4 and 3.6.5, it addresses the periodical rotation of keys as well as the removal and retirement of unknown or compromised keys.

The shortcoming of the current standards is that the focus is on encryption keys and not on the keys that are used for authentication. As a result the relationship between authentication keys and access control is insufficiently addressed.



Current Standard: Modernized Standard:8.5 Today: The user identification and authentication requirements of PCI-DSS 8.5 are heavily focused on password authentication. However, there are also other widely used authentication methods such as SSH public keys and SSL/TLS based client certificates.

These are used to authenticate normal and privileged users when they connect to database, web and other critical systems and services over FTPS, SSH, SFTP and other remote access and file transfer protocols. Keys are comparable authentication credentials to passwords and are used to enable access to critical IT systems and confidential data.

For example, if either end of a connection has root privileges, authentication keys should be subject to the same requirements as are other keys that allow access to confidential data (PCI req. 3.5 and 3.6) and as are other authentication methods, such as passwords (req. 8.5)

8.5 Modernization: 8.5.x requirements in general cover other authentication methods as well. For example: requirement 8.5.1 includes authentication methods more widely, e.g. “Control addition, deletion and modification of user accounts, credentials, and other identifier objects such as authentication tokens, keys or certificates”.

Testing procedure in 8.5.1 reflects modern data center use cases, such as accessing services remotely, e.g. “Select a sample of user accounts, including both administrators and general users. Verify that each user is authorized to access the systems locally and remotely according to policies, by performing the following: Obtain and examine an authorization form for each account’s access rights per authentication model (passwords, token, keys), including remote access authorizations and trust relationships (e.g. userA on systemA is able to access systemB as userB using authentication key X).”

8.5.4 Today: Secure shell keys and client certificates can be used to access critical services using different usernames than on the originating host. For example userA on systemA can log in to systemB as userB using SSH key authentication.

The current testing procedure of 8.5.4 does not clearly define that the access lists should also provide information of the authentication relationships and that those are disabled as well. The current testing procedure focuses only on verifying that the user account in question (typically the user accounts used for logging in to workstations etc.) has been deactivated or removed.

Also, in some environments and on some platforms, secure shell key authentication can be used to circumvent login restrictions, and can enable access even when the target user account has been disabled. Therefore it is extremely important to be able to disable the trust relationships as well.

8.5.4 Modernization: Testing procedure in 8.5.4 now meets other authentication methods. For example “Select a sample of users, whose employment has been terminated in the past six months, and review the current user access lists to verify that their accounts and related local and remote access trust relationships have been deactivated or removed for all authentication models (passwords, keys, tokens).”

The table below presents a possible evolution of the PCI-DSS standard and how the relationship between authentication keys and access control could be more effectively addressed in the future. How to link authentication key management within the standard’s requirements is addressed through focus on chapter 8; assign a unique ID to each individual with computer access.

4

Universal SSH Key Manager Connects Secure Shell User Keys and Access Control:

Universal SSH Key Manager provides enterprises the necessary tools to discover, monitor and automate the management of trust relationships for automated accounts, application ID’s and interactive users per the public and private keys. This section addresses the compliance based control issues around how the Universal SSH Key Manager can identify and manage these trust relationships in correspondence to the four modernization scenarios of PCI-DSS standards 8.5, which were outlined in the previous section.

Universal SSH Key Manager has the capability to discover public and private keys and their associated trust relationships via agentless and agent-based management connections, based on the secure shell connectivity that is already established in the enterprise’s environment. In an initial discovery phase the following information is captured from the targeted hosts:

• Keys by size, type and passphrase existence• The owner of each key based on its user or user group• The location of each key by host or host group


Current Standard: Modernized Standard:8.5.9 Today: The current requirement only defines password rotation. The same authentication credential rotation policies must be enforced on all comparable authentication methods such as secure shell user keys and client certificates. Compared to passwords, secure shell keys may allow similar or even higher level access to critical services. They should therefore be included within the same rotation policies.

8.5.9 Modernization: 8.5.9 affects other authentication methods and models as well, for example: “Change user passwords and other comparable authentication credentials, such as authentication keys, at least once every 90 days.”

8.5.10 Today: Weak authentication keys are comparable to weak passwords. The standard should define minimal requirements for authentication keys, or at least state that there must be a policy and processes in place to ensure that all the authentication keys are created and used according to the policies and best practices.

8.5.10 Modernization: 8.5.10 requires controls standards over authentication keys. For example: “Require a minimum password length of at least seven characters. Require other authentication methods to follow the defined authentication security policies.”

8.5.10a covers other authentication methods as well. For example: “For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to be at least seven characters long. For other authentication methods, inspect the settings and the environment to identify that the authentication parameters (such as key length, key type) conform to the defined policies.”

5

• Effective trust relationships between all the managed hosts and their users• Rogue public and private keys• Summary of keys (numbers deployed, created but not deployed, etc...)• Trust relationships with an unknown private or public key component

From this point forward, the secure shell user key environment can be locked down and monitored, in whole or per selected hosts. Keys that are created outside Universal SSH Key Manager system will be immediately flagged for review. The ability to regularly scan the environment at a pre-determined interval will provide the needed visibility into your secure shell key environment and the trust relationships within it.

Universal SSH Key Manager can be used to centrally manage the secure shell user key environment:

• Creation of new trust relationships, with automated key creation and distribution• Removal of trust relationships and their related secure shell user keys• Authorization approval integration into the existing approval process• Automated user key lifecycle management• Enforce key restrictions (only allow connections from a defined location, only allow the use

of pre-defined commands, use of blacklists)

Using the above process, the topics detailed above, in the potential evolution of PCI-DCC section 8.5.1 (which would require the “controlled addition, deletion, and modification of user accounts, credentials, and other identifier objects such as authentication tokens, keys or certificates”), could be sufficiently and completely addressed within the domain of secure shell user keys. Concerning the potential evolution of sections 8.5.4, 8.5.9, and 8.5.10, enterprises could acquire visibility on deactivated or removed user keys, and also gain the ability to automate key removal, rotation and renewal with regard to the policy standards and best practices in the enterprise. Also, in regard to section 8.5.10, the Universal SSH Key Manager can be used to uphold policies and standards related to the security of the secure shell user keys.

Conclusion:

The lack of visibility into the secure shell user key inventories and their relationships to the enterprise’s access control strategy and policies is still a severe security risk for numerous enterprises today. To this date, compliance drivers, such as the PCI-DSS security standard, only address key management from the perspective of how keys should be encrypted and stored. However, current standards fail to illustrate the overall connection between SSH user keys and access control management. Consequently, topics within PCI-DSS related to user accounts and authentication focus on strong password authentication, but do not illustrate that secure shell user keys or other certificates can equally provide access to critical resources in enterprises.

In conclusion, as access management within organizations matures in accordance with compliance standards, the inherent connections between secure shell user keys, their



associated automated accounts, application IDs, and interactive users, will become increasingly important. Without sufficient tools in place to reliably and clearly connect secure shell user key inventories to trust relationships, enterprises will continue to face unacceptable levels of technical risk in terms of how public and private keys may be misused. An evolution of PCI-DSS compliance initiatives that links secure shell user key authentication to access control will certainly be a welcome step toward greater security in enterprises.

For more information on secure shell user key management and PCI-DSS compliance please visit www.SSH.com.

www.ssh.com

SSH User Keys and Access Control in PCI-DSS Compliance Environments

Documents

Transcript of SSH User Keys and Access Control in PCI-DSS Compliance Environments