Updating Following Demonstration of Successful Private Key Extraction Exploit

The race is on to respond and remediate by replacing ALL keys and certificates in use with millions of applications because patching won't help.

The world runs on the trust established by digital certificates and cryptographic keys. Every business, every government. It’s the way the architects of the Internet solved the problem of securing data, keeping communications private and knowing a server, device, cloud is authenticated. Because keys and certificates provide the foundation for almost everything we know in our highly digital world, if you attack the trust established by keys and certificates then all our other security defenses become at best less effective. At worst completely ineffective. It's why Forrester Research found: "Advanced threat detection provides an important layer of protection but is not a substitute for securing keys and certificates then that can provide an attacker trusted status that evades detection."

We’re now seeing how a single vulnerability in OpenSSL named Heartbleed, present since 2011 and in use with tens of thousands of applications that make commerce and communications work online and offline, exposes keys and certificates to attack and compromise. Yes, it exposes the keys and certificates that every business and government use to bank, purchase, and communicate with online and offline. And it doesn't require an attacker to breach firewalls and other security defenses! In a public challenge, researchers successfully extracted the private SSL key for a NGINX webserver running vulnerable OpenSSL – the same state that existed before April 7, 2014. The Cryptopocalypse has arrived, and it's probably much sooner and worse than researchers at Black Hat 2013 dreamed of.

Gartner’s advice to enterprise IT security teams is very clear:
"The existence of this fault [Heartbleed] on a server undermines any confidence in the confidentially of keys that have been used on that server. Issuing a new certificate is necessary, but not sufficient. Many organizations perform “lazy” certificate rotations, and do not create new keys! This is a bad practice. Because this attack enables the recovery of the private key itself, certificate rotation alone will not protect you! New private keys must be generated."

The scope of the problem is massive: just one application that uses OpenSSL, Apache, is used to run 346M public websites or about 47% of the Internet today. And the problem is even larger since this doesn't include the tens of millions of behind-the-firewall applications, devices, appliances, and things that run Apache and use OpenSSL. And it's just one application that relies on OpenSSL.

The consequences of this vulnerability and exposure of keys and certificates is scary. Attackers can spoof trusted websites and decrypt private communications. Accomplish this and it's game over, cybercriminals win.

Live Webinar: Remediating Heartbleed Vulnerability — Register Now

Researchers that identified the vulnerability sum up the impact simply: "Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed." You must assume ALL keys and certificates are compromised and immediately replace them to remediate.

While the vulnerable code has been fixed, sadly most organizations will remain vulnerable. They are unable to change out their keys and certificates — the thousands of keys and certificates in every Global 2000 enterprise and modern government. The continued exposed vulnerability means attackers can spoof legitimate websites or decrypt private communications.

Furthermore, enterprises must assume, just as they are with userid and passwords, that ALL keys and certificates are compromised, not just those that secured vulnerable Heartbleed systems. Kill Chain Analysis helps us understand that attackers will look to expand their attacks using similar methods and targets as their first intrusion. Further infiltration of networks means that SSL keys and certificates and SSH keys, even though not running vulnerable OpenSSL, should be assumed targets and compromised.

The reason for further alarm and assumption that all keys and certificates must be replaced is that Heartbleed isn’t the first attack on keys and certificates. And, it won’t be the last. We’ve seen APT groups stealing keys and certificates, most recently the Mask APT group, breached organizations not remediating to change keys and certificates, and remaining owned by the attackers. The infamous Stuxnet attacks used stolen certificates to attack Iran nuclear facilities. And as a leaked NSA memo showed, Edward Snowden used compromised keys and certificates to execute his breach of the NSA. All of this and more is why back in December 2012 Gartner concluded: "Certificates can no longer be blindly trusted."

Now Heartbleed. The success in using compromised keys and certificates has proven there will be only more attacks and more vulnerabilities. The value of IT security is measured in how fast security teams can respond and remediate – to create new, trusted and uncompromised keys, revoke current certificates, create new trusted certificates, and get them installed and trusted before they can be misused.

It's not, as some have understood, about how can we setup a good process to optimize procedures and best practices. Nor is it just about patching software. The researchers that exposed Heartbleed further identified the requirements to remediate: "revocation of the compromised keys and reissuing and redistributing new keys."

Respected John Hopkins cryptographer Matthew Green explained further: "It’s a nightmare vulnerability, since it potentially leaks your long term secret key — the one that corresponds with your server certificate. Worse, there’s no way to tell if you’ve been exploited. That means the prudent thing to do now is revoke your certificate and get a new one."

Live Webinar: Remediating Heartbleed Vulnerability — Register Now

Respond & Remediate Now Before It's Too Late

The clock is on. Our adversaries know about these vulnerabilities. Following the example set by NIST's guidance on responding to a CA compromise, remediation for keys and certificates can be simplified as:

• Know where all keys and certificates are located
• Revoke, replace, install, and verify keys and certificates with new ones

For organizations that do not have a system to identify all keys and certificates used with SSL — whether in the datacenter or out in the cloud — Venafi can help. Venafi TrustAuthority™ can quickly be deployed, establish a comprehensive inventory of keys and certificates, where they're used, and who is responsible for the ones that to be replaced. This is followed by the revocation and replacement with new keys and certificates from one or many trust Certificate Authorities (CAs) used by your enterprise. TrustAuthority handles these complexities for security teams around the world every day. New organizations that now must respond to Heartbleed can be up, running, and back to a secured state quickly.

For organizations that already have Venafi TrustAuthority™ (previously known as Enrolment for Server Certificate Manager), security administrators already have the inventory of keys and certificates in use that need to replaced. Your TrustAuthority policy identifies the applications that keys and certificates are used with, including Apache and many other enterprise network appliances, devices, and applications. Security administrators, working with application owners, can quickly, securely and easily generate new keys and certificates from one or more of the trusted CAs used by organization. TrustAuthority can then validate that new keys and certificates are in use.

For organizations that have placed a priority on security and are using Venafi TrustForce™ (previously known as Provisioning for Server Certificate Manager), security administrators can quickly have new keys and certificates automatically generated and installed without waiting for assistance from application and operations teams. Using the data, intelligence, and policy from TrustAuthority, TrustForce securely distributes new keys and certificates, installs them, and validates the application is back up and running with the new trusted keys and certificates. This is the automated response and remediation that security teams need to deal with increasing attacks on keys and certificates.

Mad Max Here We Come: Heartbleed shows how much we blindly trust keys and certificates

The stage is set: attackers know that we can’t secure the trust that everything digital we know depends upon — we can’t secure keys and certificates and we can’t respond and remediate when attacked. The world Gartner painted — an almost Mad Max world — of “Living in a World Without Trust” is about to become reality if we don't take securing keys and certificates seriously, and put automated capabilities in place to respond and remediate immediately. One thing is for certain: this won't be the last time we're in this same position and need to respond quickly.

Contact Venafi now to get help responding and remediating to Heartbleed and be ready for attacks to come on keys and certificates.

Related resources:

• Live Webinar: Remediating Heartbleed Vulnerability — Register Now
• Understanding the Heartbleed Vulnerability
• Security Rapid Response Bulletin
• Support Security Alert: Heartbleed

Response is not complete until trust is re-established

By now most organizations have responded to the Heartbleed vulnerability by patching vulnerable systems. Good. The next step must be to replace ALL keys and certificates. Successful private key extraction exploitation in just hours shows keys and certificates must be assumed comprised. The urgency to replace keys and certificates is even more important as details emerge about exploits being used in the wild for months and possibly years. As a result, experts all agree — from Bruce Schneier, to Gartner’s Erik Heidt, to CloudFlare — the message is: replace keys and certificates.

Underestimating our adversaries and taking no action is not an option. Gartner’s advice to enterprise IT security teams is very clear:

"Because this attack enables the recovery of the private key itself, certificate rotation alone will not protect you! New private keys must be generated."

Following successful private key exploitation in its Heartbleed Challenge, CloudFlare turned from skeptical to genuinely concerned: “Our recommendation based on this finding is that everyone reissue and revoke their private keys.”

Unfortunately, I’ve observed some response teams either 1) assuming that patching is enough 2) patching and reissuing certificates without generating new keys. Unless private keys are replaced, attackers can still spoof websites and decrypt encrypted communication.

CISOs and CIOs should not report to their CEOs, board of directors, and customers that they are safe until they’ve replaced all keys and certificates. Doing so is ill advised as we learn more about new exploits and the likelihood that Heartbleed exploits occurred in 2013 and before.

Furthermore, enterprises must assume, just as they are with userid and passwords, that ALL keys and certificates are compromised, not just those that secured vulnerable Heartbleed systems. Kill Chain Analysis helps us understand that attackers will look to expand their attacks using similar methods and targets as their first intrusion. Further infiltration of networks means that SSL keys and certificate and SSH keys, even though not running vulnerable OpenSSL, should be assumed targets and compromised.

