Venafi is pleased to announce the availability of the Venafi Labs Vulnerability Report. In the last 12 months, trust-based attacks that make use of, or abuse, the trust established by keys and certificates have been catapulted to the forefront of the security industry. Highly publicized examples, like Edward Snowden, , Heartbleed, and the issuance of fraudulent certificates from intermediate certificate authorities, are causing the security industry to reevaluate how keys and certificates are secured.

Garter estimates that by 2017, 50% of network-based attacks will use SSL. This is no surprise when you consider that many organizations are enabling always-on-SSL and have little to no visibility into how keys and certificates are configured or secured. Most organizations lack the visibility into their SSL / TLS landscape. The result is that these organizations are in a state of increased exposure to trust-based attacks and have no ability to respond.

The gaps in enterprise security for keys and certificates diminish the effectiveness of all other security investments. Bad actors are able to bypass defense-in-depth solutions because of the trusted status they gain from abusing keys and certificates.

Venafi Labs frequently analyzes the websites of the Global 2000 organizations and the Alexa Top 1 Million to identify SSL / TLS vulnerabilities. The Heartbleed research [g1] that was recently published by Venafi was derived from the global SSL / TLS threat intelligence provided by the Venafi Labs Vulnerability Report. This threat intelligence is now available to anyone, allowing organizations to perform SSL / TLS vulnerability analysis for their entire publicly-facing server footprint.

Venafi Labs Vulnerability Report provides organizations with the ability to easily identify where they need to take action first to reduce their attack surface against trust-based attacks.

Automated vulnerability scanning for an organization’s entire SSL / TLS publicly-facing landscape

Once an organization is registered on the portal, the Venafi Labs Vulnerability Report will identify any of its publicly-facing SSL / TLS hosts for evaluation. This is a critical step that many organizations miss. The majority of reports show hosts of which the information security group was not aware, to which it has not applied security policies, or weak security configuration. Imagine that you have a backdoor to your house that you didn’t know about, it’s unsecured, and criminals have been using it to secretly gain access to your house for years! Although this is unlikely for an actual house, this is commonplace for SSL / TLS hosts.

It’s good practice to evaluate the hosts you know about from a SSL / TLS security perspective. But how can you evaluate the SSL / TLS security posture for systems of which you are not aware? Venafi Labs Vulnerability Report helps organizations find these ‘hidden secret doors’ into the enterprise network.

Venafi Labs Vulnerability Report performs a detailed evaluation of SSL / TLS for an organization and is able to identify which hosts belong to that organization. Unlike other solutions that only focus on a single domain at a time, the Venafi performs deep analysis to gather all publicly-facing hosts associated with an organization—including subsidiaries.

Identification of the most egregious SSL / TLS vulnerabilities

When evaluating the publicly-facing SSL / TLS security landscape, it is very easy to get overwhelmed when trying to decide where first to start remediating vulnerabilities. Venafi Labs simplifies this task with the introduction of the Venafi Labs Vulnerability Report Vulnerability Scale.

Using this Vulnerability Scale, users can quickly and easily identify where the most egregious publicly-facing SSL / TLS vulnerabilities are that should be addressed first. Using this methodology, organizations can rapidly reduce their overall threat surface.

Register to generate your free vulnerability report for your entire SSL / TLS landscape and start remediating your most egregious SSL / TLS vulnerabilities.

I’ve often been asked to provide some insight from a CISO perspective on how the threat landscape has changed and how, as a CISO, I’ve had to ensure business continuity while ensuring the environment is secure and in compliance to regulations. Having spent much of my career securing global organizations, I know firsthand how truly grueling it can be: a marathon that you run while juggling dozens of balls. For example, before you can even begin to set up your security programs, you have to understand the compliance and regulatory laws in each country where you do business.

Year after year these regulations and laws become more stringent, compounding the difficulty of securing a global company. You have to have a top-notch security team—which I have been lucky enough to have—and establish a close partnership with your company’s legal, regulatory affairs, and compliance teams. These teams should be well versed in the laws in different countries and can help your security team align its security programs with those laws. It then requires a very coordinated effort to ensure that everyone is always on the same page. Most importantly, you need to ensure that you are doing the right things right.

To stay on top of the accelerating threats that regulations and laws are meant to address, companies are going to have to make a lot of progress from where many of them are today. Just a few years ago companies thought that implementing tighter access controls with keys and certificates and encrypting sensitive traffic adequately protected their data. However, hackers have consistently and successfully used trust-based attacks to infiltrate networks and steal confidential data. Such attacks allow hackers to bypass traditional security measures. Security devices, such as data loss prevention (DLP) tools, cannot monitor encrypted traffic, and Gartner found that “less than 20% of organizations with a firewall, an intrusion prevention system (IPS), or unified threat management (UTM) appliance decrypt inbound or outbound SSL traffic.”

Your security team must be able to monitor traffic that appears to be trusted in your environment, to detect threats in that traffic, and to react to those threats. SSL visibility appliances can prop up security by decrypting data before it is sent out and monitoring it for anomalous behavior. However, SSL visibility appliances are only effective if you have an inventory of known trusted keys and certificates in your environment. You need to know whether you can truly trust encrypted traffic—or whether attackers have hijacked encryption for their purposes. Only Venafi solutions help your security team monitor for anomalous key usage or audit your encryption resources against the latest recommendations from the National Institute of Standards and Technology (NIST).

I’m very passionate about the need to detect and stop trust-based attacks. And for five years—even before joining Venafi—I have been passionate about the tool that provides the best protection against these attacks: Venafi Trust Protection Platform. As the CIO and CISO of Venafi, I enjoy the opportunities I have to partner with other CIOs and CISOs across the globe, to give them more insight into trust-based attacks, and to discuss strategies for securing their global companies. The security world is a very tight-knit group that shares information freely, and the ability to help out all organizations, not just one, is a big plus for me. Did I mention I LOVE what I do each and every day?

Even though your organization is spending millions in security technology to protect the business and stop adversaries, cybercriminals are still getting away with your data. It’s time to take a long hard look at your security strategy and ask yourself where all the gaps are. One area where most organizations fall short is key and certificate security. I’m not talking about key and certificate management—it doesn’t help mitigate or detect trust-based attacks.

The sad truth is that your organization has probably invested millions of dollars in security solutions but failed to secure keys and certificates. And as a result, the security solutions you have implemented wind-up having diminished effectiveness, because you have a gaping hole in your security strategy in which adversaries are taking advantage. I’m talking about trust-based attacks. In the last 2 years, the attacks on keys and certificates have increased dramatically with enormous impact. There are hundreds of examples, but the more well-known ones, like Snowden, Energetic Bear, Carreto, or Heartbleed, all show just how ineffective the security investments your organization is making are against trust-based attacks.

Time for a change

The perception that basic key management is good enough, either with a key lifecycle management solution or the good old spreadsheet, is like wearing a bikini in a snowstorm—you’re dangerously exposed! So if bad actors have realized the value in stealing, forging, and using keys and certificates in their malicious campaigns to bypass all the new security technology you’ve implemented, why are you still leaving your jacket at home? It’s time to dress for the weather. Take a good long hard look at your security strategy and evaluate your organization is protecting its keys and certificates.

Basic key management is not going to help you identify rogue usage of keys and certificates in the network. Neither is an IDS/IPS, NGFW, Sandboxing, or even an SSL gateway scanning solution. The truth of the matter really is that keys and certificates are blindly trusted. Combatting threats that leverage these trusted assets requires a targeted solution designed to discover their misuse.

Revamping your security strategy

Don’t undermine the millions of dollars your organization has invested in security solutions with a gap in your key and certificate protection. Close this gap to make all of your security solutions more effective. Here are some recommendations on implementing key and certificate security:

