Those Pesky Certs

Those Pesky Certs

Oh, those pesky X.509 certs. They can cause so many problems with code releases. Of all the things in cybersecurity, digital certificates are probably one of the most important elements of security, but they are possibly one of the least understood. Why? Because education around encryption tends to get past the understanding the meaning of the acronym and stop just after knowing that AES is a symmetric key method and that RSA is a public key technique.

Now researchers have found that they played a key part in the SolarWinds attack:

This article is interesting as provides a number of recommendations that can be applied into many high-risk environments:

Never store code-signing keys on developer workstations, web servers or build servers. Private keys should be kept in a FIPS 140–2 validated HSM.

This is a fundamental one. One of the main uses of a certificate is to hold the public and private key for code. When the code is built it is signed by the private key of the development company, and then the public key is held of the system where it will be installed. In this way only trusted developers will be able to install updates. For Microsoft, there is a software certificate on your machine which holds Microsoft’s public key, and when the software is installed or updated, your system will check the signature of the code. This signature is created with Microsoft’s private key. Thus, if any intruder gets into your system, and finds these keys that the developers will use, they can recompile the code with a backdoor, and then sign it with a valid key. Thus the recommendation advice you don't leave your private keys open on the system, and always protect them with hardware security module (HSM).

Segregate duties between who is authorized to sign code, who can approve the request, and who can monitor and enforce compliance with signing policies.

If you are a bank, hopefully, you will already be doing this. As a software development company, you should also apply this approach, and make sure there is a human in-between those who development, authorize and audit for code signing. If these are the same person, you are asking for trouble, as an intruder can easily become the signer and approver. The best practice is that a developer will go through a formal request process and provide evidence of their identity and the reason for the update. An authorizer will then approve this and sign the code, and where someone with an audit role will make sure that these are all tracked, and that these procedures are followed.

Define policies to limit access to code-signing keys by user, machine, location, duration, time of day, signing method or other parameters that make sense to your organization.

It seems a simple thing, but it should be a basic approach for the signing of code, and where we lock down the signing process to happen only on trusted machines. While a developer might have a test set of keys, these will not work in a production environment, and only the true signer keys will be allowed to support updates. Along with this, there can be limits to the access to the code-signing keys, and which will make sure that developers don't just push out code at any old time. For an intruder, an out-of-hours build will often be the target, as there is less chance of being detected. Certainly, a location check on the accesses is a fairly simple thing to restrict access to the keys.

Maintain an active inventory of all certificates, where they are installed, who they were issued from, and who owns them (and your domains).

These code-signing keys are your crown jewels, and a leak of the private keys can be extremely costly for a company, its partners, and customers. It seems a simple thing, but the company should have an audit log for all the signing processes and how they were used. In the many code audits I have done, I have found this to be one of the weakest areas in the process.

Control certificate issuance and approval workflows to ensure that every certificates is trusted, compliant with policy, and up-to-date.

This requires everyone in the development process to follow strict rules on how the signing process happens, and make sure that no-one can short-circuit any of the processes, as a short-circuit can mean that an intruder can perhaps issue their own trusted updates.

Regularly test your certificate re-issuance and revocation capabilities to ensure you can respond effectively to a compromise.

I can’t say more than … test, test, and test again.