I’ve been working full-time on nzyme for three months, and I’d like to share an update on our progress. Presently, I’m reporting from my home office, though I’ve mostly been working at my new downtown office. In this initial development phase, our primary focus has been on building the infrastructure and management features.
In the upcoming development update, expect the debut of the first data analysis and alerting capabilities, so don’t forget to subscribe to stay in the loop! (Mastodon, LinkedIn, RSS)
Without further ado, let’s dive into the details and explore our progress to date!
Cluster / Distributed Model
Previous versions of nzyme were all single-node based, meaning that although you could run multiple nzyme deployments, they operated independently of one another. The upcoming version of nzyme will enable running a distributed cluster.
This offers several benefits, including:
- High availability: The service remains unaffected by the loss of an nzyme node. (if computing resources are sufficient)
- Scalability: It’s easier to scale up and down when operating multiple nodes.
- Additional detection methods: For instance, running multiple taps with Wi-Fi capture allows new features like location triangulation.
A key design objective was minimizing the overhead of operating multiple nodes. Consequently, I devised the cluster model with genuinely independent nodes, allowing any request to be sent to any node at any time. No designated “leader” node exists, and no calls must be made to specific instances. This adaptability lets you spin nodes up or down as required.
All cluster logic is housed within PostgreSQL, a product that has already addressed this issue, thus eliminating the need to create our own solution that might pose challenges for new users.
TLS for Everyone
Every connection to a web application should employ TLS encryption, regardless of whether it interacts with a public network. However, setting up TLS can be challenging, as generating or converting keys and certificates can be intricate, exasperating, and time-consuming.
With nzyme’s latest version, TLS encryption for the web interface and REST API is now mandatory, and the application will not launch without it. This is a part of our commitment to secure defaults.
To implement this, I incorporated extensive automation behind the scenes. To ensure a hassle-free experience, a self-signed certificate is generated and installed by default when creating a new nzyme cluster. Afterward, you can choose to upload your own certificate and key via a user-friendly web interface page.
The entire procedure takes no more than 60 seconds, after which the built-in HTTP server restarts, and you’re ready to go.
Encryption at Rest
Securing data at rest is a critical aspect of data protection. It’s essential to encrypt sensitive information using reliable methods to prevent unauthorized access by malicious actors. For example, storing a TLS certificate or key in plaintext poses a significant security risk. Similarly, it’s crucial to ensure encryption of sensitive configuration variables like API keys or connection strings.
The new release of nzyme brings fully transparent PGP encryption and key management features. This system seamlessly encrypts and decrypts sensitive data as needed, with no additional user setup required. Key rotation and management align with NIST SP 800-57 recommendations.
Each node has a local key for secure message exchanges between nodes, as well as a shared cluster key that is automatically and securely distributed among nodes. The cluster key, for instance, is employed to encrypt and decrypt sensitive configuration variables in the database.
Health Console
In an ideal world, software problems would self-correct, but sometimes that’s not possible, or the error’s source is beyond the control of the affected program. These situations can be frustrating, as they are often difficult to detect and debug, revealing themselves through unexplained errors or unexpected behavior.
The upcoming release of nzyme introduces the “Health Console.” This feature constantly scans for known issues or configurations in the background, alerting users about them while providing explanations and steps for resolution. Examples of alerts include clock drift due to a missing NTP configuration, expiring TLS certificates, or misconfigured tap network captures.
What’s coming next?
There is one significant piece of infrastructure work remaining: the new authentication/authorization system, which will be fully multi-tenant. You can find the design document here.
Following that, we will fully re-implement Wi-Fi functionality from previous releases. Additionally, we will introduce the first detection and asset discovery features for the Ethernet stack. At the moment, it analyzes DNS traffic, which has proven to be quite effective.
We anticipate the next development update in about four weeks. In the meantime, be sure to follow me or nzyme on Mastodon, or even LinkedIn if you prefer. Don’t forget that there is also an RSS feed for this blog.
See you soon!