• Identify vulnerabilities related to keys and certificates and remediate by replacing vulnerable keys and certificates.
• Establish a baseline norm of key and certificate usage. In doing so, you will quickly be able to identify any rogue usage of keys and certificates that trigger security events.
• Define and enforce centralized policy for all keys and certificates—including SSH keys.
• Automate the remediation of trust-based attacks to reduce the overall impact.

Venafi helps organization address trust-based attacks with our Venafi Trust Protection Platform. To find your organization’s SSL vulnerabilities, register to generate an on-demand Venafi Labs Vulnerability Report.

Situation

On 20 August 2014, TrustedSec reported that Advanced Persistent Threat (APT) operators exploiting Heartbleed were responsible for the data breach of 4.5 million Community Health System patients. The Heartbleed exploit was used against a Juniper system behind the firewall to expand the APT operators’ attack in order, ultimately, to reach the patient records database.

This breach is significant for two reasons:

1. It demonstrates how APT attackers will patiently exploit Heartbleed over time.
2. The target was a behind-the-firewall system where Heartbleed remediation has been a low priority in many organizations.

The incident likely shows, as is being reported by TIME and Bloomberg, that attackers stole TLS/SSL keys and certificates to execute the breach (further confirmation needs to made).  

Heartbleed remediation, as defined by experts from Bruce Schneier to Gartner, is still overwhelmingly incomplete in most organizations. Venafi Labs recently found 97% of Global 2000 public-facing systems remain vulnerable to attack following Heartbleed to attacks due to incomplete remediation. Complete remediation requires not only a system to be patched, but also new keys to be generated and then certificates to be re-issued, installed, validated, and revoked.   

Venafi CISO, Tammy Moskites, has prepared guidelines for CISOs and their teams on why organizations need to prepare to respond to more incidents like Heartbleed.

Threat

CloudFlare and others have confirmed attackers’ ability to steal SSL/TLS keys and certificates by exploiting the Heartbleed vulnerability. The resulting use of stolen keys allows attackers to spoof trusted services and decrypt private communications. Such exploits can enable attackers to steal intellectual property, breach customer privacy directly, or allow the attacker to expand their foothold to reach the primary target.

Given that remediation of public-facing systems was prioritized in most Heartbleed responses, and that many more behind-the-firewall systems remain vulnerable, it is likely that the lack of complete Heartbleed remediation is worse than what Venafi Labs, Netcraft, and others found. This delay in completing a full remediation, including revoking and reissuing all certificates and keys, provided APT operators ample time to plan and coordinate key-stealing incidents that facilitated the data breach. Both the Aviva compromise (that used Heartbleed and was executed 6 weeks after the vulnerability was first reported) and now the Community Health System compromise demonstrate the patience and persistence of APT operators. These examples also provide a reminder that Heartbleed is not over and that remediation by changing all keys and certificates in the organization must be completed.

Impact

Organizations must act quickly to complete Heartbleed remediation for all systems, both public facing and behind-the-firewall. Heartbleed remediation requires that all keys and certificates be replaced, not just for a system to be patched. Incomplete remediation means that business and government services can be spoofed with the trust that a valid digital certificate provides and sensitive communications can be decrypted.

APT operators, from Mask to Crouching Yeti, have been known to exploit stolen keys over a period of up to 7 years. Until keys and certificates are replaced, your network, intellectual property, and customer data is still vulnerable.  

Furthermore, failing to remediate Heartbleed undermines other security controls, from strong authentication and privileged access to behavioral analysis and network access, because attackers have the trusted status of valid keys and certificates to authenticate and cloak their malicious activities.

Recommended Remediation

Venafi recommends customers complete Heartbleed remediation following guidance from Gartner and others, as follows:

• Identify all systems using OpenSSL 1.0.1 – 1.0.1f and upgrade to OpenSSL 1.0.1g
• Prioritize replacement of keys and certificates to fix based on knowledge of vulnerable applications
• Generate new keys and X.509 certificates
• Install new keys and certificates on servers, revoke vulnerable certificates
• Validate new keys and certificates are being used

Venafi customers can learn more about this process and receive additional guidance from the Venafi support team.

Venafi recommends customers use the Venafi Trust Protection Platform to take the following actions:

1. Replace all TLS/SSL keys and certificates with Venafi TrustAuthority and Venafi TrustForce:
   • Prioritize replacement first for systems known to be Heartbleed vulnerable.
   • With TrustAuthority, generate and distribute new keys and certificates.
   • With TrustForce, installation and validation will occur automatically, greatly reducing the time to when remediation is complete and the organization is no longer vulnerable.
2. Validate and report on remediation
   • Using the shared reporting services of the Trust Protection Platform, organizations can identify their progress in reducing risk.
   • The Venafi support team can provide more information and examples.
3. Replace all SSH keys and certificates with TrustForce:
   • Replace all SSH keys by rolling over older versions—installing, validating, and updating authorized key lists will be performed automatically, greatly reducing the time to when remediation is complete and the organization is no longer vulnerable.
   • Just like passwords and TLS/SSL keys and certificates are changed, replacement of all SSH keys is recommended to stop possible expansion of attacks from privileged accounts.

Please contact Venafi support with any questions or a request for help with remediation.

Additional Resources

• TrustedSec Report on Heartbleed Vulnerability Exploit: https://www.trustedsec.com/august-2014/chs-hacked-heartbleed-exclusive-trustedsec/
• Gartner Recommendations on Heartbleed Remediation: http://blogs.gartner.com/erik-heidt/heartbleed-exploit-in-openssl-how-should-you-respond/
• Completing Heartbleed Remediation with Venafi Trust Protection Platform: https://www.venafi.com/solutions/heartbleed-vulnerability/remediating-the-heartbleed
• Heartbleed Remediation Plugin for Venafi Trust Protection Platform: https://support.venafi.com/entries/53032657

Dig Deeper for Security Vulnerabilities

Business is booming and electronic information systems are running smoothly. You’ve passed all compliance audits and feel confident in your ability to defend your enterprise against cyber attacks. Data security, while a constant challenge, appears manageable. Attacks and intrusion attempts are ongoing, but breaches and direct losses so far appear to be both rare and manageable. As a Global 2000 leader with high profile, worldwide operations, you know intuitively that your systems and processes are prime targets for cybercriminals and miscreants. Perhaps your competitor just suffered an embarrassing breach? You read the news and the relevant industry press describing advanced persistent threats (APTs). Many of these APTs are now employing sophisticated malware communicating over secure sockets layers (SSL), looking to exploit cryptographic keys and digital certificates, and attempting to gain rogue secure shell (SSH) access with root access privileges. Despite copious investments in people, processes, and technology—plus verifiable compliance with all relevant data security laws and regulations—you still wonder, “Can I be missing something important? How would I even know?”

Look Forward for Security Inspiration, Not Backward

Audits are indispensable tools for certifying past performance against regulatory compliance standards that apply with general uniformity to all organizations within a given industry. They are much less effective, however, for ascertaining true information security defense capabilities on a particularized, forward-looking basis. Audits certify what took place over a specific historical reporting period—typically the last calendar or fiscal year—and may cover events that occurred long ago, even though much may have changed in the threatscape since that time. Looking backward is instructive, but looking forward is a far more effective means of assessing security readiness.

Did we provide enough security last year to pass the audit? What does barely passing an audit reveal? How urgently will necessary changes be implemented if there are no repercussions resulting from just squeaking by?

Strive for Continuous Improvement, Not Just to Pass Audits

