<![CDATA[Venafi Blog]]> http://www.venafi.com/blog/ Venafi Blog EN Copyright 2014 2014-04-24T21:41:59-06:00 <![CDATA[Responding to New SSL Cybersecurity Threats — Gartner Featured Research]]> http://www.venafi.com/blog/post/responding-to-new-ssl-cybersecurity-threats-gartner-featured-research http://www.venafi.com/blog/post/responding-to-new-ssl-cybersecurity-threats-gartner-featured-research/#When:22:49:00Z 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.

<![CDATA[Don’t Be Blinded by the Next Heartbleed]]> http://www.venafi.com/blog/post/dont-be-blinded-by-the-next-heartbleed http://www.venafi.com/blog/post/dont-be-blinded-by-the-next-heartbleed/#When:15:00:00Z 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!


Tammy Moskites, Venafi CISO

<![CDATA[Remediating Heartbleed with Next-Generation Trust Protection]]> http://www.venafi.com/blog/post/remediating-heartbleed-with-next-generation-trust-protection http://www.venafi.com/blog/post/remediating-heartbleed-with-next-generation-trust-protection/#When:18:48:00Z 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.

Venafi Search

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.

Venafi search results

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.

Venafi prive key edit

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.

Select work type

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.

<![CDATA[The World is Failing to Remediate the Heartbleed Vulnerability]]> http://www.venafi.com/blog/post/the-world-is-failing-to-remediate-the-heartbleed-vulnerability http://www.venafi.com/blog/post/the-world-is-failing-to-remediate-the-heartbleed-vulnerability/#When:03:43:00Z 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.

<![CDATA[Heartbleed Remediation: Replace ALL Keys and Certificates]]> http://www.venafi.com/blog/post/heartbleed-remediation-replace-all-keys-and-certificates http://www.venafi.com/blog/post/heartbleed-remediation-replace-all-keys-and-certificates/#When:20:03:00Z 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:

<![CDATA[Mad Max Here We Come: Heartbleed shows how much we blindly trust keys and certificates]]> http://www.venafi.com/blog/post/mad-max-here-we-come-heartbleed-shows-how-much-we-blindly-trust-keys-and-certificates http://www.venafi.com/blog/post/mad-max-here-we-come-heartbleed-shows-how-much-we-blindly-trust-keys-and-certificates/#When:20:57:00Z 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:

<![CDATA[FTC recognizes value of trust established by SSL and digital certificates]]> http://www.venafi.com/blog/post/ftc-recognizes-value-of-trust-established-by-ssl-and-digital-certificates http://www.venafi.com/blog/post/ftc-recognizes-value-of-trust-established-by-ssl-and-digital-certificates/#When:22:06:00Z Attacks on digital certificates and trusted connections drive FTC to action

Recognizing that the trust established by Secure Sockets Layer (SSL) and digital certificates plays an important role in everyday life, the US Federal Trade Commission (FTC) brought charges against Fandango and Credit Karma for failing to protect this trust. Both companies failed to validate digital certificates used for SSL/Transport Layer Security (TLS) connections in their mobile applications. The FTC acknowledged that these failures allow attackers to circumvent the trust established by digital certificates and gain access to users’ confidential personal and financial information. Once this trust is compromised, attackers can redirect traffic to an untrusted site, and the users’ applications cannot detect that traffic has been diverted. Ironically, digital certificates and SSL/TLS secure connections are designed to thwart these Man-in-the-Middle (MiTM) attacks.

The FTC illustrates how a comprised or fake digital certificate can be used for MiTM attacks against unsuspecting users.

The importance of the settlement is not that businesses must deal with another compliance requirement. Instead, the FTC is reinforcing the fact that securing the trust established by digital certificates is critical. The FTC’s action underscores what others have already found:

  • Microsoft concluded that “PKI is under attack.”
  • In its 2013 fourth quarter threat report, McAfee reported that malware that misuses digital certificates increased 52% over the third quarter.

Protecting trust is so important that no business or government can ignore it. A single compromised certificate or application that fails to validate certificates can make all the other security controls useless.

A fake certificate purporting to be for GoDaddy’s email service could allow an attacker to masquerade as GoDaddy if applications don’t check if a certificate is trusted.

Attacks on mobile applications that fail to validate digital certificates are nothing new. In an article published earlier this year, Netcraft reported that it had found dozens of fake digital certificates deployed across the Internet. Unlike many attacks using compromised digital certificates, the fake certificates that Netcraft found probably targeted users of mobile applications—40% of which, like Fandango’s and Mobile Karma’s applications, failed to validate the trust established by legitimate digital certificates. While the FTC has started its action with Fandango and Credit Karma, significantly wider holes in SSL and digital certificate security have been reported. In February 2014, for example, Apple patched Mac OS X and iOS because both failed to validate digital certificates for SSL/TLS—an issue that could have been exploited by MiTM attacks.

With Gartner predicting that 50% of network attacks will use SSL by 2017, enterprises must protect the trust established by digital certificates. The FTC provides some basic recommendations that all mobile developers should follow. In addition, developers should evaluate security, including the validation of digital certificates, with the help of a third party. Beyond this, organizations must secure and protect the keys and certificates that establish trust for mobile applications, web browsers, and the thousands of applications behind the firewall. Although every organization depends on these applications, they create a huge surface area of attack.

In response to the rise in attacks on keys and certificates, Forrester recommends that organizations:

  • Gain visibility into threats. Only about half (52%) of organizations know how many keys and certificates are in use, how those keys and certificates are used, and who is responsible for them. You can’t control what you don’t know you have.
  • Enforce policy to establish norms and detect anomalies. Once an organization has gained visibility into its key and certificate inventory, it can begin to enforce policies and establish a norm. This makes detecting anomalies easier, whether they’re accidental policy violations by a well-intentioned developer or a malicious attack.
  • Automate key and certificate functions to gain control and reduce risk. A typical large enterprise has thousands of keys and certificates to secure and protect. Work smarter, not harder, by automating security for processes such as key generation, certificate requests, monitoring for changes and anomalies, and other related tasks. This automation not only streamlines and centralizes these tasks, but also helps to establish the necessary controls to reduce risk, shrink the threat surface of attacks, and help the organization respond to attacks faster. Automation and control are part of establishing a norm that can be monitored for possible anomalies and attacks.
  • Analyze data to gain intelligence. Analysis of data gained from securing keys and certificates will provide a wealth of information and insight that can help to identify opportunities to reduce risk. By looking at the data generated, organizations can spot patterns of potentially suspicious activity or anomalies that require further investigation. Reports may also help identify keys and certificates that may be problematic, such as those that are about to expire or are no longer needed.

In line with these recommendations from Forrester, Venafi TrustAuthority enables organizations to quickly gain visibility, fix vulnerabilities, and establish policies for keys and certificates. Venafi TrustForce automates key and certificate functions to further eliminate the opportunity for compromise and enable organizations to enforce policies and remediate security incidents. IT security teams must start by gaining visibility into how keys and certificates are used, fixing vulnerable certificates, and enforcing policies to protect the trust upon which their business depends—from their mobile applications back to the data center.

<![CDATA[Why Should You Update Your Trusted CAs and Enforce Certificate Whitelists?]]> http://www.venafi.com/blog/post/why-should-you-update-your-trusted-cas-and-enforce-certificate-whitelists http://www.venafi.com/blog/post/why-should-you-update-your-trusted-cas-and-enforce-certificate-whitelists/#When:20:30:00Z Your organization’s policies—or lack of policies—regarding trusted root CA certificates are exposing you to unnecessary risk. Because certificates serve as credentials for so many mission-critical transactions, attackers are constantly trying to obtain trusted certificates that can be used in targeted attacks. Systems, for their part, refer to their store of trusted root certificates to determine which certificates to trust. If a certificate is signed by a trusted CA, the system trusts the certificate. To compromise a system, therefore, an attacker simply needs to obtain a certificate that is signed by a trusted root CA—whether by tricking the CA into issuing a fraudulent certificate or by compromising the CA. Every CA that your systems trust represents a potential entry point for attackers.

Many organizations expose themselves to unnecessary risk by allowing far too many of these entry points. They retain the default trust stores distributed with most operating systems and application servers, which include far more certificates than are necessary. According to a University Hannover Germany study, common trust stores for various platforms and operating systems—such as Windows, Linux, MacOS, Firefox, iOS and Android—contained more than 400 trusted root certificates. However, only 66% of these certificates were used to sign HTTPS certificates, leaving the other 34% of trusted root certificates susceptible to use in certificate-based attacks.

We are seeing more and more evidence of malware signed with a legitimate CA because an attacker stole a private key or obtained a fake certificate. Consider the following scenario: Your organization is currently trusting AcmeCA on many of your systems simply because AcmeCA is approved by the vendor providing the software for your systems. If a malicious attacker gains access to a fraudulent certificate from AcmeCA, that attacker can use it to attack multiple systems within your organization.

Your organization has outward-facing systems, such as those focused on customer interaction or users’ desktops, that must trust a particular CA in order to perform day-to-day business. However, your organization also includes systems that don’t need to trust a particular CA but are, in fact, trusting it. For example, internal systems that communicate only with other internal systems don’t need to trust any CAs but the internal CA(s). In addition, partner-focused systems that communicate with a limited number of partners require just a handful of CAs.

Most organizations have no visibility into which root certificates they are trusting and where those root certificates are deployed; consequently, they cannot limit their exposure to certificate-based attacks. As a critical first step, organizations must gain visibility into which root certificates are being trusted within their environment. They must compile an inventory of their root certificates so they can reduce the risks caused by unnecessary trust. In the AcmeCA scenario, for example, you would see that AcmeCA is installed on multiple systems within your organization, determine that these systems don’t need to trust AcmeCA, and remove it. Thus, an attacker would be unable to use a fraudulent certificate from AcmeCA to successfully attack your organization.

By identifying CAs that should not be trusted on mission-critical systems, organizations have the intelligence and risk awareness to prevent attacks that leverage certificates from those CAs. One way to take action is through certificate whitelisting, which ensures that whitelisted certificates are included in trust stores and blacklisted certificates are excluded from trust stores. Certificate whitelisting limits the number of CAs that are trusted, allowing organizations to secure and protect the CAs they trust while flagging or disallowing untrusted SSL/TLS sessions. As a result, the attack surface is dramatically reduced.

Organizations can eliminate unnecessary risk from digital certificates signed by untrusted CAs by establishing and enforcing certificate whitelists and updating which CAs are trusted within the enterprise. They can enforce baseline requirements for which CAs should be trusted (whitelist) and not trusted (blacklist) on mission-critical systems and ensure whitelisted certificates are included in trust stores and blacklisted certificates are excluded, preventing attacks that leverage certificates from blacklisted CAs.

<![CDATA[Windigo: Another Multi-Year APT Targets SSH Credentials]]> http://www.venafi.com/blog/post/windigo-another-multi-year-apt-targets-ssh-credentials http://www.venafi.com/blog/post/windigo-another-multi-year-apt-targets-ssh-credentials/#When:12:00:00Z Last month, ESET, a leading IT security company, published a detailed analysis of operation Windigo. This operation, active since 2011, has compromised over 25,000 Linux and Unix webservers. Cyber-criminals use these servers to steal SSH credentials, redirect visitors to malicious websites, and send millions of spam messages per day. The ESET report provides information on several components of Windigo, including Linux/Ebury, an OpenSSH backdoor used to steal payloads, SSH passwords, SSH keys, private keys, private key passphrases, and other credentials.

I found it very intriguing that the report indicated that Windigo does not exploit any cryptographic or system vulnerabilities. Instead, this operation leverages only stolen credentials—highlighting the rapidly increasing prevalence of trust-based attacks.

At the heart of operation Windigo’s success is the SSH credential-stealing Linux/Ebury backdoor. Without the SSH credentials, Windigo is not able to expand and compromise additional systems. Once malicious actors have obtained the SSH credentials and installed Linux/Ebury on systems, they can continue to collect new or modified credentials on infected systems. As they do with SSH daemon backdoors, cyber-criminals exploit the blind trust in encryption to own the compromised systems, maintaining access even if the credentials are later changed.

Stolen SSH credentials that do not provide root-level access do not go to waste; they are used as part of spam bot operations or to log into other servers. ESET monitored data sent to exfiltration servers over a period of five days. During that time, ESET captured 5,362 unique successful logins. The figure below shows the number of logins that used root credentials as compared to other forms of access.

Although the Windigo botnet is smaller than most end-user botnets, it’s important to note that Windigo-compromised systems are all webservers with a magnified ability to direct users to malicious sites hosting malware. In fact, Windigo is redirecting over 500’000 web visitors to malicious content every day. By using keys, adversaries have the privileges and trusted status required to turn legitimate systems into a malicious infrastructure that dwarfs even some cloud computing vendors.

Infected systems that are part of the operation Windigo botnet are extremely difficult to detect, in no small part because adversaries have the elevated privileges required to install any binaries they choose. They then conceal these highly sophisticated binaries with advanced cryptography. "System administrators attempting to clean systems that are part of the Windigo operation are usually able to remove other malware components such as Linux/Cdorked, but often overlook the OpenSSH backdoor due to the stealth mechanisms used.” With the backdoor still open, the Windigo operators can return at a later date and revert the changes made by system administrators.

For this reason, the ESET paper advises administrators to “completely wipe their [infected] servers and rebuild them from scratch using a verified source.” Administrators should also assume that all administrator credentials on a compromised system have also been compromised. Like Mask malware, used to steal cryptographic keys and digital certificates, operation Windigo demonstrates the increasing numbers of advanced and persistent adversaries targeting keys and credentials. Last week the latest set of released Snowden documents, titled "I Hunt Sys Admins,” further revealed how malicious attackers and nation states target the SSH credentials of system admins for theft. This unsurprising information still highlights most organizations’ lack of visibility and control over their keys and certificates.

It’s no surprise that adversaries are increasingly using keys and certificates in their nefarious campaigns. Too many organizations employ a lackluster approach to protecting their SSH keys, recklessly exposing themselves to eager cyber-criminals. In addition, most organizations have little visibility into their cryptographic assets—the very assets that criminals are exploiting—making it hard for administrators to understand the scope of the problem or to detect anomalous usages.

In research conducted by Venafi, 74% of organizations have inadequate SSH security policies. This statistic alone is an enticing invitation for any attacker. Why not target an organization with no security controls or ability to respond? Based on revelations in just the first three months of this year (including the release of more Snowden documents and revelations about Mask and Windigo), I’d suggest that we are seeing only the first crest of a threatening tsunami of attacks on SSH. It’s time organizations understand what trust-based attacks are and how to protect against them.

<![CDATA[I Hunt Sys Admins’ SSH]]> http://www.venafi.com/blog/post/i-hunt-sys-admins-ssh http://www.venafi.com/blog/post/i-hunt-sys-admins-ssh/#When:16:29:00Z SSH keys again confirmed as a favorite target for advanced attackers - how will IT security fight back?

Newly leaked NSA documents from Edward Snowden, entitled “I Hunt Sys Admins” show that sophisticated attackers are aiming to breach targets by taking aim on system administrators. Threatpost aptly described this strategy as the “biggest no-brainer.” A core part of this playbook is targeting SSH and the keys used to gain authenticated privileged access.

We must assume that based on previous attacks that adversaries of all types also are targeting system administrators and have the same or even more effective techniques. These sophisticated adversaries include nation states seeking to exploit intellectual property for economic benefit and organized cybercriminals motivated for profit.

The targeting of SSH comes as no surprise given The Mask APT operators and others hunger for SSH keys to infiltrate networks, gain administrator level access, and keep it for a very, very long time.

Part 4 of the leaked documents - “I hunt admins that use SSH” – demonstrates attackers understand the opportunity SSH provides and value for Computer Network Exploitation (CNE) - also known as owning your network, data, and business. As previous Venafi research identified, an attacker with SSH is able to gain administrator-level access that travels over encrypted sessions and in most organizations will never expire. With 1 in 2 organizations never changing SSH keys, attackers fly under the radar and remain in a breached state, forever. And in recent conversations I’ve had with some of the world’s most sophisticated IT security teams, incident response teams indicated they don’t change SSH keys during remediation – perpetuating the insanity!

If organizations can take just a few steps, they’ll have taken giant leaps in defending their enterprises from the assault on SSH and system administrators:

  1. Place IT security in charge of securing SSH: This has nothing to with technology. Systems administrators are not security experts but yet they are self-policing SSH keys that provide access to critical systems. IT security is best equipped to understand threats and security controls necessary to protect systems.
  2. Survey all keys, map key owners and access, and continuously monitor: No enterprise today knows who is responsible for all SSH keys and which servers, VMs, and cloud services these keys provide access to. Searching networks, servers, and endpoints to find all keys and map these to trusted key lists is no longer optional.
  3. Enforce key rotation policies: Probably the biggest step forward is treating SSH keys like IT security has secured other critical systems. Replacing SSH keys at regular intervals (e.g. every 30 days like your Windows password) helps to limit the exposure of a possible breach. Attackers will need to keep stealing keys, increasing the likelihood of detection, to maintain access to your network and systems.
  4. Detect anomalies, respond fast: In addition to stealing keys, attackers are known to insert their own keys as trusted. These anomalies can be detected and instantly remediated if the current trusted state of keys is known and understood. As well, incident response teams must replace SSH and SSL keys whenever they perform remediation on systems even if the compromise of a key is not suspected.

Taking these steps will go a long way to defending against attackers that hunt system administrators. Venafi is already helping the world’s most targeted enterprises secure their SSH keys with Venafi TrustAuthority to gain visibility and Venafi TrustForce to enforce policy, detect anomalies, and respond immediately. This powerful security is part of the Venafi Trust Protection Platform that secures not only SSH keys but also SSL keys and certificates along with mobile certificates.

And one more thing: if system administrators and their SSH keys are targets, it is not a giant leap to assume that SSL keys and certificates are also being targeted and compromised by the same adversaries. This would allow attackers to monitor encrypted SSL communications, surveil their targets, and impersonate trusted web services to collect data and further expand attacks. Defending our enterprises from these assaults means not just protecting SSH keys but also SSL keys and certificates.

Putting these new revelations together with our current understanding means were just another step closer to Gartner’s prediction of “Living in a World Without Trust.” If we don’t secure and protect all of the keys and certificates that establish trust for our enterprises, “I Hunt Sys Admins” shows we’re quickly headed to making this prediction a reality.

<![CDATA[March Madness & The Surge of Attacks on Trust]]> http://www.venafi.com/blog/post/march-madness-the-surge-of-attacks-on-trust http://www.venafi.com/blog/post/march-madness-the-surge-of-attacks-on-trust/#When:16:49:00Z I’m certainly not what you would call an avid NCAA college basketball fan. But each March, the brilliant folks at CBS suck me in with this wonderfully hypnotic theme song for the NCAA Men’s Basketball Championship Tournament, known in the US simply as “March Madness.” I’m not alone. Tens of millions of Americans even plunk down hard-earned cash to join March Madness pools, in which they attempt to best predict the outcome of the tournament. During the 2013 March Madness tournament, American corporate office pools alone represented a mind boggling $US 3 billion in wagers.

Unfortunately, the cyber-security professional part of my brain gets stressed out during this season. Enterprise security professionals brace for waves of March Madness related cyber-attacks because nearly every aspect of any employee’s involvement with March Madness opens up new cyber risks to both that individual and the company. The network bandwidth consumed by non-work-related video streams and the network threats are well documented, but this year the stakes get even higher with the surge in cyber-attacks and advanced persistent threats (APTs) that misuse keys and certificates to gain a trusted status. Let’s walk through typical employees’ March Madness related behaviors, and weigh the risk your enterprise faces over the next three weeks.

The University of Michigan Wolverines aren’t the only ones working hard during the 3 weeks of March Madness

The first risk posed by March Madness actually occurs as employees join pools before the tournament begins. Cyber-attackers know of pools’ popularity and are, as I type, in the midst of sending out artfully crafted spear phishing emails to millions of fans. By abusing trust in certificates, attackers can put themselves between a user and a legitimate pool site, intercepting all transmitted data without the user realizing anything is wrong. Many users are trained to look for the “green bar” and for the padlock symbol in the URL field. But attackers can obtain a wildcard SSL certificate, associated with a ficticious company, for their fraudulent March Madness pool website. Now the website not only looks and feels exactly like the real site, it also has that padlock, giving victims a false sense of security. Such cyber-attacks, which abuse SSL, are on the rise. In fact, Gartner estimates that by 2017, 50% of cyber-attacks will leverage SSL.