Respond & Remediate Now Before It's Too Late

• Know where all keys and certificates are located
• Generate new keys and certificates
• Replace new keys and certificates, revoke old ones
• Validate remediation to ensure new key and certificates are in place

To help organizations respond, Venafi has prepared more guidance on remediation steps. Venafi customers have already remediated keys and certificates in hours. And in the last few days, we’ve been helping many new customers start to respond quickly. Please contact Venafi’s Incident Response and Remediation team to help your enterprise.

Related resources:

• Live Webinar: Remediating Heartbleed Vulnerability — Register Now
• Understanding the Heartbleed Vulnerability
• Security Rapid Response Bulletin

Time is running out to change keys and certificates or else…

The world appears to be failing to respond to the Heartbleed vulnerability. In fact well under 16% of vulnerable keys and certificates have been replaced. Experts Bruce Schneier, Gartner, Akamai, and CloudFlare all agree about what enterprises must assume and do: Enterprises must assume keys and certificates are compromised. As a result, organizations MUST change ALL keys and certificates to complete remediation: rekey, reissue, and revoke.

Remediation of ALL keys and certificates is important since the vulnerability may have exposed keys and certificates as a result of continued expansion of attacks beyond the initial infiltration and vulnerability.

Respected security researcher Dan Kaminsky explained the reason behind replacing ALL keys and certificates:

“Find anything moving SSL, particularly your SSL VPNs, prioritizing on open inbound, any TCP port. Cycle your certs if you have them, you’re going to lose them, you may have already, we don’t know.”

The EFF has confirmed Heartbleed exploits in November 2013 and other reports indicate possible exploits go back two years. Therefore, we must assume our adversaries were compromising keys and certificates for long time before Monday, April 7th when the Heartbleed bug was first publically announced.

Until key and certificate replacement remediation occurs, enterprises are vulnerable to spoofing and decryption. As of April 15th, over seven days since the first calls to change keys and certificates began, Netcraft reports that only 16% of certificates known to be used with publicly vulnerable webserver were only revoked.

Less than 16% remediation

And remediation on these systems is likely even lower than 16% of publicly vulnerable systems because new keys were not created in many cases. Some incident response teams are only reissuing certificates without changing keys. Gartner’s Erik Heidt accurately describes the situation in his Heartbleed remediation blog:

“Many organizations perform ‘lazy’ certificate rotations, and do not create new keys! This is a bad practice.“

Gartner concluded, “because this attack [Heartbleed] enables the recovery of the private key itself, certificate rotation alone will not protect you! New private keys must be generated.”

This is the same guidance that once-skeptical, now-converted CloudFlare gave after researchers proved SSL/TLS keys could be stolen using the Heartbleed vulnerability:

“Our recommendation based on this finding is that everyone reissue and revoke their private keys”

Furthermore, there are hundreds of applications from IBM, Juniper, Cisco, and many others that are vulnerable to Heartbleed and use keys and certificates. Many of these operate behind the firewall and some may, incorrectly, assume replacing keys and certificates on these systems is not important. Assuming this would be a terrible mistake since behind-the-firewall attackers would love nothing more than to be able to spoof services like VPNs, security systems, applications servers, and more and decrypt encrypted SSL/TLS traffic.

Take action now while you still can

CISOs should not and cannot tolerate this situation. Some IT security leaders may be told by incident response teams that a full-scale rekey, reissue, and revoke is not necessary. Others may be told that it’s too complicated or time consuming. And there has been a false assumption that patching is all that’s required. Some may be misinformed, possibly by websites that show remediation is complete, but have no awareness of changes to keys and certificates, only to basic patching.

Do CISOs and security teams believe that usernames and passwords should not be changed? No. Therefore, they should not, and cannot, live with a situation where all keys and certificates are not replaced.

Venafi customers are quickly remediating

Venafi customers are speeding through incident response. With Venafi TrustAuthority™, security teams have full visibility into all their keys and certificates, which applications use them, and who owns them. Combined with Venafi TrustForce™, remediation is only a click away: keys and certificates can be changed and securely distributed and installed. All without any intervention from an application owner or system administrator!

Whether you’re a Venafi customer or not, please change ALL of your keys AND certificates. Triage keys and certificates from public vulnerable systems, then internal vulnerable systems, and then the remaining keys and certificates throughout the enterprise. Remediation will be complete and your organization will be secure.

You can learn more about how Venafi can help you quickly respond and remediate to incidents like Heartbleed here.

Heartbleed Impact

The Heartbleed vulnerability unequivocally demonstrates the impact a single vulnerability has on all organizations when keys and certificates are exposed. Cyber-criminals have unfettered access to the keys and certificates on vulnerable systems, without any trace. Researchers that identified the vulnerability sum up the impact simply, "any protection given by the encryption and the signatures in the X.509 certificates can be bypassed" (Heartbleed) You must assume all keys and certificates are compromised and immediately replace them to remediate. Unfortunately, most organizations cannot!

The vulnerability is not limited to webservers, it impacts any system running OpenSSL 1.0.1 – 1.0.1f. This includes mail servers, chat servers, VPN’s, network appliance, client software, VOIP phones and more. Hundreds of software applications from security vendors have already confirmed their software as being susceptible to the Heartbleed vulnerability.

Next-Generation Trust Protection for Next-Generation Threats

Venafi Trust Protection Platform provides holistic remediation from the Heartbleed vulnerability. Via TrustAuthority and TrustForce, organizations are able to quickly identify any system susceptible to the Heartbleed vulnerability, regardless if it is a publicly facing web server or on the internal network and remediate.

Venafi TrustAuthority can quickly identify systems impacted by the Heartbleed vulnerability, establish how many keys and certificates are in use, where they are used, and who is responsible for them. Once TrustAuthority defines a comprehensive inventory of all X.509 certificates, they need to be replaced.

Venafi TrustForce uses lightweight agent and agentless technologies to automate complex activities, including rekeying and recertification, for which manual processes might open vulnerabilities. With TrustForce, the remediation of keys and certificates is completely automated and secure.

The following step-by-step process outlines how organizations can automate remediation of the Heartbleed vulnerability using both TrustAuthority and TrustForce with the Vulnerability Remediation Plugin.

Step 1:

Using TrustAuthority, identify any server that may be susceptible to the Heartbleed vulnerability. This can be achieved by scanning both your internal and public networks.

Once vulnerable systems have been identified, patch them by upgrading to OpenSSL 1.0.1g OR recompile the OpenSSL library with the OPENSSL_NO_HEARTBEATS flag

Step 2:

Identify keys and certificates that need to be fixed based on knowledge of vulnerable applications.

As you review results from various search types, you can select certificates individually or in groups.

Step 3:

The generation of keys and X.509 certificates is automated via the Work Queue. However, prior to initiating a Work Queue, it is critical to make sure that a new private key is generated to remediate further compromise as a result of the private key being stolen via the Heartbleed vulnerability.

From within the Policy tree under a policy object or certificate object ensure that your certificate does not have the “Reuse Private key” option selected.

Step 4 – 5:

Using TrustAuthority and TrustForce together, the new private key generation, CSR, secure distribution, installation and revocation process for certificates is all performed automatically via the Work Queue. For organizations that only have TrustAuthority, the secure distribution and installation is manual.

Step 6 – 8:

Once all publicly facing servers susceptible to the Heartbleed vulnerability are remediated by patching OpenSSL and replacing the private key and certificates, steps 1 – 5 should be repeated for all internal servers impacted by the vulnerability.

Step 9:

Validation of the Heartbleed remediation is critical to success. For this you should validate all keys and certificates are replaced, detect anomalies and alert the organization on any related security events at least every 24 hours.

Contact Venafi to help accelerate your Heartbleed remediation.

Organizations—from service providers, banks, and retailers to government agencies—were recently blindsided by the Heartbleed bug, a critical vulnerability in the OpenSSL cryptographic software library, which underlies trust for secure transactions worldwide. Attackers wasted no time exploiting the vulnerability, which allows them to extract private Secure Socket Layer (SSL) keys with absolute ease. They can read any of the sensitive information that customers have entrusted to the organization’s now-compromised security. To protect their data and their customers, organizations had to respond even more quickly than attackers. They had to assess their vulnerability, determine which systems were using OpenSSL certificates, and then take the steps necessary to re-establish trust, including updating OpenSSL, replacing certificates, and generating new keys.

Unfortunately, most organizations are ill-equipped to respond to trust-based vulnerabilities and threats—especially in such an abbreviated timeframe. As noted in a study by the Ponemon Institute, most enterprises have as many as 17,000 certificates but few control and secure those certificates, making it difficult for their IT security teams to find and replace vulnerable certificates. As a Chief Information Security Officer (CISO) with over 25 years’ experience in IT security, compliance and identity management; with many of those years as an executive leader, I have spent a lot of time analyzing why companies aren’t protecting their precious cryptographic assets and how they can improve their security practices.

