This section explains the goals and non-goals of the system design. These principles guide the implementation and motivate use of existing technology. Having a clear understanding what the system is supposed to do and what not helps to establish a strict focus, without falling victim to feature creep.
We designed Threat Bus with the following principles in mind:
Plugin-Based Architecture: there are simply too many security tools out there to justify any other type of architecture. The plugin architecture enables us to incrementally add new functionality and compatibilities to Threat Bus, without having to touch code that could affect unrelated, existing features.
Modular Dependency Management: plugins are packaged individually and can be installed independently of each other. This way, a Threat Bus host system can keep the list of required dependencies small and manageable.
Community Project: Threat Bus is a free and open source project. We hope to come to a point where authors of awesome security tools can write the Threat Bus integration themselves. All contributions are welcome!
Distributed Deployments: concept-wise, Threat Bus is nothing else than a message format mapper and message passing engine. The use of distributed backbones, e.g., Kafka, enables Threat Bus to be deployed in a distributed fashion. Each Threat Bus host can install different app plugins, as long as they use the same backbone endpoint. Due to backbone plugins, the heavy lifting of message transmission can be offloaded to existing third-party tools.
- Third-Party Lock-In: Threat Bus is not meant to feature some tool over another. That is another strong reason for the plugin-based architecture. Every tool can be integrated. Neither are there any hard-coded first-class integrations nor certain conditions for commercial interoperability.