TRUST, Can You Put a Price On It?


The Ponemon Institute recently published the first-ever research on the cost of losing control of trust—that is, losing control of the cryptographic keys and digital certificates that underlie trust for all transactions in our digital age. How intertwined are these encryption assets and trust? Consider two major exploits of this year alone: the Bit9 certificate theft and the DigiCert compromise. In both cases, hackers managed to obtain legitimate certificates to sign their malware. Their malware perfectly masqueraded as legitimate software because to users’ systems, which rely on certificates to determine whether to throw up system warnings or automatically install software, the malware was legitimate. The financial impact of such an exploit can hardly be exaggerated.

The cyber-criminals behind these exploits understand that each cryptographic key and certificate deployed in an organization is a valuable asset ripe for exploitation. Yet according to the findings, 51 percent of organizations don’t know the most fundamental facts about their own keys and certificates: they don’t know how many keys and certificates the organization has, where they are deployed, what they are protecting, or who has access to them.

It’s not that IT security professionals are simply falling down on the job. In many organizations, policies quite properly require the deployment of keys and certificates for just about every service. As a result, the average enterprise has more than 17,000 of them. No IT staff can manage such a large volume of keys and certificates manually without errors and oversights that completely undermine the supposed value of the mission-critical security and authentication instruments. Yet more than 60 percent of global 2000 organizations do manage their encryption assets manually; we’re talking about spreadsheets that list whatever keys and certificates application admins happen to report and not much more. IT security professionals know things can’t go on like this. Like coal miners listening to the timbers creak and watching the ceilings bulge, they know disaster looms, but their reports to the surface often go unheeded by management.

Too many business executives, locked in yesterday’s security constructs of armed guards, gates and cameras, think of this issue—if they think of it at all—as an annoying management problem for IT security teams to handle. They think the organization is simply losing track of assets that remain intrinsically valuable. They fail to understand that the assets’ value is trust. Lose track of the certificates and keys, and you can no longer trust them. Their value—and the trust that makes all other IT assets valuable—simply evaporates. Worse, compromised assets become liabilities, weapons to be used against the organization.

McAfee recently learned this lesson the hard way. One of their digital certificates was revoked, trust broke down, and Mac users could no longer determine when an application could be trusted or not–to the detriment of the McAfee brand.

The average organization can expect to learn the hard way too:

• The threats are likely—One in five organizations expects failures in key and certificate management to lead to exploits and infiltrations.

• The costs will be high—The average global 2000 organization can expect an estimated $U.S. 124 million in cost exposure from a server cryptographic theft incident. And such an incident is just one of the many that could occur.

• It’s already happening—In the last 24 months, organizations have experienced at least one of these trust exploits due to their key and certificate management failures:

• IT security will continue to fall behind, especially in the cloud—The risks of manual key and certificate management will only multiply as businesses continue to seek the benefits of cloud computing.

Most cloud systems, including Amazon’s and Microsoft’s solutions, rely on SSH to establish secure channels through untrusted networks. SSH provides managers with remote root access to a server and its shell services. It also provides servers with such access to each other. This level of access lets the cloud solution do powerful things, but the more power you give admins and computer systems, the more you must trust them.

Yet SSH has no equivalent to a CA to tell systems which SSH keys to trust. IT staff must manage these trust relationships on their own. To ensure the integrity of the system, the staff should rotate keys often; Amazon Web Services recommends a 90-day period.

Already overburdened IT staff must rotate thousands of keys every 90 days. Is that going to happen? Not manually.

Trust is the foundation of all relationships: trust between admins and servers, between servers and users, between servers and other servers—and between enterprises and the markets they serve. As our world becomes more connected and more dependent on cloud and mobile technologies, CEOs, CIOs, CISOs and IT security managers must make it their top priority to maintain control over trust by managing keys and certificates. When trust is compromised, business stops.

Our hope is that the Ponemon Institute Cost of Failed Trust Report validates the many IT security professionals who already suspect the risks of losing control of trust and that the report better quantifies the costs for them. We also hope that the report motivates business and IT executives to look beyond the problem toward solutions. You can take action to guarantee the hundreds of millions of dollars at risk: make sure your organization has control over trust by implementing a full key and certificate lifecycle management solution.

Via SecurityWeek

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s