Please stop sharing your private keys

One of the recurring themes in network security is the constant battle between security and convenience. We can summon countless examples of this – using overly simple passwords, insecurely storing credentials and neglecting encryption among many others. This is a basic trade-off that users, system administrators, security professionals and CISOs have to make every day.

This is a particularly big problem for software developers and DevOps teams who commonly opt for the convenient solution of sharing private keys between one another. DevOps teams were created with the ambition of breaking down silos between various IT teams and thus streamlining the process of software development. However, under the new urgency created by DevOps integrations, software developers may be under greater pressure to push releases out and thus share private keys to speed that process along.

DevOps teams often have a problem with key distribution. In an ideal situation, an administrator will place an order for a certificate and give the private key over to a member of the team who signs the code. However, the process can be slow and often DevOps teams will circumvent the process entirely.

Often multiple team members will need the same key in order to push a release out more quickly, and that creates problems. They’re often shared directly between team members and posted on internet-accessible sites. Soon after that those private keys become very “un”-private.

SEE ALSO: Observability and security – where are the crossover points?

Profligate key sharing disrupts the important role that code signing plays – to ensure the integrity of code. Firstly, it could mean that code is signed without proper oversight or that it is signed with vulnerabilities present within the code. When private keys are too liberally shared, it even becomes impossible to see who signed what piece of code and when.

That’s just the tip of the iceberg. In human hands, private keys are just as subject to human error as anything else. Private keys are often shared in insecure ways, leaving them open to Man-in-The-Middle (MiTM) attacks. They’re often stored insecurely and left on repositories like GitHub, leaving them open to exploitation by external attackers. Furthermore, they can easily get lost. People still lose laptops and phones all the time and when private keys are found on those lost devices, their organisation’s security is also compromised.

When dealing with malicious actors, a stolen private key can be a shortcut to the heart of an organisation. The more these keys are shared, the more opportunities there are for them to be found and exploited by malicious actors. When an attacker gets their hands on your private key, it doesn’t really matter how good your firewalls or AV engines are because they can impersonate you or peer straight into your private communications.

All of these unfortunate outcomes obviously come with the standard series of woeful results from data breaches: Productivity loss, compliance penalties, reputational damage and injuries to the bottom line.

The inherent dangers of private key sharing haven’t entirely stopped people from doing it. In fact, it is a widespread and longstanding practice, however dangerous. In 2016, one study found nearly 5 million internet-connected devices that would share and reuse private keys, an increase of 40 percent on the previous year.

In the tension between security and convenience, we regularly have to make stark choices in one direction or the other – sacrificing user experience for safety and vice versa. Solutions to the problem of private key sharing often weigh down the process.

Some use dedicated Hardware Security Modules (HSM) which is an expensive solution, as well as one that requires hands-on maintenance and needs replacing every few years. Others merely request enough keys for each developer to have their own – but this too can be expensive and add to the burden on the certificate requester.

SEE ALSO: Efficiency, Security, and ROI: Three Areas to Improve Your Large M365 Tenant Management

These downsides can be circumvented with a secure software signing solution. With that in place, developers can safely share their keys and sign code with the faith that they’re not endangering themselves or their employers.

Primarily, this will allow oversight over the use of keys within the enterprise and circumvent some of the graver sins of code signing. Administrators will be able to watch and control who has access to those keys, shutting down sharing when they deem it to be unsafe. This kind of solution can meet enterprise needs in on premise, cloud or hybrid environments.

Enterprises still deal with the conflict between security and convenience, but private keys need no longer be shared insecurely. With a solution to securely sign software keys, enterprises can quickly share keys without exposing themselves to the kinds of threats which currently face those who do so manually. Developers should be able to focus on their craft – software development. A secure software signing solution allows them the convenience of focusing on software development without sacrificing security.

The post Please stop sharing your private keys appeared first on JAXenter.