What IT Auditors Need to Know About Secure Shell SSH Communications Security
Agenda Secure Shell Basics Security Risks Compliance Requirements Methods, Tools, Resources
What is Secure Shell? A cryptographic protocol for remote login, remote command execution, and securing file transfer. Available in open source and commercial implementations. Widely used on most systems (Unix, Linux, Mac, Windows, IBM Mainframes). It is client server application
Who Uses Secure Shell? Secure Shell is the tool of choice for privileged users and privileged processes: Systems administrators Contractors, IT Outsourcing Bulk file transfers Automated Processes
Popular Uses of Secure Shell Secure login to remote systems (replace Telnet) Secure file transfer (replace or secure FTP) Secure command execution on a remote host (replace rsh) Secure backup and copy Protocol and application tunneling (RDP) Widely used by system administrators Widely used in many automated machine to machine processes
Secure Shell in the Enterprise 82% OF RESPONDENTS SAID THEIR ORGANIZATION USES SECURE SHELL. 68% CONSIDER IT IMPORTANT OR CRITICAL TO THE BUSINESS
Replacement of legacy tools SSH replaces common connectivity and administration tools with their secure counterparts: FTP TELNET RCP SFTP SSH SCP Allows the use of variety of security algorithms and authentication methods: AES, 3DES, Blowfish etc. (variety of key sizes) Password, GSSAPI, PKI etc.
SSH authentication: The essentials 1) Server authentication: Server proves its identity to the client Network User (SSH Client) Host (SSH Server) 2) User authentication: Client proves user s identity to the server
Secure Shell Protocol Architecture The Secure Shell protocol consists of three layers: 3. SSH-CONNECT Multiplexes SSH tunnel into channels (IMAP, X11, sftp etc.) 2. 1. SSH-USERAUTH SSH-TRANS User authentication (passwords encrypted) Server authentication SSH client TCP/IP X11 IMAP. SSH server
Typical Uses for Automated Connections Automated file transfers Periodic Database Back-Ups Collecting Log Files Running system statistics/ health checks Executing remote commands, starting business processes
Secure Shell Security The Good: Provides confidentiality (encryption) for data transfers Enables secure systems administration Enables secure process automation (machine to machine) The Bad: Authentication keys can be an attack vector for both malicious insiders and external threats Can be used to obscure data theft Can enable other unauthorized activities
Secure Shell Authentication Keys A Key pair, consisting of a private and public key Private Key is an Identity Key. It validates identity of the person or process requesting login. Public Key is an Authorized Key. Establishes what level of access is granted to the holder(s) of the Private/Identity Key. Keys are used for automated processes Enables authentication for scheduled and automated file transfers and other tasks where user interaction is not possible. Interactive processes Private Public Keys are used for interactive connections Private key can be protected with a passphrase. Public
Generating and Adding Keys Generating a key produces two files: private key and public key To allow a connection, the source user s public key is copied to the destination user s authorized keys file on the destination server Access is allowed if the source user s home directory on the source host contains a private key that matches to a public key within the destination user s authorized keys file on the destination host Client (src_host) /home/<src_user>/.ssh Server (dest_host) /home/<dest_user>/.ssh priv pub Copy of Public Key pub 13
Identity Keys and Authorized Keys Identity (Private) Keys Identity keys reside on source systems (ssh clients) Identity keys are associated with a user only because they are stored in the user s home directory (or another accessible directory) Authorized (Public) Keys Authorized keys exist on destination systems (ssh servers) Define the Identity keys that are allowed to connect A user s authorized keys file contains all public keys that are allowed to connect as that user on a particular SSH server Authorized keys create a trust relationship: anyone who can provide the private key associated with a user s authorized public key is permitted to connect to the system as that user 14
Keys Create Trust Relationships One to One One to Many Many to Many Many to One
Agenda Secure Shell Basics Security Risks Compliance Requirements Methods, Tools, Resources
Uncontrolled Key Scenario Bob s office PC Production Server Bob is authorized to login as root to a production server. Bob creates an SSH key pair & adds public key as a root authorized key - provides an unaudited backdoor to bypass controls on root logins. Private key Public key Bob makes a copy of private key, installs it on his home computer. Connects from home. Bob shares his private key with Bill. Bill leaves the company, keeps the private key. Bob s home computer is hacked. Private key taken by an attacker. These risks could affect any SSH server, including mainframe systems.
Circumventing Jump Hosts User Logs In to Server Via Jump Host User Accesses Server & Uploads Public Key First Log In User Subsequent Log Ins User Bypasses the Jump Host and Internal Security Controls Via an SSH Key
Backdoors into Mainframes Mainframe z/os Data bases Transaction Processing TRUST TRUST S/370 USS TRUST MVS AS/400 Public key enables automated access for transaction processing into the IBM mainframe environment. Copy of public key moved to another user directory on USS Public key allows remote holder of the private key to login as the user on USS and access MVS, without going through RACF
Trust Can Propagate Lost or Stolen SSH key User
Abuse of Privileged Channels Malicious Insider Extracts Information Assets Through Encrypted Tunnel Information Assets? Malicious Insider Accesses Servers with Authorized Keys
Collapse of Separation of Duties Insiders can easily exploit poor key management controls to gain access to production, HA and back up servers What you think you have What you really have
Privileged Channel Risk Trusted insiders have the broadest access to the most critical data We hypothesize that many insider crimes go unreported because the organization is unaware of them, or because they decide for political reasons to handle it internally. Growing number of external business partners, services and other connections will expose critical services to new threats and attacks DATA BREACH INVESTIGATIONS REPORT A partner s lax security practices and poor governance often outside the victim s control or expertise are frequently catalysts in security incidents. -
The Threat is Real 24
The Costs are Huge
Agenda Secure Shell Basics Security Risks Compliance Requirements Methods, Tools, Resources
Compliance Demands Action Multiple Mandates for Secure Shell Controls ISO 27002 PCI-DSS COBIT SOX NIST HIPAA NERC FFIEC Secure Shell Has Impact Across All Domains
PCI Version 3 More Flexibility in implementation More Guidance on intent of requirements More Rigor in testing procedures Emphasis on Business as Usual (BAU) processes. From: Compliance as an annual event Companies fall out of compliance in between audits To: Compliance as Business as Usual Sound security practices always in effect
PCI Version 3 and Secure Shell Requirements pertaining to Secure Shell are pervasive across all domains PCI Requirements and Guidance focused on intent, not on technology Requirement The security mandate Intent The purpose of the mandate Guidance Where SSH Applies
PCI DSS 3.0 Structure Build and Maintain a Secure Network Protect Cardholder Data Maintain a Vulnerability Management Program Implement Strong Access Controls Regularly Monitor and Test Networks Maintain an Information Security Policy Install and maintain a firewall config Don t use vendor supplied defaults for passwords and security confiigs Protect Stored cardholder data Encrypt transmission of cardholder data Use and update AV software Develop and maintain secure applications and systems Restrict access to CD on need to know basis Assign a unique ID to each person with computer access Track and monitor all access to network and CD Regularly test security systems and processes Maintain a policy that addresses information security Secure Shell Has Impact Across All Domains of PCI DSS
From PCI Intent to Implementation There are 50 specific PCI requirements where Secure Shell has impact Requirement 6: Develop and Maintain Secure Systems and Applications Requirement 6.4: Follow change control processes and procedures for all changes to system components. Requirement 6.4.2: Separation of duties between development/test and production environments Testing Procedure 6.4.2: Observe processes and interview personnel to verify that separation of duties is in place between dev & prod. The intent of this requirement is to separate development and test functions from production functions. Scan servers and review logs to validate the same SSH keys not authorized to both dev and test Secure Shell keys used by dev must be removed before applications moved into production environments
Secure Shell Guidance PCI Controls Build and Maintain a Secure Network and Systems (1,2) Protect Cardholder Data (3,4) Maintain a Vulnerability Management Program (5,6) Implement Strong Access Control Measures (7,8,9) Regularly Monitor and Test Networks (10,11) Maintain an Information Security Policy (12) Secure Shell Guidance Document SSH data flows and trust relationships in and out of CDE. Establish configuration standards for SSH. Documented processes, controls and management of SSH user and host keys. Ensure only secure versions of SSH are deployed. Ensure best practices and change control for SSH use and deployment are in place. Remove keys when moving images from test to production. Review onboarding, offboarding and governance procedures over SSH authorized access to CDE for both interactive and automated use. Implement logging, monitoring and change detection mechanisms for SSH software and keys. Ensure SSH traffic scanned by IDS/IPS. The risk assessment process should consider the state of SSH key management and loss of defense in depth resulting from unmanaged SSH keys (e.g., risk of attack spread into disaster recovery systems and backup systems).
Current State Analysis
The Identity Governance Gap 20% of Identities Centralized directory services for standard end users 80% of Identities Little to no centralized management and activity monitoring over privileged users and machine based identities
Typical Enterprise Current State No visibility as to who has access to what Secure Shell servers No tools or methods to remove keys. Onboarding and off boarding issues No tools of methods to restrict or rotate the private keys Errors in manual key setups and maintenance
Security and Compliance Challenge Many organizations said that they are not monitoring & logging SSH activities Only 44% indicated that they have visibility into how many SSH keys are deployed in their environment, and what those authorizations are used for Based on real world experience, most organizations only have visibility into interactive user activities* (*Based on security audits performed by SSH Communications Security)
Circumventing Security In my day-to-day work, I have found that many users are frustrated by new security imperatives imposed by network managers. Although users understand the need for additional security, these restrictions cause significant bottlenecks to productivity. While these users are technically literate, network services setup and firewalls are not a normal part of their knowledgebase. This article describes the setup of a simple SSH client connecting to an AIX or Linux -based SSH server that allows a typical, technically literate individual the ability to set up, configure, and operate a flexible means of tunneling data and services over the SSH service. Users will benefit from having control of their own environment and the ability to adapt to their dayto-day needs. Administrators will benefit from reduced user requests to open ports and tighter control of their secure environments as a result. https://www.ibm.com/developerworks/aix/library/au-tunnelingssh/#icomments
Case Study: Top 5 Global Bank Over 20,000 servers on their network 1.5 million Secure Shell User Keys identified 10% or 150,000 User Keys were unknown AND ALSO HAD ROOT ACCESS No ability to monitor and enforce Secure Shell w user access Failed SOX & MAS Audit
Agenda Secure Shell Basics Security Risks Compliance Requirements Methods, Tools, Resources
What Auditors Need to Know The need to manage and control Secure Shell Use, configurations, and identities is pervasive across PCI DSS PCI DSS focuses on intent, not specific technologies. Auditors need understand the connection between PCI intent and how Secure Shell is used in PCI environments Customers want to comply to PCI and want better security Understand the Environment Identify Areas to Investigate Gather Information
Ask The Right Questions Do you use Secure Shell in your Card Holder Data Environment? Are there documented policies governing the deployment and use of Secure Shell? Do you have both interactive and automated accounts with Secure Shell access? Is Secure Shell allowed into and/or out of your network? Who has access and for what purposes? Do the configurations of sshd and authorized key files align with your policies? How do you track and manage Secure Shell software and configurations? How do you authenticate Secure Shell sessions? Do you use Secure Shell User Keys? How are the keys managed? Can users add their own keys? Do you regularly scan the environment for ssh keys? Ssh configs?
Focus Areas Scan the user key and ssh client server environment Review the sshd_config files Review sshd software versions Review authorized key file set ups Review firewall rules for where port 22 allowed Review network drives (NFS) set ups
SSH Communications Security Quick Facts: Inventors of the SSH protocol Listed: NASDAQ OMX Helsinki (SSH1V) 3,000 customers including 6 of the 10 largest US banks What We Do: Secure Shell Access Controls & Key Management Privileged Access Management Data-in-Transit Encryption SSH COMMUNICATIONS SECURITY IS THE MARKET LEADER IN DEVELOPING ADVANCED SECURITY SOLUTIONS TO MEET TODAY S BUSINESS, SECURITY AND COMPLIANCE REQUIREMENTS IN ENCRYPTED NETWORKS.
Resources From SSH Communications Management & Governance Products & Solutions Assessment Services Remediation Services White Papers Best Practices Guides and Videos Compliance Risk Mitigation Cost Control
Solution Portfolio Universal SSH Key Manager Enterprise Wide Identity and Access Management for Secure Shell. Discover, Monitor, Remediate and Manage SSH Keys and configurations CryptoAuditor Monitoring, Control and Content Awareness for Encrypted Networks Tectia SSH Secure Remote Administration, File Transfer and Application Connectivity MobileID Fast and Easy Two Factor Authentication Across the Enterprise
Links to Resources http://pages.ssh.com/pcicheatsheet.html http://pages.ssh.com/pciwhitepaper.html http://pages.ssh.com/ssh-access-pci.html http://www.ssh.com/resources/free-sshrisk-assessor Or go to www.ssh.com/resources
Growing Awareness of the Problem
Thank You Jonathan Lewis Director of Product Marketing SSH Communications Security jonathan.lewis@ssh.com 781 247 2106 Lewis Bolla Regional Sales Manager SSH Communications Security lewis.bolla@ssh.com 914 741 1117