Achieving an unblemished audit record is a laudable achievement and should be a goal of every organization, security team, and compliance officer. It is necessary, of course, but by no means is it sufficient for assuring data security against modern cyber attacks. If passing an audit is the primary yardstick and everyone is satisfied with the status quo, then what is the incentive to improve things for the next year? In some cases, failing an audit provides more impetus to pursue improvement, and would be more beneficial in the long run, than passing one by a small margin.

With so much at stake, is “good enough” really good enough? Best security practices demand more than minimal compliance.

Look Inward for Motivation, Not Outward

Motivations for achieving regulatory compliance are typically externally focused: to pass an audit; to renew a certification; to prevent a lawsuit; or to avoid a penalty such as a fine or a suspension from government contracting. By contrast, motivations for achieving true data security against a fast-changing threatscape tend to be internally focused: to meaningfully secure proprietary, customer, and employee data; to bolster active defenses; to improve detection and response capabilities; and to reduce the organization’s overall vulnerability cross-section.

The focus on passing an audit is fundamentally different from a commitment to achieving excellence in information security.

Compliance is measured by “reasonableness under the circumstances,” a sliding scale based on the nature and scope of an organizations operations. Arguing gray areas is what keeps an army of lawyers gainfully employed, but what’s considered to be “reasonable” has been steadily expanding in recent years. So be proactive and don’t wait to be tripped up by an audit! Can you identify all cryptographic keys and digital certificates in use across your enterprise and to whom they are assigned? Are they secured and protected? How strong is their encryption and how often do they get rotated? Do you know the location of every SSH-enabled server and whether the authentication keys that access them are unique or shared? What does “trust” look like in your organization?

If you strive to achieve strong security practices for their own sake, you will invariably find yourself exceeding the compliance requirements of the applicable laws and regulations in your industry. If you strive primarily for compliance, however, you will likely fall short of minimum practices necessary to achieve true data security and leave yourself vulnerable to trust-based attacks on the keys and certificates that enable enterprises to secure critical information systems.

Learn how Venafi can help protect your encryption and authentication assets against trust-based attacks to achieve both industry compliance and strong data security practices across the enterprise.

Just last week, an exploit of the Heartbleed vulnerability that used compromised keys and certificates became public. Community Health Systems (CHS) was breached following incomplete Heartbleed remediation, impacting an estimated 4.5 million patients. This breach was particularly significant because it compromised a behind-the-firewall system that has been a low priority for remediation for many companies. The severity and scope of Heartbleed, and now its exploits, put a spotlight on the importance of protecting trust—securing our keys and certificates.

With the rapid growth of threats that misuse keys and certificates, it’s not surprising that the Payment Card Industry Security Standards Council (PCI SSC) announced on Monday that Securing Cryptographic Keys and Digital Certificates is among the finalists selected for a 2015 Special Interest Group (SIG) project in support of the Payment Card Industry Data Security Standard (PCI DSS). Back in June, I posted a blog about our submission of a PCI SIG topic on Securing Cryptographic Keys and Digital Certificates. Now the acceptance of this PCI SIG as a finalist emphasizes how critical it is for organizations to protect key and certificates, which establish the trust on which businesses depend—securing data, keeping communications safe and private, and establishing trust between communicating parties.

Both organizations and Qualified Security Assessors (QSAs) will benefit from this SIG. We have increased our reliance on keys and certificates that protect communications and authorize and authenticate servers, devices, software, cloud, and privileged administrators and users. As for the PCI DSS, keys and certificates are critical to securing cardholder data, as well as all sensitive electronic information, and are specifically mentioned throughout the standard. But the PCI DSS requirements demand more visibility and security over keys and certificates than most organizations can deliver.

Most organizations have not fully remediated Heartbleed. Venafi research shows that 97% of G2000 public-facing servers are still vulnerable because keys and certificates haven’t been changed—and this doesn’t include the behind-the-firewall systems that have been a low priority for remediation. The bottom line is that there are hundreds of organizations that have not completed remediation and are another CHS waiting to happen.

Are you one of the doubters that don’t think you’ll become a victim? It looks like many G2000 organizations are. But odds are you’re already a victim—according to Ponemon Institute research, every major enterprise has been attacked using compromised keys and certificates in the last 24 months. So, I hope all of the doubters are getting converted to believers—the likelihood that you’ll be a victim of an attack on trust is very high and, without the right security in place, the impact even higher. The CHS attack and Advanced Persistent Threats (APTs) that target keys and certificates such as APT1, Mask, Energetic Bear, Crouching Yeti, and Zombie Zero—just to name a few—underscore the importance of strong key and certificate security and remediation capabilities.

The open approach of the PCI DSS requirements provides flexibility to implementing organizations, which is helpful when working to secure unique business environments. But organizations subject to the PCI DSS and QSAs need more clarity on how to secure keys and certificates to establish a foundation of trust for an effective security program and a defense against today’s cyber threats.

We have two primary objectives for this SIG:

• Develop the document PCI DSS Cryptographic Key and Digital Certificate Security Guidelines
• Draft a compliance checklist which outlines the different security options to meet the PCI DSS requirements for keys and certificates

Venafi co-submitted the PCI SIG proposal on Cryptographic Keys and Digital Certificates with SecurityMetrics, a leading QSA. SecurityMetrics brings extensive experience to the SIG—they have helped over 1 million organizations manage PCI DSS compliance and/or secure their network infrastructure, data communication, and other information assets. We also have several other participants committed to supporting the SIG, including QSAs, vendors, and merchants in the Global 2000.

So what’s next? The selected PCI SIGs will present at the 2014 PCI Community Meetings in North America (September) and Europe (October). An election will be held from October 13-23 and the PCI Participating Organizations will vote. The leading 2-3 SIG topics will become PCI SIG projects for 2015.

If you are a PCI Participating Organization, I hope you’ll vote for this important SIG, and even consider becoming one of the SIG participants. For more information, read the Venafi press release on our SIG for Securing Cryptographic Keys and Digital Certificates.

The majority of people and consumers don’t usually think about security and data privacy when they log into their mobile banking app, take a photo of the check, and make a mobile deposit directly into their account. Nor do they think about security as they conveniently purchase their movie tickets on a Fandango mobile app.  People will automatically assume the company has issued a secure app, especially if the app comes from a reputable G2000 company and they downloaded it from the Apple or Google Play app store—or even directly from their employer.  What could possibly go wrong? 

Well, evidently there’s a lot that can go wrong.  SSL vulnerabilities in the Android and iOS ecosystems and the man-in-the-middle (MITM) attacks they enable are exposing consumers’ banking credentials, health information, and other personal information.  What’s even scarier is that SSL vulnerabilities are prevalent in many of today’s most popular mobile apps as was recently uncovered by university researchers. The study found Android vulnerabilities that enabled the researchers to hack personal information such as usernames and passwords, social security numbers, and steal check images from popular mobile apps with the following success rates:

• 92% for  Gmail
• 83% for Chase 
• 92% for H&R Block 
• 86% for Newegg
• 85% for WebMD
• 83% for Hotels.com
• 48% for Amazon

FireEye also recently published data that reported security flaws in the most commonly downloaded Android apps and found that a significant number of the apps are susceptible to MITM attacks.  FireEye reported that as of July 2014, out of the 1,000 most downloaded apps in the Google Play store, 73% of the apps that use SSL/TLS to communicate with a remote server do not check certificates.  And of the 10,000 random apps in the Google Play store, 40% do not check server certificates, exposing data they exchange with their servers to potential theft.

It wasn’t too long ago that MITM attacks emerged as a major threat to web-based, online transactions, and now we see that MITM attacks are increasingly becoming more widespread for mobile apps.  Mobile apps, just like websites, use the same method to secure communications—SSL/TLS.  However, SSL certificate validation is not trivial. Mobile apps often do not implement SSL validation correctly, making them vulnerable to active MITM attacks.  For example, an attacker can substitute a legitimate SSL certificate with one under his control and view data exchanged between the mobile device and remote server or manipulate private information submitted by the user.