The oversight, I think, stems mainly from lack of awareness. Most organizations simply do not realize the extreme danger trust-based attacks pose. For many years, organizations have focused almost entirely on defense in-depth as a way of ensuring confidentiality, integrity, and availability (CIA). They rely heavily on Intrusion Detection System (IDS)/Intrusions Protection System (IPS) solutions to protect their systems and data from attacks. As effective as IDS/IPS solutions can be in mitigating attacks, many of these solutions cannot see into encrypted traffic, making it difficult, if not impossible, for them to detect attacks that exploit certificates and keys.

Many organizations also fail to understand the importance of protecting their SSH keys—leaving them open to the same type of abuse Edward Snowden used to breach security at the U.S. National Security Agency (NSA). SSH keys are a particularly easy target because SSH keys don’t expire and most enterprises don’t rotate their SSH keys. Further compounding their vulnerability, many organizations fail to track who has access to SSH keys. When administrators leave the company, they all too often take SSH keys with them, giving them ongoing privileged access to the organization’s systems.

With the sharp increase in trust-based attacks, organizations must modify their traditional CIA security models to include securing their certificates and keys. After all, certificates and keys are used to ensure confidentiality, permitting only authorized recipients to view protected data. If an attacker compromises a certificate or key, that confidentiality is no longer assured. And any IT security professional charged with ensuring availability must understand: controlling the keys and certificates on which systems rely prevents costly outages.

Organizations must take into account the critical role cryptographic assets play in ensuring confidentiality and availability because they can no longer afford to be blindsided by trust-based attacks. In my years as an IT security professional, I have assembled best practices for securing certificates and keys--practices that ensure that the trust organizations and their customers place in these vital assets is well-founded. Organizations must inventory their certificates and keys so that when a vulnerability is discovered, they can accurately assess their risk exposure. They must have policies and automated solutions for rotating keys so that they can quickly close the vulnerability. They must also be able to monitor the use of SSL and SSH keys so that they can detect suspicious behavior that flies under the radar of traditional IDS/IPS solutions.

In future blogs, I'll give you in-depth insight into each of these practices, keep you up-to-date on the latest trust-based exploits, and help you discover the best ways to protect yourself. In addition, I will throw in some blogs on leadership, competency focus areas and ideas on staffing security roles—which I know is always a challenge!

I am looking forward to having you join me each month!

Cheers!

Tammy Moskites, Venafi CISO

When it comes to defending against advanced threats that take advantage of keys and certificates, most organizations have a gaping hole in their security strategy. Cyber criminals on the other hand know all too well how little awareness, or ability to respond, most organizations have to trust-based attacks. They have figured out that they can go undetected for years by using trusted SSL connections, exploiting compromised SSL keys, or stealing SSH keys to gain rogue administrator access to servers and clouds.

Only recently are we discovering the true sophistication and breadth of the problem. Take, for example, the Mask APT operation. For more than 7 years it went undiscovered, stealing credentials such as SSL, VPN, and SSH cryptographic keys and digital certificates.

And Operation Windigo—still active—has been in the wild since 2011, compromising over 25,000 Linux and Unix web servers. Cyber criminals use these servers to steal SSH credentials, redirect visitors to malicious websites, and send millions of spam messages per day.

Trojans that steal keys and certificates are nothing new due to the high value of these cryptographic assets. A single stolen certificate is worth U.S. $700 or more on the underground market—much more than any single identity.

The Heartbleed vulnerability that was recently discovered—a free gift to every cyber criminal—enables anyone to use the vulnerability to steal private keys for X.509 certificates without any trace. What’s worse is that the vulnerability has been around since 2011, with confirmed successful exploitation since last year. This vulnerability has been dubbed as catastrophic, impacting at least twenty percent of the world’s web servers. But it’s not just web servers that are impacted, there are hundreds of application vendors that are also impacted, many of which are behind the firewall. Unfortunately, many organizations are failing to remediate adequately, resulting in unfettered access for cyber criminals.

Although perimeter-based and next-generation security solutions provide good protection against advanced threats, they do not address trust-based attacks. When an organization removes malicious code from the network but fails to replace potentially compromised keys and certificates, the organization leaves the enterprise network under the control of the cyber criminals who retain the ability to monitor, impersonate, and access the network.

The featured Gartner research examines the state of enterprises’ strategies for dealing with new SSL cybersecurity threats and vulnerabilities. The report also outlines the legal implications and negative effects when unauthorized parties can decrypt SSL traffic on the enterprise network. Securing SSL keys and certificates, enforcing trust policies, and understanding what is trusted and what is not will be critical to mitigating these escalating attacks.

In addition, the report includes recommendations provided by both Gartner and Venafi. These include suggestions on how to mitigate trust-based attacks with Next-Generation Trust Protection, so that you can secure and protect keys and certificates, while also detecting malicious use of these assets.

Download the complete research note now.

Traditionally, organizations have used certificates signed by Certificate Authorities (CAs) to secure both external and internal communications. Because security breaches and attacks on CAs are on the rise, however, organizations are looking for ways to reduce their threat surface. One strategy is to use self-signed certificates to secure communications between internal systems and to authenticate devices and users to the internal network.

When compared to certificates signed by CAs, self-signed certificates are typically considered untrustworthy because they contain both the public and private key in the same entity. This assessment may hold true when a self-signed certificate is used on a publicly accessible service, but self-signed certificates can be a valid alternative for securing internal communications. If properly secured, self-signed certificates greatly reduce the risk profile of using CA certificates for internal communications.

There’s no doubt the industry understands the benefits of using self-signed certificates to reduce the threat and exposure to attacks on CAs. However, if organizations do not have the ability to continuously monitor and protect self-signed certificates, cyber-criminals will exploit this strategy and turn it into a weakness, such as those identified in Mandiant’s APT1. (This report summarizes the activities of one of the most active Advanced Persistent Threat [APT] groups and provides guidelines for eliminating vulnerabilities this group exploits.)

A number of attacks have successfully exploited self-signed certificates. For example, the Shylock Trojan, which targeted 24 major banks (including Chase Manhattan, Bank of America, Citi, Wells Fargo, Barclays, and Bank of Scotland) last year, is designed to steal money while customers use online banking services. The Shylock Trojan uses self-signed certificates to disguise the phone home traffic to command and control. Another Trojan attack used a fake, anomalous self-signed certificate, which was supposedly from Adobe, to bypass detection. And earlier this year, Tor network exit relays were manipulated using self-signed certificates to create Man-in-the-Middle (MiTM) attacks.

Once compromised, self-signed certificates can pose a number of challenges. If an attacker has already gained access to a system, the attacker can spoof the identity of the subject. Although CAs can revoke a certificate when they discover it has been compromised, organizations cannot revoke a self-signed certificate. Instead, they must replace or rotate the certificate. If a self-signed certificate’s private key is compromised, the inability to rapidly revoke the key may open the door to malicious attackers.

In addition, most organizations underestimate the number of active certificates in use on their systems. For example, one major retail organization estimated it had 5,000 active certificates, but it actually had 20,000! Even more alarming, more than 5,000 certificates had no owners, and no one knew what they did, what they allowed, and who was responsible for them. This lack of insight can easily occur when organizations use self-signed certificates.

Organizations should also be aware of how in-house developers are using self-signed certificates. Rather than purchasing CA certificates, many in-house developers download an open source implementation of SSL and TLS, called OpenSSL and create the certificates they need to develop and test software. If used in production versions of applications, these self-signed certificates can make organizations vulnerable to unforeseen attacks. Case in point: the recent Heartbleed vulnerability shows exactly how organizations blindly trust keys and certificates and how quickly and easily cyber-criminals can exploit a trust-related vulnerability.

Couple these self-signed certificate vulnerabilities with the operational challenges most organizations face with expiring and misconfigured certificates, and you can see why attackers are quickly turning this strength into a vulnerability. Organizations must be able to swiftly replace compromised self-signed certificates on internal systems and replace the self-signed certificates used on production systems with certificates issued by an established intermediate CA. Organizations also need a mechanism to detect and monitor self-signed certificates, identify rogue certificates in use, and quickly remediate. Furthermore, organizations should establish a baseline and, when appropriate, automatically acquire new certificates to replace those that do not comply with the policies they have established.

All certificates, especially self-signed certificates, need to be secured and protected. According to the Ponemon Institute, 51% of organizations do not know exactly how many certificates are in use within their infrastructures—let alone how many of them are self-signed or CA-signed. This represents an unquantifiable risk! Organizations need to gain control over trust. They must not only know which systems use self-signed certificates but also replace these certificates on a regular basis. With clear visibility into their self-signed certificate inventory, organizations can respond much more quickly when certificates are compromised and reduce their risk to trust-based attacks.

