Emitting an indicator based on a rule or workflow is a lot easier problem for a vendor to solve than allowing someone to query them through a means other than their own existing API. Long term I think we can get there, but it will take some time. This is one of the reasons we are looking at HTTP / REST / JSON for TAXII, since most network and security product vendors use that stack for their APIs today. This should make adoption of TAXII 2.0 a much easier pill to swallow.
Thanks,
Bret Bret Jordan CISSPDirector 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."
Hi Jason, That’s not strictly correct. Firewalls have logs. IDS’s have logs and sometimes even full packet capture (Endace, Mocloch). Sandboxes often store the actual malware they have processed. It is quite possible that there is more information available. Yet it is also possible that they don’t. It is possible that the data has expired from their data store and that there is only a log entry left. Or that the logs have rolled over and now there is nothing left. We need to support both potential situations. I think that there will be some times that a security tool producing STIX Sightings will be smart enough to detect that it is sending something its seen before and will reuse the previous ID, but other times it will not. Sometimes the STIX repository will need to work out that two things are matching themselves. I am a proponent of using the data structure to extract the basic parts of the Observables and then use those to find duplicates. In other words: STIX IndicatorA -> STIX ObservableA -> CybOX AddressA -> IPv4 Address Database Entry <- CybOX AddressB <- STIX ObservableB <- STIX IndicatorB In this way, even if the security tools don’t do deduplication we can find relationships ourselves through the data itself, and then can form our own ‘STIXified’ relationship objects to more formally demonstrate the STIX relationship between the STIX objects. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company That is kind of the point - there is no way to go back to these automated systems and ask for more info - they don't have it... they have no systems of record to store it in. This will be true of all kinds of security devices: Firewall
IPS
NGFW
App Sandbox
Endpoint protection * * Most endpoints have a system of record of IOCs up on a management console somewhere, but not always All of these device classes could reasonably directly produce observables and sightings, but none of them have systems of record that can make use of IDs for querying. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security | www.securityintelligence.comWithout data, all you are is just another person with an opinion - Unknown <image001.gif>"Wunder, John A." ---2015/10/30 03:10:28 PM---But in those cases wouldn’t the consumers want some way to go back to the producers and ask for moreFrom: "Wunder, John A." <jwunder@mitre.org>To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>Date: 2015/10/30 03:10 PMSubject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0Sent by: <cti-stix@lists.oasis-open.org>
But in those cases wouldn’t the consumers want some way to go back to the producers and ask for more info? Or, when they do, do you think they would just go back with the entire sighting rather than an ID?
It just seems like we have this standard ID mechanism on most things and we should have a very good reason to not follow that pattern here.
On Oct 30, 2015, at 1:56 PM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:I think on the surface it may seem like they are different and the Org to Org sharing will be easier. But that is only the case when you have a very finite number of people contributing to the eco-system. The problem becomes more complex when every SOC in every major enterprise and mom-n-pop shop starts emitting an Indicator+CybOX+MAEC for the same exact piece of Malware. You could easily have 10,000 IDs for exactly the same thing.
Thanks,BretBret Jordan CISSP Director of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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:50, Wunder, John A. <jwunder@mitre.org> wrote:I know we hate optionality, but they could be optional. It kind of gets to Jon Baker’s earlier point that organizational sightings have a different use case (and therefore different requirements) than internal tool-based sightings and the same field set may not solve both problems. John 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
<graycol.gif>"Wunder, John A." ---2015/10/30 02:36:27 PM---Do you think tools will be doing correlation based on ID or doing correlation based on the contents
From: "Wunder, John A." < jwunder@mitre.org>
To: "Jordan, Bret" < bret.jordan@BLUECOAT.COM>
Cc: Jason Keirstead/CanEast/IBM@IBMCA, Terry MacDonald < terry@soltra.com>, "Davidson II, Mark S" < mdavidson@mitre.org>, "Barnum, Sean D." < 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 02:36 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
Sent by: < cti-stix@lists.oasis-open.org>
Do you think tools will be doing correlation based on ID or doing correlation based on the contents of an observable?
As an example, imagine you have a sighting for an e-mail:
- Subject: PLS OPEN ME KTHXBYE
- From: defnotaspammer@example.com
- Attachment: (some hash)
Then you have this other sighting:
- Subject: PLS OPEN ME KTHXBYE
- From: defnotaspammer@example.com
- Attachment: (some other hash)
Then this one:
- Subject: PLS OPEN ME KTHXBYE
- From: defnotaspammer@example.com
Which of those should match? I feel like we’re talking about this as if sightings are either the same or different when in reality there will mostly likely be degrees of similarity (0-100). So my conclusion is that IDs, even generated based on the content, are probably not all that useful for matching sightings.
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.
JohnOn Oct 30, 2015, at 1:24 PM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:
Really good points Jason.... It is amazing how things like this bubble up as you start writing code. I can now see how the ID and IDREF elements will break down rapidly and fall apart in to little pieces all over the floor. Maybe the ID and IDREF thing needs to happen in a WorkBench tool that is listening on a TAXII channel.... ???
We just need to figure out how devices can emit things they see in STIX format based on a rule or policy.
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." So here is my question. "Firewall sees something bad.. The firewall generates an observable and emits that on to a TAXII 2.0 channel. "
How is that firewall going to generate and persist that observable ID to be re-referenced by the "light bulb sighting"? Because if he sees the same "something bad" 1 minute, hour, or day later, he should be sending the same observable ID - otherwise, the sightings numbers would all be reset every time he sees it.
IE - the problem I describe extends beyond sightings, it also extends to observables and even indicators. Most producers of this information won't have the ways and means to build a giant database (of ie. all of the IP addresses they have ever seen) so that they know they will re-use the same ID if they want to re-emit an observable. As such if they want an ID that can be re-referenceable, they will have to generate an ID based on the current data, since the current data is all they have to go on.
-
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
<graycol.gif>"Jordan, Bret" ---2015/10/30 12:36:36 PM---Thanks for catching this Jason. For sightings I am not sure why you would do an ID... Let me expla
From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: 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>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/10/30 12:36 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
Sent by: <cti-stix@lists.oasis-open.org>
Thanks for catching this Jason. For sightings I am not sure why you would do an ID... Let me explain how I see the workflow going....
Firewall sees something bad.. The firewall generates an observable and emits that on to a TAXII 2.0 channel. All of the end point devices (clients, phones, printers, ip enabled light bulbs) can see that indicator and respond with a sighting if the so desire.
The sighting will have an IDREF or similar back to the objects it is referencing. Now the original client or a message handler running on the TAXII server (if the TAXII server is a broker + query repo) could pick up and aggregate all of the sightings coming back for that original observable and either store it or do something with it. In the TAXII server case (broker + repo) it might store the data in a database or bubble it up to an analyst for review before sending it out a different channel group.
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."
I know historically I have been pushing for an RFC-Compliant UUID as mandatory component of this - now i am going to backtrack on my previous argument :)
I actually think that having a UUID be mandatory is not workable, and here is why: For many (most?) products looking to produce observable and sightings, there is no system-wide "ID" in their product that could be used to represent something like an observable. Similarly, STIX producers like embedded devices and endpoints, do not have the resources or processing capacity to start storing these relationships. As such, said producers have two options for generating sightings:
a) Have a randomly-generated UUID (which is of no use to anyone in the end because it will remove all traceability and create rampant data duplication)
b) Have an algorithmically derived ID based on the data (IE, any time I issue an observable for Equals 1.2.3.4, the same ID will be derived)
(b) Is really the only workable ID mechanism for most products.
I have recently started to run into this in practice in my own product work, so I know it is a real problem that is going to hit a lot of people if we start mandating IDs and UUIDs.
Here is an assertion - why is ID even a mandatory field for a sighting? I am not sure why it is useful. If a STIX repository needs an ID for an internal record, it can generate its own in any way it wants. I am not sure why a producer needs to specify an ID.
-
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
<graycol.gif>Terry MacDonald ---2015/10/29 06:51:35 PM---Mark, That should change with the top-level relationship object. It will be quite possible to send j
From: Terry MacDonald <terry@soltra.com>
To: "Davidson II, Mark S" <mdavidson@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "Barnum, Sean D." <sbarnum@mitre.org>
Cc: Jerome Athias <athiasjerome@gmail.com>, "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/10/29 06:51 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
Sent by: <cti-stix@lists.oasis-open.org>
Mark,
That should change with the top-level relationship object. It will be quite possible to send just a relationship object in a package. This will mean that the consumer will need the ability to contact the original producer of the reference STIX data object to ask if they are allowed the full object rather than just the reference to it. Having the ability to find the TAXII server from just the STIX object ID is critical to allow this to happen.
This functionality also allows more secretive providers to ‘hide’ their data, such that consumers can understand that relationships exist, but that only a small subset of approved consumers will have access to the actual STIX object data. It gives the ability to hide stuff.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com
From: Davidson II, Mark S [mailto:mdavidson@mitre.org]
Sent: Friday, 30 October 2015 5:05 AM
To: Jordan, Bret <bret.jordan@bluecoat.com>; Barnum, Sean D. <sbarnum@mitre.org>
Cc: Jerome Athias <athiasjerome@gmail.com>; Terry MacDonald <terry@soltra.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; Wunder, John A. <jwunder@mitre.org>; 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
If want the ability to dereference arbitrary STIX IDs (for use in accessing some kind of repository, let’s say), then I think requiring a rule whereby STIX IDs can be turned into a URL could be a good requirement (Note: URLs as IDs would satisfy this requirement). While there is a concept for idref today, I personally haven’t seen an implementation that dereferences STIX IDs outside of the document containing the idref.
Thank you.
-Mark
PS, a notional example: <stix:Indicator idref=”https://example.org/stix121/indicators/123”/>
STIX SC Co-chair
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
|