After employees have joined a pool and filled out a bracket, they need to follow the action. Cyber-criminals are aware that millions of Americans, many of them sitting at their desks at work, will be online and searching for live score updates. Many employees will even try to stream games right to their computers. Attackers oblige these user requests by sending out fraudulent emails offering “free live streaming” of the games. Once a user clicks on a link in these emails, malware, perhaps similar to The Mask, installs itself and begins siphoning off credentials such as user certificates, SSH keys and RDP files for attackers’ future use in infiltrating the user’s corporate network. Once attackers gain entry, they advance their privilege by injecting their own SSH keys and moving to different areas of the network. Finally, they exfiltrate data without raising any alarms, using self-signed certificates to hide the suspicious outbound traffic.

When employees leave the desk, they’ll want to follow the action on a mobile phone or tablet. Numerous mobile apps promise to deliver March Madness game alerts right into the palm of your hand, and among those apps are a fair number of fraudulent ones. As far back as 2010, the US government has actually used a malicious March Madness mobile app as the scenario for drills preparing for a massive cyber-attack against critical infrastructure. Fraudulent apps that are digitally signed by certificates are exceptionally difficult to differentiate from valid apps. In 2013, 27% of all Android mobile malware was signed by fraudulent certificates, and Venafi expects this figure to rise to 100% by the end of 2014. These nefarious apps appear to be valid and trusted, yet they are nothing but advanced mobile malware, designed to steal data, credentials, and certificates (corporate and personal) that reside on the mobile device.

Attacks against keys and certificates present a new way for cyber-attackers to circumvent security controls, access sensitive data, and exfiltrate the stolen data without being noticed. Three months into 2014, these attacks continue to grow at alarming rates, as does the number of pieces of malware signed by SSL certificates, which reached 1.2 million in the last quarter of 2013 alone. Now in the wide-reaching social, sporting phenomenon that is March Madness, cyber attackers see one of the best social engineering opportunities of the year to target millions of Americans at the same time under the same cover story—all while exploiting the fact that attacks misusing keys and certificates are not detected by traditional security controls.

The ability to quickly detect anomalous keys and certificates is vital to minimizing the damage done by these next-generation attacks on trust. The faster you learn about a vulnerability or compromise, the less damage occurs. And the only way to detect anomalies and trust vulnerabilities is to have a solid, ongoing understanding of known good certificates and keys and of valid usages. By implementing a comprehensive program to secure trust by protecting keys and certificates, you can easily gain the clear visibility required to respond to these next-generation attacks on trust. Venafi’s Trust Protection Platform™ gives you the tools for just such a program. To find out how, in only two weeks, you can obtain a next-generation, trust protection platform—fixing critical certificate vulnerabilities, providing ongoing, policy-based monitoring, and rapidly detecting and alerting you to certificate anomalies—contact us here.

<![CDATA[Preventing Your Webservers from Becoming Phishing Sites ]]> http://www.venafi.com/blog/post/preventing-your-webservers-from-becoming-phishing-sites http://www.venafi.com/blog/post/preventing-your-webservers-from-becoming-phishing-sites/#When:19:17:00Z Despite many cyber-security advances over the last 20 years, well-known cyber-criminal exploits like phishing still pose pervasive threats. Phishing scams remain effective because they prey on human behavior. Until technology can better moderate human actions, some of the simplest cyber-criminal techniques—like phishing—will continue to be effective.

The misuse of technology can even contribute to the effectiveness of phishing attacks. In this article, I’ll be focusing on one such technology: wildcard certificates. I will give a few real-world examples of how cyber-criminals exploit the trust organizations have in such certificates, and I will provide some recommendations for protecting your resources from phishing scams.


Compromised Web Server

Using a wildcard certificate on a publically facing webserver increases the risk that cyber-criminals will use the webserver to host malicious websites in phishing campaigns.

To understand why, you must understand a bit about wildcard certificates. A wildcard certificate is a public key certificate used by all subdomains within a larger domain. Using wildcard certificates reduces the overall burden on system administrators. However, from a security standpoint, these certificates open up a can of worms.

Any subdomain created for the domain on a webserver that uses a wildcard certificate will use the same certificate. For example, a webserver with a wildcard certificate is hosting the domain https://example.com. Anyone with access to the webserver can set up a subdomain, https://phishing.example.com, on the webserver using the wildcard certificate. Visitors to the phishing site do not realize that they are on the phishing site because their browsers establish an HTTPS connection using the legitimate wildcard certificate.

You’re probably asking yourself, “Who would fall for something so simple? Surely anyone would recognize the illegitimate website.” Most phishing sites use long URLs to take advantage of the fact that a user is not likely to scroll through the entire URL. The browser also truncates the long URL, only showing, for example, the green highlighted part and not the malicious site: https://paypal.com.ylv=4$qid?532093256142-2-0351439098.webscr?cmd.phishing.example.com/83529hrs5.

Setting up a subdomain is exactly how cyber-criminals exploited a wildcard certificate on the Malaysian Police portal and used the portal for a phishing attack, as described in the following chalk talk.

Stolen Private Key

In the last five years malware designed to steal keys and certificates has proliferated, and a thriving marketplace for stolen certificates has sprung up. The recently discovered Mask malware presents yet another example of how cybercriminals compile malicious code to steal keys and certificates. Like compromising a webserver, gaining access to a wildcard certificate’s private key provides an attacker with the ability to impersonate any domain for the wildcard certificate (*.example.com).

When cyber-criminals compromised DigiNotar, a certificate authority (CA), the attackers were able to steal a Google wildcard certificate (*.google.com). Using the stolen certificate, an attacker would be able to set up a fake website for any Google service and then direct victims to the fake service by poisoning DNS services. Because the attacker is using a stolen wildcard certificate, the victim receives no warning when visiting the fake Google website.

Fake Certificate

A simpler option than compromising a CA is to trick a CA into issuing a wildcard certificate for a fictitious company. Once a hacker has the fictitious company’s wildcard certificate, the hacker can create subdomains and establish phishing sites that masquerade as belonging to any organization.

By using this technique, cybercriminals successfully hacked the Washington Post. First, attackers set up a fake Outlook Web Access (OWA) site. They then used a spear-phishing email campaign to fool journalists into visiting the OWA site. When journalists attempted to access the OWA site, their credentials were captured and later used to compromise the network.


Security controls and solutions can dramatically increase the cost of an attack. By putting these defenses in place, you increase the effort that a malicious actor must take to compromise your network. Your goal is to make compromising your network so expensive that cyber-criminals would rather focus their attention on someone else. As the saying goes: When a lion chases you, you don’t need to be the fastest runner; you just have to be faster than the person behind you.

You can make your organization more costly to exploit by avoiding wildcard certificates. Although wildcard certificates make business operations simpler, they provide tremendous opportunity to any cyber-criminal who compromises your webserver or steals a wildcard certificate’s private key.

Don’t let cyber-criminals use your wildcard certificates in malicious campaigns. Avoid using wildcard certificates on production systems, especially public-facing ones. Instead, you should use subdomain-specific certificates that are rotated often. A compromised wildcard certificate can lead to serious repercussions, but, by using short-lived, non-wildcard certificates, you significantly mitigate the impact of an attack.

<![CDATA[RSA Conference 2014: Recap and Attendee Vulnerability Survey]]> http://www.venafi.com/blog/post/rsa-conference-2014-recap-and-attendee-vulnerability-survey http://www.venafi.com/blog/post/rsa-conference-2014-recap-and-attendee-vulnerability-survey/#When:15:07:00Z I’ve been attending RSA for many years now, each year it seems to get bigger and better. This year a record breaking 28,500 attendees were in San Francisco to learn how to stop cyber-criminals in their ever increasing malicious campaigns against organizations.

RSA Conference

At RSA 2013, Microsoft declared “PKI is under attack”, and Intel Security-McAfee outright questioned the validity of digital certificates as a trust mechanism. In an ironic twist of fate, the Mask “Careto” malware was discovered days before RSA 2014. Dubbed one of the most advanced threats to date, the Mask malware payload included the theft of SSL, VPN, and SSH cryptographic keys and digital certificates.

At Venafi, each year we conduct a survey of RSA attendees to get a better understanding how well organizations are doing at protecting themselves against compromise, and responding when compromised. Our focus is specifically on how malicious actors abuse the blind trust that every organization has in keys and certificates—trust-based attacks.

Responding to an Attack

In the last 24 months, the significant increase in trust-based attacks has caught the media’s attention. It would seem with all the publicity, that organizations should be more aware and better prepared to detect and remediate trust-based attacks. But it’s quite the contrary; last year 43% of organizations took less than 24 hours to correct certificate trust on all devices for trust-based malware—malware that uses keys and certificates. This year only 35% of organizations could do the same—the time to respond actually increased, resulting in enterprise networks being compromised for longer periods of time.

Time to Stop Trust-Based Malware

The time to respond to any attack determines the amount of damage incurred to any organization. The challenge, you first need to be able to detect that your organization has been compromised and understand the attack vector. When it comes to keys and certificates as an attack vector, most organizations don’t know how to detect malicious activity. 58% of survey respondents stated that their organizations either don’t know how they would detect stolen or compromised keys and certificates used to attack their network, or simply could not detect this attack vector at all.

According to Intel Security-McAfee, in the last 24 months mobile malware has risen by 1600%. In an effort to mitigate this new threat, many organizations deploy MDM solutions and remote-wipe devices that are lost or potentially compromised. Regardless how many time a device is remote-wiped; if the certificates associated with the user (VPN, S/MIME) of the device are not revoked, and a malicious actor already has a copy, they still have access to your network. Our survey shows that almost 20% of organizations do not revoke certificates when remote-wiping a device, the result is that anyone with the certificate will have access to the network.

The Insider

The impact of the National Security Agency (NSA) breach by Edward Snowden exposed a dirty little secret that IT admins have been aware of for many years. 74% of organizations report that they have no systems to secure SSH. When detecting new SSH keys used in the cloud, 44% of respondents stated that system administrators are responsible for their own SSH keys, while 16% relied on scripted solutions to discover the SSH keys. In January of this year, the exposure of hundreds of administrators’ SSH keys showed the implications of letting administrators self-police when it comes to securing SSH keys.

Worse yet, 60% of organizations would take more than 24 hours to identify and replace rogue SSH keys used in an attack on the network.

Rise of a New Attack Vector

Gartner predicts that by 2017, over 50% of all network attacks will use encryption. We asked RSA 2014 attendees what their thoughts were on this. The results were in line with Gartner predictions, 62% of respondents believe there will be an increase in the use of SSL in cyber-attacks.

Increased use of SSL in Cyber-Attacks

I’m not surprised by the response that cyber-attacks will use more SSL over the next 3 years. The demand for “always on SSL” is only fueling the use of SSL in cyber-attacks. Cyber-criminals need to be able to disguise malicious traffic, and what better way to do so when less than 20% of SSL traffic is inspected by organizations.

Forrester Research

Every organization needs to take a step back and reevaluate their security strategy. Cyber-criminals are taking advantage of the trust established by keys and certificates. So much so that Forrester Research has concluded “advanced threat detection provides an important layer of protection but is not a substitute for securing keys and certificates that can provide an attacker trusted status that evades detection.”

As any good security practitioner would recommend, when malware known to steal credentials—including keys and certificates, and SSH keys—like Mask malware, is discovered on the network; the recommended practice is to remove the malware, change passwords, replace keys and certificates, and patch for any zero-day exploits. Sadly, 67% of RSA 2014 survey respondents work at organizations that are in a state of continuous vulnerability to cybercriminals. Only 33% of them replace user password and keys & certs when credential stealing malware is discovered on the network. Are you one them?

<![CDATA[The Evolution of Mobile Malware: Digitally Signed Malware Creates an Illusion of Trust]]> http://www.venafi.com/blog/post/the-evolution-of-mobile-malware-digitally-signed-malware-creates-an-illusion-of-trust http://www.venafi.com/blog/post/the-evolution-of-mobile-malware-digitally-signed-malware-creates-an-illusion-of-trust/#When:19:20:00Z Because cyber-criminals always seem to find new ways to circumvent traditional security measures, the threat landscape is constantly changing. A McAfee Labs Threat Report in Q3 2013 revealed an alarming trend: the type of malware proliferating most rapidly is digitally signed malware on mobile devices. McAfee Labs also identified a new family of Android malware that is enabled by compromised certificates. This new malware already accounts for 24% of digitally signed malware.

Mobile Malware

Although it is not surprising that malware targeting mobile devices—particularly Android devices—is proliferating, the severity of the threat is alarming. The rapid increase of digitally signed mobile malware continues to call into question the validity of all the mobile digital certificates that are in use and begs the question of how enterprises and individuals can distinguish between legitimate and compromised mobile certificates.

One thing is for certain, mobile malware attacks that are exploiting poorly secured cryptographic keys and certificates on mobile devices will continue to increase. Digitally signed malware is on it’s way to triple-digit growth, and by the end of 2014, it won’t be surprising to find almost all mobile malware attacks using digital certificates. But what’s even scarier is that most organizations today don’t have a mechanism in place to detect compromised mobile certificates. The traditional security controls and solutions they are using do not detect such attacks. Consequently, mobile certificates will continue to be a perfect target for cyber-criminals and pose a huge risk to organizations.

Cyber-criminals have learned that the quickest and easiest way to inject malware that resides undetected on mobile devices for months or even years is by signing the malware with compromised or stolen digital certificates. This digitally signed mobile malware can operate undetected by most organization’s whitelisting security controls. Cyber-criminals then become trusted users on mobile devices, evading traditional security controls and gaining undetected access to network resources.

Why is it so easy? Most organizations cannot detect or respond to anomalous certificates that authenticate systems and users on mobile devices, applications, and networks. Exploiting digital certificates is, therefore, the perfect attack. For example, certificates are used to verify the identity of an application’s owner. If cyber-criminals can obtain one of these digital certificates, their malware can circumvent any traditional security provisions. Because organizations do not protect their digital certificates from such attacks, users have a false sense of security, relying on an illusion of trust. Attacks that inject mobile devices with malware to gain access to corporate networks and steal corporate data take advantage of the broken trust caused by unsecured and exposed certificates and keys.

Many organizations invest significant resources into detecting and remediating mobile malware but ignore the more dangerous and underlying threat of weak and unsecured mobile certificates. Maybe they make this mistake because mobile certificate security is overshadowed by the focus placed on mobile malware itself. Whatever the reason, organizations continue to focus on mobile malware rather than examining the factors that erode trust and reducing their risk by implementing better mobile certificate security practices.

Although it is critical to address mobile malware, it is equally important to identify how attackers are exploiting broken trust to infiltrate systems and steal sensitive corporate data. I have seen too many instances where organizations place themselves at massive risk of attack because improperly secured certificates have opened doors to mobile malware.

<![CDATA[The Mask, Attacks on Trust, and Game Over ]]> http://www.venafi.com/blog/post/the-mask-attacks-on-trust-and-game-over http://www.venafi.com/blog/post/the-mask-attacks-on-trust-and-game-over/#When:12:01:00Z Breached Enterprises Will Be Owned by The Mask operation for Years to Come

For over a year, Venafi has been charting the course of attacks on the trust established by keys and certificates. The dramatic rise in attacks has led Microsoft to declare “PKI is under attack” and Intel Security-McAfee to “question the validity of digital certificates as a trust mechanism.” From key and certificate stealing trojans to stolen certificate marketplaces, the cybercriminal community has woken up to a whole slew of new vulnerabilities and powerful attacks.

The Mask

It now appears that in fact a monster has woken up! Kaspersky Labs has identified and documented what it terms as “one of the most advanced threats.” Known by its Spanish name “Careto,” The Mask operation is a sophisticated, organized attack using multiple attack methods to steal data. Its alarming set of targets include a variety of SSL, VPN, and SSH cryptographic keys and digital certificates.

The impact of this revelation is simple: breached organizations are now owned by The Mask operation. Cleaning up malware, reimaging servers, and resetting password won’t help. The attackers now own keys and certificates that provide the fundamental trust that is used to know if a server, cloud, or administrator is to be trusted. The attackers can decrypt communications and data formerly thought secure and private. The likely inability to remediate all of the compromised keys and certificates will leave the attacked breached for years, and in many cases decades.

Breached enterprises might as well bulldoze their data centers to regain ownership if they can’t replace all—not some—but all of their keys and certificates.

Forrester Research

How can this be? Mask’s operations are known to steal SSH keys used to authenticate administrators, servers, virtual machines, and cloud services. SSH keys provide root-level access and don’t expire—ever. Steal an SSH key and you likely have perpetual backdoor access. That bleak outlook is why Forrester Consulting simply previously concluded, “Advanced threat detection provides an important layer of protection but is not a substitute for securing keys and certificates that can provide an attacker trusted status that evades detection.”

Breached organizations must now identify all keys and certificates and immediately replace them. Based on industry research and Venafi’s experience in securing Global 2000 enterprises and governments, the breached will likely have no visibility in to the scope of the problem facing them and no ability to respond to these attacks on keys and certificates by replacing all of them. They need to take quick action now as the true intentions and impact of The Mask operation are yet to be seen. Otherwise, they might as well invest in bulldozers instead of malware cleanup or new firewalls.

The analysis is troubling. The details to follow are even more troubling. The impact and seriousness of The Mask on the breached cannot be understated or underestimated. For those not involved, it serves as another lesson that attacks on keys and certificates are very, very real and every enterprise must gain visibility, controls, and response mechanisms now.

Attacking Trust: Ownership for Life

Mask’s operations to steal keys and certificates is alarming. By stealing and leveraging trusted status, The Mask organization can now impersonate, surveil, collect, and decrypt its targets’ communications and data. Essentially, The Mask operators own the breached and for a very long time to come.

In a masterful criminal effort, Mask’s team didn’t just create powerful weapons—they attacked where they know their targets have no visibility and no ability to respond. Yes, the breached can now clean up malware infections, reimage servers, and reset passwords. But, as research has shown, Mask’s targets will not be able to identify and replace the tens of thousand of SSL, SSH, and other keys and certificates stolen.

Mask’s targets are like fish just caught and hauled on to a fishing boat. Fish will struggle to get back in the water, but will slowly suffocate on the boat’s deck with no hopes of escaping and returning to the water. With the ability to impersonate, surveil, collect, decrypt its targets communications and data, and their targets inability to respond and remediate to the attacks already committed with keys and certificates there may be little hope for the breached as they wait to potentially be attacked and suffocated by the blind trust they relied upon is turned against them.

Mask’s Attack on Trust

Mask’s methods of attacking trust make it a monster. Stuxnet, like 27% of Android malware, used stolen certificates today, to enable its attack. SpyEye, Zeus, and over 800 other Trojans are known to steal keys and certificates. Mandiant and others have well documented the use of self-signed certificates and SSL in enabling the APT1 group to exfiltrate stolen intellectual property. What makes Mask so special is that it uses all of these methods, improves on them, and adds new innovations. It’s a perfected weapon.

Evading Detection With Trusted Status

As reported by Kaspersky, Mask’s Windows malware was digitally signed with a valid certificate. Just like the hundreds of certificates used in malware attacks tracked by the CCSS Forum, the valid certificates enabled the malicious code to run trusted.

Signature validation

Like some other attacks using certificates, Mask’s certificate are believed to have been purchased legally from VeriSign by representing a fictitious company TecSystem Ltd of Bulgaria. Once again, Gartner’s prophetic statement on the state of IT security and certificate comes true: “Certificates can no longer be blindly trusted."

Stealing trust

What makes Mask so devastating now and for years to come is its hunger for stealing keys and certificates. SSL keys and certificates, SSH keys, disk encryption keys, and others have all been stolen. Even more troubling is that Mask’s malware not only ran on Windows but also on Linux, Mac OS, and likely mobile platforms. The theft of both server, administrator, user, and device keys and certificates for everything from SSL for websites, to administrator access to servers with SSH, to VPN access from a remote site places the breached in jeopardy now and a troubling sign for everyone else of what’s to come.

