Simple errors, old and weak cryptography, and alarming, malicious attacks are turning digital certificates and encryption keys into an expressway to downtime, targeted attacks, failed compliance, and data breaches. Fortunately, there are simple steps you can take to make sure your organization doesn’t fall victim. From online banking to the production line, thousands of certificates and keys in every enterprise are the difference between controlling success or failure. In this live webinar, learn how enterprises are using NIST and industry best practices to develop an effective Enterprise Key and Certificate Management strategy. Go to http://www.venafi.com/five-musts-ekcm/ to view the full On Demand Webinar.

1. 5 Must Haves to Prevent
Encryption Disasters
Prepared for:
Intelligent People
1
© 2013 Venafi

2. Agenda
• Brief review of major enterprise key and
certificate management challenges
• Best practices…
– Preventing downtime
– Increasing private key security
– Preparing for and responding to CA
compromise
• Q&A
2
© 2013 Venafi

3. Certificate and Key Management
Challenges
Certificate Authorities
3
© 2013 Venafi

4. Setting Up for Success
EKCM is Cross-Functional
Auditor InfoSec
• Internal Policies • Data Security
• External Regulations • Policy Enforcement
• Separation of Duties • Compliance Reporting
• Compliance • Audit Readiness
• Reporting
Admin
Datacenter
CA
Manager
Manager Admin
Admin
App
Owners
IT Operations
• System Availability Admin
• Operational Efficiency
• Best Practices Biz Units
• Monitoring • SLAs
• Management • Speed of Deployment
• Config Automation • Reporting
• Cost of Service
4

5. Roles/Stakeholders
• PKI admin(s)
• System administrators
• Business application owners
• Network team
• Auditors
• Executives
• NOC
• SOC
• Help desk
• …
5
© 2013 Venafi

6. Recipe for Disaster
PKI Admin
System Administrators
6
© 2013 Venafi

7. Preventing Downtime Due to
Certificate Expirations
7
© 2013 Venafi

8. Causes of Downtime
Operational causes:
1. Poor inventory, tracking, and
management of certificates
• End entity certificates
• Intermediate roots Technical causes:
• Roots • End entity certificate
2. Poor Execution expires
• Correct administrators NOT • Intermediate root
notified of impending certificate expires
expiration • Root certificates not
• Administrators notified but no updated on relying
action taken parties
• Renewed certificates not
properly installed
• Certificates installed but
applications not restarted
8
© 2013 Venafi

9. High-level Steps for Preventing
Downtime
 Create an inventory
 Check for certificates expiring imminently
 Compile and maintain contact information
for each certificate/key
 Monitor for expiration and notify
 Validate certificate/key installation and
operation
 Report
9

10. Establishing a Comprehensive Inventory
Internal &
Systems with External CAs
3 Agent-based
Certificates Discovery
Certificate
Inventory
A
A Database
1 Import
A
from CAs
A
A 4 Individual Import
A by Admins
2 Network
A Discovery
A
A
Network
Discovery
A - Agents Engines
10

11. Establishing Initial Ownership
Notify Groups
Certificate Authorities Certificate Inventory
Database
5 4
1 Export Maintain Notify
3 Import
Certificate Contact Turn into Certificate Contact
2 Logical
www.abcd.com rex@abcd.com Groups www.abcd.com IT
finance1.abcd.com ethel@abcd.com finance1.abcd.com Finance
ecom.abcd.com rex@abcd.com Finance ecom.abcd.com IT
mktg-4.abcd.com lester@abcd.com mktg-4.abcd.com Marketing
IT
hr1.abcd.com leroy@abcd.com hr1.abcd.com HR
dmz-34.abcd.com rex@abcd.com HR dmz-34.abcd.com IT
acctg.abcd.com ethel@abcd.com acctg.abcd.com Finance
Marketing
pr-fud.abcd.com lester@abcd.com pr-fud.abcd.com Marketing
brain.abcd.com bubba@abcd.com ThinkTank brain.abcd.com ThinkTank
cto.abcd.com bertha@abcd.com cto.abcd.com IT
11
© 2013 Venafi

