What IT Auditors Need to Know About Secure Shell. SSH Communications Security

(1)

SSH Communications Security

(2)

Agenda

• Secure Shell Basics

• Security Risks

(3)

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).

(4)

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

(5)

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

(6)

Secure Shell in the Enterprise

82% OF RESPONDENTS SAID THEIR ORGANIZATION USES SECURE

SHELL.

(7)

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:

(8)

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)

(9)

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.

(10)

Typical Uses for Automated

Connections

• Automated file transfers

• Periodic Database Back-Ups • Collecting Log Files

• Running system statistics/ health checks

(11)

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

(12)

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.

(13)

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

priv Client (src_host) /home/<src_user>/.ssh pub Server (dest_host) /home/<dest_user>/.ssh

(14)

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

(15)

Keys Create Trust Relationships

One to One

One to Many

(16)

Agenda

• Secure Shell Basics

• Security Risks

(17)

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.

(18)

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

(19)

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

(20)

Trust Can Propagate

User

(21)

Abuse of Privileged Channels

Information Assets

Malicious Insider

Accesses Servers

with Authorized

Keys

Malicious Insider Extracts Information

Assets Through Encrypted Tunnel

(22)

Collapse of Separation of Duties

Insiders can easily exploit poor key management controls to gain access to production, HA and back up servers

(23)

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

(24)

The Threat is Real

(25)

(26)

Agenda

• Secure Shell Basics

• Security Risks

• Compliance Requirements

(27)

Compliance Demands Action

Multiple Mandates for Secure Shell Controls

ISO 27002

PCI-DSS

COBIT

HIPAA

SOX

NERC

NIST

FFIEC

(28)

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

(29)

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

(30)

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

(31)

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

(32)

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

(33)

(34)

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

(35)

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

(36)

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*

(37)

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.”

(38)

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

(39)

Agenda

• Secure Shell Basics

• Security Risks

• Compliance Requirements

(40)

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

(41)

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?

(42)

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

(43)

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

(44)

Resources From SSH Communications

Compliance |Risk Mitigation |Cost Control

White Papers

Best Practices

Guides and Videos

Assessment Services

Remediation Services

(45)

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

(46)

(47)

(48)

Jonathan Lewis

Director of Product Marketing SSH Communications Security

Thank You

[email protected] 781 247 2106 Lewis Bolla

Regional Sales Manager

SSH Communications Security