The theft of so many keys and certificates is what’s likely to make Mask remembered for many years to come. Just as Stuxnet signaled to the cybercriminal community the benefits of using stolen certificates, Mask will signal the power in stealing as many kinds of keys and certificates that establish trust as possible. While a SSL key might be replaced and certificates will expire, SSH keys never expire. They will exist as a perpetual vulnerability until they are replaced and no longer trusted. SSH key rotation is something that few, if any, enterprises actually do. As more cybercriminals learn from Mask and accelerate the theft of keys and certificates, the less trust we’ll have in everything from servers, to clouds, to mobile devices.

Careto file types stolen

Changing what's trusted

If not troubling enough, Kasperky’s research has identified even more powerful capabilities in Mask’s toolset. Mask’s command set indicates that the malware could add and delete certificates to a system. This allows the attackers to set what certificates or Certificate Authorities could be trusted. These methods have been seen in the wild already going back to 2010 just as the Mask operation was gearing up. Changing what websites and software that’s trusted is a powerful weapon. Not only does it allow users and security systems alike to be tricked in to connecting to fake websites or running malicious software, it allows the encrypted communications to be decrypted.

Surveillance and monitoring today and well in to the future

Mask is also able to monitor and potentially capture network traffic. Kaspersky reports that multiple plugin modules are capable of intercepting network traffic. With stolen keys and certificates, Mask’s operators may have been able to easily monitor encrypted communications thought to be private and secure. Unfortunately, even with Mask’s known, active operations shutdown, the attacker will still be able to decrypt network communications that can be intercepted.

Escaping detection: flying under the radar with encryption


The Mask operator’s understood that exfiltrating data can be risky business and raise alarms. However, using encrypted traffic allowed Mask to keep its activities under the radar of detection. Kaspersky reports that Mask’s team used various methods including encrypting communications directly with RC-4 and also could use HTTPS. While the increased use of SSL/TLS to keep communications private is one of the reasons the BBC declared “2014: The Year of Encryption,” it also means attackers will be able to hide easier. The use of SSL and other encrypted traffic is a sign of things to come. Gartner predicts that by 2017, over 50% of all network attacks will use encryption.

Attackers Intent

The targets for Mask’s operation are reported to include government agencies, foreign-service operations, energy, oil, and gas companies, and private equity. Targets have been identified in Brazil, UK, and United States with Kaspersky’s analysis finding Spain, France, and Morocco among the most commonly targeted in terms of IP addresses and victim IDs.

With such powerful weaponry either enabled by or designed to attack trust established by keys and certificates, it appears at least one of the attacker’s intentions is to impersonate, surveil, collect, and decrypt its targets’ communications and data. And, the attackers intended to keep it that way for a long time to come. Stealing keys and certificates provides permanent access to data or systems until keys are replaced. Unfortunately, this will be years for most attacked organizations. And even worse, SSH keys never expire and will provide Mask’s attackers near perpetual root-level access inside of breached organization.

Immediate Action: Fight Back or Be Owned

For organizations attacked by Mask, action must immediately be taken to respond and remediate the attacks on trust established by keys and certificates. Breached organizations must identify all keys and certificates on networks, in servers, on endpoints, and on mobile devices. Remediation can then proceed to generate new SSL keys and certificates, generate new VPN keys and certificates, and generate new SSH keys and removing previously trusted keys from authorized key lists. However, only with complete intelligence on all keys and certificate can remediation be considered successful.

For all other organizations, Mask is another warning that demonstrates the devastating impact attacks on keys and certificates can have. Organizations must have the ability to identify all keys and certificates, enforce a known good state, detect anomalies, and respond and remediate incidents. Organizations will then be able to change keys and certificates frequently, eliminate human intervention that can open the door for malware to steal keys and certificates, and be able to respond immediately.

<![CDATA[You’re Already Compromised: Exposing SSH as an Attack Vector]]> http://www.venafi.com/blog/post/youre-already-compromised-exposing-ssh-as-an-attack-vector http://www.venafi.com/blog/post/youre-already-compromised-exposing-ssh-as-an-attack-vector/#When:12:00:00Z Before the Snowden breach, the average person rarely thought about encryption. Last year, however, encryption was at the forefront of everyone’s mind. People wanted to know what Edward Snowden disclosed about the National Security Agency (NSA) PRISM, how they could avoid being spied on, and how Snowden was able to compromise what’s believed to be one of the most secure networks in the world. Although not everyone has been paying attention, keys and certificates have actually been at the center of news for the last few years. Adversaries and insiders have long known how to abuse the trust established by keys and certificates and use them as the next attack vector.

SSH key

One of the first projects I worked on this year with the Ponemon Institute was to understand how organizations are protecting themselves from a Snowden-like breach, resulting from vulnerabilities related to Secure Shell (SSH) keys. The research spanned four regions, which included responses from over 1800 large enterprises that ranged from 1000 to over 75’000 employees. What was very evident from the research is that most organizations are inadequately prepared for or incapable of detecting a security incident related to the compromise or misuse of SSH keys. Some chilling results:

  • 51% of organizations have already been compromised via SSH
  • 60% cannot detect new SSH keys on their networks or rely on administrators to report new keys
  • 74% have no SSH policies or are manually enforcing their SSH policies
  • 54% of organizations using scripted solutions to find new SSH keys were still compromised by rogue SSH keys on their networks in the last 24 months
  • Global financial impact from one SSH-related security incident was between US $100,000 to $500,000 per organization

Operational versus vulnerability view

More than half (53%) of organizations surveyed lack the ability to define and enforce SSH policies from a central view. As a result, they typically rely on individual teams or application administrators to secure their own keys. Because these organizations do not have visibility into how SSH keys are used within the enterprise network, detecting any security incident related to the misuse of SSH keys is very difficult. Organizations that view SSH key security as an operational problem are clearly missing the point: keys and certificates are fast becoming one of cyber-criminals’ preferred attack vectors because of the trust status they provide.

74% have inadequate SSH security policies

74% of organizations either have no SSH policies or are manually enforcing an SSH policies. Using the latest GitHub exposure of more than 600 SSH private keys as an example of application administrator behavior, you can see just how well manual processes are enforced—they’re not. If you are not familiar with this example, enhancements to the GitHub search functionality inadvertently exposed hundreds of application administrators’ private keys that had been stored in GitHub, many by simple mistake. You cannot rely on manual processes to secure and protect SSH keys; mistakes are inevitable.

51% are already compromised

Last year the Ponemon Institute published the 2013 Annual Cost of Failed Trust Report. In this report, the most alarming key and certificate management threat was SSH. In the SSH research conducted in 2014, Ponemon Institute found that 51% of organizations across four regions had a security incident related to the compromise or misuse of SSH keys. More alarming is that 50% of the compromised organizations used homegrown scripted solutions to manage SSH keys. This clearly shows that scripted solutions cannot detect the anomalous usage of SSH keys or rogue SSH keys used nefariously. Moreover, 60% of organizations surveyed rely on application administrators to manually detect rogue SSH keys.

Survey Data: SSH Attacks

A never-ending nightmare

As the research suggests, organizations have limited visibility into how SSH keys are used in the enterprise network and no ability to apply policies to SSH keys. However, you would think that even organizations using manual, disparate SSH key management would provide guidelines for rotating SSH keys. After all, SSH keys have no expiration date. According to Ponemon Institute research, 50% of organizations do not have an SSH key rotation plan in place. At Venafi we’ve encountered a number of organizations that have SSH keys assigned to ex-employees on critical servers, and these ex-employees left the organization more than five years ago. Considering that SSH bypasses host-based controls and provides elevated privileges, every organization should make rotating keys a priority!

Time to respond

When asked how quickly their organization could identify and respond to a security incident related to compromised or misused SSH keys, nearly half (45%) of the respondents could mitigate the threat in one day or more. The length of time it takes to respond to a security incident, directly increases the financial burden organizations need to bear from the security incident. The financial impact for United Kingdom, Germany, and Australia ranged from US $100,000 to $250,000. US-based organizations were more significantly impacted, ranging from US $500,000 to $1000,000.

SSH Security Incidents

By using a stolen SSH private key, an adversary can gain rogue root access to enterprise networks and bypass all the security controls. Because organizations have no policies, visibility into SSH vulnerabilities, or ability to respond to an SSH-related attack, cyber-criminals are turning to SSH as an attack vector at an ever-increasing rate. Every organization needs to stop viewing SSH keys and the management thereof as an operational matter that can be resolved with a few simple discovery scripts or relying on individual application administrators to self-govern. You wouldn’t do that with domain credentials, so why treat SSH keys—which enable elevated root privilege—any differently?

Every organization needs to have central visibility into the entire SSH key inventory, understand how SSH keys are used on the enterprise network, and apply SSH policies. Only then will an organization be able to quickly detect security incidents related to SSH and immediately remediate them.

Want to learn more about SSH vulnerabilities? Download the Ponemon 2014 SSH Security Vulnerability Report Infographic now.

<![CDATA[Infographic: New Ponemon SSH Security Vulnerability Report]]> http://www.venafi.com/blog/post/infographic-new-ponemon-ssh-security-vulnerability-report http://www.venafi.com/blog/post/infographic-new-ponemon-ssh-security-vulnerability-report/#When:11:59:00Z Global organizations are under attack, and the attackers are more dangerous and persistent than ever. While the motivations vary, the goal of today’s cybercriminal is to become and remain trusted on targeted networks in order to gain full access to sensitive, regulated and valuable data and intellectual property, and circumvent existing controls.

Certificate attacks

Among the fundamental security controls enterprises rely on to protect data and ensure trust is secure shell (SSH). Yet, according to new research by the Ponemon Institute, system and application administrators—not IT security—are responsible for securing and protecting SSH keys, which exposes critical security vulnerabilities.

The research also found nearly half of all enterprises never rotate or change SSH keys. This makes their networks, servers, and cloud systems owned by the malicious actors in perpetuity when SSH keys are stolen, and represents IT’s dirty little secret, which leaves known and open back doors for cyber-criminals to compromise networks.

Data loss prevention, advanced threat detection solutions and next-generation firewalls cannot consume SSH encrypted traffic, making it easy for adversaries to steal information—over extended periods—without detection. And unlike digital certificates, SSH keys never expire, leaving the vulnerabilities and figurative back doors open indefinably.

This exclusive new infographic provides you with the analysis needed to understand the breach and how it could impact you and your organization.

Ponemon 2014 SSH Vulnerability Report Infographic

Download Infographic (JPG)

Download the Ponemon Report

<![CDATA[Fake SSL Certificates Uncovered: The Tip of the Iceberg and Weaponized Trust]]> http://www.venafi.com/blog/post/fake-ssl-certificates-uncovered-the-tip-of-the-iceberg-and-weaponized-trust http://www.venafi.com/blog/post/fake-ssl-certificates-uncovered-the-tip-of-the-iceberg-and-weaponized-trust/#When:23:12:00Z Cybercriminals are moving faster than we think to weaponize the core element of trust on the Internet: digital certificates. The many fake certificates identified by Netcraft are just the tip of the iceberg. Cybercriminals are amping their attacks on trust because the results are so powerful.


Already over a quarter of Android malware are enabled by compromised certificates and there are hundreds of trojans infecting millions of computers designed to steal keys and certificates for resale and criminal use. Today a stolen certificate is worth over 500 times more than a credit card or personal identity.

By attacking the trust established by digital certificates, cybercriminals aren’t making a quick hit. No, their intent is to own their target. Fake, compromised, stolen, misused, illicitly obtained certificates give cybercriminals the power to impersonate, surveil, and monitor—and to do so undetected.

Careto - The Mask Malware

Just recently The Mask group infiltrated hundreds of organizations. The group’s malware stole encryption keys, digital certificates, and SSH keys. While their collection efforts have just now been identified and stopped after 7 years, the real impact is yet to come.

The attackers now own thousands of keys and certificates and as result own the networks, servers, and applications of the breached. They can impersonate websites with stolen keys and certificates and have root-level access with SSH keys. Game over for these breach organizations. If they don’t fight back and change all of their keys and certificates immediately.

If businesses and governments don’t get a handle on the ways they are using certificate and can’t respond to these attacks, we all might as well be investing in bulldozers. Our data centers are worthless when the basic, foundational element of trust on the Internet—digital certificates—are compromised.

Gartner Security Quote

We can’t tell the good from the bad and so just need to bulldoze and start new. But, we don’t have a replacement technology for digital certificates so we have to stand and fight. Otherwise, the reality Gartner painted of “living in a world without trust” will come true (Gartner ID: G00238476).

<![CDATA[Patching the Perpetual MD5 Vulnerability]]> http://www.venafi.com/blog/post/patching-the-perpetual-md5-vulnerability-2014 http://www.venafi.com/blog/post/patching-the-perpetual-md5-vulnerability-2014/#When:19:30:00Z Last year, Microsoft updated the security advisory that deprecates the use of MD5 hash algorithms for certificates issued by certification authorities (CA) in the Microsoft root certificate program. The patch was released so that administrators could test its impact before the Microsoft Update on February 11, 2014 enforces the deprecation. Time has run out, hopefully organizations have tested the impact of this and are ready for tomorrows update. This is a significant security update in the fight against cyber-criminal activity that abuses the trust established by cryptographic assets like keys and certificates.

For over 17 years, cryptographers have been recommending against the use of MD5. MD5 is considered weak and insecure; an attacker can easily use an MD5 collision to forge valid digital certificates. The most well-known example of this type of attack is when attackers forged a Microsoft Windows code-signing certificate and used it to sign the Flame malware. Although the move to deprecate weak algorithms like MD5 is most certainly a step in the right direction, there still are some questions that need to be addressed.


Why is the Microsoft update important?

Cryptographers have been recommending the use of hash algorithms other than MD5 since 1996, yet Flame malware was still successful in 2012. This demonstrates that security professionals have failed to identify a vulnerability in their security strategy. However, cyber-criminals have most certainly not missed the opportunity to use cryptographic keys and digital certificates as a new way into enterprise networks. That Microsoft will soon enforce the deprecation of MD5 indicates that vendors and security professionals are starting to take note of keys and certificates as an attack vector.

hashing algorithm pie chartResearch performed by Venafi reveals that 39% of hash algorithms used by global 2000 organizations are still MD5. Such widespread use is worrying on a number of different levels as it clearly highlights that organizations either do not understand the ramifications of using weak algorithms like MD5 or that they simply have no idea that MD5 is being used in the first place. Research from the Ponemon Institute provides evidence that organizations simply don’t know that MD5 is being used—how could they when more than half of them don’t even know how many keys and certificates are in use within their networks?

What’s the impact of the security update?

Microsoft’s update is not to be taken lightly; this is probably why Microsoft has given organizations six months to test the patch. Once they have deployed the update, administrators will be able to monitor their environments for weak cryptography and take action to protect themselves from the vulnerabilities associated with MD5 hash algorithms or inadequate key sizes. Options available to administrators include the ability to block cryptographic algorithms that override operating system settings.

However, if a business has critical certificates that use MD5, enforcing such a security policy could result in system outages that may impact the business’s ability to service customer requests. For this reason, the update allows administrators to choose whether to opt-in or opt-out of each policy independently as well as to log access attempts by certificates with weak algorithms but to take no action to protect the system. The update also allows policies to be set based on certificate type such as all certificates, SSL certificates, code-signing certificates, or time stamping certificates.

Although I understand that Microsoft is allowing customers to choose how wide a net they are able to cast on MD5, the choices system administrators have when a security event is triggered should be of concern. Instead of choosing to apply the security policy to “all certificates,” some companies, out of concern for system outages, may limit the enforcement to a subset of certificate types. After all, history has shown that organizations have neglected to do anything about the known MD5 vulnerability for many years; they might easily continue to postpone the requisite changes. As a result, some companies may leave a massive open door for cyber-criminals to exploit.

Are there other weaknesses in cryptography that should concern me?

MD5 is not the only vulnerability to cryptography that should concern IT security professionals—there are many. However, I am only going to focus on a few of the most common.

1024-bit keyInsufficient key length: Since 2011 the National Institute of Standards and Technology (NIST) has deprecated encryption keys of 1024 bits or less. After December 31, 2013, the use of 1024-bit keys will be disallowed due to their insecurity. Despite this, as surveyed by Venafi, 66% of the encryption keys still used by global 2000 organizations are 1024-bit keys. Vendors and service providers like Google, Microsoft, and PayPal made the shift to 2048-bit keys earlier this year. If you have 1024-bit keys in use, now is the time to upgrade to 2048-bit keys.

Lack of visibility: majority of organizations lack visibility into or understanding of their key and certificate population. Organizations simply don’t know how many keys and certificates are in use on the network, what access they provide to critical systems, who has access to them, or how they are used. Businesses without visibility into such a critical attack vector—and with limited or no ability to respond quickly—are an attacker’s dream. To mitigate against these vulnerabilities, you must gain a complete understanding of your key and certificate population so that you know where your organization is vulnerable.

Inability to remediate: How can you defend something if you don’t know what you are defending? The lack of visibility has led to real vulnerabilities. Forrester Research found that 44% of organizations have already experienced an attack based on keys and certificates. Moreover, 60% of these businesses could not respond to the attacks, whether on SSH or SSL, within 24 hours. And the response, when unrolled, usually involves a laborious manual process that often leaves some systems unchecked.

What can I do to avoid these vulnerabilities?

To protect your business against attacks on keys and certificates, I recommend that you invest wisely in technologies that apply robust policies against the use of weak algorithms and poorly configured cryptography. At the same time, the technology should be able to detect anomalous behavior of keys and certificates and automatically respond, remediating any key- and certificate-based risks.

<![CDATA[Anomaly Detection, Knowing Normal Is the Key to Business Trust and Success]]> http://www.venafi.com/blog/post/anomaly-detection http://www.venafi.com/blog/post/anomaly-detection/#When:15:09:00Z Threats and attacks are steadily increasing, and business executives face new challenges with trust exploits. While organizations adopt cloud computing and allow employee-owned devices onto the network, the challenge of securing company data increases exponentially. When it comes to advanced persistent threats (APTs), bad actors take advantage of every exploit to steal information, and look for the weakest link in enterprise security systems.

So much emphasis in IT security today is placed on anomaly detection. Whether it is detecting abnormalities in user behavior, system states or trust relationships governed by keys and certificates, the theory is that the faster you can pinpoint anomalies, the faster you can find malicious threats and close security gaps. But the problem is that making decisions based on anomalies is predicated by one very important assumption—you must understand what “normal” looks like.

Read the full article on Security Week

<![CDATA[Mobile Certificate Vulnerabilities and Why IT Security is Losing Control]]> http://www.venafi.com/blog/post/mobile-certificate-vulnerabilities http://www.venafi.com/blog/post/mobile-certificate-vulnerabilities/#When:22:25:00Z Enterprises are turning to certificates to secure mobile devices, applications, and users, rather than relying on less secure authentication methods such as usernames and passwords. Digital certificates authenticate mobile users to a growing set of applications, including the web, cloud, Virtual Private Networks (VPNs), and wireless networks secured by 802.1X, and the shift toward Bring Your Own Device (BYOD) has led to the rapid deployment of hundreds of thousands of mobile certificates.

However, many of the security experts I speak to have little control over or visibility into their mobile certificate inventory, and they do not know which mobile certificates each user can access. As a result, cyber-criminals can easily exploit certificates for mobile devices and users and pose as trusted users, thereby infiltrating corporate networks and stealing intellectual property.

Mobile device and user certificates as an emerging threat vector

With the rapid influx of mobile devices in the enterprise, these mobile devices have become an effective threat vector against the corporate network. In fact, according to a Verizon Data Breach Report, 71% of compromised assets in 2013 involved users and their endpoints. Why are cyber-criminals targeting users’ mobile devices? These mobile devices contain enough information, such as email accounts, user passwords, and company VPN credentials, to allow attackers to infiltrate the internal network as legitimate users. The mobile devices themselves essentially serve as a conduit directly into the enterprise network. For example, if attackers can download custom malware to a mobile device, they can use the mobile device’s VPN connection to access the corporate network.

This attack method is so effective malware creators are focusing on mobile devices. In 2012 McAfee Labs discovered 44 times the number of mobile malware samples found in 2011. This means that 95% of all mobile malware samples ever seen appeared in the last year.

In addition to the increased volume of mobile threats, the threats are becoming more dangerous. Cyber-criminals have determined that one of the best ways to circumvent standard system security is to electronically “sign” their malware using a stolen or fabricated certificate. Network systems then “trust” the malware, making it possible for attackers to target specific systems and retrieve confidential data. McAfee Labs discovered that instances of signed malware increased 3 times just in Q4 2012. 