12. Ongoing Ownership Management
• System administrators are regularly reassigned
• It is critical to have up-to-date ownership information
for…
– Expiration notifications
– Notifications in case of compromise or algorithm breakage
– Other communications
• Invalid notification is worse than no notification at all
Terminated
Inventory system
Reorg
must enable
System Admins to
maintain ownership
information
12
© 2013 Venafi

13. Notify on Expiration
Reports
Expiring < 15 days
www.venafi.com 2/15/13
ecom.venafi.com 2/17/13
mktg.venafi.com 2/19/13
eng.venafi.com 2/29/13
Expiring <30 days
srv1.venafi.com
srv2.venafi.com
3/15/13
3/17/13 Emails Escalations
srv3.venafi.com 3/19/13
srvi4.venafi.com 3/29/13
Yo! Career
Expiring <90 days
srv5.venafi.com 5/15/13
Whassup? limiting…
srv6.venafi.com 6/17/13
90 60 30 15 10 5
Expired
13
© 2013 Venafi

14. Expiration Notifications Alone Don’t Cut It
Cert in service Cert in
(e.g. on network) keystore
time 1. Steady 2. New Cert 3. New Cert 4. App Reset x. Old Cert
State from CA Installed for New Cert Expires
Old Cert.
New Cert
Application
Renewal
Window
14
© 2013 Venafi

15. Monitoring and Validation
Onboard
Validation
Notifications
Network Mismatch
KeystoreMismatch
Certificate Expiring
Network Validation
New Cert New Cert App Uses Old Cert
from CA Installed New Cert Expires
Old Cert.
New Cert
Application
Cert Expiration
Alerts
…
90 60 30 days Keystore
Mismatch Events
Network
Mismatch Events
15
© 2013 Venafi

16. Private Key Security
16
© 2013 Venafi

17. Putting Private Keys at Risk
Same password
used on multiple
keystores.
Private keys and Keystore 2
passwords are not Password = abc123
changed when admins Keystore
leave the organization passwords are not
changed regularly.
Keystore 1
Password = abc123
Server
Server
Performance Monitoring
Customer Experience Monitoring Admins manually
manage private keys,
Security Monitoring making it possible to
copy them.
Private keys are
manually passed to
other groups/admins
for distribution.
17
© 2013 Venafi

18. Preventative Measures
• Implement hardware security modules
(HSMs)
– Considerations:
• Cost (initial and ongoing)
• Application compatibility
• Migration time
• Intermediation (separate admins from
keys)
18
© 2013 Venafi

19. Establishing EKCM Policies
Eliminating Admin Access to Keys
Ensure support for Remove direct administrator
secure distribution access to private keys through
across multiple automation. Maintain complete
platforms and store audit log of all
types. operations.
Web Server
Provide console for private key and
certificate management.
• Separate credentials for login
• Granular access rights – separation
of duties
• No access to private keys unless
required
• Dual control (oversight)
• Admin entitlement reporting
• Audit trail of admin operations
19
© 2013 Venafi

20. Preparing for and
Responding to CA
Compromise
…and other eventualities
20
© 2013 Venafi

21. CA Compromise and
Fraudulent Certificate Scenarios
Root CA Compromise:
Hacker is able to issue
fraudulent certificates from CA Key Theft: Stolen or
E Root CA (via system or derived copy of CA private
signing key compromise).
D key is used to issue
Root
fraudulent certificates.
CA
CA System
Compromise:
Malware or other
infiltration used to get
fraudulent certificate
signed by CA
RA Compromise: CA
(without getting copy
Infiltrate RA or steal
of CA private key).
credentials and authorize
fraudulent certificates. B C
Impersonation:
Trick RA into issuing RA
a fraudulent
certificate. A
Subject
Hacker
21
© 2013 Venafi

