Too often enterprises want to boil the ocean when it comes to reducing risk related to SSH user key based access. In this session, you will learn how to approach SSH user key and access management control and remediation in a controlled risk based approach with minimum disruption to your existing IT operations and processes. We will explore this from the following angles.

1. GAINING THE BENEFITS OF RISK
REDUCTION FOR YOUR SSH KEY
MANAGEMENT PROJECT
15 August 20161
Matthew McKenna
Chief Strategy Officer and VP of Key Accounts

2. WHAT WE WILL COVER
15 August 20162
1. The SSH user key risk equation.
3. The kind of risk we will find.
4. Mitigating risk.
5. Not repeating past sins. Finding an ideal state.
6. Ongoing governance and continuous monitoring. The next chapter.
2. Avoiding pitfalls early on about SSH Key Management.

3. ARE SSH USER KEYS “THE BIG SHORT”
OF THE SECURITY INDUSTRY?
15 August 2016 INTERNAL | SSH Communications Security3

4. THE SSH USER KEY
RISK EQUATION
15 August 2016 INTERNAL | SSH Communications Security4

5. WHY IS THIS THE RISK EQUATION?
15 August 20165
TCP/IP TCP Tunneling
Terminal
SFTPSSH Client SSH Server
Network
SSH Client SSH Server

6. BECAUSE…
15 August 20166
SSH user keys are the only form of access a user
can provision themselves without oversight or
control.
SSH user keys do not have expiration dates.
SSH Keys Credentials Access
= =

7. AN EXAMPLE OF WHAT THIS MEANS?
15 August 2016 INTERNAL | SSH Communications Security7

8. COMBINED WITH…
15 August 2016 | SSH Communications Security8
Supply
Chain/
3rd party
Access
On
Premise
Cloud

9. WHICH LOOKS A LITTLE LIKE THIS…
15 August 20169
• Only 107 Machines scanned
• 1230 User Accounts
• 2583 Public Keys
• 7883 Machine to Machine
connections
• 3993 with target ROOT
• 700 from non-ROOT to
ROOT
• 989 Private key connections
from outside scan
environment
• 72 entering environment as
ROOT

10. PRIORITIZING RISK
15 August 2016 INTERNAL | SSH Communications Security10

11. PRIORITIZING THE RISK
15 August 2016 | SSH Communications Security11
Access
Crypto
Configuration
Management

12. RISK MATRIX
15 August 2016 INTERNAL | SSH Communications Security
12
Risk
Reward
Decommissioned app
keys
DEV to PROD
connections keys
Interactive jump
server bypass
keys
Unauthorized root
trust
Unused Keys
SSH 1
keys
Unknown trusts
Shared private keys
Weak keys
Aged keys
Keys under removed user
accounts
Unauthorized
trusts through
SSH hopping
Unauthorized DBA
keys
Unauthorized trusts
under other system
accounts
Duplicate
keys
Corrupted
keys
Cluster/DR key
synchronization

13. Work
Deskto
p
Critical
Data
External
Computer
EXAMPLE 1: THE JUMP SERVER BYPASS

14. OUR PAM JUMP HOST ARCHITECTURE IS INEFFECTIVE
15 August 2016 INTERNAL | SSH Communications Security14

15. DEVELOPMENT
ENVIRONMENT
PRODUCTION
ENVIRONMENT
EXAMPLE: DEV TO PRODUCT CONNECTION

16. SEPARATION OF DUTIES
15 August 2016 NO CLASSIFICATION | SSH Communications Security16

17. EXAMPLE 3: TRANSITIVE TRUST

18. VISIBILITY OF THE ENTIRE CHAIN IS ESSENTIAL
15 August 2016 INTERNAL | SSH Communications Security18
ServerA
ServerB
ServerC
ServerD

19. AVOIDING
MISCONCEPTIONS
EARLY ON ABOUT SSH
USER KEY
MANAGEMENT
15 August 2016 INTERNAL | SSH Communications Security19

20. THE COMMON MISCONCEPTIONS TO AVOID
15 August 2016 INTERNAL | SSH Communications Security20
We need to focus
most on interactive
users that have
keys
SSH Keys are just
another key to be
managed
If we manage the
private keys we
will have control of
access
Key Rotation is a
must and is highly
important

21. MITIGATING RISK
15 August 2016 INTERNAL | SSH Communications Security21

22. GETTING STAKEHOLDER ALIGNMENT
15 August 2016 INTERNAL | SSH Communications Security22
Security
Operations
Unix
Operations
Executive
Sponsorship
Application
Teams
Other
Distributed
Platforms
Identity and
Access
Management
SSH user key
and access
management

23. ALIGNMENT OF POLICY
15 August 2016 INTERNAL | SSH Communications Security23
Access
Policy
Cryptography
Policy
Configuration
Policy

24. POLICY MATRIX AND RISK PRIORITIZATION BEST PRACTICES
15 August 2016 INTERNAL | SSH Communications Security24
Access
Policy
Cryptography
Policy
Configuration
Policy
1. Key ownership
2. Interactive Access
3. Access to Privileged
Accounts
4. Unused Access
5. Key restriction
6. Segregation of duties
7. Transitive trust
8. Shared private keys
9. DR same as PROD
10. Access mod in PROD
11. Key retirement
1. Private key
passphrase
protection
2. Key Age
3. Key Algorithm
4. Key Size
5. SSH1- Deprecated
keys
1. Key location
2. Key lockdown
3. SSH products in use
4. SSH configuration
a. Sub-channel
b. Root
c. Version
d. Algorithm
e. Timeouts
f. Logging

