recommended reading

After Heartbleed, Is Open Source More Trouble Than It’s Worth?


Jason Thompson, formerly of Q1 Labs, is the vice president of worldwide marketing at SSH Communications Security.

Almost as long as computers have been connected, malicious actors have been out to steal sensitive data.

The long human history of encryption was first applied to the digital universe beginning with the National Bureau of Standards’ Data Encryption Standard in 1979. Two decades later, OpenSSL was created to encrypt websites and user information across the Web.

Without OpenSSL, government services facilitated via the Internet would be largely impossible. And OpenSSL is now the encryption method of choice for two-thirds of all websites.

Even though it is the default in Internet encryption, the OpenSSL project lacks the human and financial resources to address every potential issue with the software. The Heartbleed OpenSSL vulnerability occurred as a direct result of this, underscoring the serious threats that can exist if open source software is not able to keep up with modern threats.

Understanding the critical risks such vulnerabilities could pose to its security, Google re-evaluated its use of open source software and created BoringSSL, a branch of the OpenSSL project. The company had been managing over 70 patches to OpenSSL -- with even more on the horizon. This was making it difficult for Google to maintain consistency across multiple code bases and causing security concerns.

This concern is driven home by the four hackers who took up a challenge by website-security firm Cloudflare and succeeded in exploiting the Heartbleed vulnerability to steal private Secure Shell -- SSH -- security keys.

This is why an OpenSSL vulnerability can be so dangerous.

Secure Shell Implementation -- Don’t Forget the Risks

Operating quietly in the background of most government networks, the Secure Shell protocol encrypts connections and accesses the agency’s most sensitive data assets.

Keys are simply text files that can be easily uploaded to the appropriate system.

Associated with each key is an identity: either a person or machine that grants access to information assets and performs specific tasks, such as transferring a file or dropping a database, depending on the assigned authorizations. In the case of Secure Shell keys, those basic text files provide access to some of the most critical information within an agency.

Because of this broad access, Secure Shell key management is a significant security concern. In a recent report, IDC called out identity and access management, or IAM, risks within Secure Shell implementations specifically. For example, using Secure Shell keys can circumvent controls and provides only limited ability to identify and remove revoked, orphaned and unauthorized keys.

IAM control has become even more important with the spike in popularity in machine-to-machine activity.

Where Identity and Access Management Comes Up Short

Agencies use identity and access management solutions to help control access to cloud infrastructure, applications, servers, and both structured and unstructured data.

These solutions manage the identities assigned to interactive human users well -- but not so the larger number of identities assigned to the automated processes that drive much of the computing in large-scale data centers.

As nonhuman identities continue to grow, identity management won’t address the vast sum of identities present in an agency: the identities performing the majority of operations.

Machine-to-machine data transfers require a secure encrypted channel. For this reason, most of the identities that enable these processes use Secure Shell for authentication and authorization. However, holes exist in the governance of identities that use Secure Shell.

Instead of a centralized provisioning procedure, application developers, application owners and process owners may all have identity creation and assigning privileges. This often leads to a lack of proper control and oversight over creation of identities and their authorizations.

Without central management and visibility, government agencies cannot be sure how many Secure Shell identities have been created, what these identities are authorized to perform and what authorizations are in fact no longer needed.

The Point Is Not That Open Source is Bad

Open source vulnerabilities present the opportunity for government entities to reconsider how they use and manage open source technologies, both in their products and within their agencies. And that’s a good thing. The point is not that open source is bad. Rather, it is a call to action for technology leaders to take another look at the critical but oft-forgotten infrastructure their agencies are riding on, especially when it is something as ubiquitous and critical as encryption technologies like SSL or Secure Shell.

Here are important questions to consider:

  • Is the agency’s open source technology being properly monitored?
  • Can we rotate keys or update to new versions in order to rapidly respond to vulnerabilities?
  • Do we know who is creating keys within the agency?
  • Who has access to what information? Are we able to see whether someone has acted maliciously?
  • Is our open source software supported by either a vendor or internal resources, or are we relying solely on someone’s good will?

Someone Is Bound to Discover Vulnerabilities -- So Be Ready

In general, OpenSSL encrypts government websites and user information just fine.

However, someone with the appropriate skill set is bound to discover vulnerabilities in any software, and OpenSSL is no exception. The problem is that this particular software is in charge of encrypting your data. Hackers can exploit OpenSSL to steal Secure Shell keys, giving them access to your network and its sensitive data.

To protect against this kind of exploitation, industry standards for using OpenSSL and implementing Secure Shell protocol include strong identity and access management controls, centralized provisioning and visibility into who is authorized to create keys -- and for what purpose.

Adopting these standards will go a long way toward protecting critical government and user data.

(Image via wwwebmeister/

Threatwatch Alert

Thousands of cyber attacks occur each day

See the latest threats


Close [ x ] More from Nextgov

Thank you for subscribing to newsletters from
We think these reports might interest you:

  • Modernizing IT for Mission Success

    Surveying Federal and Defense Leaders on Priorities and Challenges at the Tactical Edge

  • Communicating Innovation in Federal Government

    Federal Government spending on ‘obsolete technology’ continues to increase. Supporting the twin pillars of improved digital service delivery for citizens on the one hand, and the increasingly optimized and flexible working practices for federal employees on the other, are neither easy nor inexpensive tasks. This whitepaper explores how federal agencies can leverage the value of existing agency technology assets while offering IT leaders the ability to implement the kind of employee productivity, citizen service improvements and security demanded by federal oversight.

  • Effective Ransomware Response

    This whitepaper provides an overview and understanding of ransomware and how to successfully combat it.

  • Forecasting Cloud's Future

    Conversations with Federal, State, and Local Technology Leaders on Cloud-Driven Digital Transformation

  • IT Transformation Trends: Flash Storage as a Strategic IT Asset

    MIT Technology Review: Flash Storage As a Strategic IT Asset For the first time in decades, IT leaders now consider all-flash storage as a strategic IT asset. IT has become a new operating model that enables self-service with high performance, density and resiliency. It also offers the self-service agility of the public cloud combined with the security, performance, and cost-effectiveness of a private cloud. Download this MIT Technology Review paper to learn more about how all-flash storage is transforming the data center.


When you download a report, your information may be shared with the underwriters of that document.