How Team Nimiq keeps its infrastructre secure

Telegram community member oyjc.com had the following question:
image

Which let me arise the following question: how does the Nimiq team actually secure its infrastructure and deployment to prevent attacks and possible injection of malicious code in, for example, the CDN.

‘System Virtuoso’ Curd of Team Nimiq gave insight on how they try to be always one step ahead against bad actors and possible threads.

Regarding the CDN being compromised, Curd answered the following:

If a server that is distributing code, regardless of whether native or web-based code, is compromised, that’s of course a very severe situation.

Nevertheless, it’s true that it’s harder to detect whether a web page has been compromised in contrast to a native app. For example, you could verify the signature of a native app (or its signed fingerprint) before executing it. That’s something you can’t easily do with a web-page.

However, we’re already brainstorming about a possible mitigation for this issue that’s likely to improve the security in some use cases. The idea is to deeply cache some sort of a verification provider for the most security relevant parts of the code, like the keyguard, in the browser. This provider is then responsible for loading the code after it has been successfully verified by a trusted signature. Since this provider is cached in the browser and shouldn’t be reloaded from the server again, it should be able to detect unauthorized changes in the code and refuse loading it then. The method has some obvious shortcomings, e.g. it won’t work in private mode at all, because there’s simply no cache and doesn’t surive a deletion of the cache in general. But still, it could significantly improve the security in most other cases.

Additionally, we’re also working on periodically verifiying the contents of all web servers from several independent and remote locations. The idea is to act like a regression test to ensure that all users are served the same content and to detect possible attempts to alter the code e.g. for users of a specific region. (That’s not necessarily limited to monitoring just our servers :slight_smile: )

Regarding the reliability and integrity of the infrastructure Nimiq services are hosted on Curd stated the following:

The security of the infrastructure is also a crucial point for reliability of all our services.
First of all, we’re using dedicated hardware by OVH, a cloud services provider with a very good reputation, a very decent set of features, e.g. a remarkable DDOS protection, and, last but not least, a good business relationship to us. The intuition is that it’s kind of hard to build reliable services on top of an unreliable infrastructure :grin:

Additionally, the access to the management of these servers and the running software is severly restricted and monitored. The exposed software is limited to a very basic feature set and operated in a highly controlled environment.

Concerning the integrity of the code, we’re using a deployment mechanism that requires each server to independently verify the signatures of the code that is about to be deployed. Whenever, the deployment is triggered, each server pulls the repository on its own and then firstly verifies the signatures of each commit. Secondly, it also verifies the overall integritity of the current state of the tree by checking for a validly signed tag that designates the code about to be deployed.
By creating this tag, the signer ensures that the code is thoroughly reviewed and/or tested by him- or herself and meets the requirements to be deployed. This tag basically acts like a sign-off.
For highly security critical deployments, again like the keyguard, there is also the option to expect multiple independent signatures from a set of people. These people then have to independently review and verify the code, and in particular the entire state of the tree that is going to be deployed.
In any case, the server will refuse the deployment if some of these requirements are not met and won’t update the webroot of the web server.

Besides the the high quality ecosystem the Team is trying to create, it’s also reassuring to see that also the infrastructure is carefully thought through and keeps evolving to enhance the experience and security.

2 Likes