With the media no longer focusing on the Heartbleed vulnerability, most people think that organizations have adequately addressed the problem, and the threat has passed. Because most people don’t understand the full impact of Heartbleed, however, they don’t realize that the fallout from this one vulnerability is likely to continue, not just for weeks but possibly for months to come.

The problem is that most organizations responded to the Heartbleed vulnerability tactically, just as they would respond to any known vulnerability: they identified the systems using OpenSSL and patched them. These organizations did not understand that the Heartbleed vulnerability undermines the very trust on which every business and government relies to secure its data. It gives hackers privileges that they can use to compromise other, seemingly secure systems. Because most organizations didn’t understand the “big picture,” they failed to fully remediate the problem. They did not revoke and replace all of their digital certificates, leaving their systems vulnerable to ongoing trust-based attacks.

Unfortunately, I don’t believe the Heartbleed vulnerability is an isolated incident. Malicious attackers recognize the value of targeting digital assets, which is why trust-based attacks have significantly increased over the last several years. These malicious actors will continue to look for and target trust-based vulnerabilities, so organizations should not be wondering if another Heartbleed will occur; they should be preparing now to respond more quickly when the next event occurs.

Organizations that took a tactical approach to addressing the Heartbleed vulnerability (simply patching the systems they thought were affected) will be ill-prepared for the next trust-based crisis. Because these organizations don’t yet understand the danger of trust-based attacks, they will continue to focus on what they perceive is the greatest danger on the cyber-security landscape—Advanced Persistent Threats (APTs)—and rely solely on traditional security tools such as packet-inspection tools and Intrusion Detection System/Intrusion Protection System (IDS/IPS) solutions to protect their environment. All of which are inadequate against trust-based attacks. They will not realize that trust-based attacks are all too often the key component of APTs. Therefore, any security solution that does not detect and mitigate trust-based attacks is inadequate. Despite what some security vendors claim, detecting and remediating trust-based vulnerabilities such as Heartbleed requires more than just monitoring traffic and patching systems. Organizations must have a solution that inventories all certificates and digital keys in use on the network, detects anomalous usage, and helps administrators swiftly revoke and replace all certificates.

This is, of course, exactly what Venafi does best. In talking to our customers using Venafi TrustAuthority™ and TrustForce™, we found that these customers were able to respond quickly to Heartbleed, identifying susceptible systems, revoking and replacing all their certificates, as recommended by Gartner. When their Chief Executive Officers (CEOs), Chief Information Officers (CIOs), and even the Board of Directors asked, “What are you doing about this problem?” the Chief Information Security Officers (CISOs) at these organizations were able to say with complete confidence, “We have successfully remediated Heartbleed with Venafi. We have identified and patched all systems impacted, replaced private keys with new ones and issued new certificates.”

As more events such as the Heartbleed vulnerability occur, trust is going to become a top-of-mind issue for all CISOs. Protecting trust will quickly evolve from a nice-to-have to a must-have. Organizations are going to have to know where all the keys and certificates are in their environment, and they are going to have to have the agility to react to trust-based threats almost immediately. Organizations ignorant of the threat posed by trust-based attacks—organizations without a solution to combat these attacks—are going to struggle again and again.

However, CISOs who understand what hackers are looking for when they exploit a vulnerability like Heartbleed—those ever-so-critical keys and certificates—can rise above the struggle. When I meet with customers to discuss the challenges of trust-based attacks, I’ve often seen them experience a kind of “light bulb” moment, as they realize that they have to go beyond removing malware and beyond patching vulnerabilities. They have to restore the trust that the hackers compromised. I joined Venafi because I love being part of these “light bulb” moments. And I love being able to reply, when customers ask how they can possibly revoke and renew thousands or even tens of thousands of keys and certificates, that Venafi has a solution.

Cheers!

Tammy Moskites, Venafi CISO

Last month the Heartbleed vulnerability took the world by storm. IT groups across the globe scrambled to patch systems that were susceptible to the OpenSSL vulnerability known as Heartbleed. Y2K—the millennium bug—has been dwarfed in comparison to the impact the Heartbleed vulnerability has had on the world. Let’s face it, software has vulnerabilities and cybercriminals will take advantage of them. We can expect another “Heartbleed-like” vulnerability and should prepare—now. The question is, have you budgeted for it?

Have you considered the costs associated with responding to the Heartbleed vulnerability? I’m not talking about the financial impact from the theft of intellectual property or brand damage but the man-hours and salary costs to respond. Before doing so, here’s a quick recap on the severity of the Heartbleed vulnerability:

1. An attacker can steal keys and certificates without a trace.
2. The stolen keys and certificates can then be used in trust-based attacks like phishing, man-in-the-middle (MITM), and replay attacks.
3. The only way to remediate is to patch susceptible OpenSSL systems and replace all keys and certificates.
4. Replacement of all keys and certificates is recommended, because you don’t know which systems—even non-OpenSSL ones—may have had keys and certificates stolen via stepping-stone attacks. You must assume all keys and certificates have been stolen!

The average large enterprise has in excess of 17,000 encryption keys and certificates. Consider the monumental task of changing all 17,000 encryption keys and certificates in an enterprise network. This task is especially burdensome, because most organizations manually manage their public key infrastructure (PKI) via spreadsheets or basic tracking software to detect expiring certificates. To replace a certificate on a system, an administrator needs to perform multiple manual steps:

1. Generate a new key
2. Issue a certificate signing request (CSR)
3. Install the new key and certificate on the respective system
4. Revoke the old certificate

The average large enterprise takes up to four hours to perform the necessary steps to replace a certificate on a single system. The median salary for a system administrator responsible for administering the PKI is U.S. $60,000. When extrapolating the cost to respond to the Heartbleed vulnerability, it costs the organization $115.00 per certificate. To replace 17,000 encryption keys and certificates it will cost your organization $1.95 million—in labor costs alone!

And 17,000 keys and certificates is a moderate estimate for the average enterprise network. At Venafi, we have customers that have replaced all of their keys and certificates within their networks and this equaled hundreds of thousands of keys and certificates per customer.

It seems that the world is still very much in a vulnerable state. Research published by Netcraft shows that 86% of public websites susceptible to compromise from the Heartbleed vulnerability have not correctly been remediated.

Last month, I published a blog detailing how any organization can use Venafi Trust Protection Platform to expedite and automate the remediation of Heartbleed and drastically reduce the response time from hours to minutes. You can read about it here.

By using Venafi TrustAuthority™, organizations can quickly identify systems impacted by the Heartbleed vulnerability and then determine how many keys and certificates are in use, where they are used, and who is responsible for them. Venafi TrustForce™ enables automated remediation of keys and certificates. This includes the installation and validation on impacted systems.

Whether you were impacted by Heartbleed or preparing to defend against the next crippling vulnerability, now is the time to implement a solution that enables your organization to quickly and efficiently replace all keys and certificates. Can you really afford not to?

Related resources:

• Solution Brief: Remediating Heartbleed with Next-Generation Trust Protection
• Aberdeen Webinar: It's SSH—The Keys to the Kingdom Left Under the Doormat
• Gartner Research: Responding to New SSL Cybersecurity Threats

Mobile devices and mobile applications are becoming more dangerous threat vectors against the corporate network. Android devices seem to be continually under attack with new reports of malware appearing at an astounding rate of 197% from 2012 to 2013, based on Fourth Quarter 2013 McAfee Labs research. And according to the Verizon Data Breach Report, 71% of compromised assets in 2013 involved users and their endpoints.

Today, enterprises are turning to certificates to secure mobile devices, applications, and users. Digital certificates authenticate mobile users to applications, VPNs, and WiFi networks. However, many organizations have little to no control or visibility into their mobile certificate inventory and they’re unaware to which mobile certificates their users have access. A number of security risks from misused or orphaned mobile VPN certificates to unauthorized access by terminated employees or contractors can be easily exploited. Cybercriminals take advantage of mobile certificates and pose as trusted users, thereby infiltrating your network and stealing intellectual property.

Remember that mobile certificates issued to users serve as trusted credentials for secure access to your critical networks, applications, and data. So the biggest threat to your enterprise isn’t necessarily the mobile malware, but rather the unauthorized users who may access your information.

Here are 5 ways you can prevent unauthorized access of misused mobile certificates.

1. Get visibility into your entire mobile and user certificate inventory
   With clear insight into your full mobile and user certificate inventory, you can identify duplicate, orphaned, and unneeded certificates. By mapping users to the certificates they are issued, you can identify certificates that are exposed to unauthorized user access. This will enable you to establish a baseline of known certificates and normal usage.
2. Automatically enforce policies for mobile certificate issuance
   Issuing certificates to mobile devices and mobile applications according to centralized IT security policies is paramount. By enforcing cryptographic policies that control attributes such as key length, validity period, and approved CAs and by applying workflow processes to mobile certificate issuance, you can reduce your organization’s attack surface.