22. High Level Considerations
• Preventing CA compromise
– Use and maintain high security for CA(s)
– Mandate regular audits
• Detecting rogue certificates
– Anomaly and fraud detection on all
applications
• Replacing certificates after a CA
compromise…
22
© 2013 Venafi

23. Recent Public Certificate Authority &
Counterfeit Certificate Incidents
Year Incidents
• VeriSign issues Microsoft Corporation code signing
2001 certificate to a non-Microsoft employee.
• Thawte issues certificate for Live.com to non-Microsoft
employee
2008 • Comodo issues mozilla.org certificate to Startcom
• Organization forges VeriSign RapidSSL certificates
• Comodo issues nine counterfeit certificates (Google, Yahoo,
Live, etc.) when registration authority is compromised.
• StartSSL CA compromised
2011 • DigiNotar compromised. 531 fraudulent certificates issued.
Dutch government experiences major service outages.
• Boeing CA compromised
2012 • Microsoft CA certificates forged by exploiting MD5 (Flame)
2013 • Buster Paper Comercial gets code signing certificate
* Electronic Freedom Foundation uncovers many more unpublicized CA
23 incidents by analyzing CRLs from public CAs
© 2013 Venafi

24. NIST Alert on CA Compromise
http://csrc.nist.gov/publications/nistbul/july-2012_itl-bulletin.pdf
These recent attacks on CAs make it imperative that organizations ensure they
are using secure CAs and are prepared to respond to a CA compromise or
issuance of a fraudulent certificates.
- NIST, July 2012
24

25. CA Compromise & Counterfeit Certificate
and Remediation Matrix
Remove Root
Revoke Cert from
Counterfeit Revoke CA Replace All Relying
Certificates Cert Certs from CA Parties
A. Impersonation
B. RA Compromise
C. CA System
Compromise
D. CA Signing Key
Compromise
E. Root CA
Compromise
25
© 2013 Venafi

