Design Goals

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.

Non Goals

  • 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.