what it auditors need to know about secure shell · • access is allowed if the source user’s...

Copyright 2014 SSH Communications Security Copyright 2014 SSH Communications Security

SSH Communications Security

What IT Auditors Need to Know

About Secure Shell

Copyright 2014 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

SFTP

TELNET

SSH

RCP

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

2) User authentication: Client proves user’s identity to the server

User (SSH Client) Host

(SSH Server)

Network


TCP/IP

Secure Shell Protocol Architecture

• The Secure Shell protocol consists of three

layers:

SSH client

SSH server

Server authentication SSH-TRANS 1.

User authentication (passwords encrypted)

SSH-USERAUTH 2.

Multiplexes SSH tunnel into channels (IMAP, X11, sftp etc.)

SSH-CONNECT 3.

IMAP.

X11


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.

Keys are used for interactive connections

Private key can be protected with a passphrase.

Private

Public

Public

Interactive p

rocesses


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

13

priv

Client (src_host) /home/<src_user>/.ssh

pub

Server (dest_host) /home/<dest_user>/.ssh

pub Copy of Public Key


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 One Many to Many


Agenda


• Security Risks




Uncontrolled Key Scenario

Bob’s office PC

Public key

Private key

Bob creates an SSH key pair & adds public key as a root authorized key - provides an unaudited backdoor to bypass controls on root logins.

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.

Production Server

Bob is authorized to login as root to a production server.

These risks could affect any SSH server, including mainframe systems.


Circumventing Jump Hosts

First Log In

User Logs In to

Server Via Jump Host

User Accesses

Server & Uploads

Public Key

Subsequent

Log Ins

User Bypasses the Jump

Host and Internal Security

Controls Via an SSH Key

User


Backdoors into Mainframes

Mainframe z/OS

Transaction Processing

TRUST

• Copy of public key moved to another user directory on USS

• Public key enables automated access for transaction processing into the IBM mainframe environment.

• Public key allows remote holder of the private key to login as the user on USS and access MVS, without going through RACF

USS MVS

Data bases

AS/400

S/370 TRUST

TRUST


Trust Can Propagate

User

Lost or Stolen SSH key


Abuse of Privileged Channels

Information Assets

Malicious Insider Accesses Servers with Authorized

Keys

Malicious Insider Extracts Information Assets Through Encrypted Tunnel

?


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

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.

A partner’s lax security practices and poor governance—often outside the victim’s control or expertise—are frequently catalysts in security incidents. -

Trusted insiders have the broadest access to the most critical data

Growing number of external business partners, services and other connections will expose critical services to new threats and attacks

DATA BREACH INVESTIGATIONS REPORT


The Threat is Real

24


The Costs are Huge


Agenda


• Security Risks




Compliance Demands Action

Multiple Mandates for Secure Shell Controls

ISO 27002 PCI-DSS

COBIT HIPAA

SOX NERC

NIST 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

Implement Strong Access

Controls

Restrict access to CD on need to know basis

Assign a unique ID to each person

with computer

access

Regularly Monitor and Test

Networks

Track and monitor all access to

network and CD

Regularly test security systems and

processes

Maintain an Information

Security Policy

Maintain a policy that addresses

information security

Build and Maintain a

Secure Network

Install and maintain a

firewall config

Don’t use vendor

supplied defaults for passwords

and security confiigs

Protect Cardholder

Data

Protect Stored

cardholder data

Encrypt transmission of cardholder

data

Maintain a Vulnerability Management

Program

Use and update AV software

Develop and maintain

secure applications and systems

Secure Shell Has Impact Across All Domains of PCI DSS


From PCI Intent to Implementation

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.

Scan servers and review logs to validate the same SSH keys not authorized

to both dev and test

The intent of this requirement is to

separate development and test functions from production functions.

Secure Shell keys used by dev must be removed

before applications moved into production

environments

There are 50 specific PCI requirements where Secure

Shell has impact


Secure Shell Guidance

PCI Controls Secure Shell Guidance

Build and Maintain a Secure Network and Systems (1,2)

Document SSH data flows and trust relationships in and out of CDE. Establish configuration standards for SSH.

Protect Cardholder Data (3,4) Documented processes, controls and management of SSH user and host keys. Ensure only secure versions of SSH are deployed.

Maintain a Vulnerability Management Program (5,6)

Ensure best practices and change control for SSH use and deployment are in place. Remove keys when moving images from test to production.

Implement Strong Access Control Measures (7,8,9)

Review onboarding, offboarding and governance procedures over SSH authorized access to CDE for both interactive and automated use.

Regularly Monitor and Test Networks (10,11)

Implement logging, monitoring and change detection mechanisms for SSH software and keys. Ensure SSH traffic scanned by IDS/IPS.

Maintain an Information Security Policy (12)

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

80% of Identities

Little to no centralized management and activity monitoring over privileged users and machine based identities

Centralized directory services for standard end users


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 day-to-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


w

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

user access

• Failed SOX & MAS Audit


Agenda


• Security Risks




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



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

Compliance |Risk Mitigation |Cost Control

White Papers

Best Practices

Guides and Videos

Assessment Services

Remediation Services

Management & Governance Products & Solutions


Solution Portfolio

Tectia SSH Secure Remote Administration, File

Transfer and Application Connectivity

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

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-ssh-

risk-assessor

Or go to www.ssh.com/resources

http://pages.ssh.com/pcicheatsheet.html

http://pages.ssh.com/pcicheatsheet.html

http://pages.ssh.com/pciwhitepaper.html

http://pages.ssh.com/pciwhitepaper.html

http://pages.ssh.com/ssh-access-pci.html






http://www.ssh.com/resources/free-ssh-risk-assessor








http://www.ssh.com/resources


Growing Awareness of the Problem


Jonathan Lewis

Director of Product Marketing


Thank You

[email protected] 781 247 2106

Lewis Bolla

Regional Sales Manager


[email protected] 914 741 1117

what it auditors need to know about secure shell · • access is allowed if the source user’s...

Documents