Enterprises that are developing or are otherwise responsible for mobile apps deployed to their end users—consumers, customers, or clients—should fix these security vulnerabilities.  It’s up to IT security teams to ensure that user convenience never trumps the security of private consumer data.

I’m attending the 2014 PCI Community Meetings in Orlando and the PCI SSC kicked off the conference with a presentation by Jake Marcinko, Standards Manager, on Business-as-Usual (BAU) compliance practices. The PCI DSS v3, released in November 2013, emphasizes that security controls implemented for compliance should be part of an organization’s business-as-usual security strategy, enabling organizations to maintain compliance on an ongoing basis.

Compliance is not meant to be a single point in time that is achieved annually to pass an audit. Instead, compliance is meant to be an ongoing state, ensuring sustained security within the Cardholder Data Environment (CDE). Security should be maintained as part of the normal day-to-day routines and not as a periodic compliance project.

To highlight the lack of business-as-usual security processes, Jake referenced the Verizon 2014 PCI Compliance Report, saying that almost no organization achieved compliance without requiring remediation following the assessment and there is dismally low continued compliance—only 1 out of 10 passed all 12 of the PCI DSS requirements in their 2013 assessments. But this was up from only 7.5% in 2012.

Four elements of ongoing, business-as-usual security processes were outlined:

1. Monitor security control operations
2. Detect and respond to security control failures
3. Understand how changes in the organization affect security controls
4. Conduct periodic security control assessments, and identify and respond to vulnerabilities

Jake mentioned that automated security controls help with maintaining security as a business-as-usual process, providing ongoing monitoring and alerting. If manual processes are used, they need to ensure that regular monitoring is conducted for continuous security.

The PCI DSS emphasis on business-as-usual security processes does not apply to any particular PCI DSS requirement, but instead applies across the standard. When considering how this applies to keys and certificates, manual security processes are unsustainable. A study by Ponemon Research found that, on average, there are 17,000 keys and certificates in an enterprise network, but 51% of organizations are unaware of how many certificates and keys are actively in use. Although some of these keys and certificates will not be in scope of the PCI DSS, a considerable number are used in the CDE to protect Cardholder Data (CHD).

In a recent webinar on PCI DSS v3 compliance for keys and certificates with 230 attendees, a poll revealed that over half (53%) either applied manual processes to securing their keys and certificates (41%) or did not secure them at all (12%). When specifically asked about their business-as-usual security processes for keys and certificates, more than half (53%) said they had no business-as-usual processes, but merely applied a manual process at the time of audit.

Organizations need automated security to deliver business-as-usual security processes for keys and certificates. This should include comprehensive discovery for a complete inventory of keys and certificates in scope of the PCI DSS, daily monitoring of all keys and certificates, establishment of a baseline, alerts of any anomalous activity, and automatic remediation so that errors, oversights, and attacks do not become breaches.

During his presentation, Jake noted that, for now, implementing business-as-usual security controls is a best practice according to the PCI DSS v3, and not a requirement. But he said that best practices often become requirements—so don’t wait! Start incorporating business-as-usual security practices now.

Learn how Venafi can help you automate key and certificate security required in PCI DSS v3—simplifying and ensuring repeated audit success while providing ongoing security for your CDE.

Encryption and cryptography have long been thought of as the exemplars of Internet security. Unfortunately, this is not the case anymore. Encryption keys and digital certificates have become the weakest link in most organizations’ security strategies, resulting in diminished effectiveness of other security investments like NGFW, IDS/IPS, WAF, AV, etc.

In my previous post, I discussed the difference between key management and key security. The problem today is not that encryption and cryptography are broken, but rather that there are mediocre implementations to secure and protect keys and certificates from theft. Worse yet, most organizations cannot even tell the difference between rogue and legitimate usage of keys and certificates on their networks or stop attackers from using them. Bad actors and nation states continue to abuse the trust that most have in encryption, but very few in the security industry are actually doing something about it.

Undermining Your Critical Security Controls

The threatscape has changed:

• Gartner estimates by 2017, 50% of all network attacks will use SSL.
• McAfee, shows in its 2014 first quarter threat report the use of stolen certificates to sign malware continues to increase at a rate of nearly 50% quarter over quarter since 2012.
• Kaspersky Labs this year discovered multi-year APT campaigns, like Carreto and Windigo, stealing SSL and SSH keys.
• Over 90% of externally-facing servers impacted by Heartbleed have not been fully remediated.
• IBM X-Force is still seeing over 7,000 attacks per day against its customers using the Heartbleed vulnerability.

Even with all the advances in security technology over the last decade, cybercriminals are still very successful at stealing your data. The challenge is that security technologies are still designed to trust encryption. When threats use encryption, they securely bypass other security controls and hide their actions. Let’s review an example of how a bad actor can use keys and certificates to subvert any security technology or control.

Using Keys and Certificates throughout the Attack Chain

The use of keys and certificates in APT campaigns is cyclical. A typical trust-based attack can be broken up into four primary steps that include the theft of the key, use of the key, exfiltration of data, and expansion of its foothold on the network.

Step 1: Steal the Private Key

When Symantec analyzed sample malware designed to steal private keys from certificate stores, the same behavior was noted for every malware variant that was studied. In this current example, the CertOpenSystemStoreA function is used to open stored certificates, and the PFXExportCertStoreEx function exports the following certificate stores:

• MY: A certificate store that holds certificates with the associated private keys
• CA: Certificate authority certificates
• ROOT: Root certificates
• SPC: Software Publisher Certificates

The malware samples were able to steal the digital certificate and corresponding private key by performing the following actions:

1. Opens the MY certificate store
2. Allocates 3C245h bytes of memory
3. Calculates the actual data size
4. Frees the allocated memory
5. Allocates memory for the actual data size
6. The PFXExportCertStoreEx function writes data to the CRYPT_DATA_BLOB area to which the pPFX points
7. Writes data (No decryption routine is required when it writes the content of the certificate store)

Step 2: Use the Key

With access to the private key, there are a multitude of use cases for a malicious campaign. Let’s review how cybercriminals impersonate a website and sign malware with a code-signing certificate.

Website impersonation can easily be achieved using the stolen private key as part of a spear-phishing campaign. The attacker sets up a clone version of the target website—Outlook Web Access (OWA) or a company portal would be a prime target. By using the stolen private key and certificate anyone that visits the website would not see any errors in the browser. The fake website also hosts the malware that is intended for the victim.

Step 3: Exfiltrate the Data

Now that the fake website is prepped and ready to go, it’s time to execute the spear-phishing campaign. Using popular social networks like LinkedIn, it is a simple process to profile a victim and formulate a well-crafted email that will entice the victim to click on a malicious link. Imagine you get an email from the IT administrator stating that your password will be expiring shortly, and that you need to change your password by logging into OWA. The IT administrator very kindly also provided you with a link to OWA in the email for you to click on and reset your password.

When you click on the link and input your credentials into the OWA website, not only are your credentials stolen, but malware is installed onto your machine. It’s important to note that the malware is also signed using a stolen code-signing certificate to avoid detection. By signing the malware with a legitimate code-signing certificate the attackers increase their chances of avoiding detection.

In part 2 of this blog series, I will cover step 4 and discuss some examples of the actions trust-based threats perform and how bad actors use keys and certificates to maintain their foothold in the enterprise network. I will also offer some guidance on how to mitigate trust-based attacks.

Register for a customized vulnerability report to better understand your organizations SSL vulnerabilities that cybercriminals use to undermine the security controls deployed in your enterprise network.