3. Go beyond Mobile Device Management capabilities for certificates
   Although Mobile Device Management (MDM) solutions can provide capabilities such as deploying applications, remotely wiping devices, or deploying certificates for mobile devices, protecting mobile certificates and keys extends beyond the scope of MDMs. MDMs alone cannot remove potentially orphaned or compromised mobile certificates. As organization adopt new mobile applications, they must have the ability to enforce IT security policies to establish norms and detect mobile certificate-based anomalies such as orphaned or duplicate certificates. They must also respond quickly by revoking a user’s certificates across multiple CAs. Furthermore, users do not always receive mobile certificates through MDMs. They may request certificates using other tools or even multiple CAs. Therefore you must implement a solution that is capable of enforcing certificate and key policies consistently across your entire environment.
4. Immediately revoke mobile certificates when authorized use is concluded
   In the event that an employee is terminated, leaves the company without notice, or reassigns, you should immediately revoke all mobile and user certificates associated with that employee in order to prevent unauthorized access to your network. Also, keep in mind that wiping a mobile device using your MDM solution is not sufficient, because the employee could have made a copy of the certificate and key before leaving the company. Rapid revocation of all certificates, whether deployed through an MDM solution or some other means, is critical in these situations.
5. Ensure secure end-user self service If your organization enables users to request certificates using enrollment portals, you must provide a secure self-service portal that enables your end users to quickly request certificates for WiFi, VPN, email, browser, or other applications. You need a mechanism that governs user certificate issuance to ensure certificates comply with security policies, to eliminate guesswork on the part of inexperienced users, and to prevent errors.

As mobile devices continue to become more prevalent, it is important for you to take a strategic approach to securing your organization’s mobile device certificates. Following these 5 steps will help you to avoid misuse of these certificates and protect your organization against trust-based attacks that use mobile devices as an attack vector. But you don’t have to do it alone. Venafi offers a solution that can help you develop an approach to securing your mobile certificates.

Related Resources:

• Webinar: Preventing Unauthorized Access & Attacks
• Whitepaper: Securing Mobile Certificates
• Aberdeen Webinar: Mitigating SSH Vulnerabilities

In early April, the vulnerability known simply as “Heartbleed” became the latest rage. During the first week after discovery, the mainstream media aggressively reported on Heartbleed, stirring up a tornado of fear, uncertainty, and doubt amongst all Internet users. Never thought I’d see “Fox and Friends” talking about OpenSSL, two-factor authentication, and digital certificates, but it happened daily only 7 short weeks ago.

This “Heartbleed Tornado” subsequently led to enterprise security professionals receiving email inbox loads of offers claiming to help you remediate. For many, especially those in the executive suites and board rooms, it was the first time they understood the true power and importance of private encryption keys and digital certificates, as well as the imperative need to protect them. Finally, I thought, the world is waking up and understanding the need to secure and protect its most valuable assets, which provide the backbone of a trustworthy Internet—encryption keys and digital certificates.

Unfortunately, as loud as the Heartbleed Tornado roared, the lions’ share of the remediation advice related to Heartbleed was simply the following:

1. Check and see if websites you use are vulnerable (and have been patched), and
2. Emphasize the importance of changing your passwords.

Patching OpenSSL and changing user-credential passwords are two of the steps to remediation. But the elephant in the room, the exposure of private encryption keys and certificates (and thus the need to revoke and reissue them ALL), was only consistently reported on by those media outlets and bloggers in the security space itself.

Any hot media story has a shelf life, and there’s only so many Heartbleed stories that will continue to draw readers in. So once the clicks died down, the mainstream all but forgot it. And those mainstream stories that remain, only touch upon the surface of the vulnerability, such as NBC’s cosmetic piece on “How Major Websites Rank on Password Security.”

But the important thing to realize is this: The threat against a trustworthy digital universe did not begin with Heartbleed. And it certainly does not end with it either. Heartbleed was simply the latest in a growing mountain of threats that continue to evolve against encryption keys and digital certificates, and thus trust online.

For more information on Heartbleed and how to remediate effectively, check out the Venafi Heartbleed Solution page.

In my blog post about the Heartbleed hype, I stress that threats against keys and certificates neither started with the Heartbleed vulnerability, nor certainly will end with it. Threats specifically against keys and certificates go back to 2009 and 2010, where Stuxnet and Duqu provided the virtual blueprint to the cyber criminal communities around the world by using stolen certificates to make the malware infection payload look legitimate.

Attacks on the Certificate Authorities themselves accelerated in 2011, with well-known CAs such as Comodo and Digicert Malaysia suffering breaches. In September of 2011, with the breach of DigiNotar, some of its customers were left with no choice but to consider shutting down operations all together. By the end of 2011, there were 12 significant, publicly disclosed breaches of Certificate Authorities around the globe. It’s also worth mentioning that it was New Year’s Eve 2011 when Heartbleed was “born.”

In simple terms, Heartbleed is the result of a developer’s coding flaw. It’s a mistake that resulted in a massive 2+ year exposure. And no one knew it was happening. Vulnerabilities that expose keys and certificates occur frequently, although certainly not on as massive a scale as Heartbleed. Weak cryptography, along with weak processes and mistakes working with cryptography, are a daily occurrence.

In 2012, this burgeoning war on trust continued to evolve. To counteract the growing install base of advanced threat detection solutions in Global 2000 enterprises, we began to see a run on code signing certificates and widespread adoption of signing malware with certificates. Adobe announced that its code signing infrastructure had been compromised. Security vendors themselves were targeted, such as the case in which Bit9 had its secret code signing certificates stolen.

Bad actors of 2012 also realized they could subvert trust by obtaining and misusing Secure Shell (SSH) Keys on a wide scale. Various breaches and vulnerabilities, which ultimately exposed SSH Keys, were reported, most notably at GitHub and FreeBSD. Exposures involving SSH Keys are even more nebulous in some regards in that enterprises have much less visibility into or control of them. Moreover, unlike a digital certificate with a validity period shelf-life, which will eventually expire, SSH Keys have no such expiration date.

If 2012 was the year that attacks against trust learned to walk, then 2013 was the year they learned to drive….and drive fast. New attack schemes against TLS/SSL, such as Lucky 13, BEAST, CRIME, BREACH, and more, emerged, allowing for attackers to exfiltrate sensitive data from encrypted pages. Edward Snowden went from being an obscure, soft-spoken NSA contractor living in Hawaii to becoming a household name after stealing thousands of classified NSA files—all made possible by subverting the trust and access security provided SSH keys and digital certificates. The year 2013 also marked the first time we began to see a significant percentage increase in Android malware enabled by digital certificates (24% of all Android malware as of October 2013, up from 6.6% in 2012 and 2.9% in 2011).

Here in 2014, attacks on trust have graduated from college and are here to stay. Highly complex Advanced Persistent Threats exist with the main objective of stealing legitimate corporate keys and certificates of all types. Have a look at the breakdown of “El Careto” (or “The Mask”), which was discovered by Kaspersky in February after 7+ years undetected in the wild. Careto, which looks like a state-sponsored campaign due its complexity and professionalism, gathers sensitive data from infected systems, largely including VPN configurations, SSH Keys, and RDP files.

We’ve also seen substantive evidence of forged certificates being used to decrypt and monitor traffic as well as steal credentials and sensitive data. In a recent study by Facebook and Carnegie Mellon researchers, over 6,800 connections to Facebook used forged certificates.

Then over the past few weeks, evidence emerged around “ZBerp,” which is a hybrid Trojan “love child” of Zeus and Carberp and uses SSL to secure communications with command and control to evade detection by today’s most popular network security products.

From the accidental introduction of vulnerabilities, like Heartbleed, to advanced, persistent, professional efforts to both circumvent and misuse keys and certificates, the risk to these cryptographic assets is evolving and advancing. These threats undermine the trust we inherently place in keys and certificates to authenticate people and machines and encrypt data we intend to safeguard and keep private. PKI is under attack. Securing, protecting, and controlling enterprise keys and certificates is no longer simply a nice operational benefit. It’s a must have to defend the veracity of your entire business and brand.

OpenSSL has been highly publicized in the last few months—at least for the long standing bugs that have resulted in the complete breakdown of trust in the Internet and the way we do business!

Of the last 6 bugs patched in OpenSSL the most noteworthy are Heartbleed, Cupid, and OpenSSL CCS injection:

• Heartbleed enables an attacker to steal private keys and other sensitive credentials.
• Cupid takes advantage of the Heartbleed flaw in TLS over the Extensible Authentication Protocol (EAP) to attack vulnerable clients connecting to a wireless network or to attack vulnerable wireless access points. The result is similar to that of Heartbleed.
• OpenSSL CCS injection is exploited by an attacker using crafted handshakes to force weak key material to be used between a client and server to perform a man-in-the-middle (MITM) attack.

It would seem from the recent examples that attackers are more brazenly using SSL / TLS against organizations with great success. We need to ask ourselves why. I believe we can answer this question by simply reviewing the response that most organizations have taken to remediate Heartbleed and evaluate where they are now.

Venafi Labs frequently analyzes the websites of the Global 2000 organizations and the Alexa Top 1 Million to identify SSL / TLS vulnerabilities. We have found that although many organizations believe they are not susceptible to Heartbleed anymore, the data shows otherwise.

As part of our analysis for Heartbleed we first compared scanning results with previously published Heartbleed vulnerable lists from ZMAP and Github. It was pleasant to see that most domains listed on these repositories have remediated correctly. However, there are a large number of organizations that are not included on the lists and are still vulnerable. Our scan data specifically focuses on Global 2000 organizations to better understand how successful they have been at remediating Heartbleed.

Even though most Global 2000 organizations have taken steps to remediate Heartbleed, many have not fully remediated. When comparing the organizations that have correctly remediated, it would seem that discount stores took the Target breach to heart. They account for 9% that achieved full remediation of systems from the sample set.

On the other hand, telecommunications services have a long way to go to remediate Heartbleed. They are responsible for 41% of the confirmed Heartbleed vulnerable systems from the Global 2000 scan. Think of the wealth of information that cybercriminals are still syphoning off these vulnerable systems from Telecommunications services’ customers!

Heartbleed has been known to the world for 10 weeks now. Yet we still see evidence of thousands of systems susceptible to Heartbleed that have not even been patched yet. Venafi Labs will periodically publish updated information on organizations’ effectiveness with remediating the Heartbleed vulnerability based on our analysis of trust-based attacks.

Learn how Venafi can help identify systems susceptible to Heartbleed and the required remediation.

This year, the Payment Card Industry Data Security Standard (PCI DSS) is ten years old. Happy birthday PCI DSS, ten years is a significant milestone. Yet the Verizon 2014 PCI Compliance Report reveals that around 90% of organizations are not fully PCI DSS compliant. In fact, only a little more than half of the companies in the study passed 7 of the 12 PCI DSS requirements.  And with the release of PCI DSS version 3 in November 2013, and an implementation date of June 30, 2015, we can expect compliance to dip even further in the near term.

This lack of compliance is disconcerting because the PCI DSS is meant to serve as a minimum security standard. A company’s security program should meet and exceed the PCI DSS requirements, achieving compliance as a by-product of implementation. But if organizations aren’t meeting the PCI DSS requirements, not only are they not compliant, they’re not secure—providing opportunities for cybercriminals. 

With ten years under its belt, and now three versions, the PCI DSS has had time to mature and evolve to help close gaps posed by new threats. However, the requirements are often purposefully general in their mandates to provide flexibility in implementation. Although this flexibility can be helpful, it means that the requirements sometimes lack specificity. This is another reason why organizations should implement a strong security program regardless of the PCI DSS mandates. However, organizations could also benefit from additional guidance in the PCI DSS.

To help address this need for clarity, the PCI Security Standards Council (PCI SSC) supports two Special Interest Groups (SIG) each year.  The SIG topics cover either a technology challenge or implementation within a specific industry. The outcome of these SIGs is usually a guidelines document and recommended changes or clarifications to the standards.

As a PCI Participating Organization, Venafi is proposing a SIG to address Securing Cryptographic Keys and Digital Certificates. These cryptographic assets are essential to protecting all of our sensitive electronic data:

• Protect data at rest
• Secure data in transit
• Authorize and authenticate servers, devices, software, cloud, and privileged administrators and users

Cryptographic keys and digital certificates are the foundation for securing data, keeping communications safe and private, and establishing trust between communicating parties. They are critical to securing cardholder data—as well as the organization’s business—and are specifically mentioned throughout the PCI DSS. However, the PCI DSS lacks clarity and breadth on the security needed. 

What’s more, new requirements were just introduced in PCI DSS v3 that increase the demands to secure keys and certificates, such as protecting these assets against malware, providing inventory capabilities, and offering certificate-based authentication. Protection against malware is of particular importance because changes in the threat landscape have increased the attacks that target cryptographic assets to enable trust-based attacks.  

There has been a dramatic increase in the criticality of vulnerabilities and threats that impact keys and certificates, including Heartbleed,  the Mask APT operation, and Operation Windigo—just to name a few. And in the McAfee Labs Threat Report for the fourth quarter of 2013, McAfee reveals that malware signed with legitimate certificates rose by 52% quarter over quarter and more than tripled from the previous year. The report emphasizes, “… the misuse of legitimate code-signing certificates erodes user trust.” These threats underscore the importance of strong security and remediation capabilities for keys and certificates.

The proposed SIG will provide guidance on how to approach the PCI DSS requirements that address cryptographic keys and digital certificates, offering a guidance document and checklist on security options and how they interrelate to best secure businesses and comply with PCI DSS requirements. This SIG is also needed to propose new security requirements for keys and certificates:  

“New forms of attack are emerging that target data during processing and transmission — partly driven by increasing security measures put in place to protect data at rest. The PCI DSS does not currently require organizations to encrypt data being transmitted within the [cardholder data environment]. We believe that unless this is addressed, it could become a significant threat to [cardholder data].” Verizon report.

At Venafi, we know that it is already a significant threat and want to help businesses and cardholders stay secure—this is driving our SIG proposal for Securing Cryptographic Keys and Digital Certificates. Want to join our SIG efforts? The 2015 PCI DSS SIG proposal period is now open, with a deadline of July 7, 2015, so we will be submitting our SIG proposal shortly. If selected for the shortlist of proposals, our SIG topic will be voted on during the PCI Community Meetings in September and October 2014.

We would love your support. Contact me on LinkedIn if you’d like to participate in or endorse our SIG proposal efforts.

P.F. Chang customers probably felt like they were taking a step back in time when cashiers ran their credit cards through ancient systems and handed them back carbon copy receipts to sign. But if the customers then asked why the cashier wasn’t using the normal point of sale system, they would have been disturbed by the revelation of an all too modern problem: P.F. Chang had experienced a security breach, as the company announced publicly on June 10, 2014.

Unfortunately in today’s world, breaches occur more frequently than one would expect, but for companies with “Big Brand Recognition” breaches like these generate a lot of media attention. As the compromised company races to determine how many locations have been impacted and verify if data was actually stolen or altered in some way, the company’s reputation can be damaged for years to come, significantly reducing its sales and market share.

Not surprisingly, hackers have been targeting retailers because the payoff—the ability to obtain thousands or millions of valid credit card numbers—is huge. The security breach at P.F. Chang’s is yet another example of how any retailer—large, medium, or small—is at risk.

As I am writing this blog, P.F. Chang’s is still in the investigation stage; the company’s security experts haven’t yet disclosed exactly how hackers bypassed its security defenses. Other retailers that have been compromised in the last year (such as Neiman Marcus, Target, and Michaels) reported that malware was injected into their point of sale systems—systems that they might rely on partners to manage and protect. Although there appears to be some commonality in the attacks on these retailers, any part of a retailer’s onsite or online systems is at risk. Encryption alone cannot protect the transactions; the keys and certificates that enable encryption are often targeted for attack themselves.

One key defense strategy against such security breaches is having a Computer Security Incident Response Team (CSIRT). This team of security experts takes responsibility for responding to cybersecurity incidents within the organization. The team must be quick, agile, and knowledgeable about any security issue. Further, the team must define roles and responsibilities, document processes, and facilitate communication and collaboration across the entire organization and its partners. During a security issue, the team becomes command and control, actually coordinating through matrix business teams, to determine the company’s needed actions and response. Because a CSIRT team partners across the company, they are able to leverage the expertise of the cross-functional members to ensure they understand impact to the business, legal issues, as well as ensure they have a good communication strategy. This will allow the team members to create actionable plans that mitigate the company’s risk factors.

Tabletop exercises of security breaches and attacks are a critical part of any defense strategy. I was very lucky that in my past roles as CISO, I had amazing CSIRT teams with great employees (yes—I am throwing in a shout out here for all of my awesome employees!) We regularly held tabletop exercises which addressed credit card information theft or other potential emergencies that could impact the company. Some were small activities and some also included the executive leadership team up to the CEO. When these activities were completed, we would conduct a post mortem to determine what did and didn’t go well, until we were confident that everyone—including all the company’s partners—knew who to contact in the case of a threat, how to clean up any damage, and how to recover quickly.

A great scenario to add to your CSIRT tabletop planning should focus on a neglected security issue: an attack against a trusted key or certificate. Your CSIRT should know how to protect these assets and how to respond to compromises. Unfortunately, since joining Venafi, I’ve found that many people don’t know how many keys and certificates they have or where these assets are deployed. To avoid chaos when an attack occurs, companies and their partners must have an inventory of all—and I mean all—certificates and keys. The foundation of security is to know what you are protecting—therefore you must have an inventory of all hardware, software, and identities (and their corresponding user IDs, keys, and certificates).

Over the last few months, as I partner with CIOs and CISOs globally, Venafi is helping companies find insecurities in their companies’ public-facing SSL landscape. For example, when companies use wildcards, MD5, and self-signed certificates, they provide openings for hackers. Venafi solutions, which help your security teams easily pinpoint problems like these and quickly resolve them, fill in a critical gap in many security teams’ threat management plans.

Cheers!

Tammy Moskites, Venafi CIO & CISO

It’s another exciting day at Venafi and another great product release! I am thrilled to announce the release and availability of Venafi Trust Protection Platform version 14.2. This release represents our ongoing commitment and priority to prevent our customers from being vulnerable to key and certificate threats. In this latest release, we focus on improving certificate threat visibility, anomaly detection, and vulnerability remediation.

In order for organizations to detect key and certificate anomalies and vulnerabilities, they must first have a clear and in depth visibility across their entire environment. And with the increasing attacks on keys and certificates, organizations must be able to proactively detect and continuously monitor anomalies and vulnerabilities as new threats and breaches occur.

In this release, we supercharged our Certificate Dashboard to aid in the detection and continuous monitoring of certificate anomalies. The newly enhanced Certificate Dashboard gives organizations a comprehensive, real-time view of their entire SSL certificate inventory, so they can quickly detect critical SSL security vulnerabilities and anomalies.

Certificate Vulnerability Trending

Certificate trending graphs gives a view of all of the critical certificate statistics over time, so security teams can proactively identify imminent risk patterns, discover any weak links, and respond faster to attacks on certificates.

With the Certificate Trending graphs, security analysts can identify if and when vulnerabilities are increasing and the progress in addressing those vulnerabilities. You can select different trending graphs from key lengths, signing algorithms, key algorithms, validity periods, and certificate types.

In addition, monitoring critical certificate statistics allows organizations to track their remediation and security improvements over time and show they are improving their security posture. As an example, if there’s a sudden spike in MD5 certificates from a group who inadvertently deployed MD5 certificates with a new application, administrators can quickly identify this vulnerability, establish a remediation plan, and track the replacement of the vulnerable certificates until it is fully addressed.

Critical Certificate Alerts

The “Critical Alerts” section quickly highlights and identifies these critical certificate vulnerabilities:

• Weak key lengths of 1024-bits or less
• Weak signing algorithms such as SHA1 and MD5
• Validity periods of greater than two years
• Certificates expiring within 15 days
• Wildcard certificates

This is useful, for instance, when a security analyst sees a critical alert that must be addressed. They can immediately get detailed information about the vulnerable certificates and take action.

90-day Expiration View

The Certificate Dashboard provides the ability to graphically view certificate expirations and zoom in and out on any particular timeframe to get a list of certificates.

Splunk Integration—Certificate Vulnerability

Venafi TrustAuthority can automatically feed critical certificate alerts and trends to other security systems and analytics such as SIEM vendor, Splunk.

These are just some of the highlights of the version 14.2 release. For more details on the release, please contact your local Venafi account representative.

We will continue to help our customers identify and fix their key and certificate vulnerabilities, detect new threats and breaches in real-time, and ensure that when breaches do happen that they have the power to respond and take action. Venafi Trust Protection Platform 14.2 is available now.

Situation

On 8 July 2014 Google reported it had discovered certificates issued without authorization for the multiple Google-owned domains from the National Informatics Centre (NIC) Certificate Authority (CA). NICCA CA certificates are Intermediate CA certificates issued by the Indian Controller of Certifying Authorities (ICCA). NICCA CA certificates, and as a result NICCA, are trusted in Microsoft Windows and other applications, which makes this is a serious security issue for all enterprises worldwide. There are some reports that other malicious certificates were issued to fraudulently represent Yahoo and other organization. It is not clear whether this malicious action was due to fraud, breach, or complicity from the Indian authorities.

Threat

No information is available on the actors who requested or maliciously issued these certificates but their intent should be assumed to be malicious. Certificates issued for a domain would allow for spoofing of websites, encrypted communications to be disclosed, and information to be tampered with. With information obtained from the attack, attackers may proceed to steal more data or elevate privileges from credentials gained through operations. Any communication with Google, including Gmail, Google Drive, and other applications, could be compromised for all organizations and individuals worldwide, not just those operating in India. And it appears that other web services that businesses and governments communicate with, including Yahoo, have also been targeted with malicious certificate issuance.

Impact

ICCA, and as a result, NICCA-issued certificates, are trusted by Microsoft Certificate Store, including Internet Explorer and Google Chrome. NICCA CAs may be trusted in other enterprise applications. Therefore, the certificates issued for Google domains (and likely others including at least Yahoo) would be trusted allowing for websites to be spoofed, sensitive information captured, and all traffic decrypted. 

Recommended Remediation

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

1. Detect NICCA certificates with Venafi TrustAuthority:
   • Scan for any certificates on their network issued by NICCA
   • Evaluate if NICCA CA certificates are trusted by enterprise applications
   • Report and escalate any NICCA CA certificates and issued certificates
2. Remediate with Venafi TrustForce
   • Remove all NICCA CA certificates using certificate whitelisting
3. Review CA Compromise Plan
   • NIST Preparing for and Responding to Certification Authority Compromise and Fraudulent Certificate Issuance, co-developed with Venafi, is a good resource for security teams to help build their programs

Please contact Venafi support with any questions or help with remediation.

Additional Resources

• Google Alert: Maintaining digital certificate security
• Indian Controller of Certifying Authorities (ICCA)
• NIST: Preparing for and Responding to Certification Authority Compromise and Fraudulent Certificate Issuance

PART I

Is Compliance Really Just Complacence?

You’ve built a thriving business, earned a powerful brand in the marketplace, and deliver goods and services around the globe with world-class speed and efficiency. As a Global 2000 leader, you naturally have the best interests of your employees and your customers at heart, have painstakingly earned their trust, and would never willfully do anything to put them at risk. You’re confident that you provide a secure and trusted online presence, employ rigorous information security safeguards, and do everything necessary to protect the valuable data in your charge. You’ve invested heavily in people, processes, and technology, and truly believe that you’re doing all the right things. Don’t look now, but you might be deluding yourself.

Since industry-specific data security and privacy regulations now apply to most sectors of the economy in the United States, you probably find yourself falling under one or more of the following regulatory categories:

• Financial Services—Sarbanes-Oxley Act (SOX), Gramm-Leach-Bliley Act (GLB)
• Healthcare—Health Insurance Portability and Accountability Act (HIPAA)
• Retail—Payment Card Industry Data Security Standard (PCI DSS)
• Government Contractors—Federal Information Security Management Act (FISMA)
• Industrial Control and SCADA Systems—National Institute of Standards and Technology (NIST)

You take your compliance obligations seriously and devote great amounts of time and energy to ensure that your business meets all applicable legal and regulatory requirements. Despite best efforts and intentions, disturbing questions still gnaw at you. You ask yourself, “Does compliance standing alone truly make things sufficiently secure and keep sensitive data away from theft or exploitation?” Then you wonder, “How much more should I be doing?” Well, what if I told you that by focusing on compliance you’re really only doing the minimum necessary to keep the government regulators off your back and that compliance bears but a slim relationship to true data security?

Commitment to Strong Security Practices or Just Toeing the Line?

You passed an audit—hooray! But don’t pop the champagne corks quite yet. Just because you, or your auditors, certify that your business has met narrowly-defined, industry-specific information systems management requirements for the applicable reporting period doesn’t necessarily mean that all of your enterprise data or internal systems are safe from attack by outside interests or misuse from inside sources. How can this be? Don’t government regulations exist to ensure our safety? If only it were this simple. In reality, it all comes down to the ways in which rules are made, namely through legislation and through regulations.

Legislative processes in a democracy are messy, slow, and fraught with political compromise, often resulting in watered-down laws designed to obtain just enough votes to pass the chamber. Even good, noncontroversial bills are routinely held up, delayed, or filibustered for months—or entire congressional sessions—by legislators seeking publicity or near-term political gain. Lawmakers frequently trade their support for one bill in exchange for another legislator’s vote on a different matter in an age-old congressional process known as “logrolling.” Finally, obscure or unpopular legislative “riders” with slim prospects of passing on their own merits are frequently attached to popular or “must pass” bills covering completely different legal subjects, leading to the passage of convoluted Frankenlaws consisting of multiple unrelated parts.

Regulatory processes are no better. Under authority granted to them by Congress in broad, general terms, the responsible agency typically conducts a months-long study, promulgates new proposed regulations based on the study findings, and then opens an often-lengthy public comment period. After reviewing the initial comments, the agency then revises the regulations, waits again for public comments, and then ultimately publishes the final version of the requirements in the Federal Register—regulations which take effect at a future date, often the following January 1 or July 1. Businesses need time to absorb and adapt to these new regulations, and then a year later, an audit tells them whether or not they have successfully interpreted the changes.