Mobile malware, code signing, man-in-the middle (MiTM) attacks, other mobile certificate-based attacks demonstrate how easily cyber-criminals can use mobile devices to access the corporate network. In fact, mobile certificates present a risk even when attacks do not directly target them because they provide access to the enterprise.

IT is losing control of mobile and user certificates

To protect the network, IT must be able to detect when mobile device and user certificates are being attacked or compromised and prevent these compromised certificates from accessing the network. However, IT is quickly losing control of mobile and user certificates. Consider the problem: Thousands of users connect to the corporate network, and each user has multiple, personally owned mobile devices. These users and devices are issued hundreds of thousands of certificates, and IT must track and protect all of them.

In a Venafi survey conducted at the 2013 RSA Conference, we found that 57% of organizations do not have an accurate mobile certificate inventory. In addition, in more than 50% of organizations some mobile and application certificates are issued outside the control of the IT security team. The rapidly growing influx of mobile and user certificates is becoming a nightmare for IT security teams—and the lack of insight into and control over their mobile and user certificate inventory introduces significant security vulnerabilities such as:

  • Orphaned and duplicate mobile certificates

    The organization’s existing security controls do not detect certificate anomalies such as orphaned and duplicate mobile certificates, which attackers can use to gain unauthorized access. IT security teams are aware that certificates have been issued and know these certificates grant access to various resources—perhaps even critical ones. But they do not know which users have access to the certificates, how many certificates have been issued, or where the certificates have been deployed. Sophisticated attackers executing advanced persistent threats (APTs) will take advantage of any and every exploit to steal corporate—including exploiting orphaned and duplicate mobile and user certificates. For example, if attackers can download custom malware to a mobile device, they can use an orphaned VPN certificate to establish a VPN connection and gain access to a corporate network. In addition, attackers can use orphaned certificates to sign code from a “trusted” source. Once their code is trusted, attackers can use the mobile device or application to infiltrate the enterprise.

  • Constantly changing environments

    Terminated employees or contractors who have access to mobile and server certificates, Secure/Multipurpose Internet Mail Extensions (S/MIME) keys, and Secure Shell (SSH) keys can use those keys to impersonate corporate servers or steal data. In addition, users frequently change roles, and whenever they change roles, the level of access they require to corporate data changes as well. Mobile certificates issued to users serve as trusted credentials, granting users secure access to critical networks, applications, and data. But if employees or contractors are terminated or reassign and their mobile, Wi-Fi, VPN, and S/MIME certificates are not revoked, those users can still access the corporate network and sensitive information.

  • Fraudulent mobile certificates and compromised Certificate Authorities (CAs)

    As the use of certificates has increased, the CAs that issue certificates have increasingly become targets for sophisticated attacks. Hackers have successfully obtained fraudulent certificates that grant them unauthorized access and forged digital signatures. These attacks on CAs make it critical for organizations to ensure they are using secure CAs. Organizations also need to respond quickly if a CA is compromised or a fraudulent certificate is issued.

  • Weak Cryptography

    According to a Ponemon Institute research, the average Global 2000 company still uses 1024-bit keys. In fact, 1024-bit keys make up almost 70% of the encryption key inventory. In addition, the weak MD5 algorithm allows hackers to create a rogue CA root certificate that is trusted by all browsers. Unfortunately, many mobile certificates used for VPN access still use the MD5 algorithm, leaving a huge backdoor wide open for attackers to steal information.

  • Poor application security

    Mobile applications are vulnerable to MiTM attacks that are instigated by inserting rogue certificates. For example, attackers used a T-Mobile vulnerability to access and modify calls and text messages T-Mobile users sent on millions of Android smartphones. In this vulnerability, the certificate validation was not fully implemented, so without proper verification, hackers could create a fake certificate and pretend to be the T-Mobile server.

    As you can see, the rapid adoption of mobile devices has made it challenging for enterprises to secure and protect the certificates on these devices, making them prime targets for attackers eager to exploit security vulnerabilities and hijack mobile and user certificates for their own use. Bad actors and cyber-criminals have proven that once they gain access to unprotected certificates, they can authenticate to networks and gain access to corporate information.

<![CDATA[What Is a Trusted Threat?]]> http://www.venafi.com/blog/post/what-is-a-trusted-threat http://www.venafi.com/blog/post/what-is-a-trusted-threat/#When:16:00:00Z Last month I co-presented a webinar with ISIGHT Partners, a leader in cyber-threat intelligence, to discuss a white paper that exposes how keys and certificates can be used for nefarious intentions. Our purpose was to highlight some of the tactics malicious actors use and outline their profiles in relation to keys and certificates. Due to time constraints, we did not cover how most organizations expose themselves to cryptographic vulnerabilities simply because keys and certificates are viewed as an operational problem and not as a security issue that needs to be addressed immediately!

For example, for most organizations today, the most critical element of certificate management is monitoring the validity period—that is, the certificate’s expiration date. The reason is simple: if a certificate expires, it will result in a service outage. Most organizations track validity periods either in a spreadsheet or a portal such as SharePoint. Disappointingly, there are many public examples of failure to manage even the expiration date of certificates—such as the Microsoft Azure outage earlier this year—let alone the actual security configuration of a certificate.

Secure Shell (SSH) keys, on the other hand, do not have expiration dates that organizations must track. Instead organizations need to have a clear understanding of where SSH private keys are stored and control the systems to which certain individuals have access. In most organizations, it is up to the application administrator or SSH administrator to track this information. Unfortunately, in most organizations, numerous individuals manage the keys, using disparate management practices, and no one can determine how SSH keys are being used in the network. Edward SnowdenTake for example how Edward Snowden breached the National Security Agency (NSA) as an illustration of the SSH key management shortfall at the NSA.

Encryption keys and digital certificates provide the backbone of trust across corporate networks and the Internet. In planning for future expansion, organizations need to understand and appreciate that the digital universe is expanding at an alarming rate. If organizations can’t perform rudimentary key management today, how will they cope with both the volume of keys and certificates as more are consumed, and how will they secure and protect them?

This is exactly why malicious actors are increasingly taking advantage of keys and certificates as an attack vector, making them the perfect trust threat. For example, malicious actors can:

Organizations need to stop viewing keys and certificates as a basic operational issue and start understanding that they can be a serious threat to their business if they are not secured and protected.

The question is, what do organizations do about the fact that they require keys and certificates to establish trust, but malicious actors are exploiting that trust and using it against them? There is light at the end of tunnel; organizations can still use keys and certificates to establish the trust they need in the digital world, but they don’t need to accept that keys and certificates will be used against them. That’s not to say it will never happen because chances are most organizations have already been compromised, but there are ways to limit key and certificate threat exposure and respond and remediate quickly if an organization is compromised.

Taking the first step

When it comes to key and certificate security, organizations must know their key and certificate inventory. They must also understand key and certificate attributes and make sure they are configured to meet recommended security guidelines while not impeding business goals. To do this, organizations need to scan their enterprise networks on a regular basis to address key areas:

  • Secure configuration of cryptographic assets
  • Detection of anomalous key and certificate usage—malicious or negligent

Secure configuration of cryptographic assets

When organizations configure cryptographic keys and digital certificates, they should follow best practice guidelines that factor in known exploits and improvements in technology. Organizations can consult standards bodies such as the National Institute of Standards and Technology (NIST), which provide recommendations for cryptographic resources. For example, NIST has established a minimum key size of 2048 bits, stating that 1024-bit keys should no longer be used after December 31, 2013. The hashing algorithm SHA-1 has suffered the same fate<.

By enforcing standards that meet minimum security requirements, organizations can protect their network resources against potential exploits such as the BEAST exploit. However, organizations should keep in mind that evaluating singular attributes on their own will not adequately protect their network resources against breaches. As an example, when evaluating an IT infrastructure’s weakness against the BEAST exploit, organizations need to take into consideration the version of Transport Layer Security (TLS), the cypher suite, and the configuration used. Evaluating each of these factors individually would not bring to light the vulnerability.

Detection of anomalous key and certificate usage

Simply identifying the key and certificate inventory will not help organizations detect rogue usage of an SSH key or malware that is using a self-signed certificate to encrypt command and control (C2) traffic. To detect these issues, organizations need to understand the key and certificate inventory and the policies being enforced—all of which were addressed in the first step. Organizations must then frequently scan the environment so that they can detect any rogue keys or certificates that may have been maliciously placed in the network. If a rogue key or certificate is detected, organizations can investigate how it is being used and take action.

As the use of keys and certificate as an attack vector continues to rise, organizations need to take responsibility in securing and protecting the very trust that is established by keys and certificates. Treating them as an operational issue will only result in opportunity for malicious actors to compromise networks. Regularly evaluating the network to detect key and certificate vulnerabilities is the only way to mitigate key and certificate based attacks.

<![CDATA[Are MDM solutions sufficient to secure your mobile environments?]]> http://www.venafi.com/blog/post/are-mdm-solutions-sufficient-to-secure-your-mobile-environments http://www.venafi.com/blog/post/are-mdm-solutions-sufficient-to-secure-your-mobile-environments/#When:15:48:00Z Mobile Device Management (MDM) solutions have served as the point of the spear in the mobile arms race. The question is, “Are they sufficient to ensure the security of your mobile environment?” MDM solutions definitely provide important capabilities such as deploying applications, securing content, wiping devices, and so on. The challenge comes in the area of mobile certificates and keys. Although MDM solutions can automatically provision certificates for mobile devices, the security and protection of mobile certificates and keys extend beyond the scope of MDM solutions.

Certificates and keys can potentially be copied from mobile devices once they’re provisioned. In addition, MDM solutions are not the only way to issue certificates to users and mobile devices. Because of the diversity of use cases, device types, and applications, many organizations have erected enrollment portals so that users can register to receive certificates. And an increasing number of mobile applications and systems are capable of requesting certificates directly from Certificate Authorities (CAs).

MDM and SSL in your environment

Certificates are a critical component of mobile security and the security of your corporate systems and data. Attackers are targeting certificates and keys because they realize that once they obtain access to a certificate and key that an organization trusts, they can rapidly circumvent other security mechanisms, increasing the success rate and potential breadth of their attacks. If attackers obtain access to a certificate that your Wi-Fi or Virtual Private Network (VPN) systems trust, they gain access to your corporate network and can directly target specific systems.

MDM solutions represent an important element of any mobile security program, but to effectively secure and protect the certificates and keys that ensure strong authentication you need a solution that spans across your environment—a solution that enables you to prevent, detect, and respond to attacks that target those certificates and keys. The sections that follow outline the capabilities this solution should provide.

  • Enforce Policies: As mentioned earlier, users do not always receive mobile certificates through an MDM solution. Because users may request certificates using other tools (such as enrollment portals) or even multiple CAs, you must implement a solution that is capable of enforcing certificate and key policies consistently across your entire environment. MDM solutions may provide policy enforcement but only for the certificates they issue, and often these policies are defined and managed by individuals that are not part of the Public Key Infrastructure (PKI) group responsible for setting up and enforcing corporate-wide policies for certificates and private keys.

  • Limit Trust: Attackers are targeting the systems that users access through their mobile devices. An important prevention measure is to ensure that those systems trust only necessary CAs. If an extraneous CA is then compromised, these systems are not vulnerable.

  • Manage all of your company’s certificates: Application servers, appliances, other servers, and infrastructure systems are outside the scope of MDM solutions. Your solution must provide visibility into all the CAs trusted in your environment so you can detect attacks and take preventive action.

  • Limit Key Usage: When an attacker compromises a certificate, its usefulness is limited by the defined “key usage” of that certificate. You need a solution that ensures that certificate templates and key usages are appropriately enforced so that certificates have limited application and value to attackers if they’re compromised. Again, MDM solutions provide the ability to select key usages for the certificates they issue but not for certificates that are obtained through some other means.

  • Establish Consistent Enrollment Processes: Certificate enrollment is a prime target for attackers, especially if inconsistent or diverse processes allow attackers to request and receive approval for a fraudulent certificate. Based on the needs of various business applications and organizational constraints, mobile certificates may be requested and provisioned outside of MDM solutions. It is critical to enforce enrollment policies and oversight across all enrollment methods.

  • Limit Certificate Issuers: The diversity of mobile environments increases the likelihood that unapproved CAs will be used—thereby increasing the risk that a CA will be compromised. Interestingly, although many organizations have spent millions of dollars securing their internal CAs, their mobile groups have begun issuing certificates from the CAs embedded in their MDM solution. It is important to have oversight and control that extend beyond an MDM solution to ensure that only approved CAs are used.

  • Map User Certificates: When an employee is terminated, you must be able to identify the certificates issued to that employee, whether they were provisioned through an MDM solution, Windows auto enrollment, an enrollment portal, or another method. In addition, if that employee was responsible for managing certificates on devices, you must be able to quickly identify those certificates so they can be replaced and revoked.

  • Detect Anomalies and Vulnerabilities:  A key element in preventing potential attacks is detecting anomalies and vulnerabilities so you can take preventive action. To do this, you need visibility across your entire certificate environment and the ability to report on and analyze your certificate inventory across all enrollment and provisioning methods.

  • Immediately Revoke Certificates: When an employee is terminated or resigns from the company, you must be able to rapidly revoke all certificates that were issued to that employee. It’s critical to realize that wiping a device or container 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 provisioned through an MDM solution or some other means, is paramount in these situations.

  • Replace Managed Certificates: If a system administrator is terminated or resigns from the company, the security risk is greater. The former employee may have had access to and made copies of certificates and private keys on mission-critical systems. Consequently, you must notify employees who are responsible for these systems so the certificates and keys can be reassigned, replaced, and revoked. Although infrastructure certificates that employees manage are outside the scope of an MDM solution, they are a critical element that must be addressed when a system administrator leaves the company.

As mentioned earlier, MDM solutions are a critical element to mobile security. To ensure the security and protection of your environment, however, you must augment them with a solution that provides broader oversight and control of certificates and keys.

<![CDATA[2020 Hindsight Starts Today]]> http://www.venafi.com/blog/post/2020-hindsight-starts-today http://www.venafi.com/blog/post/2020-hindsight-starts-today/#When:17:00:00Z I’m pretty sure that all who read this blog will agree: traditional prevention-centric security models are becoming less and less effective each day, while conversely, people- and information-centric security models continue to advance and gain effectiveness. In a nutshell, people- and information-centric strategies begin by defining “the norm” (what is good). These strategies help companies quickly identify anomalies and then quickly respond and resolve those anomalies.

We’re at a point where we must assume attacks and breaches will happen constantly and turn legacy prevention-centric security strategies completely on their head. Today’s new security technologies that operate under this assumption, such as micro-virtualization for the endpoint by Bromium, are positioned to become an essential component of any enterprise security strategy in 2020.

gartnerIn fact, Gartner has spent the past 6 months boldly predicting at various IT- and security-related events that by 2020 prevention-centric strategies will be obsolete. This makes total sense if you consider two major developments:



  • The convergence of several major computing trends, such as cloud, mobile and the internet of things—all of which rapidly fuel expansion of the digital universe.
  • The launch of increasingly sophisticated cyber-attacks, namely Advanced Persistent Threats (APTs)—many of which target the above burgeoning trends.

First, let’s talk about the digital universe. As the digital universe grows and becomes more pervasive in our lives, our ability to trust this universe becomes more and more important. Without trust, the entire digital universe fails. Fast-forward to 2020, and this notion of a digital “world without trust”, becomes even more daunting, especially if you consider the following estimates:

I could go on, but I think you get the picture. The numbers above are at a digital universe-wide level, but you can expect your corporate infrastructure and network to grow and scale similarly, if not faster.

The opportunity this “big data” presents is fascinating. But now, consider the “opportunities” this anticipated growth provides cyber-attackers. As the digital universe expands, our ability to preserve trust in this universe becomes more challenging, more daunting and more imperative. And if we don’t have trust, it really doesn’t matter how many internet-connected devices researchers believe we will have in 2020. Without trust in the digital universe, our world of frequent and convenient online commerce may cease to work.

So if you’re struggling to secure and protect trust today and you have plans to leverage and monetize your enterprise’s growing digital capabilities, something definitely needs to change, and change now. Encryption keys and digital certificates provide the backbone of trust for your organization’s digital assets, yet they also serve as a cyber-attacker’s weapon of choice to evade detection.


The highest profile example of this is the U.S. National Security Agency (NSA) breach by Edward Snowden earlier this year, the success of which relied heavily upon a total breakdown of trusted computing. Like the size of your digital footprint, these “attacks on trust” will only keep growing if they continue to be successful.


Because certificates are being used as cyber-weapons, their validity periods are becoming shorter and shorter. Today, I personally recommend employing certificates with a maximum validity period of no longer than one year. The rationale is that the longer a particular certificate is used, the more likely it will be copied or forged and thus will no longer be trustworthy. Some studies go even further, and proclaim “short-lived” certificates limit the scope of vulnerability, as a result of having validity periods of only a few days. While this practice sounds great in theory and enhances certificate security, the operational aspects could be a nightmare. Quite simply, IT groups cannot effectively and securely manually perform that type of ultra-frequent certificate revocation and provisioning.

The good news is that even now in 2013 it is possible to both secure trust and effectively execute all required processes around a rapid rotation of certificates, regardless of how large your digital universe may eventually grow. Venafi’s current technology platform for protecting any key, any certificate, anywhere is engineered around Gartner’s 2020 recommendations. Venafi’s platform provides a people- and information-centric security and protection strategy for keys and certificates. It establishes the norm (a baseline inventory of keys and certificates) and provides rapid anomaly detection along with dynamic response technology to remediate attacks. Furthermore, Venafi’s platform allows an enterprise to quickly and securely revoke anomalous keys and certificates that are associated with APTs or unknown machines/devices, and rapidly enroll and provision new ones, regardless of how often.

For your growing digital footprint to remain trustworthy, your organization’s move toward a people-and information-centric security strategy must include the protection of keys and certificates. The success of your security strategy depends upon your ability to comprehensively cover 100% of your attack-vector surface, and allowing for rapid detection and response in all areas.

And now is the time to begin securing and protecting this trust in your infrastructure because the larger infrastructure grows, the longer it takes to initially control and secure. By creating a strong program to control and secure digital trust today, you place your business in an ideal position to confidently expand its digital footprint and maximize its value to the business tomorrow. Bring it on, 2020.

<![CDATA[Controlling the Wild West of Mobile ]]> http://www.venafi.com/blog/post/controlling-the-wild-west-of-mobile http://www.venafi.com/blog/post/controlling-the-wild-west-of-mobile/#When:17:00:00Z Mobile. It’s the new normal. Never in the history of the world has a technology changed the way we work, live, and play in such a short period of time.

Think back 20 years. In 1993, we faxed important documents, checked answering machines, paid bills with paper checks, dialed 411 to find a number we needed, tuned into the local TV news at 6:20 p.m. to get the weather forecast, and took our roll of film to the local pharmacy to be developed. And astonishingly enough, back in my day growing up near Boston, we even called each other on landline phones to talk about the great deal we got that day on the new Nirvana “Nevermind” CD at Strawberries (sadly, a now long-defunct local music and cassette tape retailer).

Today, we can complete all these tasks (and much, MUCH more) on our smartphones and tablets. And we can perform all these tasks without uttering a single word.

This explosion of mobile technology makes us more productive than ever, yet conversely, keeps cyber-criminals very busy. We find ourselves in a “Wild West” period for mobile technology: opportunity abounds amongst danger at every turn. It’s estimated that by the end of 2013, nearly 90,000 new strains of mobile malware will have been released, and that figure will quadruple to over 403,000 new strains by the end of 2014.  Clearly, the convenience of mobile technology comes complete with an unprecedented, exploding new threat surface, which must be secured and protected.

Over the last decade, a multi-billion dollar market has emerged around mobile security. The mobile security market is expected to total approximately $1.88 billion by the end of 2013 and to grow to $2.9 billion by 2017. Nearly all, major enterprise security solution vendors provide products and services that address threats to mobile communications, productivity, and commerce.

Among these solutions, Mobile Device Management (MDM) has emerged as a “must-have” for many organizations. MDM vendors promote easy-to-implement solutions, which secure mobility without interfering with users’ experience. Most solutions, such as those from Citrix and Zenprise, offer some type of “top 10 must-haves” for secure enterprise mobility.

