Update on Unimus security - 2022 edition

Early last year we wrote our first report on the security of Unimus releases and Unimus' code-base (available here). The report was prompted by the "SolarWinds incident", and the following questions from our user-base (you) on what the state of Unimus security was. Since last year however, many things have happened in the security industry as a whole (log4j anyone?), and we have also been working hard to improve the security of Unimus specifically as well.

We think now (since we just released the results of Unimus pentests) is the right time to do a "state of Unimus security" update for 2022.

New Security Hub

We have created a new Security Hub.

This is hosted on a completely separate server without any links to our other infrastructure to avoid the possibility of tampering with the data in case our other infrastructure components were compromised.

For now, you can find the hashes of all current production binaries, as well as instructions on how to check the hashes and code signatures of all our binaries. Security-related documents are also hosted there - you can find the results of the mentioned pentests there as well. We will be adding more to the Security Hub in the coming months.

Full offline / airgapped mode for Unimus

We are officially announcing support for full offline mode - support for running Unimus in air-gapped networks.

Even tho we have always tried to be as transparent with what Unimus sends to our licensing server and we support proxying the licensing communication, we understand that having a hard requirement on outbound connectivity from Unimus to our licensing server can be a security issue in sensitive environments.

Implementing support for full offline is a large amount of work, but we want to bring this into Unimus before the end of this year (2022). The offline mode will be available to any customer on the Unlimited License tier once ready.

Penetration testing

Like we mentioned at the start of the article - we published the results of penetration tests of the Unimus API and the web GUI earlier this week. This was the culmination of our security focus over the last year. In the lead-up to the pentests, we did multiple internal rounds of reviews and improvements to security of both our infrastructure, the build pipeline (CI/CD) and the codebase itself.

You can check out the full pentest results here. As a short summary - we are very happy with the results. A single major issue has been identified which was fixed in the 2.2.3 release, with the rest being only lower severity findings.

Code signing

In last year's report we stated that we wanted to introduce code-signing across the entire Unimus binary ecosystem. I am glad to report that this has been done, and since release 2.1.0 (August 2021), all our release binaries are fully code-signed. The Security Hub shows the commands you can use to validate the signatures.

As a side-note - on Windows you can just right-click the .exe files, and you will find the full signing chain in the "Properties" of the .exes.

Bug bounty / Security bounty program

Another area we pointed to in last year's report was the establishment of an official Security Bounty program. We worked on this over the last year, but sadly due to circumstances outside of our control, an official bounty program is not yet ready. So while we don't have any news on this front for now, we are still committed to find a way to make this happen. As soon as any progress is made, we will keep you informed.

Our infrastructure, CI/CD systems and the Unimus build pipeline

Other than the directly visible public efforts mentioned above, we have also been putting a lot of time into our internal infrastructure, our CI/CD systems and our software build pipelines.

There has been progress on many fronts in these categories, from technology (work on internal SSO systems to make sure all access controls and account management is in a single place); to monitoring, reviews and audits of our systems (periodic reviews of our infrastructure, monitoring for IoC (indicators of compromise), work on SIEM, etc.); to process improvements (our onboarding and offboarding processes to assure no accounts are left open that should be closed) - all the way to the build process of Unimus itself (we have for example implemented policies which assure that vulnerable software components (like log4j) can not be a part of our software).

The above is not a complete list at all, so if you are interested in any particular area from this section, let us know and we will gladly provide more details.

The outro

With the pentests (and all the work preceding them) now behind us, the largest time investments into security that were needed are now done. Going forward, we will however be keeping increased attention on security, and continue to promote security internally as one of the most important aspects of our software.

If you have any questions and / or comments, please post in the topic corresponding to this article on our forums.