Wow! All through this extended time period, technology steadily advances and human ingenuity methodically progresses, including the actions of threat actors on a worldwide stage. New data security and privacy perils steadily emerge, while existing dangers morph or retreat across the ever-changing threatscape. Legislation and regulation are also highly mutable over time, as they are subject to shifting political trade winds. As a result, they can change course or even reverse themselves as presidential administrations come and go. Ultimately, legislation and regulations often significantly lag behind, and poorly reflect, the actual threats they are intended to address.

Protecting the Enterprise against Trust-Based Attacks

To truly protect your critical data and server infrastructure, you must look beyond parochial compliance requirements and take a broader view of your overall information security practices, specifically in relation to protecting information assets against trust-based attacks. First, conduct a full and complete inventory of all encryption keys and digital certificates, plus all authentication keys used within the enterprise. Use the strongest mainstream cryptography possible to secure these digital assets and then enforce robust security policies across your enterprise without exception. Understand trust relationships between users, keys, and the systems and servers they properly access. Replace weak signing algorithms and short key lengths, use trustworthy certificate authorities, and shorten key and certificate validity periods to one year. Monitor authentication and encryption usage patterns and alert when anomalies are detected. Finally, ensure that you have the ability to rotate all keys and certificates if a security breach is ever detected or suspected.

No CEO or CISO wants to tell stakeholders that he or she is doing just the minimum required by compliance requirements—and not everything possible—to protect the enterprise and its customers against trust attacks.

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.

Organizations have become reliant on SSH to provide authentication and establish elevated privileges between administrators, applications, and virtual machines in the data center and out to cloud. SSH helps enterprises establish trust. However, there is a darker side to SSH, a dirty little secret that research published by Forrester exposes. Most bad actors understand this secret and continuously take advantage of it. In fact, the problem is becoming worse as organizations become more reliant on SSH to administer workloads in the cloud.

Lax Policy Enforcement

On a daily basis, IT security professionals must balance a myriad of threats and security challenges, all while ensuring the business remains operational. When you take into account the elevated privileges SSH provides, you would assume that enterprises make SSH keys more secure and apply more well-defined, stringent polices than simple usernames and passwords, which provide fewer privileges. But this is not the case. Most organizations have a 30-, 60-, or 90-day password rotation policy. However, Forrester research shows that most organizations have no policies or controls to secure SSH keys. Almost three-quarters (73%) of organizations hardly ever rotate SSH keys. They also rely on system administrators to self-govern their SSH keys. This negligence provides bad actors with near unfettered access to enterprise networks with elevated privileges, sometimes for a span of several years (see an example of a multi-year APT attack).

Increasing Attack on SSH

In the last 24 months, nearly 50% of survey respondents reported that they had to respond to security incidents related to the compromise or misuse of SSH keys. Unfortunately, even with such a high frequency in security incidents, information security professionals don’t seem to be taking the issue seriously. Only 9% of organizations scan for unauthorized SSH activity every 12 hours. The remaining survey respondents either do not scan at all or at a frequency that ranges from greater than every 12 hours to every month. When compared to vulnerability scanning or AV scanning, you would never consider 12 hours to be sufficient.

Closing the Gaps in SSH Security

When considering the importance of SSH and the fact that they provide the ‘keys to the kingdom’—your enterprise network—the security of SSH keys should be a high priority. Forrester research recommends the following minimum steps be taken to close the SSH security gaps:

1. Ensure there is centralized visibility and control over SSH keys. Reliance on disparate administrative controls is proven to be ineffective.
2. Ensure there is centralized policy enforcement. Policy enforcement helps reduce the number of mistakes made when configuring SSH.
3. Ensure there is a clear understanding of baseline usage. Without an understanding of how SSH keys are used and by whom, it is near impossible to detect any security incident related to SSH compromise.
4. Ensure there is continuous monitoring of the network to identify any anomalous SSH usage. With a clear baseline of SSH usage and continuous monitoring you can dramatically reduce your organizations threat surface.
5. Ensure remediation of identified SSH vulnerabilities is acted upon swiftly. An SSH compromise provides bad actors with elevated privileges to the enterprise network.

To learn more about the Forrester research, Gaps in SSH Security Create an Open Door for Attackers, visit Venafi.com.

Trust is arguably the most important component of any functioning society on the planet. Since nearly all who will read this blog are information security professionals, you likely know that Bruce Schneier even wrote an insightful book about it. Without trust, we feel at risk, exposed, and uncertain, ultimately rendering all others in the society with whom we interact in a doubtful state of volatility.

In the physical world, every hour of every day we perform what we view as pedestrian activities, which in reality, involve untold levels of trust to function as designed. Every day activities, like driving in a car, flying on an airplane, depositing money in the bank, eating out at a restaurant, and even drinking and using the water that comes out of the faucets in our homes, involve inordinate amounts of trust to remain, well, delightfully commonplace.

So what if I told you the trust you know and love was beginning to slowly disintegrate before your very eyes? Wouldn’t you want to do something about it to save it? Of course you would, and that’s why you should read on.

Since the dawn of the digital age, our trust in commonplace activities has evolved to include everything we do online.  You trust that when you open a web browser, type in the domain name of your bank, log in to your account, and transmit data with that financial institution online that you are communicating privately and securely.  In reality, you’re trusting all the load balancers, servers, devices, and machine-to-machine communication that occurs in nanoseconds, with each click of the mouse at your desk or push of the icon on your tablet or phone.

With more and more of society’s activities occuring online, and growing faster than ever with the burgeoning “Internet of Things,” we rely more and more upon the authenticity and validation of each component making up the underpinning of the digital universe’s infrastructure.  Each Global 2000 enterprise owns or leases their respective online real estate within the greater digital universe, and if they care about their business, they are responsible for the security, authenticity, and privacy of the data stored upon it or passing through it.  In other words, to make any corporation’s real estate a place where people and other corporations want to do business, at its foundation, it must ultimately be trustworthy.

In an effort to keep our online real estate as trustworthy as possible and secure the company against those that aren’t trustworthy, Global 2000 enterprises employ large security organizations. These teams of security experts in turn adopt and apply security strategies made up of security solutions. All of these solutions fundamentally afford the enterprise visibility to see various threat events and the ability to remediate these threat events. We use security frameworks, industry best practices, and security audits to understand what parts of our security strategy need corrective investment, have exposures to close, and have audit findings to be addressed.

But at a more granular level, how do Global 2000 enterprises ensure each and every infrastructure component within their online real estate is secure and authentic, so the data stored upon each component (or passing through) will be kept private and secure?  Until the world invents a new mechanism, we all use encryption keys and digital certificates.  Each component of an enterprise’s online real estate relies upon encryption keys and digital certificates to confidentally authenticate each component and to keep the associated data private and safe from exposure.

In addition to risk of deprication without innovation, it is these enterprise keys and certificates which are being misused, abused, and targeted more and more by bad actors, including well-organized cybercriminal and espionage groups, as well as malicious or otherwise compromised insiders. Encryption keys and digital certificates are THE foundation of trust online, and it’s this trust that is under attack.

If we continue to allow this corrosion of online trust, our activities online are more and more at risk, exposed, and uncertain. We ultimately reach the same doubtful state of volatility that we reach in the physical world when trust becomes compromised. We must have the visibility into events that threaten encryption keys and digital certificates, just like we have visibility into our networks, user IDs and passwords, privlidged user accounts, and other digital components in which we demand visibility as part of our core security strategy. We must have the ability to respond and remediate threats and weaknesses associated with encryption keys and certificates.

Without having full visibility, control, and remediation capabilities with keys and certificates, our security strategies have serious blind spots (and Gartner agrees). And even more vexing, the way in which we measure our success using security frameworks, industry best practices, and security audits may become completely undermined if we don’t account for threats using keys and certificates to conceal themselves, or threats which target weaker, vulnerable ones. This is exactly what SANS realized, when they recently added numerous control measures to Critical Security Control #17 (Data Protection).

And this is what we do at Venafi. We eliminate the snowballing blind spot that typically exists with enterprises’ encryption keys and digital certificates and enable enterprises to give their trusted online real estate the security and protection it deserves.  We provide a proven technology platform which empowers enterprises to achieve comprehensive visibility into all encryption keys and digital certificates. We also provide the ability to respond and remediate against insider and outsider threats misusing, abusing, or targeting weak encryption keys and digital certificates. Venafi exists to defend and champion trust in the digital age. Given the ominous consequences of trust becoming compromised in your online real estate, and thus trust in your brand becoming compromised, nothing is more important. Nothing is of a higher priority than trust. This is why we named our solution the Venafi Trust Protection Platform. This is what we mean by Securing Trust by Protecting Keys and Certificates.