On Tuesday, 3 November 2015, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
> Um, why do we want the same ID? If the attacker has sent our Org the same pdf 2000 times then don’t we want to record that fact, and link the Sighting objects (with Observable Instances) to the Incident object with 2000 relationship objects? Then > don’t we want to also send that group of Incident, Sightings, Observables and Relationships to others in our Threat Sharing group so that they are aware of them? That is accurate.
I am going to humbly suggest that there is no way any large organization has the resources to do what you are suggesting (record unique sighting objects in the graph for every occurrence of an indicator). I could easily have tens of thousands or more sightings of a single indicator in 1 day alone in real-world situations... extrapolate that out to millions of indicators monitored and months of data and you will see how this would impact your graph. Why would I want unique records of all of those sightings, to what purpose is it serving? What people care about in a sighting is a count of indicators, so that they can give increased significance to those that are currently "live". IE - the way I see things happening in most all implementations is the sighting will be ingested, it will be used to increment some counts, and it will then be discarded. I can't possibly see any implementation storing raw sightings, at least not at an enterprise scale, unless it has some arbitrary cap like "store raw sightings for 24 hours and then discard"
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - UnknownTerry MacDonald ---2015/10/30 07:32:02 PM---Um, why do we want the same ID? If the attacker has sent our Org the same pdf 2000 times then don’t
From: Terry MacDonald <terry@soltra.com>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <mdavidson@mitre.org>, "Sean D. Barnum" <sbarnum@mitre.org>, Jerome Athias <athiasjerome@gmail.com>, "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/10/30 07:32 PM
Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0
Um, why do we want the same ID? If the attacker has sent our Org the same pdf 2000 times then don’t we want to record that fact, and link the Sighting objects (with Observable Instances) to the Incident object with 2000 relationship objects? Then don’t we want to also send that group of Incident, Sightings, Observables and Relationships to others in our Threat Sharing group so that they are aware of them? That is accurate.
If we are worried about the size of storing the PDF multiple times, then it is up to the implementation to recognize that the MD5 of the attachment item is the same and then actually only store it once (just like MS Exchange servers have been doing since mid-2000’s).
How do we identify to others that the above data came from us?
If the ID of the object just generated from the <HashofContent> then there is no easy way to do this. If the ID of the object generated from the namespace.<HashofContent> then we have more chance.
But what happens if we decide to update the Incident? The ID is now namespace.<NewHashofContent>. Now how do we de-duplicate? Do we now have to puclish a relationship object explicitly stating the is a replacement object for the namespace.<HashofContent> object?
And what about relationship objects? Part of the power of separate top-level objects is that we can now just tell people about the relationship, but we can keep the actual data node it refers to a secret. Therefore in some implementations the only link to tie relationships together is the fact both relationships share an ID:
e.g
RelationshipA (src: CampaignA -> Threat ActorA)
RelationshipB (src: IndicatorA -> CampaignA)
RelationshipC (src: IndicatorB -> CampaignA)
The recipient may not have the CampaignA data or ThreatActorA data, but they will still know that the IndicatorA and IndicatorB are related to the same campaign thanks to the relationship contains in the same IDs. This completely breaks if the ID’s change over time.
We need an ID solution that:
- Includes the domain namespace in the ID so that recipients know where to ask for more information.
- The ID stays the same over the lifetime of the object even if it is updated and the content changes.
- Recognizes that IDs will be coming from many different companies and many different sources and that we ned a way of easily understanding who produced the data.
To go over the FW use case again
1. FW 1 see a series of weaponized PDFs come down through email. For each weaponized PDF email it detects, it creates a detection alert and sends that to its FW mgmt server.
2. The FW mgmt. server has STIX/TAXII capabilities. For the first detection alert that the FW MGMT receives, it creates a STIX v2 Sighting object, and a corresponding STIX Observable containing a CybOX EmailMessage Object and a related File object, and two relationship objects to join the STIX Sighting to the Observables. It stores a mapping of the Observable SHA256 / file ID in a local internal data table for the EmailMessage and the File. It sends these out on the TAXII channel that it was configured to use.
3. The main TAXII repository receives this STIX v2 Sighting object and the corresponding STIX Observable containing a CybOX an EmailMessage Object and a related File object, and adds them to its repository.
4. For the second detection alert that the FW MGMT receives, it does a SHA256 hash of the Email contents and the attached File independently to see if it’s seen them before. It hasn’t seen the EmailMessage before, but it has seen the attached PDF.
5. it creates a STIX v2 Sighting object, and a corresponding STIX Observable containing a new CybOX EmailMessage Object (email address was different). The EmailMessage contains the idref of the previously generated File object. It also adds two relationship objects to join the new STIX Sighting to the Observables. It sends these out on the TAXII channel that it was configured to use.
6. The main TAXII repository receives this second detection STIX v2 content, and adds them to its repository.
7. The next detection alerts each will create a new Sighting object, new EmailMessage object but will refer to the same File object. Relationships will be created between these objects as well.
At this point, the main taxi repo knows that the File objects are all related.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com
From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
Sent: Saturday, 31 October 2015 4:54 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Wunder, John A. <jwunder@mitre.org>; Terry MacDonald <terry@soltra.com>; Mark Davidson <mdavidson@mitre.org>; Sean D. Barnum <sbarnum@mitre.org>; Jerome Athias <athiasjerome@gmail.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0
Lets run the FW use case to the ground, since most everyone should understand it...
FW 1 see a series of weaponized PDFs come down. Say it sees the same Weaponized PDF 2,000 times over a period of 3 days. A large phishing attack with a lot of click happy users.
1) Now it is highly unlikely with the current model that the FW will remember and use the same ID value (UUID) for each Indicator+Observable+MAEC data blob it issues for this Weaponized PDF. In fact, it will probably have 2,000 different UUID IDs for the same Indicator.
2) Now when you compound this by 60,000 client in the network issuing Sightings, this becomes to blow up quickly.
Maybe... Just maybe.... The FW could take the JSON Indicator that it is going to issue and hash the data blob and use that hash as the ID. Then at least each FW that is running the same code and is seeing basically the same thing with the same amount of data-enrichment, will issue the same ID value.
We will have a totally different problem in TAXII Land in the Query REST API. Because you will probably want to do something like:
/t2/query/indicator/file_name/FreeFood.pdf
or
/t2/query/indicator/file_hash/<some file hash of the PDF>
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 Oct 30, 2015, at 11:42, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
So then the question becomes - if the consumers are not using the IDs, then why are they required...
"That said, that doesn’t mean sightings shouldn’t have IDs. If I autogen IDs for sightings then you can delete them, revoke them, ask for more info about them, etc. Maybe not everyone will do or support that (a firewall generating millions of sightings won’t persist the ID, but the threat intel tool working human-to-human sightings might) but by having an ID we can at least support it."
I am against a mandatory 32 or 64 or whatever bytes in every sighting message if usually the bytes don't have any meaning behind them.
And to again re-iterate - this problem is beyond sightings... it certainly exists for many classes of observables, and sometimes even indicators.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown