TAXII 2 Server
This project was a server implementing the TAXII 2 spec for sharing cyber threat intelligence (STIX objects). It began as a way to learn Node.js and MongoDB, and once it was moved to a work project, we started using it to share actionable adversary simulation content over STIX via TAXII.
Fig. 1: Functional Overview
⤢ ZOOM
I decided to learn Node around Node 8 and this was a good project for it. I added a few cool things like an async job queue for uploading / importing data since STIX objects can get big. I built out validation and a management UI that weren't part of the spec. Once this moved to a work project we started building out a roles system and a review process for approving content changes. We had a few different teams interested in this internally, but eventually the content delivery mechanism for our adversary simulation work changed requirements and other interested parties left so the project was archived.
One of the things that initially surprised me was how fractured CTI was (and continues to be). I think we share indicators decently well, but nobody outside of MITRE was sharing full STIX-ified records of attacks. I realize that this thinking was naive in that the level of effort to structure data in this way is high and more commonly threat intelligence reports are in natural language. Attack Flow attempted to solve some of this but uptake is limited and I think the verbosity and academic nature have led to only the most devoted teams sticking with it.
Specifications
| Tech | Node, Express, Mongoose |
| Database | MongoDB |
| Spec | TAXII 2.0 / STIX |
| Queue | Bull (Redis) |
| Validation | ajv, STIX 2.0 schemas |
| Year | 2017 |
| Source | Open Core (GitHub) - everything but the core taxii 2 spec is proprietary work-only |
Notes
Interesting Stuff
- Like the Unfetter TAXII server, the same URL serves TAXII JSON to a client or an HTML page if you hit it in a browser
- Imports go through a Bull queue on Redis and stream the JSON so big STIX bundles don't cause I/O problems
- Validation is a separate package so we could open source the core"
- Every API root gets its own Mongo db so we could have separate instances of TAXII and AuthZ accordingly