In an effort to create a more secure mobile enterprise, MDM solutions integrate with mobile certificate authorities (CAs), simplifying the process of requesting and receiving certificates to secure mobile communications. Today, most companies issue multiple certificates to authenticate users, devices, applications, and virtual private networks (VPNs) to the corporate network.


Cyber-attackers exploit weak certificates to exist in mobile environments

The use of mobile certificates is growing, and the attack surface is growing along with it. Without a good understanding of your legitimate mobile certificate inventory, you allow glaring weaknesses to exist in your mobile environment, including orphaned certificates, fraudulent certificates, and weak-crypto certificates. Cyber-attackers can easily detect and exploit these weaknesses.

Mobile and user certificates must be secured and protected as aggressively as any other part of the infrastructure. At a high-level, to effectively secure and protect mobile trust, enterprises need to:

  • Prevent mobile certificates from being misused
  • Detect mobile certificate anomalies
  • Respond with immediate remediation when a threat is detected

mobile trust

Securing and Protecting Mobile Certificate = “Mobile Trust”

Take the common case of a user losing a smartphone: The resolution policy is typically to remotely wipe the smartphone via the MDM and issue a new one. However, a remote wipe alone doesn’t guarantee that your organization is safe from attack. All certificates on that lost smartphone can be copied and manipulated. And if the certificates associated with that user are not immediately revoked, you have a hidden vulnerability. Multiply the number of employees by the average number of devices and certificates each employee has, and you can see how an organization’s risk can spiral out of control. Having a “kill switch” not only for the device but also for ALL certificates ON the device is paramount to success.

Adding the security and protection of mobile certificates to your mobile security strategy slams the door on a wide-reaching component of the mobile attack surface. As with traditional infrastructure, there is no silver bullet for mobile security. But controlling which mobile users and devices you can and cannot trust is a good first step and can be completed today. It took more than 100 years for the Wild West to be won. Let’s work together to ensure it doesn’t take that long to better secure mobile ecosystem.

<![CDATA[The Demise of 1024-bit Certificates]]> http://www.venafi.com/blog/post/the-demise-of-1024-bit-certificates http://www.venafi.com/blog/post/the-demise-of-1024-bit-certificates/#When:16:00:00Z Nearly everyone understands the need to use data encryption to protect data both in transit and at rest, but I have found that there is some confusion about the strength of the key that is used to encrypt that data. Some of this confusion is in part due to the fact that we have been warned for so long that certain keys and certificates are not strong enough, yet organizations that issue these certificates continue to allow us to acquire these weak encryption assets. This practice reminds me of the proverb of the boy who cried wolf. For nearly four years, the U.S. National Institute of Standards and Technology (NIST) has been telling us that we should be using 2048-bit keys, but we have collectively ignored those warnings. Now that the requirement to use 2048-bit certificates is upon us, many are decrying the fact that this requirement is being foisted upon the industry without much warning. These people are forgetting that we have grown complacent with the constant warning cries—much like the people who ignored the boy crying wolf. Now that the danger is upon us, we are caught unaware and unprepared.

Briefcase lock three digit

What’s the big deal anyway? Hackers may be able to use the increasing computational power available—either on their physical hardware or through renting cloud computing hours—to overcome the encryption strength of algorithms and key sizes that were once deemed sufficient. A few years ago, a “brute force” attack that cracked an encryption algorithm was unthinkable, but such an attack is fast approaching the horizon of reality. In a brute force attack, a machine systematically tries all possible encryption combinations in an attempt to crack open the data. To understand how a simple brute attack works, think of an old-fashioned, three-digit briefcase lock. If you wanted to, you could try rotating the wheels in a systematic fashion until you stumbled across the right combination to open the lock. You may discover the right combination of digits on the first try, or the hundredth, or the last possible combination, but you will discover the combination sooner or later.

According to Moore’s Law, computational power doubles roughly every 18-24 months. This means that a key strength that was adequate a few years ago is rapidly reaching obsolescence at an ever increasing rate. And if quantum computing evolves and makes its way to the masses, encryption algorithms will also need to evolve to provide the strength to resist even more powerful attacks. Even encryption techniques that we feel are adequate today may be rendered useless if quantum computing continues to evolve and makes its way to the masses. Therefore, correcting a problem today—such as the move from 1024 to 2048-bit encryption—will not ensure that you will never have to do this again.


The Certificate Authority/Browser Forum (CA/B Forum) seems to have sounded the death knell for the 1024-bit certificate. The forum has instructed Certificate Authorities (CAs) to support only 2048-bit certificates and larger by the end of 2013. Responding to this requirement, many CAs stated that they would revoke all active certificates that are below 2048 bits on October 1, 2013. Other CAs have been a bit more gracious in not overtly revoking them on that day, but all have stood by the CA/B forum’s edict to require 2048-bit certificates by 1/1/2014. See the blog post titled “Gone in 60 Months” which you can read if you want additional information on this topic.

What is the result of this requirement? In short, the most visible action may be that individual Internet browsers will begin to disallow the use of certificates that are less than 2048 bits. For example, Mozilla provided an implementation timeline of December 31, 2013. “Soon after this date [December 31, 2013], Mozilla will disable the SSL and Code Signing trust bits for root certificates with RSA key sizes smaller than 2048 bits.[CA:MD5and1024]” And on September 24, 2013, Google Chrome’s team stated in a submission to the CA/B Forum that “in early 2014, Chrome will begin warning users who attempt to access sites with certificates issued by publicly-trusted CAs, that meet the Baseline Requirements' effective date, and with key sizes smaller than those specified in Appendix A [that is, less than 2048 bits].”[Upcoming changes to Google Chrome's certificate handling].

“What effect will this new requirement have on my organization?” is a question I have fielded with ever-increasing frequency. Most people ask this question with a sense of confidence, clearly thinking that there will be little or no impact. Unfortunately my experience and research have shown that this will not be the case. Even just a cursory review of some of the most common banking, retail, airline, software providers, and even government sites will yield a plethora of 1024-bit certificates.

This problem becomes even more difficult to tackle because organizations incorrectly assume that they can rely on their internal and external CAs to help them identify all their weak certificates. If the only certificates in use were those generated by a CA, then this would be a reasonable solution. However, almost any software application that we install and most hardware devices on which we rely have certificates, and a huge portion of these certificates are 1024 bits. These certificates are found in email systems, virtualization platforms, routers and switches, printers, databases, telecom equipment, and almost all other systems and devices we rely upon in our daily operations. I’m certainly not trying to be an alarmist and say that the world will come to a screeching halt on 1/1/2014 ala Y2K. There is a real possibility, however, that users may have a particularly bad experience when they access websites to transact business and they see browser warnings. Perhaps it will be the inability of network administrators may be unable to log in remotely and manage the network virtualization infrastructure or even perform simple tasks such as adjusting wireless access points.

The first step in remediating this issue is really quite simple: we must create a comprehensive inventory of all certificates on all of our devices. The second step is also relatively easy: we must continuously monitor the entire network to ensure that “weak” certificates are not introduced into the environment as new applications come online and new devices are installed. The third step is a bit more involved: we must move quickly to replace all weak certificates identified in the first step above. When more weak certificates are discovered on the network during continuous monitoring (the second step above) they must be replaced immediately. It becomes more challenging when these certificates are found on hardware devices such as printers and telecom equipment, yet no weak certificate or key should be ignored. Only with constant vigilance, until the industry from top to bottom fully complies with the requirement to use 2048 bit certificates, will we be able to eradicate these weak keys and certificates.

<![CDATA[Deciphering How Edward Snowden Breached the NSA]]> http://www.venafi.com/blog/post/deciphering-how-edward-snowden-breached-the-nsa http://www.venafi.com/blog/post/deciphering-how-edward-snowden-breached-the-nsa/#When:15:30:00Z The importance of knowing exactly how Snowden breached security by attacking trust and an open invitation to correct us

To date little real information exists publicly to explain how Edward Snowden stole secrets from one of the world’s most advanced and sophisticated intelligence organizations. Reports on “How Snowden Did It” detail little more than the obvious: he breached the National Security Agency (NSA). As experts in securing and protecting the trust established by keys and certificates, Venafi understands how Snowden accomplished this breach. To develop this understanding, Venafi security analysts have methodically analyzed public information for over 3 months, connected pieces of the puzzle based on our knowledge of attacks and vulnerability in the Global 2000, and requested peer review and feedback from industry experts.

Ironically, the blueprint and methods for Snowden's attack were well known to the NSA. The NSA had to look no further than the US’s own Stuxnet attack to understand their vulnerability. Clearly, Edward Snowden understood this. Here we describe how Venafi solved this puzzle and explain why Snowden’s actions affect not only the NSA but your organization.


Edward Snowden

If we’re wrong, we invite the NSA and Edward Snowden to correct us. NSA Director General Keith Alexander wants to promote information sharing, and now is the perfect opportunity. General Alexander stated “At the end of the day it's about people and trust” and we agree. The attacks on trust that breached the NSA are vulnerabilities in every business and government. Sharing how the breach was researched and executed is important to help every business protect its valuable intellectual property, customer data, and reputation. We believe both the NSA and Edward Snowden would agree that helping businesses and governments improve their security is a worthy cause.

Limited (read that as no) information to date has been shared publicly

Neither investigative reports nor the NSA leadership’s public statements have explained the methods Snowden used to breach the NSA’s security.

Here is what we know about Snowden’s work environment and the tools he had at his disposal:

  1. Valid access—As a contractor, Snowden was issued a valid Common Access Card (CAC). This smart card had preloaded cryptographic keys and digital certificates that authenticated his identity and provided basic trusted status and access to the information and systems he was authorized to access.
  2. SSH Keys—As a systems administrator, Snowden used Secure Shell (SSH) keys to authenticate and manage systems as a part of his everyday job. Prior to working for the NSA, Snowden is known to have tested the limits of his administrator privileges to gain unauthorized access to classified information while at his CIA post in Geneva, Switzerland.
  3. Limited computing resources—Like many external attackers, Snowden didn’t have a bay of servers, top-end Macintosh computers, or even a Windows laptop hanging off the NSA network, which is referred to as NSAnet. It’s been reported that Snowden had basic terminal or thin-client access to the NSAnet. He had much the same view an attacker might have after a successful initial intrusion or reconnaissance mission.

Piecing together the puzzle of how Snowden attacked trust to breach the NSA

Once we understood Snowden’s tools and network environment, we reviewed the information that had been reported about Snowden and identified the critical elements that would help us piece together the full story of how Snowden attacked the trust established by cryptographic keys and digital certificates to breach the NSA:

  • Snowden fabricated digital keys—In testimony to the House Permanent Select Committee on Intelligence, General Alexander explained that Snowden “fabricated digital keys” to enable his attack. “Fabricating keys” could describe creating his own digital certificates or other types of cryptographic keys such as those used for SSH access.
  • The role of keys and certificates—In the same testimony to the House Permanent Select Committee on Intelligence, Congresswoman Terri Sewell asked General Alexander to describe the role and use of digital certificates in the NSA. Because this line of questioning follows the classified briefing Alexander presented, it is highly likely that the use of certificates was discussed in the classified briefing. In the context of “fabrication” of certificates, self-signed certificates are created and issued by their maker. Self-signed certificates are common part of the cybercriminals toolkit to enable the exfiltration of data.
  • Branching out—Snowden reportedly obtained usernames and passwords from dozens of colleagues. This afforded him the opportunity to significantly extend his reach and time to gather data. When logging in with his colleagues credentials, he would also have access to their SSH keys and digital certificates. And he could also then take “fabricated” SSH keys and establish them as trusted. In all cases, and unlike passwords that are frequently required to be changed, SSH keys and digital certificates live much, much longer lives.
  • Snowden’s perfect security—Finally, Snowden has boasted that encryption provides the perfect security system. In an online Question and Answer session with The Guardian, Snowden explained: “Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on.” Snowden also claims to have encrypted his stolen data for distribution. Therefore, his use of encryption, which is enabled by SSH keys and self-signed certificates, is that much more likely and supports General Alexander’s statement that Snowden fabricated keys. Cisco, Mandiant, and other experts have long established the use of encrypted and authenticated sessions as a common cybercriminal tool to exfiltrate undetecetd. In fact, as far back as 10 years ago, Snowden was inquiring on message boards about methods to create anonymous and obfuscated connections, and even mentioned SSH as a common method.

NSA Chief Keith AlexandarGeneral Alexander summed up well Snowden’s ability to attack: “Snowden betrayed the trust and confidence we had in him. This was an individual with top secret clearance whose duty it was to administer these networks. He betrayed that confidence and stole some of our secrets.” Unfortunately it seems that like so many organizations Venafi has worked with, the NSA had no awareness and no ability to respond to these attacks on keys and certificates.

Venafi Exposes How Snowden Did It: Three Important Steps on the Kill Chain

Using military Kill Chain analysis, which Lockheed Martin and others have made popular in IT security, we can reveal how Snowden executed his theft of data from the NSA: Edward Snowden Infographic

  1. Researching the target—Snowden used his valid access (such as CAC with keys and certificates and SSH keys for system administration) to determine what information was available and where it was stored—even if he didn’t immediately have full access to that information.
  2. Initial intrusion—Snowden gained unauthorized access to other administrative SSH keys and inserted his own to gain full, trusted status to information he was not authorized to access. Using usernames and passwords from colleagues could afford him more opportunities to take keys or insert his own as trusted. Having “root” or equivalent administrative status gave Snowden total access to all data. Just like an advanced and persistent attacker, he took care not to set off alarms and covered his tracks.
  3. Exfiltration—To get data off the NSAnet, he could not simply save it to a flash drive. Instead data needed to be moved across networks and under the radar to evade detection. Just like common cybercriminals, Snowden used Command and Control servers to receive encrypted data sessions. These sessions were authenticated with self-signed certificates.

> View the Breaching the NSA Infographic

Everything’s already been seen in the wild

You might think that only advanced cyber teams in the NSA have the knowledge and skill to fabricate self-signed certificates or use unauthorized SSH keys to exfiltrate data. However, all of these attacks have been reported publicly in the wild. Cyber-criminals have used them to launch successful attacks and will continue to use them. In fact, Snowden was in many ways just following the methods and means the NSA had already used successfully.

Evolution of Cyberattacks InfographicIn one of the first and most powerful demonstration of what attacking the trust established by keys and certificates can accomplish, the NSA is reported to have helped carry out the Stuxnet attacks on Iranian nuclear facilities. Using stolen digital certificates from unknowing Taiwanese companies, the architects of Stuxnet, identified by Snowden to include the NSA, were able to launch the Stuxnet attacks with trusted status. These and other attacks provided Snowden a blueprint for attack: compromise the trust established by keys and digital certificates.

More specifically to the NSA Breach, attackers used SSH key stealing Trojans to gain unauthorized access to SSH keys and have unfettered access to the FreeBSD source code for more than a month. As a system administrator, Snowden didn’t need to use Trojans to steal or create his own SSH keys.

Mandiant reported that the APT1 attackers generated self-signed certificates to enable their command and control servers to receive cloaked, encrypted stolen data. These certificates went completely undetected as being rogue—purporting to be from IBM or Google or for use with “webserver” or “alpha server.” Freely available tools such as OpenSSL would allow Snowden to create self-signed certificates on demand.

The gap that’s allowed cyber-criminals to breach these and other organizations is why Forrester Consulting described the situation in simple, blunt terms: “Basically, the enterprise is a sitting duck.”

Every enterprise is an NSA breach waiting to happen

Ponemon Institute Cost of Failed Trust ReportJust like the NSA, most enterprises have little to no awareness of the keys and certificates used to create trust—the authentication, integrity, and privacy on which almost all IT security is built. In fact, the Ponemon Institute surveyed 2,300 large organizations and reported that these organizations have, on average, more than 17,000 keys and certificates in their core infrastructure alone. This number doesn’t include mobile apps or the SSH keys that administrators use to access systems. Ponemon also reported that 51% of organizations don’t know where and how these keys and certificates are used. And industry experts agree, this number is grossly underreported.

All these facts clearly applied to the NSA before Snowden breached the agency’s security and stole data. The NSA had no awareness of the keys and certificates in use, no ability to detect anomalies, and no ability to respond to an attack. Because of these deficiencies, General Alexander believes strongly that the NSA must use automated machine intelligence to improve its ability to detect and respond to threats:

“What we’re in the process of doing—not fast enough—is reducing our system administrators by about 90 percent. What we’ve done is put people in the loop of transferring data, securing networks and doing things that machines are probably better at doing.”

The NSA is already setting out on the path Gartner expects most organizations to reach by 2020 or sooner: reallocating spending to focus on detection and remediation of security issues using fast, automated security systems. This trend will create a tectonic shift in IT security, putting almost two-thirds of IT security’s budget into detection and remediation, up from less than 10 percent today. Forrester Research - Attacks on Trust: The Cybercriminal's New Weapon

But, the game won’t be over if these detection and remediation efforts don’t include securing and protecting the keys and certificates that provide the foundation of trust in the modern world. Therefore, the NSA would be well advised to take Forrester Consulting’s advice:

“Advanced threat detection provides an important layer of protection but is not a substitute for securing keys and certificates that can provide an attacker trusted status that evades detection.” Of course, Edward Snowden knew this. Unfortunately, the NSA did not.

Want to learn more about this problem and the strategies that can help an organization secure and protect its data?

<![CDATA[Infographic: How Snowden Breached the NSA]]> http://www.venafi.com/blog/post/edward-snowden-breaching-the-nsa-infographic http://www.venafi.com/blog/post/edward-snowden-breaching-the-nsa-infographic/#When:14:00:00Z How Edward Snowden did it and is your enterprise next?

There’s one secret that's still lurking at the NSA: How did Edward Snowden breach the world’s most sophisticated IT security organization? This secret has as much to do with the NSA as it does with your organization. In this exclusive infographic, Venafi breaks open how Edward Snowden breached the NSA. Venafi is sharing this information and challenges the NSA or Edward Snowden to provide more information so that enterprises around the world can secure their systems and valuable data.


NSA Director General Keith Alexander summed up well Snowden’s attack: “Snowden betrayed the trust and confidence we had in him.” The attack on trust, the trust that’s established by cryptographic keys and digital certificates, is what left the NSA unable to detect or respond. From SSH keys to self-signed certificates, every enterprise is vulnerable. This exclusive infographic provides you with the analysis needed to understand the breach and how it could impact you and your organization.

Edward Snowden Infographic

Download Infographic (JPG)

Learn more about how Edward Snowden compromised the NSA.

<![CDATA[Broken Trust – Exposing the Malicious Use of Digital Certificates and Cryptographic Keys]]> http://www.venafi.com/blog/post/broken-trust http://www.venafi.com/blog/post/broken-trust/#When:15:30:00Z Digital certificates and cryptographic keys are interwoven into our everyday lives. Think about it: from accessing the Wi-Fi hotspot at your local coffee shop to flying across the county in a new Boeing 737, keys and certificates are entwined into the very fabric of cyber-space. They help to authenticate and secure person-to-machine and machine-to-machine communications—creating the foundation for secure online transactions. Data at rest or in transit is secured by keys and certificates. They establish trust.

But what happens when trust is broken? When malicious actors take advantage of trust established by keys and certificates, turn that trust against you, and use certificates and keys for nefarious gain. That’s exactly what is happening. The last few years have seen a rampant increase in the use of keys and certificates as an attack vector against organizations. It’s important to recognize cyber-criminals’ motives and techniques to understand how to better protect yourself from the onslaught of attacks on keys and certificates.

Generally, there are three types of cyber-criminals: cyber-crime actors, cyber-espionage actors, and other threat actors such as hacktivist groups. Cyber-crime actors are motivated by financial gain, whereas cyber espionage actors are driven by the collection of intellectual property (IP). Hacktivists, on the other hand, are motivated by ideologies such as religious beliefs, or political views.

iSIGHT logo

Venafi collaborated with ISIGHT Partners to highlight some examples of how reliant society is on keys and certificates, and how cyber-criminals exploit keys and certificates to gain illicit access to organizations. ISIGHT Partners provides detailed information about the different types of cyber-criminals, including:

  • Threat actor threat sources
  • Threat actor attack methodologies
  • Threat actor attack surface