Today, at the 2014 PCI Community Meetings in Orlando, the 2014 PCI Special Interest Groups (SIGs) provided updates on their progress and presentations were given on the 2015 PCI SIG proposals in hopes of getting votes to become 2015 PCI SIG projects. As I’ve mentioned in previous blogs, Venafi has co-submitted a 2015 PCI SIG proposal with SecurityMetrics on Cryptographic Keys and Digital Certificates Security Guidelines. In the presentations today, Kevin Bocek, VP of Security Strategy and Threat Intelligence at Venafi, delivered the presentation for this SIG proposal. Watching the sessions at the PCI Community Meetings, now is the right time for this important PCI SIG topic.

Today’s keynote from Bob Arno, >Adventures of a Theifhunter, really called into question our trust of other people. He talked about how teams of pickpockets work together to steal from unsuspecting victims and how they use the stolen credit cards. The pickpockets are successful, because we generally trust the people around us. Keys and certificates also establish trust, but, in both cases, criminals are leveraging this trust to avoid detection while committing their crimes.

Merchants, financial institutions, and payment processors rely on thousands of keys and certificates as the foundation of trust in the cardholder data environments (CDE), protecting cardholder data (CHD) across their websites, virtual machines, mobile devices, and cloud servers. Yet it is this very trust that cybercriminals want to use, not only to evade detection, but to achieve authentication and trusted status that bypasses other security controls and allows their actions to remain hidden. If only one of your critical keys or certificates is compromised, the digital trust you have established is eliminated. And this opens organizations up to PCI DSS audit failures and, more importantly, breaches.

The PCI SIG on Cryptographic Keys and Digital Certificates Security Guidelines has already rallied support from Global 100 merchants, PCI Qualified Security Assessors (QSAs), and security experts, and we’re looking for more support from the PCI community.

The 2015 PCI SIG proposals will be presented again at the 2014 PCI Community Meetings in Berlin (Oct 7-9). Then PCI Participating Organizations will vote on the 2015 PCI SIG proposals from October 13-23. After the vote, the PCI Security Standards Council (PCI SSC) will select 2-3 presentations to become 2015 PCI SIG projects. In early November, there will be a call for participation for the selected SIGs and the projects will kick off in January 2015.

Want more information? Want to get involved? Visit the website for the PCI SIG on Cryptographic Keys and Digital Certificates Security Guidelines at www.protecttrust.org.

Mapping Certificate and Key Security to Critical Security Controls

I travel all over the world to meet with CIOs and CISOs and discuss their top-of-mind concerns. Our discussions inevitably return to the unrelenting barrage of trust-based attacks. Vulnerabilities like Heartbleed and successfully executed trust-based attacks have demonstrated just how devastating these attacks can be: if an organization’s web servers, cloud systems, and network systems cannot be trusted, that organization cannot run its business. 

Given the current threat landscape, securing an organization’s infrastructure can seem a bit daunting, but CISOs aren’t alone in their efforts to protect their critical systems. Critical controls are designed to help organizations mitigate risks to their most important systems and confidential data. For example, the SANS 20 Critical Security Controls provides a comprehensive framework of security controls for protecting systems and data against cyber threats. These controls are based on the recommendations of experts worldwide—from both private industries and government agencies.

These experts have realized what I’ve maintained for years—just how critical an organization’s keys and certificates are to its security posture. What can be more critical than the foundation of trust for all critical systems? As a result, the SANS 20 Critical Security Controls have been updated to include measures for protecting keys and certificates. Organizations need to go through their internal controls and processes—like I’ve done as a CISO—and ensure that their processes for handling keys and certificates map to recommended security controls.

For example, most organizations know that best practices include implementing Secure Socket Layer (SSL) and Secure Shell (SSH), but they may not realize that they must go beyond simply using these security protocols to using them correctly. Otherwise, they have no protection against attacks that exploit misconfigured, mismanaged, or unprotected keys. SANS Control 12 points out two such common attacks for exploiting administrative privileges: the first attack dupes the administrative user into opening a malicious email attachment, but the second attack is arguably more insidious, allowing attackers to guess or crack passwords and then elevate their privileges—Edward Snowden used this type of attack to gain access to information he was not authorized to access.

SANS Control 17, which focuses on data protection, emphasizes the importance of securing keys and certificates using “proven processes” defined in standards such as the National Institute of Standards and Technology (NIST) SP 800-57. NIST 800-57 outlines best practices for managing and securing cryptographic keys and certificates from the initial certificate request to revocation or deletion of the certificate. SANS Control 17 suggests several ways to get the most benefit from these NIST best practices. I’m going to highlight just a couple:

• Only allow approved Certificate Authorities (CAs) to issue certificates within the enterprise (CSC 17-10)
• Perform an annual review of algorithms and key lengths in use for protection of sensitive data (CSC 17-11)

Think for a moment about how you would begin mapping your processes to these two recommendations:

• Do you have policies that specify which CAs are approved?
• Do you have an auditable process that validates that administrators must submit certificate requests to approved CAs?
• Do you have a timely process for replacing certificates signed by non-approved CAs with approved certificates?
• Do you have an inventory of all certificates in your environment, their issuing CAs, and their private key algorithms?
• Do you have an inventory of all SSH keys in your environment, their key algorithms, and key lengths?
• Do you have a system for validating that all certificates and SSH keys actually in use in your environment are listed in this inventory?

I LOVE that I can say that Venafi solutions allow you to answer “yes” to all of these.

If you are interested in more details about mapping your processes for securing keys and certificates to the SANS Critical Security Controls, stay tuned: my white paper on that subject, coauthored with George Muldoon, will be coming soon.

In my last blog on “SSL Vulnerabilities in Your Mobile Apps: What Could Possibly Go Wrong?” I reported on the latest threats facing many enterprises today, because enterprises are failing to secure the trust in the mobile apps they’re developing for their end users. Researchers discovered that many of the popular mobile apps developed by reputable companies often do not implement SSL validation correctly, making them vulnerable to active man-in-the-middle (MITM) attacks. In MITM attacks an attacker can substitute a legitimate SSL certificate with one under his control and view and/or manipulate private information submitted by the user.

As a follow-up to my previous blog, I’d like to focus on the business impacts that these mobile app security vulnerabilities have on enterprises and why CISOs should keep them in mind.

Customer Privacy Breached

Adopting an app-based strategy for your customers is not easy and it comes with significant risks. As mentioned above, the SSL vulnerabilities found in mobile apps are prone to MITM attacks that trick users into leaking sensitive data. And these leaks are particularly threatening because consumers are using mobile apps to access banking records, healthcare benefit plans, and retail accounts. This creates security risks for enterprises because it requires them to expose backend systems and data via APIs, which means that consumers’ sensitive information is being placed at risk of compromise. Attackers exploit mobile apps that do not check the validity of SSL certificates by using fake unassigned certificates to attack end users. Attackers can intercept traffic on wireless networks used by mobile devices and insert the fake SSL certificates, inject malicious information-stealing code directly into the apps, and divert users to compromised sites to conduct fraudulent transactions without most users noticing the difference.

Brand Reputation Damage

When an attacker finds an exploit or flaw in your mobile apps that leaks your customers’ private information, be prepared for a PR nightmare, because this will surely make a very large splash in the media. Security and privacy issues can have a major impact on customer adoption of your mobile apps, damage your company's brand reputation, and even negatively impact revenue. Keep in mind that you will not always get a second chance to get it right with your customers.

Audit Failure

