I don't actually think the pattern would be shared directly within STIX, but that the workflow would actually follow a similar pattern as described below. I have tweaked the workflow descriptions you gave to reflect how I view the process to work. I would be interested in your comments and those of others.
1) My SOC needs to be able to tell my threat intelligence group “we are seeing X followed by Y followed by Z, this looks strange”
This is where we need to be able to send a series of linked observables as a strange ordered series of observed behaviours. I see this as where the STIX Observation object (or series of linked objects) will be used. This is potentially where the STIX request/response message type would come into play as well, as the STIX request could contain the observation objects and would also ask "we are seeing these... is anyone else seeing this?", but it would ask it only of the local threat intel group.
2) My threat intelligence group needs to be able to ask my ISAO “we are seeing X followed by Y followed by Z, are you seeing anything like this”
This step is where the threat intel group could check its own threat intelligence repository to see if they have any matching observables or matching indicators that could describe all or part of the observed behaviours. If they don't find anything, they would produce a STIX request message out to each different threat sharing group they are part of, asking if anyone has seen the observed events, and if so to please reply with more information. I see this as being a STIX request message per sharing group containing the observations, and a question type meaning 'has anyone seen these?"
3) Org 2 tells Org 1 via the ISAO “yes we are seeing that pattern as well, here's an indicator we created earlier and some more information about this
This is where the STIX response would be used. The STIX response could contain the Indicators that match the traffic, the threat actor involved in previous attacks, the malicious tools used, courses of action, the campaigns underway from that threat actor right now. In fact any STIX content that Org2 feels would be useful, and that they are willing to provide out to the whole trustgroup.
3b) The threat intel group analyses the results from Org 2 and determines it looks logical enough to give back to the SOC
The SOC receives a STIX response (matching the STIX request they sent earlier) from the threat intelligence team repository, and it contains some indicators to look for, as well as some more information about the threat actor that Org2 believes to be involved with this attack. The SOC now have additional indicators to look for and roll those out to their detective and protective controls.
4) Org 1 investigates the pattern and finds that it matches the observables they have exactly. Org 2 “+1” the pattern
This would be done within Org1 after they investigate the pattern, hand the details to the SOC and the SOC finds additional matches. This can be done in two ways in my mind:
- Org 1 can generate an Opinion object which will allow them to say they 'strongly agree' with the content in the Org2 indicator object. This distribution of this Opinion object will increase the trust that others in the sharing groups have for that indicator, and effectively allows less skilled organizations to crowd source which objects are considered more 'truthful'.
- Org 1 can also generate Sightings (in whatever form we decide) and can provide those back to Org2 to allow them to gain more insight. This will in turn allow for Org2 to refine their Indicators to improve the quality of the matching, and reduce the number of false positives.
5) Org 3 (and many other orgs) “+1” the pattern as well
I don't believe that we need to be able to distribute patterns outside of indicators in order to do this workflow, and I believe that we have the basic structures to do this if we added the Opinion object and added the STIX request/response message types..