Transcript DAMA Presentation Authentication Policy January 13, 2009

DAMA Presentation
Authentication Policy
January 13, 2009
Beyond Passwords....a new way of thinking about Authentication
Tommy Ward, CISSP
Sr Manager, Security
EMC Consulting
© Copyright 2009 EMC Corporation. All rights reserved.
1
Agenda
 What do you mean ‘beyond passwords’
 About Policy
 Authentication options
 How to select from those options
 Homework assignment
© Copyright 2009 EMC Corporation. All rights reserved.
2
One Problem with Passwords
© Copyright 2009 EMC Corporation. All rights reserved.
3
Problems with passwords
 They can be guessed
 They can be shared
 They can be sniffed
 Susceptible to brute force attacks
 They can be phished
 They are often forgotten
 Post-it® Note vulnerability
© Copyright 2009 EMC Corporation. All rights reserved.
4
Interesting Password Trivia
 April 2004 (London)
– >70% revealed their computer
password for a bar of chocolate
– 34% volunteered their password
when asked without even needing
to be bribed
– 79% unwittingly gave away
information that could be used to
steal their identity when questioned
– 33% share passwords
– On average, people have to
remember 4 passwords
© Copyright 2009 EMC Corporation. All rights reserved.
 May 2005 (San Francisco)
– 67% turned over their passwords
for $3 coffee coupons
– 70% of those who said “no way”
gave up significant hints (wife’s
name, anniversary date, pet’s
name)
– 79% said they use the same
password for multiple Web sites
– Nearly 60% have >=4 passwords
– One executive, too busy to stop,
sent his secretary back with his
password so he could get the free
coffee (she gave up hers, too)
5
Beyond Passwords...any day now
 “Given today's networked environments,
CERT recommends that sites concerned
about the security and integrity of their
systems and networks consider moving
away from standard, reusable
passwords.”
 CERT® Advisory CA-1994-01 Ongoing
Network Monitoring Attacks
 Essentially, passwords are obsolete
technology!
If we are all using obsolete technology from the last century,
maybe we have a policy problem.
© Copyright 2009 EMC Corporation. All rights reserved.
6
What is Information Security Policy?
 Widely used term, which means
different things to different people
– Vendors: The configuration files which
determine how our product works
– IT: The ‘rules’ we have to live by
– Security Officer: The rules I need to see
followed
– CEO: Huh?
 Directives regarding information
security, based on best practices and
reflecting business requirements
– Identifies business and regulatory drivers
– Based on risk management principles
– Tailored for each business
 Documented management
decisions regarding protection of
information assets
© Copyright 2009 EMC Corporation. All rights reserved.
7
Information Security Policy Hierarchy
Management states intent, delegates roles
(Board)
Governance
Applicability of Controls
Standards & Procedures
System Configuration Files
© Copyright 2009 EMC Corporation. All rights reserved.
From framework, select appropriate
controls to satisfy intent
(CISO)
Define standard configurations and
processes which implement the controls
(Security Managers)
Configure systems to
enforce the standards
(IT / Operations)
8
Information Security Policy Hierarchy,
Federal version
Used to create an organization's
computer security program
Program
Issue Specific Policy
System Specific Policies
System Configuration Files
Address specific issues of concern
to the organization
Focus on decisions taken by
management
to protect a particular system
Configure systems to
enforce the standards
(IT / Operations)
Source: NIST Special Publication 800-12
© Copyright 2009 EMC Corporation. All rights reserved.
9
How it works – process of policy development
Documentation
collection and
governance
process review
Interviews of key
stakeholders
1
 Review policies, procedures,
organization and administrative controls
 Conduct interviews
2
 Assess business requirements
 Evaluate management processes
and controls
 Define future state for all policy
objectives
Data correlation for
analysis of current
policy maturity
3
Gap analysis and
policy creation /
update
4
 Draft or update policies to reflect all
discovered requirements
5
 Review and explain policy updates in
workshop setting
Socializing with
stakeholders
 Prioritize objectives
 Promulgate complete policy
documents
© Copyright 2009 EMC Corporation. All rights reserved.
10
Security Management Lifecycle, simple
Assessment
Policy
Plan
Audit
Do
Architecture
Design
Check
Incident
Response
Act
Controls
Intrusion
Detection
Logging
© Copyright 2009 EMC Corporation. All rights reserved.
11
Back to Authentication, a Key Control
© Copyright 2009 EMC Corporation. All rights reserved.
12
What is Authentication?
 The essential foundation for trusted