Fandango and Credit Karma mobile apps failed to secure SSL and validate certificates and exposed consumers’ sensitive personal information. Both were heavily penalized by the FTC and should serve as a reminder of the seriousness behind failing to secure and validate SSL certificates. By overriding the default validation process, Fandango undermined the security of ticket purchases made through its iOS app and exposed consumers’ credit card details, including card number, security code, zip code, and expiration date, as well as consumers’ email addresses and passwords. Similarly, Credit Karma’s apps for iOS and Android disabled the default validation process, exposing consumers’ Social Security Numbers, names, dates of birth, home addresses, phone numbers, email addresses, passwords, credit scores, and other credit report details such as account names and balances.

It is the responsibility of IT security teams and CISOs to ensure that they protect customers’ privacy and safeguard them from fraudulent or malicious activities. And to do this, organizations need to ensure their apps are not leaking private information, ensure trusted connections to services, and have the right intelligence to ensure trust between the business and the customer.

When it comes to cybersecurity, any new regulatory compliance measure or guidance is typically driven by a significant expansion of associated real-world threats and incidents. For example, in October 2005, the Federal Financial Institutions Examination Council (FFIEC) issued very pointed guidance requiring a second factor of authentication in an Internet banking environment. This effectively replaced the initial FFIEC Internet banking authentication guidance of 2001. The updated FFIEC guidance came as a result of these real-world instances:

1. The massive growth of Internet banking (from 2001-2005), and
2. The increase in the number and sophistication of threats to Internet banking authentication

Each financial services enterprise then proceeded to come up with a plan to technologically require users to employ a second factor of authentication (beyond a password) that would be as minimally intrusive as possible to the customer’s online experience. Fast-forward to present day, and this is why risk-based and behavioral scoring occurs behind the scenes at any bank’s login page, serving as that least intrusive, yet valid, second factor of authentication.

New risk areas and new real-world incidents drive the evolution of information security audit and compliance.

Similar to user IDs and passwords, encryption keys and digital certificates provide trusted authentication (along with trusted encryption of the data transmitted), whether between two machines or a machine and a user. However, if cybercriminals compromise, for example, SSH keys that provide root-level access to critical Linux systems, they’ll get away with a whole lot more than a few hundred dollars from a user’s checking account. When it comes to protecting keys and certificates, the stakes are much, much higher for the enterprise.

Malicious use and compromise of keys and certificates is no longer a theoretical threat. In 2013, even prior to the discovery of Heartbleed, an analysis by the Ponemon Institute of over 2000 large, global enterprises showed that ALL had experienced and responded to an attack on keys and certificates in the previous 24 months. In this same study, IT security professionals estimated the impact of an attack on trust to total on average almost $35 million.

Add to this equation the fact that enterprise usage of keys and certificates is growing at rates similar to the adoption of online banking in the early 2000s. It then becomes very apparent that risks associated with keys and certificates (and thus trust online) can easily spiral out of control if Global 2000 organizations don’t act now.

From a compliance perspective, encryption keys and digital certificates are now where online banking user IDs and passwords were in 2005. Attackers are expanding their efforts to breach their targets via weaknesses in keys and certificates, as they know many organizations’ PKI are silently rife with vulnerability. This is why many Global 2000 industry compliance bodies are more and more insisting that all enterprise encryption keys and digital certificates be protected in a similar manner to all other privileged access credentials at an organization.

Requirements around the protection of keys and certificates (Next Generation Trust Protection) have been added directly or indirectly to nearly all major regulatory compliance bodies.

Failing to protect trust can result in serious regulatory and business consequences for the enterprise, ranging from failed audits and fines to irreversible brand reputation damage. Our mission here at Venafi is to prevent this from happening to our customers. Given that enterprise keys and certificates provide trusted communication, implementing a program to protect enterprise keys and certificates is now more commonly referred to as “Next Generation Trust Protection.”

The collective risks involved with unprotected keys and certificates are at an all-time high, and regulatory compliance bodies are now evolving to address them. This is a point of convergence for Next Generation Trust Protection, where the risk and real-life threats to keys and certificates drive widespread regulatory and security framework evolution. The Venafi Trust Protection Platform secures trust by protecting enterprise keys and certificates and is well positioned to meet industry best practice needs around Trust Protection. By instituting a Next Generation Trust Protection program, you’re not only better securing the enterprise brand and dramatically cutting costs, but you’re also staying ahead of the evolving information security compliance curve.

There have been a lot of retailers making headlines for payment system breaches, where millions of credit card numbers have been stolen. After a breach, the retailer has to take a hard look at the people, processes, and technology that are in place in their Information Security organization. How the organization complies with their own Information Security policies, standards, and guidelines must be analyzed and the gaps in infrastructure and applications must be identified and prioritized so that risk can be greatly reduced.

For any organization that processes, stores, and transmits cardholder data, the Payment Card Industry Data Security Standard (PCI-DSS) helps keep cardholder data secure. There are 6 objectives supported by 12 high-level requirements and over 200 detailed requirements. The number of requirements that apply to an entity that is storing, transmitting, or processing cardholder data depends on the number of transactions processed, the cardholder data flow, and if there has been an egregious violation. Egregious violations occur when the following is present on a network: a Primary Account Number (PAN) stored in the clear in a database, a PAN transmitted in the clear over an open public network, or stored sensitive authentication data. This authentication data includes full track data from the magnetic stripe or chip, the 3- or 4-digit code on the front or back of the credit card (CAV2/CVC2/CVV2/CID), or personal identification numbers (PINs/PIN blocks). So even a merchant with low transaction volumes could have all 239 requirements apply if they have not properly scoped or implemented the network and cardholder data handling.

Requirements three and four fall under the objective, Protect Cardholder Data, and define critical protection methods that use cryptography. The cryptography has to be implemented in a secure manner to keep intruders out. “If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person.” (PCI-DSS, pg. 34) So there are a lot of requirements, but underlying the security of the entire PCI-DSS is the application of strong cryptography in the right places and the assurance that the private keys are protected. Private keys must stay private. Failure to do so undermines all of the other security controls that are in place.

So how does one protect a private key? The PCI-DSS requirement 3.5.2 goes into detail on this, and I will blog about this next month. For now, I want to highlight the physical security requirements under requirement 9, Restrict Physical Access to Cardholder Data. To do this I want to share my experience in having implemented a Certification Authority (CA). Five tiers of physical security, were implemented to secure the Root CA, which was an offline CA, and four for the online CAs:

• Tier 1: Employees
  Operating policies and procedures including employee screening
• Tier 2: Building
  7X24X365 guard force with a central control station, photo ID access, intrusion detection system, and closed circuit TV
• Tier 3: CA Facility
  Structural protection, controlled access system, and self-contained UPS power system
• Tier 4: CA Secure Rooms
  Walls with steel mesh, two-person access with biometric control, closed circuit TV, and motion alarms
• Tier 5: Root Private Key
  Class 5 dual drawer safe with dual locks on each drawer
• Additionally, all of Requirement 9 was met

I know you’re not all protecting Certification Authority keys, however, the care taken to protect CA keys, should be thought about for the private keys on the payment network. In order to protect private keys there has to be physical and network defense in depth present. I could argue that all 239 PCI-DSS requirements should be in place to protect private keys. But I bet most organizations do not give private encryption keys much thought, and therefore, do not know what private keys are on their network, who put them there, if they have been rotated, if they are accessible by only the key custodians or by any administrator, and if they are exposed to the internet because of zero-day malware or other Trojans that have gone undetected.

There are numerous current attacks on private keys. Yes, I know some are because the X.509 standard was not implemented properly, and this was taken advantage of by intruders and malicious individuals. But in your organization, can you be sure that the wrong people don’t have your private keys, that an intruder has not replaced them, and that you have all the proper controls in place to ensure this?