26. Detailed Steps for Preparing for & Responding
in the Venafi Best Practices Document
Preparing for a CA Compromise
Relying a. Review CA Security and Communications: Once you have a complete list a. Certificate Replacement Plan: If a CA is compromised, that CA’s certificate a. Revocation Checking: Ensure that revocation checking is enabled and
Preparatory Steps CA Subject Party of all CAs in use in your environment—which may involve replacing must be revoked and all of the certificates issued by the CA become invalid mandatory (i.e. operations or transactions cannot proceed if the status of
a. Develop, Communicate, and Track Compliance with Certificate certificates from unapproved CAs—review the security practices for each and must be replaced. In environments with large numbers of active the certificate cannot be checked due to an unavailable CRL or OCSP
Policies and Procedures : The installation and management of CA (internal and external) to assure yourself that the CAs are minimizing certificates, large‐scale replacements can be very disruptive and can cause responder). All standard builds and images (e.g. operating systems and 
certificates and private keys is generally very distributed within the risks of compromise. Review how each CA is monitored for potential operations to stop for extended periods of time. Therefore, it is critical to applications) should have revocation checking enabled. In addition,
enterprises, where installation and oversight typically falls to the compromise and the response and communication plans in place in case of have a well‐defined plan for replacing certificates in a rapid yet orderly wherever possible, application configuration management systems should
each administrator responsible for the machines and applications a compromise. Ensure that the CA knows who within your organization to  fashion. be used to ensure that revocation checking is not turned off.
where the certificates are deployed. This increases the possibility contact. It is important to review the security of your CAs (internal and
   b. Overall Response Plan: Organizations must have an overall CA
that best practices will not be followed. Consequently, it is important external) on a periodic basis.
An inventory and list of owners serve as the foundation for a rapid
to define, communicate, and educate personnel on clear policies and compromise response plan. This plan must identify key points of contact
response by ensuring that all certificate owners can be contacted when a
procedures. Recommendations for these policies and procedures are (who should be contacted first in case a compromise is detected),
Ensure that you are not using a root CA to issue end‐entity certificates. If a compromise occurs. Certificate owners must also understand the steps for
provided in the preparation steps below as well as other best delineate roles and responsibilities, provide a communications plan (to  
root is being used to issue end‐entity certificates, replace those certificates replacing certificates. However, since many certificate owners do not 
Subjects, Relying Parties, executives, etc.), specify a certificate
practices from Venafi. with certificates from an Intermediate CA. perform certificate operations frequently, they will likely need assistance. 
replacement plan, provide a CA migration plan, and support other
b. CA Transition Plan: If a CA is compromised, you must obtain certificates It is therefore important to have a plan for staffing a help desk to handle
b. Establish and Maintain Certificate Inventory: An important step in elements described in this document.
from another CA. It is best to have plans in place for the new CA before a the large number of support requests as all certificates are replaced. If high
preparing for a CA compromise is building a comprehensive inventory
CA compromise occurs. For external CAs, it may good to maintain a priority systems and certificates have been identified during the inventory
of the certificates and private keys deployed in your environment.
relationship with multiple CAs so that contractual relationships are in place process, the replacement plan should also include steps for ensuring those
This includes tracking precisely which CAs are used by which 
prior to a CA compromise event that requires you to move away from a certificates are replaced early in the process.
platforms and applications so that appropriate action can be taken if
one of them is compromised. A comprehensive inventory also vendor entirely. For internal CAs, implement a plan for rapidly establishing Finally, it is important to have a method for monitoring the replacement of
enables you to identify all certificates that need to be replaced in the a new CA in the event of a compromise. certificates so that it is clear which systems are not safe, where problems
case of a compromise and to validate that they are actually replaced. are occurring and when the process is complete. This monitoring and
c. Education: Responding to a CA compromise involves multiple stakeholders
tracking also makes it possible to report back to executives and other
and roles. A response will be more successful if individuals in each of those
stakeholders. A target timeframe should be set for the amount of time
A good first step in establishing an inventory is requesting a list of roles are educated beforehand. Here are some examples:
required to replace certificates and get systems and business applications
issued certificates from your known CAs. However, this may not a. CA Management Personnel: Provide education on monitoring for
back in operation.
account for all certificates in use in your environment, as some compromise events and procedures for taking remedial action
systems might use other, unknown CAs or self‐signed certificates of b. Root Inventory: Establish an inventory of all roots that are trusted in your
(including communication plans) if a compromise occurs.
organization and establish a plan for replacing them if necessary. This step
which you are not aware. It is often prudent to perform a manual  b. Certificate Owners (Subjects): Ensure that all certificate owners
is important in case a root CA is compromised and a root must no longer 
inventory (asking all administrators to report the certificates they are understand the consequences of a CA compromise and the
responsible for) or automated inventory (performing automated be trusted.
importance of maintaining up‐to‐date contact information so that
network and/or file scans to discover certificates). they can be notified in case of a compromise. In addition,
  
certificate owners should understand the steps they would take to
rapidly replace their certificate(s) if a compromise occurs.
While creating an inventory, it is critical to identify owners for each
c. Relying Parties: Ensure that all Relying Parties (i.e. owners of
certificate and contact information. This enables you to rapidly
systems that check certificates to authenticate or communicate
contact all appropriate owners if a compromise occurs so they can
with other systems) understand the importance of configuring all
take action. Because certificate deployments and owners change, it is
systems to check revocation status. These checks ensure that
important to implement a system for keeping inventory and
systems do not trust certificates that have been revoked by the
ownership information up to date.
issuing CA. If revocation checking is interfering with operations,
Relying Parties should notify the central PKI organization to
determine ways of addressing the issues without disabling the
You should periodically analyze the collected inventory data. Then
CA Key or System
Impersonation RA Compromise Compromise Root CA Compromise
Relying Relying Relying Relying
Steps CA Subject Party Steps CA Subject Party Steps CA Subject Party Steps CA Subject Party
a. Revoke the Fraudulent Certificate a. Revoke the Fraudulent Certificate a. Revoke the certificate of the compromised CA. a. Revoke all non‐expired certificates issued from the CA and issue a
  
