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

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

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

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

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

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

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

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

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

Mobile. It’s the new normal. Never in the history of the world has a technology changed the way we work, live, and play in such a short period of time.

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

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

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

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

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

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

Cyber-attackers exploit weak certificates to exist in mobile environments

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

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

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

Securing and Protecting Mobile Certificate = “Mobile Trust”

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

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

I’m pretty sure that all who read this blog will agree: traditional prevention-centric security models are becoming less and less effective each day, while conversely, people- and information-centric security models continue to advance and gain effectiveness. In a nutshell, people- and information-centric strategies begin by defining “the norm” (what is good). These strategies help companies quickly identify anomalies and then quickly respond and resolve those anomalies.

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

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

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

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

• 50 to 75 billion “devices” will be connected to the internet (compared to 8.7 billion in 2012).
• Nearly 6 billion smartphones will be in the hands of consumers (compared to 2 billion in 2010).
• The average household will own roughly 50 internet-connected devices.
• The overall size of the digital universe will reach 40,000 Exabytes or 40 trillion gigabytes (more than 5,200 gigabytes for every man, woman, and child in 2020).
• From now until 2020, the digital universe will nearly double every two years.

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

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

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

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

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

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

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

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

Mobile Device Management (MDM) solutions have served as the point of the spear in the mobile arms race. The question is, “Are they sufficient to ensure the security of your mobile environment?” MDM solutions definitely provide important capabilities such as deploying applications, securing content, wiping devices, and so on. The challenge comes in the area of mobile certificates and keys. Although MDM solutions can automatically provision certificates for mobile devices, the security and protection of mobile certificates and keys extend beyond the scope of MDM solutions.

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

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

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

Prevention

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

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

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

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

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

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

Detection

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

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

Response

• Immediately Revoke Certificates: When an employee is terminated or resigns from the company, you must be able to rapidly revoke all certificates that were issued to that employee. It’s critical to realize that wiping a device or container using your MDM solution is not sufficient because the employee could have made a copy of the certificate and key before leaving the company. Rapid revocation of all certificates, whether provisioned through an MDM solution or some other means, is paramount in these situations.

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

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

Last month I co-presented a webinar with ISIGHT Partners, a leader in cyber-threat intelligence, to discuss a white paper that exposes how keys and certificates can be used for nefarious intentions. Our purpose was to highlight some of the tactics malicious actors use and outline their profiles in relation to keys and certificates. Due to time constraints, we did not cover how most organizations expose themselves to cryptographic vulnerabilities simply because keys and certificates are viewed as an operational problem and not as a security issue that needs to be addressed immediately!

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

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

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

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

• Sign malicious code with a stolen legitimate certificate to avoid anti-virus detection
• Take advantage of inadequate procedures for issuing certificates and obtain a fake Secure Sockets Layer (SSL) certificate, which can be used in man-in-the-middle attacks
• Exploit an organization’s limited visibility into the usage of SSH to launch insider threats
• Use advances in technology to exploit legacy cryptographic technology and standards

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

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

Taking the first step

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

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

Secure configuration of cryptographic assets

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

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

Detection of anomalous key and certificate usage

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

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

Enterprises are turning to certificates to secure mobile devices, applications, and users, rather than relying on less secure authentication methods such as usernames and passwords.  Digital certificates authenticate mobile users to a growing set of applications, including the web, cloud, Virtual Private Networks (VPNs), and wireless networks secured by 802.1X, and the shift toward Bring Your Own Device (BYOD) has led to the rapid deployment of hundreds of thousands of mobile certificates.

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

Mobile device and user certificates as an emerging threat vector

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

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

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

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

IT is losing control of mobile and user certificates

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

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

• Orphaned and duplicate mobile certificates

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

• Constantly changing environments

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

• Fraudulent mobile certificates and compromised Certificate Authorities (CAs)

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

• Weak Cryptography

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

• Poor application security

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

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

Enterprises are turning to certificates to secure mobile devices, applications, and users, rather than relying on less secure authentication methods such as usernames and passwords. Digital certificates authenticate mobile users to a growing set of applications, including the web, cloud, Virtual Private Networks (VPNs), and wireless networks secured by 802.1X, and the shift toward Bring Your Own Device (BYOD) has led to the rapid deployment of hundreds of thousands of mobile certificates.

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

Mobile device and user certificates as an emerging threat vector

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

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

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

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

IT is losing control of mobile and user certificates

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

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

• Orphaned and duplicate mobile certificates

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

• Constantly changing environments

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

• Fraudulent mobile certificates and compromised Certificate Authorities (CAs)

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

• Weak Cryptography

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

• Poor application security

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

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

Threats and attacks are steadily increasing, and business executives face new challenges with trust exploits. While organizations adopt cloud computing and allow employee-owned devices onto the network, the challenge of securing company data increases exponentially. When it comes to advanced persistent threats (APTs), bad actors take advantage of every exploit to steal information, and look for the weakest link in enterprise security systems.

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

Read the full article on Security Week

Last year, Microsoft updated the security advisory that deprecates the use of MD5 hash algorithms for certificates issued by certification authorities (CA) in the Microsoft root certificate program. The patch was released so that administrators could test its impact before the Microsoft Update on February 11, 2014 enforces the deprecation. Time has run out, hopefully organizations have tested the impact of this and are ready for tomorrows update. This is a significant security update in the fight against cyber-criminal activity that abuses the trust established by cryptographic assets like keys and certificates.

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

Why is the Microsoft update important?

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

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.

Cybercriminals are moving faster than we think to weaponize the core element of trust on the Internet: digital certificates. The many fake certificates identified by Netcraft are just the tip of the iceberg. Cybercriminals are amping their attacks on trust because the results are so powerful.

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

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

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

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

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

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

Global organizations are under attack, and the attackers are more dangerous and persistent than ever. While the motivations vary, the goal of today’s cybercriminal is to become and remain trusted on targeted networks in order to gain full access to sensitive, regulated and valuable data and intellectual property, and circumvent existing controls.

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

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

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

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

Download Infographic (JPG)