Right now many enterprises are in final stages of their 2015 budget cycles and many are allocating budget for one of the most important problems and highest areas of risk: protecting the trust established by keys and certificates. Trust is a top-of-mind issue for CEOs and boards. Thousands of keys and certificates—many unknown to security teams—create the trust on which businesses run. If any one key or certificate is compromised, tampered with, or forged, brand reputation suffers, intellectual property can be stolen, and customer privacy breached. The consequences of failing to secure trust are considerable and can significantly damage business.

Why is securing keys and certificates so important now? As we have come to rely more heavily on keys and certificates, cybercriminals have made them more of a target. They want to use keys and certificates to be authenticated and evade detection, bypassing other security controls and keeping their actions cloaked.

Organizations layer security controls to create a defense-in-depth approach to protecting their business. But a lack of key and certificate security undermines the Critical Security Controls (CSCs) listed by the SANS Institute. For example, according to Gartner, 25% to 50% of all traffic in organizations is encrypted. Most security controls, like malware, boundary defenses, and data protection, do not decrypt data, but instead rely on keys and certificates to determine trust.

The challenge is that security technologies are still designed to trust encryption. When attackers use encryption, they securely bypass your other security controls and hide their actions. The strength of your security program depends on the trust established by keys and certificates and how well you protect that trust. If your top 2015 priorities are data security, privileged access, data loss prevention, PCI DSS v3, advanced threat mitigation, or mobility, then securing keys and certificates is critical to your team’s success.

If you have not already included key and certificate security in your 2015 budget, I encourage you to include this essential Next Generation Trust Protection as a top priority. Since Heartbleed, CEOs, Board of Directors, and even Audit Committees are asking their CISOs what they are doing about better securing keys and certificates—especially when hackers used the Heartbleed vulnerability to breach a behind-the-firewall system at Community Health Systems that affected an estimated 4.5 million patients! If keys and certificates are not replaced, exploits of Heartbleed can steal intellectual property, breach customer privacy, and irreparably damage reputation.

With these consequences, it’s incredibly surprising that so many have not fully remediated Heartbleed: in research from July 2014, Venafi Labs found 97% of public-facing G2000 servers are still vulnerable because keys and certificates hadn’t been changed—and this doesn’t include the behind-the-firewall systems that have been a low priority for remediation.

I know firsthand that CISOs are always being asked to do more with less and have to prioritize many important projects during budget cycles. I joined Venafi earlier this year to help other CISOs and CIOs fortify their strategies and defend their businesses. Since I joined Venafi, I’ve worked with over 150 CISOs and CIOs to help them understand the problem and begin budgeting now. I can do the same for you by sharing a budget recommendation brief that summarizes the information gathered from these CISO meetings.

Effective key and certificate security can complement your current priorities and improve the effectiveness of your critical security controls. Enterprises need to make key and certificate security a top priority in 2015, or an opportunity to get started with any left over 2014 funds. Without key and certificate security, there are security gaps that bypass critical security controls. And Heartbleed is just one of numerous vulnerabilities and attacks on trust—these are increasing in frequency and severity, continually threatening the trust that is the foundation of business.

I am personally committed to helping my fellow CISOs secure their businesses against trust-based attacks and welcome them to reach out to me directly to help them put together a plan to protect their keys and certificates and secure their business.

In my previous post, I discussed the first three steps of four showing how a typical trust-based attack can be broken up into the following: 1) theft of the key, 2) use of the key, 3) exfiltration of data, and 4) expansion of its foothold on the network. This post focuses on step 4 while outlining some examples of the actions trust-based attacks perform and how bad actors use keys and certificates to maintain their foothold in the enterprise network.

When reviewing the security architecture for any enterprise network, the majority of the time you will hear security architects talk about defense-in-depth strategies. This equates to the layering of multiple best-of-breed security solutions to stop an attacker from getting in to the network and data leaking out of the network. But what happens when every security solution deployed as part of the enterprise security strategy can be bypassed? This is exactly the case when it comes to trust-based attacks. Security solutions are inherently designed to trust keys and certificates as part of the security stack.

The result is catastrophic. Organizations that invest millions of dollars and hundreds of man-hours in security solutions are constantly being breached because their security controls are undermined as a result of inadequate key and certificate security—they have no visibility into the use of their keys and certificates or ability to respond to an attack. Using these keys and certificates, attackers are able to bypass the organizations’ other security controls unnoticed due to the trusted status granted.

In step 4 of a typical trust-based attack, bad actors will use the stolen keys and certificates to maintain and strengthen their foothold on the network. As part of this process, the malware that was installed in step 3 is used to steal additional credentials, including keys and certificates. Common examples like Mask Operation and Crouching Yeti were successful for up to 7 years, showing just how long APT operators can go undetected.

Once inside the corporate network the name of the game is remain undetected for as long as possible. For cybercriminals, the use of encryption and keys and certificates provides the perfect cover. At the same time, it’s important for cybercriminals to collect additional keys and certificates to be used for future access and malicious campaigns while maintaining privileged access.

A good example of a massive security hole in most organizations is SSH. Forrester research identified almost three-quarters (73%) of organizations hardly ever rotate SSH keys. Public key authentication is one of the more popular authentication deployments of SSH. Unfortunately, it also requires adequate security of the private key. However, more than 50% of organizations don’t even know how many keys and certificates are in use in the network and have no security controls for these keys and certificates.

When authenticating via SSH, privileged identity management (PIM) solutions are bypassed. This is by no means an impediment of PIM solutions: it’s the design of SSH. The majority of security solutions have no visibility into the use of SSH and other keys and certificates on the network. It’s no wonder cybercriminals are taking advantage of them at an ever increasing rate, undermining current security controls.

Keys and certificates are critical for secure communication across the Internet, but when a security method is used for malice, something needs to be done about it. Enterprises need to start by knowing where all of the keys and certificates are on the network, how they are used on the network, who has access to them, and how they are configured. Organizations can get direction from security standards, like SANS 20, that provide very specific guidance on key and certificate security. These standards show promise in their recognition that trust-based attacks need to stopped.

In the recent blog post on Allocating 2015 Budget for Key and Certificate Security, by Tammy Moskites, the CISO and CIO of Venafi, she emphasizes how unsecure keys and certificates can undermine critical security controls. This is certainly true. A lack of key and certificate security undermines a minimum of 40% of the Critical Security Controls (CSCs) listed by the SANS Institute. But key and certificate security should also be considered a critical security control, in and of itself—not just a function that impacts them.

The latest version of The Critical Security Controls for Effective Cyber Defense by the SANS Institute now includes requirements for securing keys and certificates in Section 17 on Data Protection. These changes recognize that data protection must go beyond Data Loss Prevention (DLP) and Data Classification solutions, which cannot see encrypted traffic—creating a security gap (as mentioned in Tammy’s blog). But folding in these new key and certificate security requirements elevates key and certificate security to a Critical Security Control. Below are examples of the key and certificate security now listed under Data Protection.

New Key and Certificate Security in SANS20 CSC Version 5, Requirement 17: Data Protection

• 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 CAs 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 lifecycle.

An effective data protection framework must close gaps by securing cryptographic keys and digital certificates to protect the trust behind secure, authenticated, and encrypted communications.

Key and certificate security is explicitly mentioned under Data Protection, but also directly impacts many of the other SANS critical security controls that address authentication, access control, vulnerability assessment, and defense against trust-based attacks.

SANS 20 Critical Security Controls

Like Tammy, I also urge you to budget for key and certificate security in 2015, if not earlier with remaining 2014 funds. Tammy and others in Venafi have been working with many of the top global enterprises to help them plan key and certificate security, often folding this in with other important security and compliance projects. We’ve taken what we’ve learned from these successful engagements and captured them in a budget recommendation brief, as well as a more detailed white paper, Budgeting for Next Generation Trust Protection.

