In the second part of this three-part series, we explored the potential of using an existing STIX 2.1 Object for structuring the analysis of competing hypotheses (ACH). But once we looked at what was needed to structure ACH it became apparent that the 2.1 STIX Opinion Object was not going to work. We needed a new Object.
When we think how to best represent the process of ACH with a STIX entity, we need to know what this entity should look like in order to be able to conduct ACH. After all, ACH uses a variety of measures to assess how strong a given hypothesis is by using reliability and credibility as a way to score each hypothesis against all evidence available.
The Hypothesis Object: Properties
To get started, let’s list some assumptions we are making about this new Object:
- A Hypothesis Object must consist of evidence
- A Hypothesis Object must consist of a way to score the reliability of evidence
- A Hypothesis Object must consist of a way to score the credibility of evidence
- A Hypothesis Object can represent the process and the end result of hypothesis testing
- Evidence within a Hypothesis Object can consist of STIX entities
- Evidence within a Hypothesis Object does not need to consist of only STIX entities
- The Hypothesis Object ‘title’ can be the result of the author’s strongest hypothesis being tested
- A Hypothesis Object contains a property of ‘evidence type’ as a way to classify what types of evidence are being used to support certain hypotheses
These assumptions will become important as we start to think of properties that this Object should have.
There are still a lot of unknowns. For example:
- Is a Hypothesis Object a standalone Object?
- How will one Hypothesis Object relate to the original testing group in which it was tested?
- How do we expect the Hypothesis Object to fit into a data model?
One of the biggest hurdles at this point is how to deal with the hypothesis as a standalone Object, or as a grouping of hypotheses that are all being tested against the available evidence. Another hurdle is the identification of a data model the Hypothesis Object can work in.
For example, how can the Hypothesis Object help make the original Digital Shadows information from Part One more digestible for consumers of threat intelligence?
Opinion Object vs Hypothesis Object
In part two of this series, we determined that one of the reasons the Opinion Object is not the best Object to structure hypothesis testing is because it needs to provide a consumer/collaborator with a way to interact with entities without needing any evidence. An opinion is an expression of a varying degree of ‘Agree’ or ‘Disagree’ on a relationship or on an entity. It allows consumers/producers to apply a feeling about an entity without needing to supply any evidence supporting it.
Here are more applicable examples that demonstrate the need to have separate Opinion and Hypothesis Objects:
- A SOC analyst using a ‘Strongly Disagree’ Opinion Object to flag and identify false positives within their environment
- Opinion Objects used to evaluate sources over time (i.e. how many ‘Strongly Disagree’ opinions has my analyst team created that relate to entities/relationships from producer X)
- A downstream intelligence consumer in the ecommerce sector relates a ‘Strongly Agree’ opinion to the relationship between Magecart Threat Actor à British Airways Campaign as a way to signal and identify Threat Actors and attribution that are important to them
- Use Opinion Objects as a way to expand an organization’s threat hunting around the diamond model (i.e. to identify all the ‘Strongly Disagree’ opinions related to Threat Actors as a way to identify what additional intelligence around attribution may be needed
Opinion Objects provide a flexible way of validating intelligence as it fits within a consumer’s environment. Hypothesis Objects provide a way to collect what we know about the larger threat landscape and to propose and test multiple hypotheses around a given threat.
Next Steps: Proposed Hypothesis Object Specification and Properties
The Hypothesis Object gives us a good starting point for structuring the analysis of competing hypotheses (ACH), but there is more to consider. There are some further steps we can take to move the Object forward:
- Identify a working prototype from the assumptions we have made about what the Hypothesis Object should look like
- Represent this in a proposed data model
- Provide a proposal to the OASIS community: https://github.com/oasis-open/cti-sep-repository
EclecticIQ will continue to work on this issue and engage the community and OASIS to help identify more details about this Object. We invite other parties interested in representing ACH within an entity or working on structuring ACH to collaborate with us and reach out to us.
We hope you enjoyed this post. Follow us here for more interesting reads on Cyber Threat Intelligence or check out our resource section for whitepapers, threat analysis reports and more.