What’s very evident from the research is that cyber-criminals will use any tactic they can to gain access into an organization’s network. The Broken Trust white paper includes a few case studies that show exactly how cyber-criminals use keys and certificates to their advantage, exploiting the trust keys and certificates are meant to establish. Some of the case studies include:

  • Using certificates in a spam campaign
  • Pharming
  • Using Secure Shell (SSH) to infiltrate a network and expand a user’s rights within that network
  • Using Secure Sockets Layer (SSL) to disguise communications

The alarming part is that the examples in the paper are by no means an exhaustive list. On a daily basis, news outlets report new ways cyber-criminals are taking advantage of the blind trust most organizations have in keys and certificates.


Download your copy of the Broken Trust whitepaper to learn more.

<![CDATA[SSH – Does Your “Cloud Neighbor” Have an Open Backdoor to Your Cloud App?]]> http://www.venafi.com/blog/post/ssh-an-open-backdoor-to-your-cloud-app http://www.venafi.com/blog/post/ssh-an-open-backdoor-to-your-cloud-app/#When:14:30:00Z Secure Shell (SSH) is the de facto protocol used by millions to authenticate to workloads running in the cloud and transfer data securely. Even more SSH sessions are established automatically between systems, allowing those systems to securely transfer data without human intervention. In either case, this technology underpins the security of vital network communications. According to the Ponemon Institute, organizations recognize SSH’s role in securing network communication and list threats to their SSH keys as the number one most alarming threat arising from failure to control trust in the cloud.

SSH Keys SSH authentication holds only as strong as the safeguards around the authentication tokens, the SSH keys. Failure to secure and protect these keys can compromise the environment, breaking down the trust that SSH should establish. Malicious actors take advantage of common mistakes in key management, the following are some of the common pitfalls organizations fall prey to.

The Weakest Link

Malicious actors often target SSH keys because SSH bypasses the authentication controls that typically regulate a system’s elevated privileges. In their efforts to exploit SSH, malicious actors naturally focus on compromising the weakest link in a highly secure protocol—human error and mismanagement of the private SSH keys. Ponemon_Institute_123x37 The risks are real, and so are the costs. According to the Ponemon Institute, the average U.S. organization risks losing up to $87 million per stolen SSH key.

Lack of control

Less than 50% of organizations have a clear understanding of their encryption key and certificate inventory—let alone efficient controls to provision, rotate, track, or remove SSH keys. System administrators usually deploy keys manually, with different groups managing their own independent silos, leading to a fractured, distributed system. Without centralized monitoring and automated tools, system administrators cannot secure or maintain control of keys. Amazon-Cloud-Computing-Logo A report issued by Dell SecureWorks’ Counter Threat Unit revealed that one in every five Amazon Machine Images (AMI) has unknown SSH keys, each of which represents a door into the system to which an unknown party has access. As shocking as this fact seems, it is actually not surprising when you consider the ad-hoc management practices common in many organizations. In performing their jobs, application administrators copy their host key to multiple workloads but often fail to document the locations. As employees move on to new jobs, the keys linger, and the organization loses all ability to manage and assess its systems’ exposure to unauthorized access.

Injected elevated trust

An SSH server uses public-key cryptography to validate the authenticity of the connecting host. If the server simply accepts a public key without truly validating the identity of the connecting host, however, the server could easily give an attacker elevated access. The mass assignment vulnerability, which is still largely unpatched, offers one example of an injected elevated trust exploit. In secure networks, users require root or admin privileges to append their own SSH keys to the authorized key file. Using the mass-assignment vulnerability, however, attackers create accounts that have the appropriate permissions. They then add their own SSH keys to gain the elevated privileges required to compromise the system.

Recycled rogue workloads

Cloud computing environments often reuse workloads. Amazon Web Services (AWS), for example, offers thousands of AMIs. However, you should exercise extreme caution when reusing a workload; educate yourself about the workload’s applications and configuration. In addition to rogue SSH keys, you may also find specific compromised packages. For example, earlier this year hackers compromised thousands of web servers’ SSH daemons with a rootkit. The rootkit rendered companies’ key and password rotation policies futile: the SSH daemon simply yielded the new credentials to the attackers. The SSH rootkit completely replaced the ssh-agent and sshd binaries; only reinstalling SSH completely eliminated the threat.

Best Practices

Establish a baseline

Cloud computing has proliferated the use of SSH keys, and administrative efforts have not kept pace. Yet, when you fail to understand the SSH deployment in your organization—which keys give access to which systems and who has access to those keys—you risk losing intellectual property and, worse, losing control of the workloads. Inventory the entire organization on a regular basis to discover SSH keys on workloads running in the cloud and in the datacenter. Establish a baseline of normal usage so that you easily detect any anomalous SSH behavior.

Enforce policies

Frequent credential rotation is a best practice, and you should make no exception with SSH keys. Unfortunately many organizations leave SSH keys on systems for years without any rotation. Although most cloud computing workloads are ephemeral, they are typically spun up from templates with existing SSH credentials, which are rarely rotated. Malicious actors can also crack vulnerable versions of SSH or SSH keys that use exploitable hash algorithms or weak key length. To secure your environment, enforce cryptographic encryption policies that prohibit the use of weak algorithms and key lengths, implement version control, and mandate key rotation.

Scrutinize workload templates

If you choose to use prebuilt templates, implement an assessment process before the workload is used in production. Do not simply accept a pre-built workload template created by someone you do not know. First carefully inspect the template; ensure that the applications are patched, the workload configuration is secure, and that there are no rogue applications or keys that may be used as a backdoor.

<![CDATA[Patching the Perpetual MD5 Vulnerability]]> http://www.venafi.com/blog/post/patching-the-perpetual-md5-vulnerability http://www.venafi.com/blog/post/patching-the-perpetual-md5-vulnerability/#When:20:00:00Z Earlier this month, Microsoft updated the security advisory that deprecates the use of MD5 hash algorithms for certificates issued by certification authorities (CA) in the Microsoft root certificate program. The patch has been released so that administrators can test its impact before a Microsoft Update on February 11, 2014 enforces the deprecation. This is an important move in the fight against the cyber-criminal activity that abuses the trust established by cryptographic assets like keys and certificates.

For over 17 years, cryptographers have been recommending against the use of MD5. MD5 is considered weak and insecure; an attacker can easily use an MD5 collision to forge valid digital certificates. The most well-known example of this type of attack is when attackers forged a Microsoft Windows code-signing certificate and used it to sign the Flame malware. Although the move to deprecate weak algorithms like MD5 is most certainly a step in the right direction, there still are some questions that need to be addressed.


Why is the Microsoft update important?

Cryptographers have been recommending the use of hash algorithms other than MD5 since 1996, yet Flame malware was still successful in 2012. This demonstrates that security professionals have failed to identify a vulnerability in their security strategy. However, cyber-criminals have most certainly not missed the opportunity to use cryptographic keys and digital certificates as a new way into enterprise networks. That Microsoft will soon enforce the deprecation of MD5 indicates that vendors and security professionals are starting to take note of keys and certificates as an attack vector.

hashing algorithm pie chartResearch performed by Venafi reveals that 39% of hash algorithms used by global 2000 organizations are still MD5. Such widespread use is worrying on a number of different levels as it clearly highlights that organizations either do not understand the ramifications of using weak algorithms like MD5 or that they simply have no idea that MD5 is being used in the first place. Research from the Ponemon Institute provides evidence that organizations simply don’t know that MD5 is being used—how could they when more than half of them don’t even know how many keys and certificates are in use within their networks?

What’s the impact of the security update?

Microsoft’s update is not to be taken lightly; this is probably why Microsoft has given organizations six months to test the patch. Once they have deployed the update, administrators will be able to monitor their environments for weak cryptography and take action to protect themselves from the vulnerabilities associated with MD5 hash algorithms or inadequate key sizes. Options available to administrators include the ability to block cryptographic algorithms that override operating system settings.

However, if a business has critical certificates that use MD5, enforcing such a security policy could result in system outages that may impact the business’s ability to service customer requests. For this reason, the update allows administrators to choose whether to opt-in or opt-out of each policy independently as well as to log access attempts by certificates with weak algorithms but to take no action to protect the system. The update also allows policies to be set based on certificate type such as all certificates, SSL certificates, code-signing certificates, or time stamping certificates.

Although I understand that Microsoft is allowing customers to choose how wide a net they are able to cast on MD5, the choices system administrators have when a security event is triggered should be of concern. Instead of choosing to apply the security policy to “all certificates,” some companies, out of concern for system outages, may limit the enforcement to a subset of certificate types. After all, history has shown that organizations have neglected to do anything about the known MD5 vulnerability for many years; they might easily continue to postpone the requisite changes. As a result, some companies may leave a massive open door for cyber-criminals to exploit.

Are there other weaknesses in cryptography that should concern me?

MD5 is not the only vulnerability to cryptography that should concern IT security professionals—there are many. However, I am only going to focus on a few of the most common.

1024-bit keyInsufficient key length: Since 2011 the National Institute of Standards and Technology (NIST) has deprecated encryption keys of 1024 bits or less. After December 31, 2013, the use of 1024-bit keys will be disallowed due to their insecurity. Despite this, as surveyed by Venafi, 66% of the encryption keys still used by global 2000 organizations are 1024-bit keys. Vendors and service providers like Google, Microsoft, and PayPal made the shift to 2048-bit keys earlier this year. If you have 1024-bit keys in use, now is the time to upgrade to 2048-bit keys.

Lack of visibility: majority of organizations lack visibility into or understanding of their key and certificate population. Organizations simply don’t know how many keys and certificates are in use on the network, what access they provide to critical systems, who has access to them, or how they are used. Businesses without visibility into such a critical attack vector—and with limited or no ability to respond quickly—are an attacker’s dream. To mitigate against these vulnerabilities, you must gain a complete understanding of your key and certificate population so that you know where your organization is vulnerable.

Inability to remediate: How can you defend something if you don’t know what you are defending? The lack of visibility has led to real vulnerabilities. Forrester Research found that 44% of organizations have already experienced an attack based on keys and certificates. Moreover, 60% of these businesses could not respond to the attacks, whether on SSH or SSL, within 24 hours. And the response, when unrolled, usually involves a laborious manual process that often leaves some systems unchecked.

What can I do to avoid these vulnerabilities?

To protect your business against attacks on keys and certificates, I recommend that you invest wisely in technologies that apply robust policies against the use of weak algorithms and poorly configured cryptography. At the same time, the technology should be able to detect anomalous behavior of keys and certificates and automatically respond, remediating any key- and certificate-based risks.

<![CDATA[Reading the Cyber Attacker’s Playbook from across the Field]]> http://www.venafi.com/blog/post/reading-the-cyber-attackers-playbook-from-across-the-field http://www.venafi.com/blog/post/reading-the-cyber-attackers-playbook-from-across-the-field/#When:15:30:00Z Picture this: Tom Brady and the New England Patriots offense are about to run a critical play against the Denver Broncos. A trip to the Championship Game is on the line. New England is on Denver’s 1-yard line, down by 5 points, and it’s 4th down with only 2 seconds remaining in the game. Yeah, it’s a big play.

In the huddle moments ago, Brady got the play from the sideline coaches: Power run up the middle. As Brady surveys the defense, he sees the entire Denver defense forming a brick wall at the line, in a position of strength to stop the exact play the Patriots are about to run.

Brady, as any good quarterback would, calls an audible. The New England offense quickly changes and is now showing that the quarterback will throw a pass. But Denver doesn’t move. The defense remains frozen—11 players crammed together waiting for a run. They don’t change their defensive positions.

The ball is snapped, and Brady completes a game-winning touchdown pass to a wide-open receiver—one of five wide-open receivers from which he had to choose.

This seems a bit ridiculous, doesn’t it? I mean, why would Denver NOT make the appropriate changes to defend against New England’s play change from run to pass—especially considering there’s a championship on the line?

The reality is, of course, Denver would make the change! No team would be so inept, especially at such a critical moment. And if you were coaching Denver, I’m certain you would make sure the defensive players responded to the change in the New England offense.

So why must security professionals put up with this “defensive paralysis” when so much is at stake with the information that must be protected? The battle between enterprise IT security teams, who defend against dynamically changing cyber threats, and cyber attackers, who relentlessly try to get around those defenses, is unfortunately just like this hypothetical American football scenario if the enterprise has no visibility or no way to respond to a threat.

Cyber attackers inherently move faster than the enterprise. For starters, the cyber attackers are always on the offense, leaving the enterprise no choice but to be in a constant state of response, always playing defense. Any offense has one universal advantage: The offense KNOWS what will happen next, and the defense does not. Consequently, the key to success for any defense depends upon how quickly it understands (gains visibility) and counteracts (responds to) what the offense attempts to do.

In addition to the offensive advantage, bad actors need not spend time plodding through a rigorous process to select and purchase a security solution. Unless some critical extenuating circumstance exists, justifying the need to expedite parts of the process, acquisition activities typically take upward of 6-12 months.

This process typically includes investigation meetings, presentations, demonstrations, proof-of-concepts, justification write-ups, decision meetings, contract reviews, price negotiations, executive approvals, identification of resources, training, possible hardware and software builds to support the solution, solution design meetings, installation and implementation efforts, and Quality Assurance testing. And this is the process if you HAD actually budgeted for the solution you’re trying to acquire.

All the while, cyber-criminals around the world understand this. They know you run an uphill Spartan Race in the mud with a 75-pound backpack and ankle weights. They don’t write up a business case, present it to a committee, or ask to use next year’s budget early. Nope. Their job description is this:  #1-Figure out where you have no visibility and no ability to respond. #2-Attack.

By the time you start to plan a 60-day proof-of-concept, cyber-criminals have already siphoned off a fair amount of whatever they targeted to steal from you.

Now, I’m not suggesting enterprises scrap their due diligence and acquisition process. That’s foolish. However, it is imperative that all organizations rethink how to optimize and expedite their purchasing process, especially for IT security solutions, and to do so without compromising the risk of purchasing a solution that fails to live up to the expectations promised in PowerPoint slides.

In addition to creating acquisition efficiencies to speed up your defense, you need to effectively prioritize when and where to make your next security investment. To do this, you need to completely understand how the cyber attackers view your organization, and what THEY view as your organization’s weaknesses. In essence, you must build a copy of their playbook.

Here are three initial steps you can take to catch up to cyber attackers’ offense and quickly fill in new security gaps as they occur:

1.) Understand the new, evolving and fast-growing threats.

Information about zero-day attacks, attack trends, and overall cyber-attack alerts is at your fingertips. Take full advantage of this information. Leverage the experts’ knowledge, which is posted daily on social media, along with the numerous industry quarterly and monthly reports. Reports and feeds from Mandiant, Fireeye, McAfee and even Venafi’s Threat Center cover the latest on all threats, from evolving Advanced Persistent Threats (APTs) to the alarming growth of attacks on certificates and keys.

Invite vendors to your site on a quarterly basis and ask them to educate you on the latest threats they see across their customer base. We at Venafi do this for our customers whenever they need us, and it’s very powerful. Collect and correlate all of this knowledge and maintain a comprehensive threat landscape (ThreatScape) model for your organization. Ask yourself, if my company is attacked today by one of these emerging threats, can I detect it?  Can I respond and remediate?  If the answer to any of these questions is no, you have a new gap.

Prepare to add brand new categories to your ThreatScape. Complex new attack methodologies, as we witnessed in 2011 with Stuxnet and Flame, provided the blueprint for the next-generation cyber attacks on trust we are seeing today. Now only two years later, it’s commonplace for APTs to forge, steal, and misuse certificates and keys as a general practice.

Earlier this year, Scott Charney, Microsoft Corporate Vice President of Trustworthy Computing, emphasized this in his popular keynote presentation at RSA Conference 2013 (Fast forward to 19:30 for his comments on Public Key Infrastructure [PKI] under attack).

There are many examples of trust being attacked and manipulated. These attacks range from insider methods, such as how Edward Snowden used unprotected and unsecured Secure Shell (SSH) keys to gradually elevate his privileges at the National Security Agency (NSA), to the evolution of known attacks, such as malicious browser extensions. These attacks now typically involve the silent installation of a rogue root CA certificate, allowing man-in-the-middle attacks to be more successful, while completely circumventing other security technologies designed to detect and prevent attacks.

Attacks on trust work well for cyber attackers and improve their success rate when combined with other known attack strategies. Unless securing and protecting certificates and keys are part of your evolving ThreatScape, according to Forrester, you’re a sitting duck.

2.) Improve solution decision making and purchasing efficiencies.

Again, you should never purchase a solution without solid due diligence, but the fact remains that today’s purchasing processes include a fair amount of excess. Challenge your own purchasing process every step of the way.

For example, do you really need to complete a proof-of-concept for a product that is mature and is used in production by hundreds or thousands of other companies? Proof-of-concepts are time consuming, and although many people think they are “free,” they’re actually costly because they keep internal resources from completing other responsibilities.

Instead, if a technology is already “proven” because you know it works for many other companies, why not insist the vendor simply provide references and agree to a contract that allows you to walk away if you are not satisfied?

3.) Think like the cyber attackers: Analyze where you have the LEAST “Visibility” and the LEAST “ability to respond” vs. your ThreatScape>.

