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.

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 stolen, and represents IT’s dirty little secret, which leaves known and open back doors for cyber-criminals to compromise networks.

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

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

Download Infographic (JPG)

Download the Ponemon Report

Before the Snowden breach, the average person rarely thought about encryption. Last year, however, encryption was at the forefront of everyone’s mind. People wanted to know what Edward Snowden disclosed about the National Security Agency (NSA) PRISM, how they could avoid being spied on, and how Snowden was able to compromise what’s believed to be one of the most secure networks in the world. Although not everyone has been paying attention, keys and certificates have actually been at the center of news for the last few years. Adversaries and insiders have long known how to abuse the trust established by keys and certificates and use them as the next attack vector.

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

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

Operational versus vulnerability view

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

74% have inadequate SSH security policies

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

51% are already compromised

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

A never-ending nightmare

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

Time to respond

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

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

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

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

Breached Enterprises Will Be Owned by The Mask operation for Years to Come

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

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

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

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

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

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

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

Attacking Trust: Ownership for Life

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

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

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

Mask’s Attack on Trust

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

Evading Detection With Trusted Status

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

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

Stealing trust

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

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

Changing what's trusted

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

Surveillance and monitoring today and well in to the future

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

Escaping detection: flying under the radar with encryption

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

Attackers Intent

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

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

Immediate Action: Fight Back or Be Owned

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

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

Because cyber-criminals always seem to find new ways to circumvent traditional security measures, the threat landscape is constantly changing. A McAfee Labs Threat Report in Q3 2013 revealed an alarming trend: the type of malware proliferating most rapidly is digitally signed malware on mobile devices. McAfee Labs also identified a new family of Android malware that is enabled by compromised certificates. This new malware already accounts for 24% of digitally signed malware.

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

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

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

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

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

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

I’ve been attending RSA for many years now, each year it seems to get bigger and better. This year a record breaking 28,500 attendees were in San Francisco to learn how to stop cyber-criminals in their ever increasing malicious campaigns against organizations.

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

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

Responding to an Attack

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

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

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

The Insider

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

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

Rise of a New Attack Vector

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

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

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

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

Despite many cyber-security advances over the last 20 years, well-known cyber-criminal exploits like phishing still pose pervasive threats. Phishing scams remain effective because they prey on human behavior. Until technology can better moderate human actions, some of the simplest cyber-criminal techniques—like phishing—will continue to be effective.

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

Compromised Web Server

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

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

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

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

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

Stolen Private Key

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

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

Fake Certificate

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

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

Recommendations

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

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

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

I’m certainly not what you would call an avid NCAA college basketball fan. But each March, the brilliant folks at CBS suck me in with this wonderfully hypnotic theme song for the NCAA Men’s Basketball Championship Tournament, known in the US simply as “March Madness.” I’m not alone. Tens of millions of Americans even plunk down hard-earned cash to join March Madness pools, in which they attempt to best predict the outcome of the tournament. During the 2013 March Madness tournament, American corporate office pools alone represented a mind boggling $US 3 billion in wagers.

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

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

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

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

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

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

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

SSH keys again confirmed as a favorite target for advanced attackers - how will IT security fight back?

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

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

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

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

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

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

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

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

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

Last month, ESET, a leading IT security company, published a detailed analysis of operation Windigo. This operation, active since 2011, has compromised over 25,000 Linux and Unix webservers. Cyber-criminals use these servers to steal SSH credentials, redirect visitors to malicious websites, and send millions of spam messages per day. The ESET report provides information on several components of Windigo, including Linux/Ebury, an OpenSSH backdoor used to steal payloads, SSH passwords, SSH keys, private keys, private key passphrases, and other credentials.

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

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

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

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

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

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

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

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

Your organization’s policies—or lack of policies—regarding trusted root CA certificates are exposing you to unnecessary risk. Because certificates serve as credentials for so many mission-critical transactions, attackers are constantly trying to obtain trusted certificates that can be used in targeted attacks. Systems, for their part, refer to their store of trusted root certificates to determine which certificates to trust. If a certificate is signed by a trusted CA, the system trusts the certificate. To compromise a system, therefore, an attacker simply needs to obtain a certificate that is signed by a trusted root CA—whether by tricking the CA into issuing a fraudulent certificate or by compromising the CA. Every CA that your systems trust represents a potential entry point for attackers.

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

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

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

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

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

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

Attacks on digital certificates and trusted connections drive FTC to action

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

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

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

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

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

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

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

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

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

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

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