Security design

This document describes how our security processes are designed.

Audience#

The audience for this document is people who stake with us that are technically inclined and curious about how we design things or people who wish to use our VaaS (Validator as a Service) platform.

Description#

We don’t do security through obscurity. In most cases, that ends up being obscurity. Therefore, we are transparent with our designs rather than hide behind promises. With both professional security experience and hands-on industry certifications, such as OSCP, you can rest assured that you’re in good hands. We’re not playing catch up with the hacker mindset - we adopted that a long time ago. We lead in this space rather than follow.

Security features#

This is a list of the things that we do to build one of the most secure staking providers out there, if not the most secure.

Hardware wallets#

We use hardware wallets for managing our staking provider. While your funds are always safe as we run a non-custodial service, the purpose is to protect the management of our staking provider itself.

Full disk encryption#

We use full disk encryption for all our servers. The purpose is to avoid leaking any data at rest, whether this is due to decommissioned hardware or theft.

File integrity monitoring#

We run file integrity monitoring services on our servers to detect any unauthorised change.

Two-factor authentication#

We employ two-factor authentication whenever this is possible. This adds a secondary protection layer as merely holding a key or a password is not enough to access our servers or accounts as the 2FA tokens are generated separately.

Network access reduced to a minimum#

The only publicly available networking is the one needed for us to be able to run our services. Everything else is dropped by default.

The proactive measures that we take:

• Firewall enabled by default.
• Shadow services. We do not open administrative interfaces to the world so it’s impossible to tell whether an administrative process even runs.

Automated assessments#

We run automated suites for auditing, hardening, and compliance testing.

Patch policy#

We keep our systems fully up to date. It is surprising how many companies out there fail to keep up with this very basic, yet very important, security aspect.

On top of pulling security updates from upstream, we also take proactive measures by using dynamic patching for the kernel (KernelCare) and critical libraries (LibraryCare). This allows us to shift specific maintenance windows to avoid disrupting the service whilst nodes are active (eligible state for Elrond), yet still, keep up with security patching.

Encrypted secrets storage#

We use Hashicorp Vault as the validator key storage and seed from Vault when a node machine is initialised. We also employ single-use tokens that automatically expire as soon as these keys are read from Vault and exported on a new validator machine.

The Elrond node service itself requires a key to be stored as plaintext on the filesystem on the server running that particular node service, hence our strict requirement for full disk encryption.

Enterprise Linux 8#

This is another design choice where we do things differently. The reason for this is that EL8 (whether Red Hat or rebuilds) have more secure defaults compared to what the vast majority of the network is using. Our machines run with SELinux in enforcing mode.

We do maintain compatibility with Ubuntu 20.04 in terms of tooling, apart from the extra features provided by EL8. However, our deployment target is EL8.

Own setup tooling#

We developed our setup tooling from scratch to avoid certain security deficiencies with the upstream setup tools for Elrond.