This isn't ready for a GitHub issue since it needs a lot of fleshing out, but as part of the work we have been doing with incident report sharing we found that one of the major hurdles using TAXII is the fact that a large number of objects are required all of which are connected via relationships, and many of which we would want to have specific values or identities provided supplied to us. So if we were to use TAXII an ideal scenario would be to have a standard that the TAXII server could read to enforce this standard which could also be sent to any TAXII client that wanted to submit to a collection so they would know what was required and potentially even use this information to build UIs or forms to allow integrated SOARs to pass on this type of incident report.
I see this coming in a few parts.
- Have an additional property in the response to /{api-root}/collections/ "template". This would have 3 allowed values: "enforced", "available", "none". If this field was not present it defaults to "none" to ensure backwards compatibility.
- Add a new GET endpoint /{api-root}/collections/{id}/template which returns the schema template to clients
- Define what this template looks like
- Actually verify we can use these templates for both enforcement on the server side and to help guide GUIs or forms on the client side
For the actual template itself I was thinking something like this, but I haven't started writing any code to make sure it would work at all and this example is far from complete:
[
{
"type": "incident",
"min_count": 1,
"max_count": 1,
"id": "incident-1",
"property_rules": {
"target_ref": {
"rule": "reference_list",
"refs": ["impact-availability", "impact-confidentiality"]
}
},
"required_extensions": ["extension-definition--ef765651-680c-498d-9894-99799f2fa126"]
},
{
"type": "identity",
"min_count": 1,
"max_count": null,
"id": "impacted-entity",
"property_rules": {
"external_references: {
"rule": "object_array",
"allow_additional": true,
"require_matching": true,
"object_rules": {
"property_rules": {
"source_name": {
"rule": "enum",
"values": ["cage_code"]
}
}
}
},
"name": {
"rule": "exists"
}
}
},
{
"type": "impact",
"min_count": 1,
"max_count": null,
"id": "impact-confidentiality",
"property_rules": {
"impact_category": {
"rule": "enum",
"values": ["confidentiality"]
},
"impacted_refs": {
"rule": "reference_list",
"refs": ["impacted-entity"]
}
}
},
{
"type": "impact",
"min_count": 1,
"max_count": null,
"id": "impact-availability",
"property_rules": {
"impact_category": {
"rule": "enum",
"values": ["availability"]
}
}
},
{
"type": "relationship",
"min_count": 1,
"max_count": 1,
"property_rules": {
"relationship_type": {
"rule": "enum",
"values": ["impacts"]
},
"source_ref": {
"rule": "reference",
"ref": "incident"
},
"target_ref": {
"rule": "reference",
"ref": "impacted-entity"
}
}
}
]
The above example would show that a submission must have exactly 1 incident, 1 or more Identities which must have a name and external reference of a given type, must have one or more relationships between the incident and the impacted identities with the relationship_type of impacts, and also has to include at least one confidentiality and integrity impact which also must be appropriately linked through embedded relationships.
Ideally this would allow tools with TAXII clients to know what they can fill in and store to speed up future submissions. This is all very rough and as I said it's not tested in code yet, but I thought it would be good to discuss as we talk about kicking off work on TAXII again.
------------------------------
Jeffrey Mates
US Department of Defense (DoD)
------------------------------