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 reduces the quadratic complexity of interconnecting N tools with each another to simply supporting N independent tools. Security tools only need to how to connect with Threat Bus and are automatically integrated with every other tool that is connected to the bus.
Open Standard Formats: Threat Bus uses the STIX-2 (version 2.1) format for Indicators and Sightings. The goal is to comply with industry standards so that modern tools can integrate natively with Threat Bus with minimal message mapping overhead.
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!
Inherited Scalability: Conceptually, Threat Bus is a simple message passing engine. It inherits the scalability of its backbone. For example, using a distributed backbone like RabbitMQ allows for deploying multiple Threat Bus hosts in a scalable fashion.
- 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.