business processes
 Establishes trust by proving the identity
of the participants in a transaction
– The degree of confidence in the vetting
process used to establish the identity
 Needed for critical services
–
–
–
–
Personalization
Access Management
Audit
Identity Management
© Copyright 2009 EMC Corporation. All rights reserved.
13
Types of Authentication Factors
 Something you have
– Examples: one-time password list, grid card, tokencode,
public key certificate and private key
 Something you know
– Example: password, PIN, pass phrase
 Something you are
– Example: biometrics, retina scan
 Combinations of the above
“Strong” authentication requires multiple authentication factors
© Copyright 2009 EMC Corporation. All rights reserved.
14
Contextual Authentication
 Where am I attempting access from?
– Geo location
 New location
 Surface velocity
– IP address
– Workstation
 What time of day am I attempting access?
 What am I trying to do once I establish access?
– The same thing I always do....check balance and transfer some money to
my wife’s account?
– Initiate a wire transfer to a bank in Paraguay?
– Change my mailing address / email address?
 Other factors, TBD
© Copyright 2009 EMC Corporation. All rights reserved.
15
Authentication Taxonomy #1 - Technology
 Biometrics
 One Time Passwords (OTP)
 Smart Chip
 Certificates PKI
 Knowledge based
 Hybrids
Source: adapted from Broadview / Jefferies, “Authentication Market Taxonomy” (10/2004)
© Copyright 2009 EMC Corporation. All rights reserved.
16
Authentication Taxonomy #2 – Security Level
 Level 1 – No identity proof required
– No identity proof required; higher level mechanisms may be used
 Level 2 – Single factor
– ID and password
 Level 3 – Multi-factor
– Soft cryptographic token stored on a computer
– Hard token: cryptographic key stored on a special hardware device
– One time password device based on cryptographic key
 Level 4 – Cryptographic protocol with proof of key possession
– Strong cryptographic authentication based on symmetric or asymmetric cryptography,
all parties must be authenticated
© Copyright 2009 EMC Corporation. All rights reserved.
Source: NIST 800-63
17
How to Choose the right Authentication
 Remember, “One size does not fit all.”
 Group authentication methods by either type of access, or type of assets.
Access Method
Asset
Local login
email
Remote via VPN
file & print services
Web enabled application
Oracle financials
Federated access via partner portal
new product designs
 Consider regulatory and contractual requirements
 Consider risks specific to the access method, and sensitivity of those
assets
 Map requirements to the method/asset, and select appropriate
authentication which meets requirements and your budget
© Copyright 2009 EMC Corporation. All rights reserved.
18
Common Authentication Best Practices
 Passwords: local login to the workstation and LAN
 OTP tokens: remote VPN access to corporate network
 Smart chip (Smart cards): alternative for either of the above, plus facility
access control
 Biometrics: alternative to passwords within corporate environment
 Contextual (Risk Based Authentication): Alternative to passwords for
consumer, web based access
 Out of wallet (Knowledge based): Used for out of band authentication in
one-off situations such as account enablement or credential reset
© Copyright 2009 EMC Corporation. All rights reserved.
19
Authentication Methods:
Advantages and Disadvantages
Authentication
Method
Advantage
Disadvantage
Passwords
Low acquisition cost, ubiquitous
support, minimal user training
required
Least secure, surprising support
costs due to forgotten password
OTP Tokens
High security, portable across
multiple workstations, widely
accepted as strong
Smart Chip
Biometrics
Contextual
Acquisition cost, requires
backend application integration,
lost/stolen token results in
support and cost burden
High security, possible integration Requires card reader, requires
with facilities access control
backend integration, support for
lost/stolen cards
High perceived security, ease of
Cost of sensors, need
use
workaround for ADA compliance,
perceived privacy issues
Stronger than password, less
expensive than other alternatives,
more extensible for fraud
prevention
© Copyright 2009 EMC Corporation. All rights reserved.
Requires custom backend
integration, primarily web only,
variable effectiveness
20
Authentication Policy, general examples
All access to company owned assets will be
appropriately authenticated.
Governance
Applicability of Controls
All remote access to the corporate
network will incorporate strong authentication
Standards & Procedures
All strong authentication will be based
on one time password tokens of
xyz brand / style
System Configuration Files
© Copyright 2009 EMC Corporation. All rights reserved.
# # Restrict access with SecurID #
<Directory /.../private>
AuthType "SecurID"
require valid-user
</Directory>
21
Authentication Policy, specific examples
 Replace the out of date “Password Policy” with policy which addresses