This easy exercise makes it very clear where you should make your next security investments. This is your security solution priority roadmap. It’s a simple quadrant analysis to maintain, and it should be updated at least once a month based upon your understanding of your ThreatScape (see #1).

Take the fast-evolving threats against certificates and keys as an example. Certificates and keys are pervasive throughout the enterprise, from servers to laptops, tablets to phones. Pretty much the entire infrastructure relies upon certificates and keys for trust. Ponemon Institute’s research from earlier this year found that the average Global 2000 organization has more than 17,000 certificates and keys, yet 51% of the 2,300 respondents were unable to confirm how many they really have. Cyber-criminals know thatSecure Sockets Layer (SSL) is vulnerable, and they know full well that a majority of organizations do not yet secure and protect certificates and keys. In other words:  No visibility, no ability to respond. This is exactly what cyber attackers seek, and thus, Certificate and Key Protection would rank low in the ThreatScape coverage quadrant.

cyber attackers visibility and abillity

Now, if you were a cyber attacker, where would you attack?

With end-of-year, “use-or-lose” funds possibly available, you can employ this type of analysis right now to quickly understand which solution(s) address your highest priority (areas of low visibility and low ability to respond).

Bad actors around the world already perform this analysis on your organization. They actively seek to find the perfect attack formula for any target, and once they find it, they call an audible and get ready to throw the winning pass, while you stand with a defense that is blinded and unable to respond to the play. The good news here is that by gaining and continually updating your ThreatScape intelligence and by implementing a smarter acquisition and purchasing process, you may just be able to draw up a copy of the cyber attackers’ playbook from across the field and call your own audible in time to intercept that pass.

<![CDATA[Gone in 60 Months or Less]]> http://www.venafi.com/blog/post/gone-in-60-months-or-less http://www.venafi.com/blog/post/gone-in-60-months-or-less/#When:16:45:00Z Vendors enforcing a 60-month validity period will help organizations adhere to best practices

For years, cybercriminals have been taking advantage of the blind trust organizations and users place in cryptographic keys and digital certificates. Only now are vendors starting to respond to the use of keys and certificates as an attack vector.

google_chromeLast month, for example, Google announced that as of Q1 2014 Google Chrome and the Chromium browser will not accept digital certificates with a validity period of more than 60 months. Certificates with a longer validity period will be considered invalid (Deprecating support for long-lived certificates). Mozilla is considering implementing the same restrictions, however no decision has been announced yet. But are the responses from vendors enough in the constant battle against compromised keys and certificates as an attack vector?

The Certificate Authority Browser (CA/B) Forum, a volunteer organization that includes leading Certificate Authorities (CAs) and software vendors, has issued some baseline requirements for keys and certificates, which include reducing the certificate’s validity period. By 1 April 2015 CAs should not issue certificates that have a validity period greater than 39 months. The CA/B Forum makes some—very few—exceptions whereby CAs are allowed to issue certificates that have a 60-month validity period.

NISTThe National Institute of Standards and Technology (NIST) has disallowed the use of 1024-bit keys after 31 December 2013 because they are insecure. Rapid advances in computational power and cloud computing make it easy for cybercriminals to break 1024-bit keys. When a researcher from Ecole Polytechnique Fédérale de Lausanne (EPFL) in Switzerland cracked a 700-bit RSA key in 2007, he estimated that 1024-bit key lengths would be exploitable 5 to 10 years from then. Not even three years later, in 2010, researchers cracked a 1024-bit RSA key.

Last week Symantec responded to the NIST’s recommendation in a Symantec blog, stating that on 1 October 2013 Symantec will automatically revoke all certificates that have a key length of less than 2048 bits. The only exception is certificates that are set to expire before 31 December 2013. Symantec responded quickly because the company wants to help customers avoid potential disruptions to their websites and internal systems during the holiday period (Deadline to Upgrade to 2048-bit SSL Certificates? Sooner Than You Might Think).

Both the certificate’s validity period and the key’s length are paramount in any security strategy. The deprecation of vulnerable key lengths is the first step in mitigating against keys and certificates as an attack vector, but reducing the validity period of certificates is an important second step. Longer validity periods offer an inviting open door to cybercriminals who can take advantage of advances in computational power and cloud computing to launch more sophisticated attacks. No one knows when 2048-bit keys will be broken, but enforcing a 60-month validity period will help organizations adhere to best practices, rotating certificates on a regular basis and when doing so potentially replacing older certificates with ones that have better cypher strengths. Who knows, in 60 months companies may need to move to 4096-bit keys to achieve adequate security.

Symantec’s move to revoke all 1024-bit certificates with expiration dates after 31 December 2013 on the 1 October 2013 is a bold move, which is most certainly in the right direction. With such a short amount of time before the certificates become invalid, however, it will be very challenging for many organizations to replace the certificates in time. Most organizations—more than 50%–don’t have a clue how many keys and certificates they have in their inventory (Ponemon Institute Cost of Failed Trust Report). Moreover, they manage their certificate inventories manually, making it difficult to respond quickly to new guidelines or actual attacks.

Cyber-attacks continue to advance in complexity and speed and increasingly target the keys and certificates used to establish trust—from the data center to the cloud. With the advances in technology, is a 60-month, or even a 39-month, validity period for certificates short enough to reduce risk? Perhaps certificates should be ephemeral, with a lifespan of only a few seconds? Reducing the lifespan of certificates to only a few seconds may drastically limit the exploitation of certificates as an attack vector.

<![CDATA[PCI DSS 3.0 Sneak Peek]]> http://www.venafi.com/blog/post/pci-dss-3.0-sneak-peek http://www.venafi.com/blog/post/pci-dss-3.0-sneak-peek/#When:17:00:00Z The Need for Greater Flexibility and an Evolving Threatscape Put Spotlight on Keys and Certificates

The PCI Security Standard Council (SSC) recently previewed PCI DSS 3.0, the next update of the payment card standard which will be released at the North American Community Meeting in Las Vegas at the end of September. Detailed in the SSC’s highlights are a number of changes that will be important to protecting the keys and certificates used to secure payment card transactions. September’s meeting will also debut proposals for the 2014 Specific Interest Groups (SIGs), which include a key management SIG to provide more guidance for protecting the keys and certificates on which we depend for trust and privacy.

DSS 3.0 is driven by the increasingly complex threatscape targeting the entire PCI ecosystem, including attacks on keys and certificates. Forrester recently found that “there is simply a lack of visibility and control over the hundreds and thousands of keys and certificates responsible for creating the confidence and security in today’s modern world that we’ve all taken for granted.” Cybercriminals have caught on to this opportunity, as Forrester notes: “This gap enables a situation that is every attacker’s dream: 1) The enterprise has no visibility into the problem, and 2) the enterprise has no controls to respond to an attack. Basically, the enterprise is a sitting duck.”

The SSC is focusing on three themes for the PCI DSS 3.0 updates:

  • Education and awareness: Increase the understanding of the standard’s purpose and the steps organizations must take to comply with that standard
  • Flexibility: Allow more customization to help organizations implement the right controls coupled with monitoring and testing
  • Shared responsibility for security: Increase awareness of the responsibilities for securing data and the fact that there are now more access points to cardholder data, especially with the adoption of cloud services

All three themes will impact the expectations for an organization to secure and protect keys and certificates.

The following updates in PCI DSS 3.0 are of particular interest:

  • Requirement #2: Maintain an inventory of system components in scope for PCI DSS. Research has shown that enterprises have, on average, 17,000 keys and certificates. Many of these will fall in scope and need to be fully documented and maintained. Although organizations may have an awareness of the keys and certificates used on public-facing web servers, most fail to comprehend the number and use of keys and certificates on application servers, databases, load balancers, payment gateways, phone systems, printers, and much more. Organizations must consider not only X.509 certificates but also SSH keys. To keep an updated inventory, organizations will need systems that can constantly and thoroughly monitor all keys and certificates.
  • Requirement #2: Clarified that changing default passwords is required for application and service accounts as well as user accounts. Keys and certificates are stored in a variety of keystores, which may sometimes have default passphrases. Organizations need systems that can discover all keys and certificates and identify their application owners so that, at a minimum, organizations can change keystore passphrases from the default settings.
  • Requirement #3: Provided flexibility with more options for secure storage of cryptographic keys and clarified principles of split knowledge and dual control. Securing keys is just one area of increased flexibility outlined in the PCI DSS 3.0 update; however, the additional enhancements won’t be fully understood until 3.0 is available.
  • Requirement #5: Evaluate evolving malware threats for systems not commonly affected by malware. Although this update does not state exactly how organizations should detect and evaluate evolving threats, it is vitally important because cybercriminals are always trying to attack where organizations least expect those attacks. Many organizations overlook attacks on keys and certificates, but according to McAfee, in 2013 malware enabled by compromised certificates grew 10x over 2012. In February 2013, Symantec found 800 Trojans, which were designed to steal certificates, and these Trojans have been used to infect millions of computers. Self-signed certificates, used with everything from application servers to printers, pose another problem: organizations may have tens of thousands of self-signed certificates but do not have the ability to discern valid certificates from anomalous ones. Mandiant’s APT1 report found that cybercriminals had used self-signed certificates purporting to be from “IBM” or for use as “WEBSERVER” to enable their attacks and exfiltration of data. The only way to establish a baseline, detect anomalies, and evaluate new risks is to continuously monitor keys and certificates and enforce policies.
  • Requirement #8: Security considerations for authentication mechanisms such as physical security tokens, smart cards, and certificates. Since the last PCI DSS update, organizations have realized that password and one-time password authentication methods do not adequately protect their systems and data. Combined with the increased use of mobile devices and applications, certificate-based authentication has grown in popularity. In fact, Gartner noted that “certificate-based authentication can provide a high level of security, as well as a great UX.” Increased flexibility to use digital certificates for authentication will also require increased levels of monitoring and anomaly detection.

While the highlights revealed so far indicate that organizations will need to better demonstrate how they are securing and protecting keys and certificates, full details and understanding of these changes will need to wait until the SSC releases PCI DSS 3.0.

As mentioned, the other important event at the Las Vegas meeting will be the first presentation of 2014 Special Interest Group (SIG) proposals. These focused working groups will play an important role in removing ambiguities and improving controls for changing environments. One SIG that will be proposed for online voting in November is “Encryption Key Management Guidance.” If approved, the SIG’s work will likely increase the scrutiny Qualified Security Assessors (QSAs) give to analyzing how organizations are securing their certificates and keys.

Look for more updates and analysis from Venafi following the 2013 North America Community Meeting at the end of September.

<![CDATA[Evolution of Cyber Attacks Infographic]]> http://www.venafi.com/blog/post/evolution-of-cyber-attacks-infographic http://www.venafi.com/blog/post/evolution-of-cyber-attacks-infographic/#When:14:05:00Z 16 years: from viruses, worms, DDoS, advanced persistent threats, to key and certificate-based attacks

It used to be that programmers created and launched annoying but mild virus and spam malware to show the world just how brilliant they were and to gain notoriety. Today, we live in a very different world where cyber threats and attacks are recognized as significant global, political and commercial challenges with serious financial and reputational consequences. Check out the full report, A Historical Overview of the Evolving Cyberattack Landscape to see how cyberwarfare and new attacks on trust have escalated over the last 16 years.

Evolution of Cyber-attacks Infographic

<![CDATA[The Cybercriminal’s New Weapon: Insights from Forrester Research Every IT Security Team Needs to Know]]> http://www.venafi.com/blog/post/the-cybercriminals-new-weapon-insights-from-forrester-research-every-it-security-team-needs-to-know http://www.venafi.com/blog/post/the-cybercriminals-new-weapon-insights-from-forrester-research-every-it-security-team-needs-to-know/#When:14:20:00Z In the 21st century, there’s probably one certainty in life beyond death and taxes: cybercriminals will use what we’ve trusted against us. From email to online banking, cybercriminals hijack what we trust. In a new study, Forrester concludes that cybercriminals have added new weapons to their arsenal: cryptographic keys and digital certificates. And in doing so, they’ve converted what is supposed to create security and trust in to a powerful attack weapon. Download your copy of this new study, Attacks on Trust: Cybercriminal’s New Weapon to learn more.

Because of the demonstrated capabilities compromised keys and certificate provide adversaries, new security systems, like next-generation threat protection systems, prove little help in thwarting attacks since criminals take on trusted status. These conclusions echo Venafi’s analysis looking back over the last 16 years of weaponization by the cybercriminal community.

Forrester’s study identifies new insights including:

  • How spending on keys and certificates ranks compared to other data security initiatives
  • How advanced threat protection (APT) investments are being prioritized
  • What is the impact to organizations by attacks on trust and are enterprises concerned

Forrester finds that:

“There is simply a lack of visibility and control over the hundreds and thousands of keys and certificates responsible for creating the confidence and security in today’s modern world that we’ve all taken for granted.”

And the problem is of our doing.

“The risk established by this gap wouldn’t be tolerated elsewhere today. No CISO could consider having tens of thousands of unknown network ports open and have no way to control them.”

How serious is the problem then? Forrester concludes that it’s one of the most serious facing enterprises today:

“This gap enables a situation that is every attacker’s dream: 1) The enterprise has no visibility into the problem, and 2) the enterprise has no controls to respond to an attack. Basically, the enterprise is a sitting duck.”

How can IT security teams can fight back against an “attacker’s dream” that leaves every enterprise a “sitting duck?” Forrester recommends 4 goals enterprise should and can achieve. Getting these right is important today, but Forrester believes even more important in the future:

“As cloud services and user mobility increase, there will be new and expanding use cases for cryptographic keys and digital certificates. With this increased dependency, the surface area of attack for every government and business also increases. Your future — the trust in and control over your cloud services, mobile devices, and data — depends upon on how you secure keys and certificates.”

Download your copy of this new study, Attacks on Trust: Cybercriminal’s New Weapon to learn more.

<![CDATA[Black Hat 2013 Briefings Day 2 Report]]> http://www.venafi.com/blog/post/black-hat-2013-briefings-day-2-report http://www.venafi.com/blog/post/black-hat-2013-briefings-day-2-report/#When:14:30:00Z The last day of briefings at Black Hat 2013 was full of new attacks that every enterprise needs to be aware of. The attacks on the trust that’s established by keys, certificates, and underlying cryptography displayed at Black Hat is both a recognition of the cybercriminal focus and their importance to everyday life.

While salacious and headline grabbing, one of most important sessions this year was Cryptopocalypse. The presenters from iSEC Partners detailed how academic advancement in mathematics have accelerated and new breakthroughs could happen any day that lead to the ability to factor RSA keys at key lengths thought adequate today. As an example, the panel presented how the

The presenters used humor to make an important point, saying:

It’s been 40 years since many of the asymmetric cryptographic innovations we depend on everyday were made and guidance to move on is almost a decade old itself. When the NSA released Suite B cryptographic recommendations, they decided not to include the RSA algorithms, indicating the US government should make preparations to move away from RSA. It’s likely a good time for enterprises to review the recommendations.

The NIST guidance on CA Compromise provides a good set of detailed recommendations to prepare organization for dealing with compromised certificates –whether due to an attack on a CA or when particular cryptographic methods can no longer be trusted.

<![CDATA[Black Hat 2013 Briefings Day 1 Report]]> http://www.venafi.com/blog/post/black-hat-2013-briefings-day-1-report http://www.venafi.com/blog/post/black-hat-2013-briefings-day-1-report/#When:13:00:00Z The first day of Black Hat was all about the opening keynote: NSA Director General Keith Alexander’s opening stirred emotions but also shared some new insights in to NSA operations.

Most interesting for me was the screenshot of the analyst’s user interface to the NSA’ phone metadata. Looking very Windows 3.11ish, the small screen shot shows how you can search for calls and the data that’s returned back.


Beyond the keynote, there were a number of great briefings. Topping the list was the very serious, but at times comical view, in to the FBI’s programs to identify malicious insiders by the agency’s former CISO Patrick Reidy.







The FBI learned that looking for insiders could not be performed by merely looking for anomalous behavior outside the norm of the entire user community. Instead, data must be normalized and analysis considered in context of the individual. The use of analytics and recommendations on normalizing data are great lessons for everyone looking to use big data to detect threats.





Day one also revealed that attacks on SSL and TLS are possible even without access to a server’s master asymmetric keypair. Using session tickets symmetric sessions keys are stored to create a stateless environment for encryption. While reducing server demands, it means TLS sessions could be decrypted without a server’s private.





While the attack tool demonstrated and released to attendees required server access and memory dumping, something that attackers are capable of pulling off, enterprises need to understand the constantly changing use of keys and certificates. This is especially true as the shift to elastic public and private cloud computing moves in to higher gear and developers are now making security decisions outside the domain of IT security.

<![CDATA[Happy Birthday Black Hat – 16 Years of Attacks]]> http://www.venafi.com/blog/post/happy-birthday-black-hat-16-years-of-attacks http://www.venafi.com/blog/post/happy-birthday-black-hat-16-years-of-attacks/#When:14:00:00Z This year Black Hat turns 16. In honor of its longevity, we’ve produced a new report that chronicles the evolution of cyberattacks and methods over the past 16 years. Looking back, the cyberattacks have used every weapon in their arsenal from malware, to Trojans. The tactics, targets, motives and identities of cybercriminals have changed substantially during this period, and we take a look at how what began as a way for computer geeks to gain notoriety has become a worldwide industry with far-reaching national defense and economic ramifications. The attacks have become increasingly nefarious, complex and frequent.

The graphic below highlights the evolution of cyberattacks since 1997, the year Black Hat launched. As IT footprints have expanded, so too have the type and variety of attacks, forcing all IT-dependent organizations to contend with diminished trust.


In addition to chronicling the evolution of cyberattacks, the piece also discusses intelligence trends that can help readers shape effective cyber-defense strategies, as well as a few tricks that have not changed much over the years. The means by which digital smart weapons are guided into their targets and authenticate within target networks has, however, changed dramatically. One of the most dramatic developments is the corruption and weaponization of online trust, established by digital certificates and cryptographic keys.

As business and government have responded, our reliance on cryptographic keys and certificates has increased. Yet the criminals have turned our strength against us, using digital certificates and cryptographic keys—the fundamental components for digital security and trust—to compromise systems, trick people, and gain access to sensitive data. And why not? Keys and certificates are the perfect vehicle for exploitation.


According to McAfee, last year alone malware signed by stolen digital keys grew by a factor of ten as criminals took advantage of the difficulty of detecting and responding to compromised keys and certificates. Most organizations are not able to identify an attack until after the fact, they cannot respond to an attack, and most have failed to deploy effective controls that can stop cybercriminals from attacking either of these technologies.

As global enterprises and government agencies continue to expand their digital presence by connecting literally everything to the Internet, the size of their attack surface will grow, opening up more opportunities for cybercriminals.

Access the full report here and stop by and see us in Las Vegas at the Black Hat show next week. We’ll be at booth #333.

<![CDATA[Self-Signed Certificates-What’s the concern?]]> http://www.venafi.com/blog/post/self-signed-certificates-what-is-the-concern http://www.venafi.com/blog/post/self-signed-certificates-what-is-the-concern/#When:20:00:00Z Because most advanced persistent threats (APTs) succeed when someone makes an innocent error—clicks that link, runs that Java application—you’re probably looking for ways to train employees to see through common ruses. But if your organisation is like most others, it has thousands of assets that are working just as hard training employees to not let the hackers in.

What are these assets that can work against you? Self-signed certificates.

Many organizations face a common challenge and frequently ask the question – why should we treat self-signed certificates in the same manner as we do other types?

Do organizations address any other security controls the way they do self-signed certificates – No visibility and No controls?

Certificates are used to secure and authenticate communications, yet organizations are doing nothing to keep it that way. Over 50% of organizations are not even aware of the number of keys and certificates used within their own environments. For any opportunistic cybercriminal, this is the perfect attack vector.

What self-signed certificates do in your environment

CA-signed certificates call on a trusted third-party to testify that, for example, a web server really belongs to your bank and not a hacker phishing for your account. A self-signed certificate, on the other hand, presents itself without any outside stamp of approval, relying on users to click past a warning to accept it.

Organizations deploy these certificates extensively on embedded web servers in printers and in network devices or perhaps even on internal-facing applications. Just like CA-signed certificates, self-signed certificates serve the important purpose of authenticating and securing communications—with the seeming added bonus of costing nothing and being easy to generate or even coming pre-installed.

Limited visibility

A Venafi customer performed a discovery and uncovered 87,000 records.

Of these records 63,664 self-signed certificates were discovered.

  • {"key":"Hewlett-Packard Company","value":47894},
  • {"key":"International Business Machines Corp","value":10360},
  • {"key":" VMware Inc.,","value":4360},
  • {"key":" Dell Inc.","value"::1050},

Upon running a query Venafi uncovered ‘nine’ instances of a certificate introduced on October 3rd 2003, due to expire on October 2nd 2013. The organization was unaware of the certificate's location, or how it was being used.

A wolf in sheep’s clothing

Self-signed certificates provide the perfect cover for advanced threats. In fact, the Mandiant APT1 report shows attackers used self-signed certificates, such as certificates purporting to be from “IBM” or for use as “WEBMAIL,” “EMAIL,” “"SERVER,” or “"ALPHA,” for control and control (C&C) cover

Consider a typical day for employees, whether normal users or IT administrators. Administrators might need to access an administrative console, so they click past a familiar security warning from the embedded self-signed certificate. Or users need to download and run a Java applet to offload processing from an older embedded web server. Again, they must click through a certificate warning.

The self-signed certificates become the boy who cried wolf, raising so many warnings during normal operations that users notice nothing suspicious when a hacker redirects them to a fake printer or network device. Similarly, users may click through Java security warnings and download and run a malicious Java applet on their machine. Many modern web threats silently hijack the browser, so the certificate warning might give users their only chance to save their machine from compromise. Instead, given nothing but a warning that looks so much like the innocent ones so long ignored, users let the hacker in.

How you can protect yourself

First, you need to realize that your organization likely has many self-signed certificates even if inventories indicate otherwise. A Venafi customer recently discovered that 63,664 of its 87,000 certificates were self-signed, and the company had no idea where those certificates were deployed.

Next, you must determine how you will counteract the bad habits that self-signed certificates are instilling in users. You might set up an internal CA and replace self-signed certificates with certificates signed by it. You might keep the self-signed certificates, but monitor their use more closely, training employees to recognize the certificates that truly belong to their appliances and applications.

In any case, ongoing visibility into and control over your certificate deployment, combined with enforcement of best practices, will provide your primary line of defense—helping employees recognize a wolf when they see one.

<![CDATA[SSH Keys - Improved Security Controls or Improved Protocol?]]> http://www.venafi.com/blog/post/ssh-keys-improved-security-controls-or-improved-protocol http://www.venafi.com/blog/post/ssh-keys-improved-security-controls-or-improved-protocol/#When:13:00:00Z As the use of Secure Shell (SSH) keys and related encryption services evolves and expands, security experts question what drives that evolution and are looking for ways to maximize the security effectiveness of the ubiquitous technology.

Recently, the Ponemon Institute found that most enterprises believe the largest security threat to their cryptographic assets is SSH key pairs, which are heavily entrenched in both data centers and cloud computing platforms. Simply put, enterprises fear attackers can easily compromise corporate access and data, thanks to weaknesses in traditional SSH key escrow and management processes.

Read the full article on Security Week

<![CDATA[Stop Crimeware That Uses Keys and Certificates Against You]]> http://www.venafi.com/blog/post/stop-crimeware-that-uses-keys-and-certificates-against-you http://www.venafi.com/blog/post/stop-crimeware-that-uses-keys-and-certificates-against-you/#When:16:25:00Z Again and again the news breaks: bad actors have succeeded in infiltrating an organization and stealing data. How did they get in, and how did they evade detection for long periods? Increasingly often, they are using crimeware designed to steal keys and certificates.