These materials emphasize why securing keys and certificates is critical when protecting against today’s threatscape, how this protection complements your planned security and compliance projects, and how to position and estimate budget. Of course, Tammy and the rest of us at Venafi are happy to help you customize your budget efforts.

Too often we take the trust established by keys and certificates for granted, but without key and certificate security we leave an open door to trust-based attacks, breach, and compromise.

I know that meeting and maintaining PCI DSS compliance is a major undertaking for fellow CISOs and teams, and our collective efforts to do so improve the overall security of our organizations. Yesterday, the PCI SSC opened the voting for the 2015 PCI special interest group (SIG) projects and PCI Participating Organizations can vote through October 24. These PCI SIGs are an opportunity to gain clarity on meeting the PCI DSS requirements more effectively and efficiently, increasing security. Let’s vote for the topics that will provide the most value.

An important proposal addresses the need to better protect digital trust called, Securing Cryptographic Keys and Digital Certificates. This protection has become critical for merchants, financial institutions, and payment processors. Keys and certificates authorize and authenticate servers, devices, software, cloud, and privileged administrators and users—establishing the trust on which our businesses depend. But as we’ve come to rely more heavily on keys and certificates, cybercriminals have made them more of a target. They use unprotected keys and certificates as weapons that authenticate and evade detection, bypassing other security controls.

Controlling requirements for cryptographic keys and digital certificates are contained throughout the PCI DSS for data at rest, data in transit, authorization and authentication. But beyond providing guidance on meeting these requirements, the SIG can provide direction on how to maintain security within particular use cases, including remediating vulnerabilities like Heartbleed and defending against increasing trust-based attacks (think Snowden, the Mask Operation, APT1, and more ). The PCI DSS includes general security requirements for keys and certificates, but organizations also need to know how to defend against real-world threats.

This PCI SIG is an opportunity to pull together the knowledge from merchants, financial institutions, payment processors, QSAs, and security experts to provide invaluable guidance on securing keys and certificates to preserve our trust in digital business communications. To learn more and show your support for the PCI DSS SIG on Security Cryptographic Keys and Digital Certificates, visit www.protecttrust.org and vote in the PCI SSC SIG election today.

Cheers!

The increasing reliance on mobile devices and applications is driving the need for mobile certificates to ensure that devices and applications are secure, authenticated, and encrypted for enterprise users. But failing to protect mobile certificates—to whom they are issued and when they need to be revoked—opens the door to unauthorized access, data leakage, and intellectual property theft.  The fact is that keys and certificates of all kinds, including mobile certificates, are being targeted to initiate and continue attacks every single day.

However, research published by Forrester Research uncovers that IT security professionals are not fully aware of the implications of what is required to protect mobile certificates. This creates gaps in understanding how to perform the most critical functions necessary for securing mobile certificates.

IT Security’s Role in Protecting Mobile Certificates

A study by Forrester Research found that a majority of IT security decision makers rely on digital certificates to secure their mobile applications and systems, such as VPN, Mobile Device Management (MDM), email, WIFI, SSL/TLS mobile applications, and Mobile Application Management (MAM). Nearly 80% of IT security professionals acknowledge they own the responsibility for protecting mobile certificates. And two-thirds or more of IT security decision makers believe they should own responsibility for security functions, including certificate issuance, policy, updates, deployment, and revocation.

Gaps in Security Awareness

Although most agree that they are responsible, 77% of IT security professionals who responded to the survey said that they have very little visibility into the applications, users, use cases, and security of mobile certificates, and 71% said they do not have full control.  But what’s even more shocking, one of the most important functions—detecting anomalies—is a task that IT security is not prepared to perform.  Only 38% claim they have the ability to detect mobile certificate anomalies, such as duplicate certificates, or active certificates issued to terminated employees, both of which can be used for unauthorized access.

IT Security Does Not Have Full Visibility or Control of the Use of Mobile Certificates.
Source: Forrester Research – IT Security’s Responsibility: Protecting Mobile Certificates

Closing the Gaps

So what can you do to close the gaps that exist in mobile certificate security?  Forrester Research recommends the following steps that enterprise organizations should take to protect mobile certificates:

• Establish common policy across applications and desktops, laptops, tablets, and phones
• Identify all sources of certificates
• Map all found certificates to a single user and establish a baseline
• Enforce policy for all mobile certificates
• Detect anomalies like duplicate certificates or unrevoked certificates for terminated employees
• Respond quickly to anomalies with kill-switch-like revocation
• Prepare to quickly remediate when incidents like Heartbleed occur that require all certificates to be rekeyed, reissued, and revoked

To learn more, read the Forrester Research study, IT Security’s Responsibility: Protecting Mobile Certificates.

Since last month’s blog where I started to discuss the importance of protecting private keys in payment networks, even more retailers have made the news for credit card data breaches. I also personally received a new debit card because of these high-profile retailer data breaches. This is a cause for concern for both retailers and consumers. When cardholder data is stolen, it costs a lot of money to replace the credit and debit cards and refund the money to the cardholder for purchases they did not make. This cost could be passed along to the consumer via paying more for goods and services due to higher merchant interchange rates. So, protecting the private keys that keep the payment card systems data from being disclosed, modified, or unavailable is very important.

While proper compliance to all of the applicable requirements of the Payment Card Industry Data Security Standard (PCI-DSS) to your cardholder data environment will ultimately help protect your private keys and secure your cardholder data, here I want to cover the requirements specific to managing and securing keys. The first step in this process is to know where the private keys are on the cardholder data network. (PCI-DSS req. 2.4) Organizations can accomplish this by providing an inventory of their private keys and where they are located. Once private key locations are known, the rest of the requirements involved in securing keys can be met. 

Requirement 3 of the PCI-DSS addresses securing encryption keys with the intent to protect keys so that the cardholder data is not exposed. These requirements use the words exposed or disclosed. When I see this language, I think of confidentiality—one of the pillars of information security. Confidentiality, through using encryption, keeps data from being exposed or disclosed, when it should not be, and is a form of access control. There are several steps to securing the keys during their lifecycle, including access control, proper approvals, and any policies that have to be applied around key length, signing algorithms, validity period, and trusted third parties, if applicable. Norms must be established, and continuous monitoring and reporting must occur, as well as continuous inventory, so that protecting cardholder data is achieved.

Requirements 3 in the PCI-DSS addresses key security as follows:

• Render the Primary Account Number (PAN) unreadable via the use of strong cryptography, including the associated key management processes and procedures. (3.4)
• Document and implement procedures for protecting keys so that cardholder data is not disclosed and misused. (3.5)
• Secure private keys either with a key-encrypting key, within a secure cryptographic device, or by using two full-length key components. (3.5.2)
• Document and implement key management processes and procedures for cryptographic keys. (3.6)
• Do not allow keys to expire. (3.6.4)
• Change the keys when they expire—do not just renew the validity period. (3.6.5)
• Archive, destroy, or revoke the key when the integrity of the key has been or is suspected to have been compromised. (3.6.5)

Although these requirements are applied to data at rest in requirement 3, QSAs apply these same key management requirements to section 4, data in transit, over open, public networks. SSL is currently the technology of choice to achieve this. As in section 3, keys cannot expire and the server certificate must use strong cryptography, for example, 2048-bit keys, not 1024-bit. Other items of note, are verifying that certificates are issued from a trusted source and the TLS configuration on the server has been done properly to ensure integrity of the secure connection. Run a Venafi Labs vulnerability report to determine if these certificate or TLS configuration vulnerabilities exist in your network.

On cardholder data networks, private keys provide the base of trust and confidentiality, protecting against disclosure of personal account numbers and sensitive authentication data. Using strong cryptography and implementing good people, process, and technology around keys will keep the underlying infrastructure of trust protected in your cardholder data network. Cryptographic keys are the foundation of trust in any system.