Digital signatures are a valuable mechanism for ensuring the software that your employees install and run is authentic and has not been altered by a third party (e.g. malware insertion). That being said, how often do you think your employees actually right-click on a file in Windows to check the digital signature values before launching an application or installer? Or even check the digital signature of an RPM downloaded on Linux?
Almost no end user even thinks of doing this, so why even bother digitally signing code? Fortunately, some platforms (execution environments) can be configured to require valid digital signatures before an application runs without requiring the user to manually check the signature.
Platforms, like Windows, will warn you if a piece of software looks suspicious, but what data is Microsoft relying upon to make that determination? Digital signatures. By default, in Windows, Microsoft is trying to perform some minimal validation on the user’s behalf. To further reduce the risk of running unauthorized or even worse, malicious software, Microsoft natively supports a feature that can be enabled called AppLocker. This feature allows an organization to whitelist certificates that organizations use for signing code, thus enabling organizations to prevent unwanted, unapproved software running in the enterprise.
But AppLocker isn’t the only game in town for reducing the risk of unwanted, unauthorized or malicious software being run in your enterprise. Several vendors use similar whitelisting techniques, including Bit9, Carbon Black, Symantec with SolidCore and others.
In practice, what this means is that your security organization could sign all authorized software packages that are deemed safe to be used with your organization’s own code signing certificate and then you can configure your execution platforms to only install/run applications signed with your code signing certificate.
Validating digital signatures before running installers, script and programs is not unique to just Microsoft and Windows. Java environments can enforce that code is signed, protecting web servers from executing unauthorized code. Of course, iOS and Android have required that any application and code run on their platform be signed from the very beginning. In addition, Microsoft also provides the ability to restrict PowerShell script execution to only those that have been digitally signed. And RedHat OpenShift environments can enforce that only signed Docker containers can be executed. There are many other ways organizations can leverage signed code to make their computing platforms safer.
Has your organization taken a hard look at all the ways available to significantly reduce the risk of unknown code execution, giving more clarity to knowing exactly what is able to run in your enterprise? As you consider which policy is best for your organization, and what is allowed to execute, how would you manage the process of signing applications, containers, scripts and installers?
If you are signing software created internally or signing software from third parties to work with your whitelisting solution, make sure you are not introducing new risk. If you are not properly managing your code signing certificates and securing private keys so that they cannot be accessed unless authorized, you could be increasing organizational risk. If you can’t control what you are signing, then enforcing the requirement for signature could actually open you up to malicious software running undetected in your environment.
This is where Venafi can help. Our CodeSign Protect solution secures the code signing process across the entire enterprise by keeping private keys in secure storage, automating and enforcing approval workflows to ensure that these keys can only be accessed for authorized usage, and providing your audit and security teams with visibility of all applications that have been digitally signed.
How well are you signing enterprise software in your organization?