cti-stix — archive

[Terry MacDonald <terry.macdonald@threatloop.com>]

Hi Jane, That's a great idea, for an implementation consuming STIX to use as a way of tracking the various hypothesis internally. In my mind the each different producer that sends a relationship object is effectively sending a single hypothesis. If you as a consumer were to receive multiple different relationships, and you also had one more internal relationship that you yourself had formed, then by combining them all together you have your list of competing hypotheses. If we enable each relationship to be up-voted or down-voted, then we have a way of crowdsourcing the communities opinions on which hypothesis is the 'right' one. This allows a consumer to calculate for themselves which of the competing theories for a particular relationship are the most correct. It could be pretty powerful. The way to allow this functionality within STIX is to do away with using a single Confidence attribute, and instead use Information Credibility and Information Source Reliability metrics. This could potentially map into existing STIX data model like this: Information Credibility: Rename the existing Confidence attribute to Credibility  Information Source Reliability: Add a new field to the InformationSource object called Reliability This would enable: Implementations over time can decide for themselves which Information Sources are reliable, and can raise or lower their information source reliability scores based on the quality of the data coming in. Implementations can then share those information source reliability scores with others. This would enable poor quality producers to be discovered quickly, allowing consumers to 'adjust' the information credibility score downwards during import. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 31 July 2015 at 09:19, JG on CTI-TC < jg@ctin.us > wrote: Bret & All: Here is a rough 3-dimensional drawing of what I was trying to get at in my previous post on combining the Admiralty Code with an Analysis of Competing Hypotheses (ACH) approach. Note that we don't want to have our CybOX or STIX data in the lower left of the Reliability/Credibility 2-dimensional plane [5F - Improbable & Reliability cannot be judged].  Rather, we want our data to be in the top right (where I've placed an Orange Star) if at all possible [1A - Completely reliable & Confirmed by other sources].  But, if it is not there (yet), we can convey a much finer level of detail to our consumers of the data using this 2-factor system. Then, on the 3rd dimension we may need to construct a typology to characterize how an Incident Responder or Analyst is thinking about a problem at a certain point in time. [Hypothesis-1 (e.g., This is a Foo APT); Hypothesis-2 (This is an Foobar Backdoor); Hypothesis-n (Fill in the Blanks)]. So as more data comes in from sharing partners in an ISAO or ISAC (i.e., Sightings) and is associated through Relationships with the Campaign, the Threat Actor, the TTP or ExploitTarget (etc...)... it is enriched along the Reliability/Credibility continuum and competing hypotheses fall away. Jane Ginn, MSIA, MRP Cyber Threat Intelligence Network, Inc. rjg@ctin.us On 7/30/2015 9:40 AM, Jordan, Bret wrote: Can you spell this out in a table format with options so we can better understand what is being proposed?  Like what we are doing in the relationship object discussion? Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." On Jul 30, 2015, at 09:53, JG on CTI-TC < jg@ctin.us > wrote: All: What if we combine Terry's suggestions about the Admiralty Code with a more classical interpretation of Analysis of Competing Hypotheses (ACH) as has been used in the intelligence community?  This concept is outlined in this chapter of "The Psychology of Intelligence Analysis" from the CIA: https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/psychology-of-intelligence-analysis/art11.html This would address the Use Case that Patrick outlined below... (which BTW, really coincides with some of the threat intel sharing cases I've observed), while at the same time moves us away from a poorly understood description of "confidence"...that seems to be problematic because of the different assumptions each User brings to the table. I would see the ACH factor as a Third Dimension to what we've been discussing with respect to Information Reliability. Realize that I'm looking at this from the POV of the Analyst/User that is trying to take IoCs & cyber observables and any other clues and assemble the bigger picture...without a lot of certainty about the Threat Actor, the motivation, the targeted systems, etc....  In this context speculations about competing hypotheses and how they might be assembled in, for example, a Report object, might be useful.... Where an Information Reliability/ACH measure might be applied (e.g., at the CybOX object level) then becomes useful in interpretation by the Human Analysts of the STIX/CybOX information. Jane Ginn On 7/29/2015 5:16 PM, Terry MacDonald wrote: Not necessarily Bret. It may be an 'hypothesis' that someone is wanting to share - to 'put it out there' to see if anyone agrees with it. Being able to mark something (using the Information reliability scale I posted earlier) as '3 - Possibly True' or '4 - Doubtfully True' then allows consumers to determine what level of confidence they want to assign to the information. On Jul 29, 2015, at 16:39, Patrick Maroney < Pmaroney@Specere.org > wrote: Re: "One comment, if you have no confidence in the accuracy of something, meaning you have not done any due diligence on your end, should you really be sharing it? Isn't this the whole problem with the Internet today? People spewing forth crap that is just wrong, and then it gets archived in Google as Gospel. " Sharing unfiltered, unvetted intelligence on Emerging Threats/Previously Unrecognized Threats is extremely valuable in many of the communities I participate in.  The critical element is to properly mark it.  For example one community uses "Investigating" to flag something as preliminary (say I've analyzed 100% 0Day APT Malware, and I run Strings on the binary and get 50 IP Addresses and Domains.  Yet the Malware was only observed to attempt communication with 6/50.  By sharing this type of intelligence [WITH CONTEXT] with the community others can be aware and say, Hey!!!  I didn't see the vectors you did, but I did see a different subset of 6 out of your 50.  We ran it in an air gapped sandbox and when the test access to Google.com failed the Malware beaconing switched to these different IPs and Ports.  Let's mark these 6 new IOCs as actionable and let everyone know the malware may behave differently in different environments and to keep an eye out for the other 38 IOCs." Capturing and retaining properly marked indicators has also revealed key discoveries years later:  for example: "Hey we were investigating something else and our search revealed APT Actor "X" was indeed using nameyourfavoritecommoditybotnet back in 2011!!!!  We didn't realize we had actionable indicators at the time.  Thanks for posting those informational Strings back in 2011!!!!! Filtering Intelligence will significantly impede detection of multi-Stage exploitation and variants of RATs deployed in the Entrenchment phase of lateral movement once adversary has established their initial beachhead and begins deploying.  The key is to ensure you convey all of the context you've developed (and "show your work" to back any of your assertions). On Wed, Jul 29, 2015 at 3:06 PM -0700, "Terry MacDonald" < terry.macdonald@threatloop.com > wrote: I was thinking back to the Admiralty Code ( https://en.wikipedia.org/wiki/Admiralty_code ) regarding reliability and credibility when I wrote that. The idea was if someone had learned from a 3rd party that there was a relationship between Threat Group A and Threat Group B, but had not yet been able to determine the reliability/truthfulness of what that third party had said. They may want to send out that relationship, as kind of a 'something we've heard but not had a chance to verify ourselves'. That's where I was headed with the Unknown option. Maybe it would be better to use the terms from Information Reliability instead of Confidence when describing relationships within STIX? ( https://en.wikipedia.org/wiki/Intelligence_source_and_information_reliability ) Rating Description 1 Confirmed Logical, consistent with other relevant information, confirmed by independent sources. 2 Probably true Logical, consistent with other relevant information, not confirmed. 3 Possibly true Reasonably logical, agrees with some relevant information, not confirmed. 4 Doubtfully true Not logical but possible, no other information on the subject, not confirmed. 5 Improbable Not logical, contradicted by other relevant information. 6 Cannot be judged The validity of the information can not be determined. -- Jane Ginn, MSIA, MRP Cyber Threat Intelligence Network, Inc. jg@ctin.us