final CRL. 
b. Notify the Subject of the Fraudulent Certificate b. Revoke the credentials of the compromised RA (issuing new b. Establish a point of contact or help desk to answer questions and
  
credentials if the RA will resume its duties).  provide support.  b. Establish a point of contact or help desk to answer questions and
c. Notify potential Relying Parties to ensure they are checking for provide support.   
revocation. This notification may be provided through direct c. Carefully check all logs to ensure that all fraudulent certificates c. Notify all Subjects who have been issued certificates from the

communication or public relations announcements. have been identified and revoked.  compromised CA that their certificate will need to be replaced and c. Notify all CAs that have been issued certificates from the root CA

provide instructions. that those CAs are no longer valid. Ensure they contact the Subjects
d. Notify vendors of software or systems used by Relying Parties (e.g. d. Notify the Subject(s) of the Fraudulent Certificate(s)
 to whom they have issued certificates that those certificates are no 
browsers). If the potential use of the fraudulent certificate will have d. Notify potential Relying Parties to ensure they are checking for longer valid and must be replaced.
a high impact, it may make sense for software and system vendors  e. Notify potential Relying Parties to ensure they are checking for revocation. This notification may be provided through direct 
to explicitly block the use of the fraudulent certificate. revocation. This notification may be provided through direct 
 communication or public relations announcements. d. Notify vendors of software or systems that include the certificate
communication or public relations announcements. for the compromised root CA in their product trust stores that the
e. Ensure that revocation checking is enabled and mandatory (i.e. 
e. Notify vendors of software or systems used by Relying Parties (e.g. certificate must be removed.
operations or transactions cannot proceed if the status of the f. Notify vendors of software or systems used by Relying Parties (e.g.
browsers). If the potential use of the fraudulent certificate will have
certificate cannot be checked due to an unavailable CRL or OCSP  browsers). If the potential use of the fraudulent certificate will have e. Notify all Relying Parties to inform them that the root certificate for
a high impact, it may make sense for software and system vendors 
responder). a high impact, it may make sense for software and system vendors 
to explicitly block the use of the fraudulent certificate. the compromised root CA must be removed from their trust stores.
to explicitly block the use of the fraudulent certificate. This notification may be provided through direct communication or 
f. Replace all certificates from the compromised CA with new public relations announcements.
g. Ensure that revocation checking is enabled and mandatory (i.e.
certificates from a different CA. For internal CAs, this may involve
operations or transactions cannot proceed if the status of the  f. Notify all Subjects who have been issued certificates from the
setting up a new CA. For external CAs, this may involve enrolling for
certificate cannot be checked due to an unavailable CRL or OCSP 
new certificates. compromised CA that their certificate will need to be replaced and
responder). 
provide instructions.
g. Inform all potential Relying Parties of the new CA that will be used. 
g. Replace all certificates from subordinates of the compromised root
h. If a new root is required to validate the new certificates, make it CA with new certificates from different CAs. For internal CAs, this
available for secure distribution to all potential Relying Parties.  
may involve setting up a new CA. For external CAs, this may involve 
enrolling for new certificates from a different CA from the same
i. If a new root certificate is required to validate certificates, install
 vendor or selecting a different vendor.
