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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

Recommendations

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.

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.

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 know 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.

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.

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.

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.

The race is on to respond and remediate by replacing 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! The Cryptopocalypse has arrived, and it's probably much sooner and worse than researchers at Black Hat 2013 dreamed of.

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 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.

But, this isn’t the first attack of keys and certificate 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 systems. Security administrators, working with application owners, can quickly, securely and easily generate new keys and certificates from one or more of the trusted CAs used by organization. TrustAuthority can then validate that new keys and certificates are in use.

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

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

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

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

Related resources:

• Live Webinar: Remediating Heartbleed Vulnerability — Register Now
• Press Release: Remediation for Heartbleed Vulnerability Requires Keys and Certificates to be Replaced
• Security Rapid Response Bulletin

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 Scheier, to Gartner’s Eric Heidt, to CloudFlare — the message is: replace keys and certificates.

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

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

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

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

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

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

Respond & Remediate Now Before It's Too Late

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

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

Related resources:

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

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

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

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

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

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

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

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

Less than 16% remediation

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

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

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

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

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

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

Take action now while you still can

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

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

Venafi customers are quickly remediating

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

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

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

Heartbleed Impact

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

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

Next-Generation Trust Protection for Next-Generation Threats

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

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

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

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

Step 1:

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

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

Step 2:

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

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

Step 3:

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

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

Step 4 – 5:

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

Step 6 – 8:

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

Step 9:

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

Contact Venafi to help accelerate your Heartbleed remediation.

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

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

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

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

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

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

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

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

Cheers!

Tammy Moskites, Venafi CISO

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

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

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

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

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

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

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

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

Download the complete research note now.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers!

Tammy Moskites, Venafi CISO

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

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

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

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

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

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

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

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

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

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

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

Related resources:

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

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

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

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

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

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

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

Related Resources:

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