The Payment Card Industry Data Security Standard (PCI DSS) is familiar to everyone in positions of responsibility in major finance companies, telcos, big box and online retailers and a host of other large organizations. Ensuring PCI DSS compliance is mandatory and fundamental in any organization that accepts, transmits or stores any cardholder data, regardless of the size or number of transactions. SSH-enabled access to critical systems and data is a vital factor in gaining and remaining PCI DSS compliant.
How is SSH used in cardholder data environments?
Typically, SSH-enabled access is used for any or all of the following:
- system administrator access
- application administrator access
- developer access
- device admin access
- automated processes, file transfers
- remote desktop protocol
- backup and restore
- system fail over
- VPN access
- contractor or business partner access.
Timed financial transactions are commonly enabled by SSH Keys that grant access between systems.
The aim of PCI-DSS is secure handling of credit card transactions. The Secure Shell protocol plays a vital role.
In CDEs, Secure Shell:
- Encrypts traffic between two end points that supports the protection of cardholder data in transit.
- Secures the transmission of CHD from two end points by leveraging SFTP.
- Is a secure alternative or replacement for older tools (e.g., Telnet, FTP or RSH) that prevents unauthorized access to the CHD, which could lead to a security breach.
- Provides user and server authentication that ensures authorized user access to CHD.
- Provides secure access to application developers, system and network administrators who manage and support the cardholder data environment.
- Secures mission-critical backups and business continuity processes.
- Is used by 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 to protect the CHD.
Know your acronyms!
- CDE - Cardholder Data Environment
- CHD - Cardholder Data
- CC - Credit Card
- PCI-DSS - Payment Card Industry Data Security Standard
- SSH - Secure Shell protocol
- RSH - Remote Shell
- SFTP - Secure File Transfer Protocol
- SSH.COM - SSH Communications Security, enterprise software solutions and inventors of the Secure Shell protocol (that’s us;))
- SoD - Segregation of Duties
Top 3 PCI DSS compliance issues from weak Secure Shell governance
We work with many of the world’s major credit card companies and banks in the US, Europe and Asia, in addition to the world’s biggest retailers. We have conducted in-depth network scanning, consulted and deployed our software solutions in partnership with security architects at a raft of household name banks and CC companies. There are three key issues that frequently come to light:
-
Segregation of duties
-
PAM bypass
-
SSH Key management
Segregation of Duties is an audit failure point
The intent of the requirement for SoD is to ensure that development/test functions are separated from production functions. For example, a developer may use an administrator-level account with elevated privileges for use in the development environment, and have a separate account with user-level access to the production environment.
In environments where one individual performs multiple roles (for example, application development and implementing updates to production systems), duties should be assigned such that no one individual has end-to-end control of a process without an independent checkpoint. For example, assign responsibility for development, authorization and monitoring to separate individuals.
In environments with cardholder data SoD minimizes risk and helps ensure that access is limited to those individuals with a business need to know. Audit failure scenarios include e.g. developers or 3rd party subcontractors gaining access to credit card data while working on application development, unmanaged privileged access credentials – or spreadsheets of passwords – that offer access to CHD accessible by insiders or hackers.
In SSH Risk Assessment key scanning in major financial organizations we typically find that 25-50% of production connections enabled by SSH Keys originate from non-production sources. As enterprises become more agile and must implement stronger access controls there’s a conflict. DevOps culture is not a natural fit to the Segregation of Duties and legacy infrastructure.
PAM bypass – privileged users don’t have the time to waste on legacy systems
Privileged users, such as systems administrators, face various challenges in their day-to-day work when they must decide how and when to access critical systems. Major finance, tech, telcos etc. all have security policies in place, and typically have some kind of access software. However, the reality is that sysadmin root users often have to act fast under pressure and do not have time to configure the company’s legacy privileged access system, so they create their own key ad-hoc so they can get on with their work.
Typically Privileged Access Management (PAM) solutions are blind to SSH keys that have been placed directly on the target server. Root users can self-provision these keys in seconds to create a direct connection from client to server, bypassing PAM controls and with the sessions undetected by PAM software.
Legacy, mismanaged and unmanaged keys – the secondary attack vector
The more untracked, unknown, non-expiring, under-encrypted or lost SSH keys in your environment, the greater the risk from human error or exploitation by nefarious actors. Unmanaged SSH Keys are a jackpot for hackers as they provide a stealth secondary attack vector that enables them to move laterally inside networks and access systems and data after their initial entry hack.
SSH key environments in major enterprises are vast. We typically find hundreds of thousands, even millions of keys, so many that it’s impossible for humans to manually chart and control. Vital information, such as key strength, validity, ownership and purpose is not logged or auditable.
Some organizations have vault-based SSH Key management systems but these only cover those keys that have actually been onboarded and registered into the vault. Our research has highlighted that in typical enterprises, there are vast numbers of keys that persist outside the vault. Unfortunately, ad hoc record keeping in spreadsheets is common.
SSH Keys used by developers and testers must be removed prior to migrating your CDE to production. Remnant non-production access may lead to audit infractions and/or a breach.
“With major finance companies we are typically able to remove 90% of unused keys for a massive reduction in manual work and risk, without impacting network performance.” Tatu Ylönen, founder, SSH.COM and inventor of the SSH protocol.
Your CDE is a vulnerability and risk factor
“Criminals are becoming increasingly sophisticated in how they break into systems. It is, therefore, critical that merchants take steps to secure their systems to limit their exposure to account data compromises.” VISA Europe
Remediating actions and risk mitigation
“I realised the problem of scale and the scale of the problem in 2010 – we got enquiries from major financial players that needed key management. Since 2011, we have developed underlying technologies and software management tools to meet the specific demands of the world’s biggest financial institutions – and solve their key compliance problem.” Tatu Ylönen
Secure Shell governance should be a named item in your risk inventory to ensure that it is risk loaded and prioritized accordingly.
Remediation of your legacy SSH Key environment is essential. Unmanaged SSH Keys lurk under the radar in many organizations until an internal or external audit – or a breach – prompts action.
Deploy privileged access policies and tools that are fit for purpose. Ensure that they align with the day-to-day realities for sysadmins and IT maintenance, the fast pace of DevOps, extend to third parties and subcontractors, and provide a full audit trail and drill downs for ease-of-audit.
For more information about SSH Key management best practice, see https://info.ssh.com/isaca-practitioner-guide
To discuss SSH in your CDE get in touch with one of our SSH.COM experts in confidence here.