this root certificate in all necessary trust stores.
h. Inform all potential Relying Parties of the new CA that will be used. 
j. Ensure that revocation checking is enabled and mandatory (i.e.
operations or transactions cannot proceed if the status of the i. If a new root CA is established, make the root certificate for the
certificate cannot be checked due to the unavailability of the CRL or 
new CA available for secure distribution to all potential Relying 
OCSP responder.) 
Parties.
k. Track the replacement of certificates through the completion of the j. If a new root certificate is required to validate certificates, install
process.  this root certificate in all necessary trust stores. 
k. As an ongoing precaution, ensure that revocation checking is
enabled and mandatory (i.e. operations or transactions cannot 
proceed if the status of the certificate cannot be checked due to the
26
© 2013 Venafi

27. Preparing for a CA Compromise
Document Clear
Ensure only Approved A Certificate
Roots are Trusted K Policies
Inventory Root CAs
that are Trusted on Create CA
Relying Party Systems J B Compromise
Response Plan
Enforce Revocation
Checking on Relying I Educate all
C Stakeholders
Party Systems
Systems Trusting CAs
Certificates D
(Relying Parties) Review CA
Security and
Systems Where E Communications
Policies
Certificates are F Establish
Installed (Subjects) Inventory Backup CA
Server-side Plans
G and Client-
Certificate
Verify that side Certs
Owners
only Approved
H CAs are used.
Identify Cert Owners
(Subjects) and
Relying Parties
27
© 2013 Venafi

28. Responding to a CA Compromise
Validate That Revocation Validate
Checking is Enabled on Cert & Root Establish Clear
Relying Party Systems
G H Understanding of
Replacement
A What Occurred
(What Type of
Compromise, etc.)
B Activate Help
Desk
Track and
I Report on
Remove/ F Progress
Replace
Root
Certificates Replace E Revoke
Certificates C Certificates &
Establish New
CA(s)
D
Notify Subjects,
Relying Parties,
and Vendors
28
© 2013 Venafi

29. The Threat is Evolving
Stuxnet CA Compromises Adobe
Duqu Flame Buster
Attackers stole private Attackers Attackers exploited
keys from two compromise or dupe MD5 to create a face
Taiwanese companies certificate authorities Microsoft CA
and Adobe to sign to issue fraudulent certificate and then
code. certificates for further sign code.
attacks.
Hackers are increasingly targeting public key infrastructure
for attacks because it is a broadly used security mechanism.
Poor certificate management practices
put you at risk.
29
© 2013 Venafi

30. Diagram of PKI Ecosystem
Root
CA
Issuing CA
Certificate
Issuing
CACA
Registration CRL
Authority
CRL
OCSP
Responder
End Entity
Certificate CRL
Distribution
Subject Point
Root
Relying Certificate
Party
30
© 2013 Venafi

31. Certificate and Key Management
Challenges
Certificate Authorities
31
© 2013 Venafi

32. Summary of Best Practices
• Create an inventory
• Analyze the inventory and policy
compliance
• Compile and maintain ownership
information for each certificate/key
• Monitor, validate, and notify
• Manage enrollment
• Optimize and secure provisioning
– Private Key Management
• Educate all stakeholders
32

33. Next Steps
• Attend the third part of this
webinar series: “Establishing
EKCM policies and Ensuring Today’s Presentation
Compliance”
Mar 21, 11am EST, 8am PST, 4pm GMT
• Download NIST’s ITL Bulletin:
“Preparing for and Responding
to CA Compromise” NIST ITL Bulletin
www.venafi.com/NIST
• Questions?
– Paul Turner
33 info@venafi.com
© 2013 Venafi. All rights reserved.

34. Unpublished Work of Venafi, Inc. All Rights Reserved.
This work is an unpublished work and contains confidential, proprietary, and trade secret information of Venafi, Inc. Access to this work is restricted to Venafi
employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied,
distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Venafi, Inc. Any use or
exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.
General Disclaimer
This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. Venafi, Inc. makes no
representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or
fitness for any particular purpose. Further, Venafi, Inc. reserves the right to revise this document and to make changes to its content, at any time, without
obligation to notify any person or entity of such revisions or changes. All Venafi marks referenced in this presentation are trademarks or registered
trademarks of Venafi, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.
34
© 2013 Venafi