New Critical Security Controls Guidelines
for SSL/TLS Management
A SANS Whitepaper
Written by Barbara Filkins
Advisor: Stephen Northcutt
June 2015
Sponsored by
Venafi
©2015 SANS™ Institute
Introduction
The Internet is built on a foundation of verified trust. Because networks hide the identity
of whoever is at the other end of a secure connection, the only way to establish a
reasonable level of trust is to place confidence in protected documentation that can
act like a passport that confirms an identity or like an immune system that identifies
anything from outside the body as untrustworthy. The need for authentication and
“A cryptosystem
assurance is great and options are few; therefore, we have come to rely on encrypted
should be secure even
SSL/TLS (Secure Sockets Layer/Transport Layer Security) certificates for almost every
if everything about
new application, appliance, device and cloud service. Unfortunately, this system can
the system, except
the key, is public
be gamed with bogus certificates. And because threat detection tools such as IDS/IPS,
data loss prevention and even next-generation firewalls can’t effectively look inside
encrypted traffic to identify threats, sites that accept bogus certificates from users open
knowledge.”
themselves up to a whole host of exploits their security technologies can’t even see.
-Auguste Kerckhoff,
This is not a small problem. A series of data breaches, certificate thefts and vulnerabilities
19th century
in the technology itself have allowed thousands, perhaps tens of thousands, of genuine
certificates to be misappropriated for use as bogus identifications. Despite high-profile
scandals over systemic weaknesses, including Heartbleed, POODLE and FREAK, the
greatest threat to the security of SSL/TLS certificates appears to be the lax controls most
organizations exert over securing keys and certificates.
Critical Security Controls
Developed through a consortium of U.S. and international agencies
and companies, the Critical Security Controls are a relatively small set
of prioritized, well-vetted and well-supported security actions that
organizations can take to assess and constantly improve their security
state. The Council on CyberSecurity, an independent, global nonprofit
entity committed to a secure and open Internet, is responsible for
stewardship and development of the controls. The actions defined
by the controls are a subset of the comprehensive catalog defined by
the National Institute of Standards and Technology (NIST) SP 800-53.
The controls serve as the basis for immediate high-value action.
Standardization and automation are top priorities.
Although SSL/TLS is foundational to a whole series of data
protection, access and detection controls, managing the
keys and certificates behind SSL is becoming increasingly
difficult and critical in both IT security and business terms.1
The Ponemon Institute’s 2015 “Cost of Failed Trust Report”
estimates that, over the last two years, the number of keys and
certificates deployed from web servers to cloud services has
grown over 34 percent, to almost 24,000 per enterprise—not
counting those used beyond the firewall.
This is why the SANS Critical Security Controls, which were
transferred to the stewardship of the Council on CyberSecurity
in 2013, have been updated to improve SSL/TLS security
enforcement rules. This paper will focus on updates and specific recommendations
found in Control 17,2 Data Protection, in order to provide practical advice for the
management and detection of SSL/TLS security.
SANS ANALYST PROGRAM
1
Forrester Research, “Predictions 2015: Data Security and Privacy Are Competitive Differentiators,” Nov. 14, 2014, pp. 1–2.
2
See www.sans.org/critical-security-controls and www.counciloncybersecurity.org/critical-controls
1
New Critical Security Controls Guidelines for SSL/TLS Management
The Role of Certificates in SSL/TLS
SSL/TLS certificates play a critical role in secure and encrypted communications between
a client and a server. First, the server’s certificate, containing its public key, is used by the
client to determine whether the client should accept a trust relationship with the server.
If the client accepts or validates the authenticity of the server, then the server certificate
is used to establish a secure, encrypted channel for the ensuing session. Figure 1
illustrates the SSL/TLS handshake.
Figure 1. Primer: SSL/TLS Handshake3
These protocols are not new. SSL became an Internet standard in 1994, with TLS being
added soon thereafter.4 Both are constructed around a similar architecture using X.509
certificates. Although there are some differences between SSL and TLS, this document
refers to the protocol as SSL/TLS, since the two share a common architecture.
SSL/TLS is most often represented as HTTPS, but the protocol can be used to secure
any TCP-based application. SSL/TLS is also popular for encrypting traffic between email
clients and POP or IMAP servers, setting up secure tunnels between IDS sensors and
management consoles, and supporting VPNs as a lower-cost alternative to IPSec.
3
4
SANS ANALYST PROGRAM
SANS Sec 401.4, Secure Communications Course Book, pp. 136–137.
http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#tls_services
2
New Critical Security Controls Guidelines for SSL/TLS Management
The Role of Certificates in SSL/TLS
(CONTINUED)
When Certs Go Bad
Numerous incidents directly related to SSL/TLS have left the security community
wondering whether we should be relying on these certificate-based protocols. To
determine the answer, it is helpful to understand the major elements behind these
incidents and the incidents’ consequences.
Trusted certificate authorities are supposed to issue digital certificates only to the
owners of the domain names for which certificates are requested. Rogue or fraudulent
certificates are used to impersonate legitimate websites, allowing attackers to snoop on
Four Key Functions Built Around Trust
As critical building blocks for secure e-commerce, SSL/TLS certificates
provide:
the encrypted communications of users who connect to those
sites if their connections are intercepted in transit.
The trust essential to SSL/TLS has been repeatedly tested
• A uthentication: Verification that the business or organization a
user is communicating with really is who it says it is, and not an
impostor.
in large-scale incidents, including one in 2014, when India’s
• C onfidentiality: Secure sessions with a website so that
information provided over the Internet by the user cannot be
intercepted in transit.
the government’s certificates.5 In another case, for seven
• I ntegrity: No message alteration without detection.
man-in-the-middle (MITM) attacks.
•N
onrepudiation: Assurance that the sender and recipient of an
electronic message or transaction cannot deny sending or receiving
the message or engaging in the transaction.
governmental certificate authority was compromised, causing
Google, Facebook and the Indian government itself to revoke
years, DarkHotel spread fraudulent and stolen certificates6
throughout hotel networks, targeting executive guests for
On March 23, 2015, Google issued a warning that
unauthorized digital certificates were issued for some of its
domains. The phony TLS certificates were issued by Egypt-
based MCS Holdings, an intermediate certificate authority operating under the China
Internet Network Information Center (CNNIC), the Chinese domain registrar and
certificate authority. These bogus certs are trusted by all major operating systems and
browsers, although a fallback mechanism known as public key pinning prevents Chrome
and Firefox browsers from accepting those that vouch for the authenticity of Google
properties.7
SANS ANALYST PROGRAM
5
w
ww.pcworld.com/article/2452860/digital-certificate-breach-at-indian-authority-also-targeted-yahoo-domains-possibly-others.html
6
http://arstechnica.com/security/2014/11/darkhotel-uses-bogus-crypto-certificates-to-snare-wi-fi-connected-execs/
7
http://arstechnica.com/security/2015/03/google-warns-of-unauthorized-tls-certificates-trusted-by-almost-all-oses/
3
New Critical Security Controls Guidelines for SSL/TLS Management
The Role of Certificates in SSL/TLS
(CONTINUED)
Figure 2 shows the major impersonations, compromises and thefts that can result in
MITM attacks. The certificate authority (CA) issues the digital certificate. A registration
authority (RA) is an entity trusted by the CA to register or vouch for the identity of a
user or organization to the CA, focusing on identifying and authenticating users or
organizations (usually according to preset standards) to which a certificate will be issued.
A CA and an RA can be the same entity.
Figure 2. Certificate Compromise8
These examples raise the question of who is in control of the certificate authorities and
whether targeted attacks may be the work not of opportunists, but of nation-states
perpetrating MITM attacks against foreign countries, foreign citizens and perhaps their
own populations.
The New Economy: Theft and (Re)Sale of Legitimately Signed Certificates
SSL/TLS certificates are designed to establish trust, so those who are able to acquire
them illicitly have done the equivalent of faking sincerity. The underground economy
has found many ways to monetize data stolen from infected hosts. One way is to resell
legitimate signing codes, which then can be used to digitally sign executables and
scripts to confirm the software author.9 This could undermine any aspect of the Internet
certificate-based community, whether for code-signing or access to an e-commerce site.
SANS ANALYST PROGRAM
8
Reprinted from ITL BULLETIN FOR JULY 2012, which can be found at http://csrc.nist.gov/publications/nistbul/july-2012_itl-bulletin.pdf
9
https://isc.sans.edu/diary/Extracting+Digital+Signatures+from+Signed+Malware/15779
4
New Critical Security Controls Guidelines for SSL/TLS Management
The Role of Certificates in SSL/TLS
(CONTINUED)
The resale of stolen digital certificates may be the next major global market for dark-side
and cyber warfare teams.10 The 2015 Ponemon report put a black-market dollar value for a
stolen, legitimate cert at $1,000. A vulnerability or major breach can easily result in stolen
certificates. The Sony breach, for example, resulted in dozens of keys being published to
the Internet, some of which may still be valid.
SSL: Vulnerable to Attack
Over the last year, attacks against specific SSL vulnerabilities have repeatedly made the
news. Table 1 lists some of the more infamous exploits and their associated vulnerabilities.
Table 1. SSL/TLS Attacks Against Specific Vulnerabilities
Name
Date Identified
Vector
Remediation
Heartbleed11
4/2014
Exploits vulnerability in
OpenSSL that allows attacker
on the open Internet to read
memory and compromise keys12
Patch vulnerable servers
Generate new key pair
Install new certificate
Revoke old certificate
POODLE13
9/2014
Known flaw in SSL v3.0 that
allows exploitation of way it
ignores padding bytes when
running in cipher block chaining
(CBC) mode
Disable SSLv3.0 on both
servers and clients, starting
with servers that have highest
impact; Upgrade to TLS v1.2,
which is not vulnerable
FREAK14
3/2015
A vulnerable browser connects
to a susceptible web server
that accepts “export-grade”
encryption
Server: Test and configure
disable support for TLS export
cipher suites as well as other
cipher suites that are known
to be insecure and enable
forward secrecy
Client (Browser): Update,
patch, maintain secure
configuration
SANS ANALYST PROGRAM
11
http://heartbleed.com
12
http://arstechnica.com/security/2014/04/private-crypto-keys-are-accessible-to-heartbleed-hackers-new-data-shows/
13
www.openssl.org/~bodo/ssl-poodle.pdf
14
https://freakattack.com
5
New Critical Security Controls Guidelines for SSL/TLS Management
The Role of Certificates in SSL/TLS
(CONTINUED)
These vulnerabilities have prompted industry to move away from SSL v3.0, preferably to
TLS v1.2. Following the NIST declaration that the SSL v3.0 protocol is no longer acceptable
for “protection of data due to inherent weaknesses within the protocol,” the PCI Council
began work on revising the Data Security Standard (PCI-DSS) and the Payment Application
Data Security Standard (PA-DSS), urging organizations to work with their IT departments
and/or partners to determine if they are using SSL and identify available options for
“upgrading to a strong cryptographic protocol as soon as possible.”15 PCI DSS 3.1, formally
released on April 15, 2015, sets a migration date to TLS 1.1 or higher by June 2016.16
System administrators and security teams tend to be complacent toward the internal use
of SSL/TLS. A University of Maryland paper published in October 2014, months after the
Heartbleed bug became famous in April 2014, showed that well over half of vulnerable
websites had not been completely remediated.17
Organizations that don’t keep track of certificates being used on their sites or within
their networks can also run into problems. Those that are dependent on browser-based
access even to internal systems can find themselves fighting outages caused by expired
certificates. Organizations that don’t set and enforce policies on which certificates
to accept can find themselves compromised by certificates faked by irresponsible
certificate authorities, data thieves or software such as the Superfish adware that
reportedly replaced legitimate certificates with fakes that allowed it to hijack web pages
and insert advertisements.18
SANS ANALYST PROGRAM
15
h ttp://training.pcisecuritystandards.org/pci-ssc-bulletin-on-impending-revisions-to-pci-dss-pa-dss-assessor?ecid=ACsprvs9qvy
TK9zRGYhsuCCz4uQnU3dhH0KUdzmnfcRBQ2yosf8cWGQc80Ij2sfj6TshufCk030H
16
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1_Summary_of_Changes.pdf
17
www.umdrightnow.umd.edu/news/umd-cyber-experts-discover-lapses-heartbleed-bug-fix
18
www.pcworld.com/article/2886357/lenovo-preinstalls-man-in-the-middle-adware-that-hijacks-https-traffic-on-new-pcs.html
6
New Critical Security Controls Guidelines for SSL/TLS Management
Critical Security Controls Guidance
Despite the issues with SSL/TLS, a well-configured deployment in a properly patched
environment generally does exactly what it’s meant to. Even in a well-configured
environment, though, an attacker can take control of an unknown vulnerability. The
challenge is both being prepared—hardening, patching and maintaining a secure
environment—and never assuming you’re beyond the reach of a determined attacker.
CSC 17 Updates
The Critical Security Controls version 5.1 for Effective Cyber Defense currently consists
of 20 controls that provide an actionable framework for cyber defense. CSC 17, titled,
“Data Protection,” defines “the processes and tools used to prevent data exfiltration,
mitigate the effects of exfiltrated data and ensure the privacy and integrity of sensitive
information.”19 In v5.1, CSC 17 adds requirements for securing keys and certificates,
underscoring that protection of that data is best achieved through the application of a
combination of encryption, integrity protection and data loss prevention techniques.
See Table 2.
Table 2. CSC 17 Recommendations for Data Protection20
SANS ANALYST PROGRAM
ID#
Description
Category
CSC 17-1
Deploy approved hard drive encryption software to mobile
devices and systems that hold sensitive data.
Quick win
CSC 17-2 (NEW)
Verify that cryptographic devices and software are configured to
use publicly vetted algorithms.
Quick win
CSC 17-3 (NEW)
Perform an assessment of data to identify sensitive information
that requires the application of encryption and integrity controls.
Quick win
CSC 17-4 (NEW)
Review cloud provider security practices for data protection.
Quick Win
CSC 17-5
Deploy an automated tool on network perimeters that monitors
for certain sensitive information (i.e., personally identifiable
information), keywords and other document characteristics to
discover unauthorized attempts to exfiltrate data across network
boundaries and block such transfers while alerting information
security personnel.
Visibility/
Attribution
CSC 17-6
Conduct periodic scans of server machines using automated tools
to determine whether sensitive data (e.g., personally identifiable
information, health, credit card and classified information) is
present on the system in clear text. These tools, which search for
patterns that indicate the presence of sensitive information, can
help identify if a business or technical process is leaving behind or
otherwise leaking sensitive information.
Visibility/
Attribution
CSC 17-7
Move data between networks using secure, authenticated and
encrypted mechanisms.
Configuration/
Hygiene
19
www.counciloncybersecurity.org/critical-controls
20
www.counciloncybersecurity.org/critical-controls, pp. 91–92.
7
New Critical Security Controls Guidelines for SSL/TLS Management
Critical Security Controls Guidance
(CONTINUED)
Table 2. CSC 17 Recommendations for Data Protection (CONTINUED)
SANS ANALYST PROGRAM
ID#
Description
Category
CSC 17-8
If there is no business need for supporting such devices, configure
systems so that they will not write data to USB tokens or USB hard
drives. If such devices are required, enterprise software should
be used that can configure systems to allow only specific USB
devices (based on serial number or other unique property) to
be accessed, and that can automatically encrypt all data placed
on such devices. An inventory of all authorized devices must be
maintained.
Configuration/
Hygiene
CSC 17-9
Use network-based DLP solutions to monitor and control the
flow of data within the network. Any anomalies that exceed the
normal traffic patterns should be noted and appropriate action
taken to address them.
Configuration/
Hygiene
CSC 17-10 (NEW)
Only allow approved Certificate Authorities to issue certificates
within the enterprise; review and verify each CA’s Certificate
Practices Statement (CPS) and Certificate Policy (CP).
Configuration/
Hygiene
CSC 17-11 (NEW)
Perform an annual review of algorithms and key lengths in use for
protection of sensitive data.
Configuration/
Hygiene
CSC 17-12
Monitor all traffic leaving the organization and detect any
unauthorized use of encryption. Attackers often use an encrypted
channel to bypass network security devices. Therefore it is
essential that organizations be able to detect rogue connections,
terminate the connection, and remediate the infected system.
Advanced
CSC 17-13
Block access to known file transfer and email exfiltration websites.
Advanced
CSC 17-14 (NEW)
Define roles and responsibilities related to management of
encryption keys within the enterprise; define processes for life
cycle.
Advanced
CSC 17-15 (NEW)
Where applicable, implement Hardware Security Modules (HSMs)
for protection of private keys (e.g., for sub CAs) or key encryption
keys.
8
New Critical Security Controls Guidelines for SSL/TLS Management
Critical Security Controls Guidance
(CONTINUED)
Almost every category in Control 17 relates in some way to key and certificate
management, including the encryption recommendations for mobile and cloud.
However, the 5.1 update has several new recommendations related specifically to SSL/
TLS management issues:
• CSC 17-2: Verify that cryptographic devices and software are configured to use
publicly vetted algorithms.
• CSC 17-3: Perform an assessment of data to identify sensitive information that
requires the application of encryption and integrity controls.
• CSC 17-10: Only allow approved certificate authorities (CAs) to issue certificates
within the enterprise; Review and verify each CA’s certificate practices statement
(CPS) and certificate policy (CP).
• CSC 17-11: Perform an annual review of algorithms and key lengths in use for
protection of sensitive data.
• CSC 17-14: Define roles and responsibilities related to management of encryption
keys within the enterprise; define processes for life cycle.
An Actionable Approach
Even mid-size organizations have an estimated 10,000 or more possible SSL/TLS
certificates. Enterprises with a wide variety of devices, apps and operating systems need
to assess the certificates in their environment by asking, “What do I have? How do I
manage it? And how can I tell that my management is effective?”
Using the CSC methodology to build a strategy around these updates can be the best
approach to help your organization address SSL/TLS certificate and key management.
Step 1: Assess the Situation and Perform Initial Gap Assessment
First, review organizational governance practices related to key and certificate
management; knowing the foundational material will help you analyze the results and
let you know how to respond to the inevitable surprise:
• Do you have an existing data classification and protection policy that calls out
the need for encryption and integrity controls? Is that policy actionable and
enforceable? (CSC 17-2)
• Do you have a good map that shows both the physical network and the possible
locations of your sensitive data, including the keys and certificates themselves?
(CSC 17-2)
• Do you have any existing policies related to key management, such as approved
issues or prohibitions across self-signed certificates? (CSC 17-3)
SANS ANALYST PROGRAM
9
New Critical Security Controls Guidelines for SSL/TLS Management
Critical Security Controls Guidance
(CONTINUED)
Next build an inventory of existing certificates using certificate-tracking tools that allow
automation of the discovery, inspection and monitoring of deployed SSL/TLS certificates.
Build an organizational inventory of SSL certificates across your enterprise, delving deep
into all platforms to build a complete inventory—servers, workstations, network
appliances and devices, mobile, cloud. Your tool should provide detailed certificate
reporting that detects the types of certificates (OV, DV, EV, self-signed) from all CAs as
well as identifies problems with issuers, key lengths, algorithms and other certificate
elements.
Review the results to identify gaps to be corrected, risks to be remediated and issues to
be managed:
• How many SSL/TLS certificates are there in the organization, both on internal
networks and in the cloud if using a hybrid or public cloud model?
• How many certificate authorities are being used? Are there certs from someone
that shouldn’t be in your environment—entities such as CNIC or unapproved
issuers such as GoDaddy that are outside of policy? Do you have an extensive use
of self-signed certs?
• What are the cryptographic algorithms in use? What are the key lengths?
• What is the expiration status? How many are current, expiring or expired? (Expired
certificates can cause costly problems, as Microsoft found out with a two-day
global interruption of Azure services in February 2013.)21
• What adjustments are needed to the governance practices for key and certificate
management based on identified gaps, company data use objectives and
compliance rules?
Step 2: Develop Your Implementation Roadmap
Develop your plan to close gaps, remediate risks and address certificate-management
issues. Choose which controls should be implemented in each phase of the project;
schedule each phase based on business risk considerations.
Step 3: Implement the First Steps in Your Plan
Implement the first steps of your roadmap. Consider how proposed activities integrate
with existing processes and tools. Decide what can be repurposed in your “as is”
environment and what new tools, processes and skills may be needed.
21
SANS ANALYST PROGRAM
http://azure.microsoft.com/blog/2013/03/01/details-of-the-february-22nd-2013-windows-azure-storage-disruption/
10
New Critical Security Controls Guidelines for SSL/TLS Management
Critical Security Controls Guidance
(CONTINUED)
Step 4: Integrate CSC 17 Key/Certificate Controls into Operations
Integrating the updated or new controls—tools and processes—into your standard
operations is a clear priority. Just as important is providing your workforce—both IT and
end user—with appropriate training and awareness commensurate with their roles and
use of certificates.
Step 5: Report and Manage Progress Against Your Implementation Roadmap
The CSC methodology provides metrics to evaluate the effectiveness of automation for
that control family. CSC 17 metrics relevant to SSL/TLS certificates include ones that can
answer these questions:
• Does the system store cryptographic key material securely?
• Does the system use only NIST-approved encryption algorithms?
• Are the systems able to identify the location, department and other critical details
about where the sensitive data originated?
It is advisable at least once per year to re-evaluate both the algorithms and key sizes
you use to ensure that the organization is not falling behind on new vulnerabilities
and exploits against its SSL/TLS installations. Schedule periodic scans of certificates to
determine if all SSL/TLS certificates remain compliant with your policies, standards and
guidelines.
Test your detection and reporting capabilities as well as your incident response
performance by sending test data sets, both unencrypted and encrypted, across
network boundaries from internal systems to ensure that you can detect when
something goes amiss and evaluate how long it takes your organization to recover,
including the replacement of compromised keys and certificates. Table 3 provides a
listing of best practices.
SANS ANALYST PROGRAM
11
New Critical Security Controls Guidelines for SSL/TLS Management
Critical Security Controls Guidance
(CONTINUED)
Table 3. Best Practices for SSL/TLS Certificate and Key Management
Objective
Recommended Activities
Establish
Governance
Ensure key/certificate management practices are reflected in enterprise policies,
guidelines and standards (e.g., encryption algorithms, modes of operation, key length
and protocols).
Classify keys according to enterprise data classification policies and schemas.
(CSC 17-2)
Define administrative oversight and control procedures that clearly identify who is
responsible, accountable and authorized to act regarding certificate management.
Establish policies and procedures that require the use of only whitelisted CAs.
(CSC 17-10)
Develop
Actionable
Classification
and Protection
Procedures
Around
Encrypted Data
Develop/maintain network map/inventory of key data sources, sinks and locations,
including data not normally visible to end users like certificate stores on servers,
workstations, mobile devices. (CSC 17-6)
Maintain inventory of what data is cryptographically protected, what OSI layer it
resides at or in what data store, and how it is protected (CSC 17‐11). Note: Without all
the keys, decrypting inbound SSL/TLS traffic is impossible.
Monitor known interfaces, both internally and externally, for abuse. Be able to monitor
for anomalies. Know the normal termination points for encrypted tunnels—VPNs.
Implement data discovery tools to actively scan and detect sensitive data to
determine alignment with policy. (CSC 17-5) (Note: Many tools still have a high false
positive rate.)
Implement data loss/leak prevention solutions to detect potential data breach/data
exfiltration transmissions and prevent them by monitoring, detecting and blocking
sensitive data while in use (endpoint actions), in motion (network traffic) and at rest
(data storage). (CSC 17‐3, CS 17-6)
Implement SSL/
TLS Certificate
Life Cycle
Management
Select a centralized key management system that automates certificate life cycle
steps: 1) issuance (obtain certificates from trusted CA according to governance
policy and standards); 2) inventory (log pertinent information about certificate
type, deployment, expiration date, person and department responsible for the
management of certificates); 3) refresh (track expiration, replace prior to expiration
and verify proper certificate installation; 4) revocation/retirement. (CSC 17-14)
Align certificate life cycle management practices with NIST 800-57 and SP 800-52
Revision 1, Guidelines for the Selection, Configuration, and Use of Transport Layer
Security (TLS) Implementations.
Integrate, Deploy, Integrate certificate management deployment with applications and infrastructure
and Operate
such as delivering SSL/TLS keys and certificates are to an SSL decryption appliance or
issuing new SSL/TLS keys to a load balancer. (CSC 17-8, 17-10, 17‐14)
Establish reports, alerts and notifications for changes in certificate status from initial/
current inventory baseline. Note: Incorporate change management procedures
around new use cases for key/certificates (e.g., inbound SSL/TLS decryption).
Establish training programs for both SSL/TLS end users and key/certificate
administrators as well as awareness and understanding for both to help identify
misuse or possible compromises.
Monitor and
Respond
Monitor certificate-related activity against established policy, standards and the
approved SSL/TLS certificate inventory baseline.
Test for effectiveness of SSL/TLS key management practices through pre-defined
testing (Note: See discussion in Step 5 related to CSC 17 metrics and evaluation
recommendations.)
Test response to known incidents to evaluate and improve enterprise incident
response, breach detection and related processes.
SANS ANALYST PROGRAM
12
New Critical Security Controls Guidelines for SSL/TLS Management
Conclusion
Certificates can be compromised—whether through fraud, theft, vulnerabilities or
just plain complacency. Nonetheless, proper hygiene, attention to maintenance and
management can resolve most security issues related to SSL/TLS, similar in many ways to
best practices for password management.
The key to keeping SSL/TLS transactions secure is to stay aware, keep current and be
prepared to take action quickly to contain and recover from an incident. A vital tool
for this is the Critical Security Controls, a relatively small number of highly focused
recommendations for practical, effective actions for getting out of trouble simply by
following instructions. The actions involving SSL/TLS key and certificate management
amount to a ready-made methodology for the orderly establishment, application,
operationalization and evaluation of related processes. Feedback mechanisms report on
the real-world efficacy of both the recommended actions and the tools involved.
Combine SSL/TLS key and certificate management best practices with other data
protection controls such as encryption and data loss prevention. Keep the management
of keys and certificates current and aligned with new operational standards, not just in
cryptology, but in other processes covered by the controls, such as identity and access
management (CSC 15), user activity management (CSC 16), and incident response (CSC
18), as well as more traditional areas of network security.
SANS ANALYST PROGRAM
13
New Critical Security Controls Guidelines for SSL/TLS Management
About the Author
Barb Filkins, a senior SANS analyst who holds the CISSP and SANS GSEC (Gold), GCH (Gold), GLSC
(Gold), and GCPM (Silver) certifications, has done extensive work in system procurement, vendor
selection and vendor negotiations as a systems engineering and infrastructure design consultant. She
is deeply involved with HIPAA security issues in the health and human services industry, with clients
ranging from federal agencies (DoD and VA) to municipalities and commercial businesses. She focuses
on issues related to automation—privacy, identity theft and exposure to fraud, as well as the legal
aspects of enforcing information security in today’s mobile and cloud environments.
Sponsor
SANS would like to thank its sponsor:
SANS ANALYST PROGRAM
19
New Critical Security Controls Guidelines for SSL/TLS Management