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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Even though most Global 2000 organizations have taken steps to remediate Heartbleed, many have not fully remediated. Although 44% of Global 2000 organizations have replaced the private keys and reissued the certificates, they have failed to revoke the old certificates.

Remediation of Heartbleed requires the replacement of the private keys, reissuance of the certificates, and revocation of the old certificates. Failure to do so provides an opportunity for bad actors to use the old certificate to spoof the company website in phishing campaigns.

Only 2% of Global 2000 organizations have performed all of the required steps to fully remediate Heartbleed.

There could be a multitude of reasons as to why we are seeing such a low revocation rate. One theory is that most CAs are not able to handle the load of the mass revocation that is required. Another is that many organizations are hesitant to revoke certificates in fear of causing a service outage on unknown systems. This in itself is concerning.  You should know where your certificates are being used. Heartbleed has clearly highlighted the deficiencies with certificate revocation lists (CRL) and CRL distribution points (CDP) that were not designed to handle large quantities of certificate revocations.

When comparing the organizations that have correctly remediated, it would seem that discount stores took the Target breach to heart. They account for 9% that achieved full remediation of systems from the sample set.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers!

Tammy Moskites, Venafi CIO & CISO

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

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

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

Certificate Vulnerability Trending

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

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

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

Critical Certificate Alerts

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

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

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

90-day Expiration View

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

Splunk Integration—Certificate Vulnerability

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

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

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

Situation

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

Threat

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

Impact

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

Recommended Remediation

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

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

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

Additional Resources

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

PART I

Is Compliance Really Just Complacence?

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

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

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

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

Commitment to Strong Security Practices or Just Toeing the Line?

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

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

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

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

Protecting the Enterprise against Trust-Based Attacks

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

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

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

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

The first day of Black Hat was all about the opening keynote: NSA Director General Keith Alexander’s opening stirred emotions but also shared some new insights in to NSA operations.

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

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

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

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

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

The last day of briefings at Black Hat 2013 was full of new attacks that every enterprise needs to be aware of. The attacks on the trust that’s established by keys, certificates, and underlying cryptography displayed at Black Hat is both a recognition of the cybercriminal focus and their importance to everyday life.

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

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

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

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

In the 21st century, there’s probably one certainty in life beyond death and taxes: cybercriminals will use what we’ve trusted against us. From email to online banking, cybercriminals hijack what we trust. In a new study, Forrester concludes that cybercriminals have added new weapons to their arsenal: cryptographic keys and digital certificates. And in doing so, they’ve converted what is supposed to create security and trust in to a powerful attack weapon. Download your copy of this new study, Attacks on Trust: Cybercriminal’s New Weapon to learn more.

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

Forrester’s study identifies new insights including:

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

Forrester finds that:

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

And the problem is of our doing.

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

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

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

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

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

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

16 years: from viruses, worms, DDoS, advanced persistent threats, to key and certificate-based attacks

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

The Need for Greater Flexibility and an Evolving Threatscape Put Spotlight on Keys and Certificates

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

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

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

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

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

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

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

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

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

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

Vendors enforcing a 60-month validity period will help organizations adhere to best practices

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

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

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

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

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

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

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

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

Picture this: Tom Brady and the New England Patriots offense are about to run a critical play against the Denver Broncos. A trip to the Championship Game is on the line. New England is on Denver’s 1-yard line, down by 5 points, and it’s 4th down with only 2 seconds remaining in the game. Yeah, it’s a big play.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.) Improve solution decision making and purchasing efficiencies.

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

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

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

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

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

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

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

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

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

Earlier this month, Microsoft updated the security advisory that deprecates the use of MD5 hash algorithms for certificates issued by certification authorities (CA) in the Microsoft root certificate program. The patch has been released so that administrators can test its impact before a Microsoft Update on February 11, 2014 enforces the deprecation. This is an important move in the fight against the cyber-criminal activity that abuses the trust established by cryptographic assets like keys and certificates.

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

Why is the Microsoft update important?

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

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

What’s the impact of the security update?

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

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

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

Are there other weaknesses in cryptography that should concern me?

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

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

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

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

What can I do to avoid these vulnerabilities?

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

Secure Shell (SSH) is the de facto protocol used by millions to authenticate to workloads running in the cloud and transfer data securely. Even more SSH sessions are established automatically between systems, allowing those systems to securely transfer data without human intervention. In either case, this technology underpins the security of vital network communications. According to the Ponemon Institute, organizations recognize SSH’s role in securing network communication and list threats to their SSH keys as the number one most alarming threat arising from failure to control trust in the cloud.

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

The Weakest Link

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

Lack of control

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

Injected elevated trust

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

Recycled rogue workloads

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

Best Practices

Establish a baseline

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

Enforce policies

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

Scrutinize workload templates

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

Digital certificates and cryptographic keys are interwoven into our everyday lives. Think about it: from accessing the Wi-Fi hotspot at your local coffee shop to flying across the county in a new Boeing 737, keys and certificates are entwined into the very fabric of cyber-space. They help to authenticate and secure person-to-machine and machine-to-machine communications—creating the foundation for secure online transactions. Data at rest or in transit is secured by keys and certificates. They establish trust.

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

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

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

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

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

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

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

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

How Edward Snowden did it and is your enterprise next?

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

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

Download Infographic (JPG)

Learn more about how Edward Snowden compromised the NSA.

• Watch The Snowden Breach: Attack Steps & Prevention Webinar
• Read the Blog: Deciphering How Snowden Breached the NSA
• Learn How to Protect Your Organization From Snowden-style Attacks

The importance of knowing exactly how Snowden breached security by attacking trust and an open invitation to correct us

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> View the Breaching the NSA Infographic

Everything’s already been seen in the wild

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

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

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

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

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

Every enterprise is an NSA breach waiting to happen

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

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

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

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

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

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

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

• Watch The Snowden Breach: Attack Steps & Prevention Webinar
• View the Breaching the NSA Infographic
• Learn How to Protect Your Organization From Snowden-style Attacks