25. USE CASE VS. RISK ASSOCIATION
15 August 2016 INTERNAL | SSH Communications Security25
1. SA
2. DBA
3. Individual
4. Root
= System Admin login to SSH server
= Database Admin login to SSH
server
= DEV/other login to SSH server
= Root user login to SSH server
Interactive SSH login
using keys
(individual use)
1. Application
2. Monitoring
3. System
= Business app login and performing
app specific task
= Automated system monitoring
application login and performing
application specific tasks
= Automated system administration
tasks login and performing app
specific tasks
Non-interactive SSH
login using keys
(automated/process
usage)

26. BREAKDOWN OF USE CASES ACROSS ENVIRONMENT
15 August 2016 INTERNAL | SSH Communications Security26
1. Prod to prod, non-interactive single application
2. Prod to prod, non-interactive cross application
3. Prod to prod, interactive
4. Non-prod to prod, interactive/non-interactive
5. Unknown to prod, interactive/non-interactive

27. MAP OUT AGAINST RISK IMPACTS
15 August 2016 INTERNAL | SSH Communications Security27
Application
Risk Score
Resilience Risk
Score
3rd Party Risk
Score
Application criticality to the business
Operational impact financially
Are vendors or other outsiders touching this
application?

28. BOIL THE OCEAN VERSUS TARGETED APPROACH
15 August 2016 INTERNAL | SSH Communications Security28
Approach Pros Cons
Discover &
Remediate
Approach
• Gain quick visibility of as much as
possible across as many platforms
as possible
• Eliminate high risk items and quick
wins in fastest time
• Remediation before locked is limited to
users with local home directories or clear
policy violations
Application
Lockdown
Approach
• Stops bleed of unauthorized
provisioning most effectively
• Highest degree of control of
remediation effort
• Requires application team involvement
• Requires effective communication
process and project management for
tracking

29. HIGH LEVEL PROCESS
15 August 2016 INTERNAL | SSH Communications Security29
Discovery Report Monitor Lockdown Remediation Integration Automation Governance
Discover, Assess, Monitor Control and Remediate
Continuous
Governance
Project Design Architecture Design
Documentation
Training
Piloting
Proposal POC Plan Policies Architecture Install Document Testing

30. INTEGRATION TO IAM FRAMEWORK
15 August 2016 | SSH Communications Security30
APP OWNER
HR USER
SSH OWNER
BUSINESS OWNER APP INFO
USER
ACCOUNT APP
& POLICY INFO
KEY DATA
IDM
Key Manager
SOURCE DESTINATION
1. Reconciliation of IAM
and Universal SSH
Key Manager (UKM)
(daily)
2. Account creation
3. Off-boarding – Account
deletion/ ownership
changes
4. Unauthorized key
replacement and key
expiration
5. Account revalidation
USE CASES

31. NOT REPEATING PAST
SINS. THE IDEAL
STATE.
15 August 2016 INTERNAL | SSH Communications Security31

32. NOT REPEATING PAST SINS. THE IDEAL STATE.
15 August 2016 | SSH Communications Security32
Cloud
Environments
‘Legacy’ On Premise Environments
Universal SSH
Key Manager
SSH DevOpsCryptoAuditor
SSH Access
Platform
1. Conversion of
existing
environment to a
central authorized
key repository
(LDAP)
2. Usage of a central location to request
keys as well as map identities to dynamic
resources and containers.
3. Identity
propagation
and
authorization

33. ONGOING
GOVERNANCE,
CONTINUOUS
MONITORING AND THE
NEXT CHAPTER.
15 August 2016 INTERNAL | SSH Communications Security33

34. ONGOING GOVERNANCE. CONTINUOUS MONITORING.
15 August 2016 INTERNAL | SSH Communications Security34
1. Historical Connections
don’t match
2. Key related Operations
don’t match historical
connections
3.. Cryptographic exceptions
outside baseline
configuration
4. User accounts sharing the
same private key
5. Duplicate keys
6. Shared private keys
7. Non-passphrase protected
private keys
8. Number of authorized
keys on target accounts too
high
9. Number of private keys on
target accounts too high
10. Duplicate keys with
varying key parameters
(options, key comments)
11. Non-compliant key
counts start to increase
12. Same authorized key
deployed under multiple
target accounts / ROOT wide
access

35. JUST THE TIP OF THE ICEBERG
15 August 2016 | SSH Communications Security35
National Institute of Standards & Technology
NIST-IR 7966 - Security of Interactive &
Automated Access Management
Using Secure Shell (SSH)
This publication is a public document & free
of charge for all:
http://dx.doi.org/10.6028/NIST.IR.7966

36. JOIN US ON OUR NEXT EPISODE IN OUR EIGHT PART SERIES
15 August 2016 INTERNAL | SSH Communications Security36
Addressing Compliance
Concerns for Your SSH Key
Management Project
http://info.ssh.com/addressing-
compliance-concerns-for-ssh-
key-management
• What are auditors looking for related to SSH user key-based
access?
• What are the requirements of SOX, PCI, Basel II, HIPAA and
others?
• Guidelines for effective policy building, implementation and
control of SSH user key-based access.
• Proactive approaches and reporting outputs to put the auditors
at ease.
September 15th, 2016
8.00 a.m. ET / 1.00 pm GMT
1.00 p.m. ET / 6.00 pm GMT
Fouad Khalil
Director of Compliance