Keys and certificates should form the foundation of every enterprise’s security. But organizations—blindly trusting in the security of keys and certificates that they do not inventory and track, let alone regulate with assigned custodians and access policies—have left the door open to bad actors, all too ready to steal a key or certificate. Stolen security assets then become weapons in the hackers’ hands. The bad actors can sign malware so that it appears legitimate, crack into cloud systems managed by SSH keys—the possibilities spin out from there. With the recent leak of the source code of the Carberp Trojan, one example of crimeware that steals keys and certificates, similar attacks will only proliferate.

To protect your organization, you need to understand bad actors’ tactics. Let’s examine a common targeted attack for infiltrating an organization. This attack is based on a spear-phishing campaign, in which a victim inadvertently installs a remote access Trojan (RAT). The hacker then ramps up the damage using the RAT to obtain more keys and greater access, burrowing past the original victim further and further into the organization’s data.

targeted attack cycle

Phase 1: The bad actor first obtains or builds the RAT and any other crimeware to be used during the attack. From this very first phase, hijacked encryption assets play a role. Typically, the bad actor digitally signs the malicious code with a fake or stolen digital key, helping the crimeware evade security solutions.

Phase 2 & 3: The hacker selects and investigates potential victims. Using information that is freely available on the Internet, the hacker designs a spear-phishing campaign with personal details to lure victims into clicking a URL or opening an attachment. Either action delivers the malicious payload, which is installed on the victim’s machine.

Phase 4: During this phase the malicious payload establishes an outbound connection back to the bad actor. In most cases, this connection is encrypted with SSL, helping attackers to evade network-based threat detection and interfering with security vendors attempting to analyze their traffic.

Phase 5: Having infiltrated the network, the bad actors expand the scope of the attack. They strengthen their foothold in the network by stealing user credentials; in particular, they seek elevated credentials like SSH keys, which can offer root access to valuable systems. Also during this phase, bad actors add further outbound connections for redundancy, as well as for providing more immediate access to systems and data flagged as high value.

Phase 6: The final phase consists of slowly extracting the data from the victim. Bad actors know to encrypt their traffic and to keep it slow, avoiding unusual behavior that might trip an event trigger.


Gain visibility: The first step in mitigating these trust-based attacks—attacks that use your trusted keys and certificates against you—is to understand your key and certificate inventory. Without clear visibility into the cryptographic credential inventory, strong control over the number and types of keys and certificates, and clear policies assigning owners to particular cryptographic credentials, an organization can do little to defend itself against these attacks.

Monitor for anomalies: Network monitoring tools can help you detect the use of suspicious SSL certificates or SSH sessions in your network. By cross-referencing a suspicious SSL certificate with the known certificate inventory—once you have gained that visibility—you can quickly determine whether the SSL traffic is legitimate or possibly part of a targeted attack. Similarly, you can detect suspicious SSH sessions that might indicate a hacker quietly expanding into your critical systems.

Respond quickly: In the event that you detect an anomaly and prove it to be malicious, you must respond quickly, limiting the scope of the damage by removing compromised credentials and replacing them with new, valid keys and certificates. Because improper removal of a certificate may impact applications’ trust chains and cause an outage, you must carefully plan and monitor the rotation of any key material. Automated deployment and verification tools not only speed the response but prevent unexpected downtime due to human errors.

Venafi Director™ is a platform that provides Enterprise Key and Certificate Management enabling organizations to gain insight and control over their keys and certificates in the datacenter, on desktops and mobile devices, and in the cloud. Director is a vendor-agnostic platform that reduces organizations’ threat surface and response time to targeted attacks with full key and certificate lifecycle control spanning across the widest range of certificate authorities (CA). The Director platform enables organizations to rapidly develop an accurate key and certificate inventory to quickly identify security risks associated with trust exploits, operational and compliance risks. Enterprises can quickly establish consistent policies and automate operations across the organization and in to the cloud. As a result, organizations can successfully prevent security breaches, eliminate unplanned outages, and achieve audit success and compliance.

<![CDATA[The High Financial Costs of Failed Trust]]> http://www.venafi.com/blog/post/the-high-financial-costs-of-failed-trust http://www.venafi.com/blog/post/the-high-financial-costs-of-failed-trust/#When:20:00:00Z Trust comes at a price. However, while IT security professionals understand this, they often treat trust as an afterthought. As a result, companies suffer the consequences in unexpected recovery costs and failed business relationships.

The financial sector takes trust very seriously; stakeholders at financial institutions never trivialize the trust their clients place in them because they know the entire value of the company rests on that trust. That same level of concern should extend throughout the business world, and the proper control of trust should form a primary component of security management. This view is validated by cutting-edge research from the Ponemon Institute, an independent center dedicated to research on data privacy, data protection and information security policy.

Read the full article on Security Week

<![CDATA[Are Your Private Keys and Digital Certificates a Risk to You?]]> http://www.venafi.com/blog/post/are-your-private-keys-and-digital-certificates-a-risk-to-you http://www.venafi.com/blog/post/are-your-private-keys-and-digital-certificates-a-risk-to-you/#When:16:05:00Z Last month I wrote about the use of digital certificates and encryption keys used nefariously against organizations. In the time it takes you read this blog, 1388 new malicious programs would have been submitted to AV-Test for analysis. With a percentage of these malicious programs stealing private keys and digital certificates, it’s imperative that you understand where and how these assets are being used within your organizations. In one month of malware analysis Symantec found over 800 samples that had been designed to steal keys and certificates. The growth rate of malware using digital keys and certificates is staggering. Compared to the growth rate of apps submitted to Apple every day, digital certificates used in malware is 5 times that – in the last year by 600%.

The question that needs to be answered, why would an attacker steal private keys and digital certificates? Simply put, to gain access to your data more easily. Signed malware with a stolen digital certificate, in many cases, will be executed without any error from operating systems. In the month that Symantec specifically tracked malware that steals encryption keys and digital certificates, the US alone accounted for more than half of all infections worldwide.

Attackers haven’t ignored Secure Shell (SSH) keys either. Stolen SSH keys are used to break into systems and expand within the network. As an organizations you should prioritize in understanding where SSH keys are being used, who has access to them or for what purpose in order to reduce your attack surface. Take for example the FreeBSD servers that were hacked late last year as a result of a stolen SSH key – which was being used by a developer. Had the SSH private key been assigned a password, the attack would probably not have been successful, or at least made more difficult.

Most organizations have been hacked at one time or another; according to FireEye, 95% are already breached. In fact, one in five global 2000 organizations expect to be compromised in the next two years due to weak or legacy cryptography. Organizations do not look at, or understand how many keys and certs—51% according to Ponemon—are in use that have access to their data. Compared to traditional network perimeter security, you would not expose external facing ports to internal only traffic with no monitoring. Why then allow keys and certificates to be used within the organization without appropriate control. Organizations need to understand where the security gaps that expose the network to exploits which take advantage of keys and certificates are?

attack surface and threat response time graph

The first thing you learn in any offensive strategy is to look for your opponents weak areas. It is no different for cyber-criminals. Organizations no longer deal with securing company data behind the proverbial four walls. With the cloud computing, employee owned device, and very soon the “internet of things", the attack surface cyber-criminals can exploit has increased exponentially. To add to the problem, organizations need to maintain control over, and respond to attacks on a global basis as employees become more mobile.

Strategies to reduce your risk

Trust but verify: The average global 2000 organization has in excess of 17,000 encryption keys that they need to deal with – most of the time manually. The first step in self-defense is to know thy self. Your organization is inept to defend itself against trust exploits if there is not a clear understanding of the encryption key and certificate inventory. One of the concepts in the Forrester Zero Trust model is that all resources should be accessed securely regardless of location. Cybercriminals can easily collect unencrypted data within the network, therefore internal data should be protected in the same manner in which external data is—encrypted. The entire encryption keys lifecycle should be securely managed with an enterprise key and certificate management solution.

Control: Nearly 60 percent of RSA 2013 survey respondents stated that they were concerned about the issuance of certificates to mobile devices outside of IT control. The same percentage of respondents were also perturbed that system administrators, who are not security experts, were responsible for encryption keys and certificates, which can result in security breaches, unplanned outages, or audit and compliance failures. Only with well-defined policies can you mitigate against this risk. By enforcing long key lengths, strong algorithms, frequent rotation of keys, along with short validity periods for certificates, can you increase your ability to reduce the threat surface.

Automate: How long would it take you to respond to an attack related to SSH key or digital certificate theft? That is, the length of time it would take your organization to replace the keys and certificates to protect the data? Sixty percent of attendees at RSA2013 said it would take one or more days to respond to an attack that took advantage of encryption keys or certificates. Only through automated processes can you respond fast enough to a compromise, and rotate out encryption keys and certs that have been compromised.

Venafi Director™ is a platform that provides Enterprise Key and Certificate Management enabling organizations to gain insight and control over their keys and certificates in the datacenter, on desktops and mobile devices, and in the cloud. Director is a vendor-agnostic platform that reduces organizations’ threat surface and response time to targeted attacks with full key and certificate lifecycle control spanning across the widest range of certificate authorities (CA). The Director platform enables organizations to rapidly develop an accurate key and certificate inventory to quickly identify security risks associated with trust exploits, operational and compliance risks. Enterprises can quickly establish consistent policies and automate operations across the organization and in to the cloud. As a result, organizations can successfully prevent security breaches, eliminate unplanned outages, and achieve audit success and compliance.

<![CDATA[Do you trust in the internet, are digital certificates the new malware?]]> http://www.venafi.com/blog/post/do-you-trust-in-the-internet-are-digital-certificates-the-new-malware http://www.venafi.com/blog/post/do-you-trust-in-the-internet-are-digital-certificates-the-new-malware/#When:18:45:00Z Organized criminals are using encryption keys and digital certificates against you on a daily basis. We’ve all come to trust that we securely communicate with websites as we go about our daily online transactions. The green address bar in our browsers gives us a sense of confidence that the transfer of information is secure. However, many times when our browsers popup with a warning that something is wrong with the website certificate, we ignore it and proceed anyway. Cryptographic keys and certificates are the core of trust in digital communication. But what happens when that trust is used for nefarious action against you?

For years now organized groups have been using encryption keys and digital certificates to steal information. Stuxnet and Flame are two commonly known examples of malware that took advantage of weaknesses in MD5 and were signed by forged certificates. Why do this? To make the malware appear as if it comes from a legitimate source. In doing so the operating system will allow the installation of the malware without any warning.

One does not even need to go to the extent to forge a certificate. It’s much easier to simply steal one to sign the malicious code. So far, for the month of April, the Common Computing Security Standards (CCSS) forum has logged sixteen legitimate digital certificates associated with malware. Doesn’t sound too bad compared to the number of nodes on the internet, right? Wrong, take into account that there is an average of 200,000 new malicious programs found every day, the problem is quite serious!

If forging or stealing a digital certificate sounds like too much work, why not setup a fake company, and deceive a public certificate authority (CA) into issuing you a legitimate certificate? That is exactly what the creators of Brazilian banking malware did. A fake company was setup to successfully dupe the CA DigiCert into issuing the nonexistent company Buster Paper Comercial Ltda with a legitimate certificate. 1

The advent of new gTLDs makes obtaining a legitimate certificate all too easy for top level domain names. These new certificates can be used for man-in-the-middle attacks. Read more on gTLD security woes.

The Mandiant APT1 report (http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf) released earlier this year showed that 100% of attacks identified were based on compromised credentials – from laptops to servers. Attackers are compromising and misusing keys and certificates used for authentication all the time. They are using keys and certificates to encrypt Command & Control traffic. It’s no surprise that every organization surveyed by the Ponemon Institute has had to respond to at least 1 attack on keys and certificates over the last 2 years.

What to do about it?

Despite the multi-layer defense in depth strategies deployed by organizations, we clearly see that targeted attacks are taking advantage of trust, breaking it down, and using it against us. We need new strategies to protect our data—the new currency.

In an effort to address the breakdown in trust, earlier this month the National Institute of Standards and Technology (NIST) released a baseline set of security controls and practices to support the secure issuance of certificates. This is specifically aimed at CAs as a result of analysis of the continuous security breaches showing “insufficient security controls being in place on the computer systems and networks at these CAs, and sometimes exacerbated by weak record keeping” (http://csrc.nist.gov/publications/drafts/nistir-7924/draft_nistir_7924.pdf).

One in five organizations expect to respond to an attack related to encryption keys and digital certificates in the next two years. Attackers are looking two things: 1) where there is little visibility of a vulnerability 2) there is little ability to respond. On average, enterprises have over 17,000 keys 3. Sixty percent of attendees at RSA2013 said it would take one or more days to respond to an attack that took advantage of encryption keys or certificates.

Trust can only be established and maintained if you have a clear understanding where your organization is vulnerable, and are able to respond to an attack—they are inevitable—with the least amount of damage. To do this you need to understand the source of the encryption keys and certificates, how they are being used, and managed.

With a clear understanding and control over your key and certificate inventory you can trust in the internet, and respond to the rise in malware that takes advantage of keys and certificates.

<![CDATA[TRUST, Can You Put a Price On It?]]> http://www.venafi.com/blog/post/trust-can-you-put-a-price-on-it http://www.venafi.com/blog/post/trust-can-you-put-a-price-on-it/#When:20:54:00Z The Ponemon Institute recently published the first-ever research on the cost of losing control of trust—that is, losing control of the cryptographic keys and digital certificates that underlie trust for all transactions in our digital age. How intertwined are these encryption assets and trust? Consider two major exploits of this year alone: the Bit9 certificate theft and the DigiCert compromise.

In both cases, hackers managed to obtain legitimate certificates to sign their malware. Their malware perfectly masqueraded as legitimate software because to users’ systems, which rely on certificates to determine whether to throw up system warnings or automatically install software, the malware was legitimate. The financial impact of such an exploit can hardly be exaggerated.

Read the full article on Security Week

<![CDATA[gTLD security woes – the breakdown of trust]]> http://www.venafi.com/blog/post/gtld-security-woes-the-breakdown-of-trust http://www.venafi.com/blog/post/gtld-security-woes-the-breakdown-of-trust/#When:19:00:00Z The recent news about the looming generic top-level domain (gTLDs) names that the Internet Corporation for Assigned Names and Numbers (ICANN) is adding has sparked mixed emotions. Dot-anything domain extensions are already being auctioned off and should be seen as early as April 23, 2013. Despite growing contention from organizations such as the CA Security Council, it seems evident that gTLDs like “.local”, “.corp”, “.internal” to name a few will probably come to pass.

There are two areas of controversy related to the proposed gTLDs that directly impact each other. The first is the impact on security, while the second is the time organizations have to respond to the new gTLDs. Organizations face instrumental challenges nowadays to reduce their threat surface, and respond to targeted attacks related to the breakdown in trust asset management like keys and certificates. Sadly many are failing, the addition of gTLDs only helps them fail faster at poor key and certificate management.

Security - the Man-in-the-Middle:

One concern over the gTLDs is with regard to a domain like “.corp” or “.local” for example. Many organizations have used these domains for internal domains. It would be very easy for an attacker to spoof one of these internal domains for an internal company website, and redirecting employee traffic to a malicious website. On a public internet connection, instead of an employee going to intranet.corp, they could very easily be sending sensitive authentication information to unknown sources that have registered wildcard “.corp” TLDs.

Man-in-the-middle attacks are nothing new. It is fairly easy for an attacker to redirect traffic via DNS to a fake website with a fraudulent certificate. The big concern over gTLDs is based on the fact that a large percentage of organizations do use generic top-level domain names internally. By ICANN making these gTLDs available for purchase it causes a duplication issue. There will be collisions on the internet from conflicting certificates issued to the same gTLDs by certificate authorities (CAs) who have issued short name certificates to organizations using these generic domain names.

For a long time CAs have been issuing short name certificates to organizations for internal use for non-fully qualified domain names. The massive risk of the new gTLDs is that an attacker can apply for a certificate from a CA for a gTLD before it is approved by ICANN. Once ICANN approves the gTLD, the attacker has a legitimate certificate to go about performing man-in-the-middle attacks.

Time is not on your side:

ICANN already started accepting applications in 2012, and expects registry agreements as soon as April 23, 2013.

The implications of the new gTLDs results in organizations having to change their internal organizational structure where they no longer use non-fully qualified domain names like “intranet.corp” to fully qualified domain names like intranet.company.com. This is no small task and can take years to fully execute.

Short name certificates that have already been issued need to be deprecated. CAs have been requested to stop issuing such certificates by Nov 1, 2015. Organizations need to move quickly to plug the security gap before it becomes an issue. One of the fastest ways would be to block the names from resolving. However this will result in unexpected behavior on corporate networks, which in tail will result in increased costs and potential downtime.

The gTLD saga once again highlights the fact that a large percentage of organizations do not know how many certificates they have.

Confirmed by the Ponemon Institute, fifty one percent of global 2000 organizations do not know how many keys and certificates are in use within their organizations. When you take into account that organizations need to understand how many short name certificates are in use within the network to close the security gap of new gTLDs, time is very short indeed.

<![CDATA[The architects of our own destruction]]> http://www.venafi.com/blog/post/the-architects-of-our-own-destruction http://www.venafi.com/blog/post/the-architects-of-our-own-destruction/#When:17:35:00Z Caesar, infrastructure, outsourcing and offshoring

I never wanted to spend my life in IT. I passed a programming exam at high school because I promised the teacher I would never return. It was the hardest 50% I ever had to work for! My passions were history and literature, and especially Latin, which I was actually quite good at. And little did I realise all these years later that the “dead” civilisation would come back to haunt me!

Learn More

<![CDATA[Keeping Trust Under Control Is the Key to IT Security]]> http://www.venafi.com/blog/post/keeping-trust-under-control-is-the-key-to-it-security http://www.venafi.com/blog/post/keeping-trust-under-control-is-the-key-to-it-security/#When:17:00:00Z Security has its foundation in trust, but trust and control over the source of trust go hand in hand. What happens when a lack of control over the technologies on which trust is built means you can no longer trust them?

Take a look, for example, at our reliance on cryptographic keys and digital certificates—technologies that were once thought of as intrinsically trustworthy. Case after case has shown how easily malicious individuals can usurp control of those technologies. Keys can be stolen and certificates forged.

Read the full article on Security Week

<![CDATA[Amazon’s CloudHSM, a step in the right direction]]> http://www.venafi.com/blog/post/amazons-cloudhsm-a-step-in-the-right-direction http://www.venafi.com/blog/post/amazons-cloudhsm-a-step-in-the-right-direction/#When:13:45:00Z Earlier this week Amazon Web Services announced their new CloudHSM offering. Essentially the service is a Luna SA appliances offered by SafeNet for each tenant, and can take at least two days to provision once ordered. The cryptographic assets are not accessible to AWS as they hold the admin credentials and the customer keeps both the HSM Admin and HSM Partition Owner credentials.

You can choose from multiple availability zones in the US East and EU West regions. The Cloud HSM is meant specifically for use in the AWS Virtual Private Cloud (VPC).

Amazon CloudHSM

Ref: AWS CloudHSM

The addition of the AWS CloudHSM is a welcome evolution in making the cloud more secure. However it still leaves many problems. In a recent publication about the “Cost of Failed Trust” by the Ponemon Institute, the average global 2000 organization has in excess of 17,000 encryption keys and certificates spread across their network. A network that spans the enterprises datacenter into virtual private clouds such as the AWS offering, and mobile devices.

Organizations need to be weary of silo management of encryption keys and certs. The Cloud HSM is only available for AWS Virtual Private Cloud workloads. Thus creating silo management of keys and certificates for your AWS deployment, your datacenter deployment and mobile devices. You need to make sure you implement a centralized key management solution in order to gain full visibility into your entire key and certificate inventory.

The only key difference whether or not you are using an HSM on-premise or the AWS CloudHSM is the location of the HSM. You still need to be able to manage your entire key and certificate inventory. The CloudHSM is not going to provide you with this.

Make sure you deploy a key and certificate management platform, that from a single pane of glass can manage the encryption keys stored within the HSM—be it AWS CloudHSM or a locally installed one. Venafi Encryption Director manages any key, any certificate, anywhere.