PCI DSS, SSH, and PCI Compliance

Payment Card Industry (PCI) Security Standards Council (SSC) was founded in 2006 by major credit card companies American Express, Visa, MasterCard, Discover, etc., with the following two priorities:

  • Helping merchants and financial institutions understand and implement standards for security policies, technologies and ongoing processes that protect their payment systems from breaches and theft of cardholder data.
  • Helping vendors understand and implement standards for creating secure payment solutions.

The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The standard provides a baseline of technical and operational requirements designed to protect account data.

With the new version 3.2 of the standard, it has become apparent that security requirements are added, changed or removed mostly based on mitigating current vulnerabilities identified in breach reports. The changes are also intended to help organizations maintain an effectively test compliance between security assessments.

SSH and PCI DSS

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

Given the purpose of the standard, which is to secure the handling of credit card transactions, the SSH protocol:

  • Encrypts traffic and file transfers between two endpoints and protects of cardholder data (CHD) in transit.
  • Is a secure alternative/replacement for obsolete tools such as telnet, FTP, rsh, etc. SSH prevents unauthorized CHD access that could lead to a security breach.
  • Provides strong authentication of users and devices.
  • Provides secure access to the cardholder data environment (CDE) for application developers and system/network administrators.
  • Secures mission critical backups and business continuity processes.
  • Secures the thousands of automated processes that drive day-to-day IT operations, including moving CHD within and between enterprises that are in scope of PCI DSS.
  • Prevents man-in-the-middle attacks and protects CHD.

Ramifications of Non-compliance or Consequences of Breaches

As with any non-compliance or breach scenario, organizations may be impacted by any of the following:

  • Customers lost confidence resulting in loss of business
  • Sales may be impacted which would impact the bottom line
  • Revenue and sales impacts will surely lead to loss of jobs
  • Typical costs incurred from a breach such as attorneys, fees, issuing new credit cards, etc.
  • Become an auditor target for almost every PCI DSS requirement applicable to your merchant level
  • The ability to process card payments may be terminated
  • And last but not least, potentially going out of business

Organizations must be diligent and continuously assessing their compliance with PCI DSS. Regularly conduct risk assessments when standards or infrastructures change is critical to ensure ongoing compliance.

PCI Compliance SSH Mapping Guidance

Below we highlight some of the key requirements the standard puts forth and shed some light on how SSH Communication Security can help pave the way to compliance:

RequirementGuidance
1.1.2 Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks.SSH keys create connections, access, and data transfer routes between systems that must be documented.
1.1.5 Description of groups, roles, and responsibilities for management of network components.The network diagram will identify the connectivity for all components. This will assist in identifying all communications requiring SSH. A scan of authorized keys is recommended to confirm deployment specs - see SSH Risk Assessment. Deploying Universal SSH Key Manager in your cardholder data enviroment (CDE) will further assist and confirm authorized access as dictated by roles and responsibilities.
2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure - for example, use secured technologies such as SSH, SFTP, FTPS, TLS, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.Tectia SSH provides secure encrypted file transfers and can tunnel legacy applications inside an encrypted tunnel. Universal SSH Key Manager controls access within and across the boundary of the CDE. CryptoAuditor prevents tunneling into the CDE.
3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary.SSH keys can provide access to cryptographic keys used for encrypting cardholder data (CHD) and should be restricted accordingly on any system that stores keys used to secure stored CHD against misuse. At the minimum, it must be understood who (including what processes or systems) has access to the encryption keys (including access using commercial SSH user authentication keys).
7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.Properly configured and deployed Our products will further enhance your logical access controls. It can support your defined roles and responsibilities and only grant access based on approved roles.
8.3 Requires multi-factor authentication for all personnel with non-console administrative access to the CDE. New requirement 8.3.2 addresses multi-factor authentication for all personnel with remote access to the CDE (incorporates former requirement 8.3).Our products are critical in supporting privileged access controls. They support three basic principles of privileged access: Approval, logging and monitoring and the post activity reviews.
10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup).SSH Communications Security exceeds this requirement with out of the box configuration.

What Next?

Exploiting data security weaknesses in the cardholder data environment remains a popular tactic for cyber criminals. With the added risks associated with ineffective access controls along with the most common threat – human error – organizations must remain diligent in enforcing and continuously monitoring their security controls whether driven by PCI compliance or simply to protect what is important.

We provide services and tools to address compliance in relation to SSH keys and encrypted access. We also provide tools to prevent SSH tunneling from the Internet into the internal network.

We recommend that you contact us for:

Organizations are also simultaneously facing other IT challenges and transformations into cloud and IoT. We play into several aspects of the ongoing transformation.

The offering of SSH Communications Security is a compliance enabler for all of the above. Conversely, lack of visibility into how SSH is deployed and who has access to what data using SSH keys in the cardholder data environment and otherwise exposes an organization to grave risks and liabilities. For example, the Sarbanes-Oxley law for public companies even has criminal penalties for negligent or fraudulent certifications by the CEO and CFO.

What is the best way to prepare for a PCI DSS audit? Be your own auditor first! This can be accomplished by conducting a thorough control gap assessment which will pave the way for an easier audit and an achievable compliance attestation.

Additional Links