need for multiple levels of authentication strength
 Selection of user authentication to XYZ Corp assets will be based on
recommendations from the CISO, referencing a risk assessment of such
access. Where mandated by government regulation or contractual
obligation, strong authentication based on the XYZ Corp “Standard for
One-Time Passwords” will be implemented. Authentication for login to
local workstations will be via password which complies with XYZ Corp
“Standard for Password Rules”
© Copyright 2009 EMC Corporation. All rights reserved.
22
Rules on Passwords
 Only use where risk assessment indicates it to be appropriate
 Minimum 8 characters
 Mixed case
 Mixed alpha – numeric
 Special characters are good, if supported by the system
 Do not share passwords (special case is root, or other system accounts,
which should be minimized by using account equivalents, sudo, etc)
 Do not use the same password on different systems, especially on
systems of different trustworthiness
 Password aging (lets discuss this later)
 Password history
 Non-dictionary based
 Force a change after privileged user is terminated
 Write them down......
© Copyright 2009 EMC Corporation. All rights reserved.
23
Password Aging
 This is the rule that requires you to
change your password every n days
 Common practice, and codified in most
standards
 But, is it effective....
– Designed to limit time that an attacker has to
guess your password
– Or limit the damage they can do once the
account is compromised
– Backup control in case you forgot to change
passwords after the admin leaves
 Recommendation: Make the duration
as long as your auditors will accept. For
any system that is so critical that you
should change passwords frequently, use
strong authentication instead
© Copyright 2009 EMC Corporation. All rights reserved.
24
Write them down?
 It is not reasonable to expect that users will comply with the rules on
length, uniqueness and complexity and still remember them
 Without a sanctioned tool, users will write them on notepads, keep them
in their wallet, in a Word or Excel file (maybe password protected,
maybe not), or will attempt to circumvent the complexity policy
 Recommendation: If humans can’t remember them, then give them a
tool to keep track of them
 Password Safe is one such tool. Mandate it or something similar.
 Password Gorilla is an alternative.
© Copyright 2009 EMC Corporation. All rights reserved.
25
Homework, Lesson 1
 Who knows where your security policy(s) reside?
– Ask someone to help you find a reference to your company’s password policy.
– How long does it take them to find it?
 If they can’t find it, are they aware of the requirements?
© Copyright 2009 EMC Corporation. All rights reserved.
26
Homework, Lesson 2
 Reviewing security policy, does it address any authentication
requirements other than passwords?
– Remote access
– Privileged account access
– Access to other critical systems
 If it doesn’t address more than passwords, how does stronger
authentication get selected or approved?
© Copyright 2009 EMC Corporation. All rights reserved.
27
Homework, Lesson 3
 Reviewing security policy, does it require complexity, and then say “don’t
write them down”?
– How many sets of account credentials do you have to remember
– How about your employees
– Ask a few admins how many they have and if it is difficult to remember them all
 Maybe the “don’t write them down” needs to be clarified
© Copyright 2009 EMC Corporation. All rights reserved.
28
Homework, Lesson 4
 Reviewing security policy, how do you authenticate user requests for
password resets?
– How many resets do you process?
– Does your helpdesk have any way of verifying the identity of the requestor?
 You may need revised help desk policy, and a system to authenticate
users by phone
© Copyright 2009 EMC Corporation. All rights reserved.
29
Homework, Lesson 5
 What about your personal accounts?
–
–
–
–
–
On-line banking
Utility company
Travel site
Brokerage.
ad infinitum
 Do you have the same passwords for all accounts?
 Do you have complex passwords?
 Can you remember them? (hint: If you are over 40 and can remember
them all, maybe they aren’t complex enough)
© Copyright 2009 EMC Corporation. All rights reserved.
30
References
 Security Policy
– NIST SP 800-12 “An Introduction to Computer Security: The NIST Handbook”
 Authentication
– NIST 800-63 Electronic Authentication Guideline (09/04)
 Federated Identity
– Security Assertion Markup Language (SAML) (www.oasis-open.org)
– Liberty Alliance (http://www.projectliberty.org/)
– SAML and Liberty are merging
 Password Safe http://passwordsafe.sourceforge.net/
 Password Gorilla http://fpx.de/fp/Software/Gorilla/#Credits
© Copyright 2009 EMC Corporation. All rights reserved.
31