On Thursday, 29 October 2015, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
Can someone go through the workflow for using these assertion-type sightings? It is far from clear to me how these are planned to be used.
- The only way negative assertions work in practice is if we are now saying that when one consumes an object, they should reply with either a positive or negative assertion.
- Going down the track that *every indicator* should be responded to with a sighting, either positive or negative.
- Now you have another problem, for how long do you report these "negative assertions"? Forever? Indicators do not have a life-span attribute.
-
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 - UnknownJoep Gommers ---2015/10/29 10:57:52 AM---I’m not sure about the semantics. Other then in our threat model (STIX) we need to be able to make s
From: Joep Gommers <joep@eclecticiq.com>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, Jason Keirstead/CanEast/IBM@IBMCA, "Sean D. Barnum" <sbarnum@mitre.org>, "Cory Casanave" <cory-c@modeldriven.com>, "Thompson, Dean" <Dean.Thompson@anz.com>, Terry MacDonald <terry@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/10/29 10:57 AM
Subject: Re: [cti-stix] Top-level Sighting Object from last meeting
Sent by: <cti-stix@lists.oasis-open.org>
I’m not sure about the semantics. Other then in our threat model (STIX) we need to be able to make statements around
I [machine or human] [certaintly|almost certaintly|probably|evenly|probably not|have not] [have observed|have not observed] [something on my abstraction level] when evaluating against [information source]
E.g.
I machine have certainly observed 213.197.30.28 on network X, firewall B
I human have probably observed TTP X on host Y, AV scanner X
I machine have probably observed indicator X (e.g. 80% match) on SIEM B, model Y, logevents XYS
I machine have not observed file.exe on SIEM C, logs until 2015-01-01
I human have almost certainly observed report Y while watching raw network packets in ASCII
Not sure (also not natively my language, my apologies) about it being sightings/assertions/etc.
J-
From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, October 29, 2015 at 2:49 PM
To: Joep Gommers <joep@eclecticiq.com>
Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Sean D. Barnum" <sbarnum@mitre.org>, Cory Casanave <cory-c@modeldriven.com>, "Thompson, Dean" <Dean.Thompson@anz.com>, Terry MacDonald <terry@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Top-level Sighting Object from last meeting
Joep,
Would these be assertions or actual sightings?
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 29, 2015, at 03:03, Joep Gommers <joep@eclecticiq.com> wrote:
Per my previous comment;
I agree to the extent that this described one of the use-cases for sightings nicely. Machine matching of known indicator and warning information.
However, I think there are many scenario in which it is not the threat intelligence that has the largest information position and something can be sighted through hypothesis, interpretation or information to known in the threat model. Example:
- AV scanner sees something and reports a sighting on a malware name in TTP, while NOT telling us about the indicator and warning information underlying it
- Human analyst sees something described as a thought model in a report, not knowing the specific technical indications, but judging based on other analytic models that is it occurring
In summary – CTI goes hand in hand with non technical information and sighting related requirements IMO.
J-
From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, October 29, 2015 at 1:50 AM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: "Sean D. Barnum" <sbarnum@mitre.org>, Cory Casanave <cory-c@modeldriven.com>, "Thompson, Dean" <Dean.Thompson@anz.com>, Terry MacDonald <terry@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Top-level Sighting Object from last meeting
I think you're right, in fact, the logistics of even having sightings on indicators gets very complex, as an indicator can contain many observables that may or may not also have time factors. Saying you "saw" a complex indicator would be quite difficult for anyone to implement in practice. But sighting observables - essentially adding a +1 to a cybox signature - tools will be able to do this easily, at all levels of the network.
Sent from IBM Verse
Jordan, Bret --- Re: [cti-stix] Top-level Sighting Object from last meeting ---
From: "Jordan, Bret" <bret.jordan@bluecoat.com> To: "Sean D. Barnum" <sbarnum@mitre.org> Cc: "Cory Casanave" <cory-c@modeldriven.com>, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>, "Thompson, Dean" <Dean.Thompson@anz.com>, "Terry MacDonald" <terry@soltra.com>, cti-stix@lists.oasis-open.org Date: Wed, Oct 28, 2015 5:26 PM Subject: Re: [cti-stix] Top-level Sighting Object from last meeting
A point of semantics but I am not sure you can sight an indicator, but you can sight an observable. An indicator is really an assertion that an observable is bad, right?
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 28, 2015, at 14:22, Barnum, Sean D. <sbarnum@mitre.org> wrote:
Observing something “ad hoc” is simply an observation and is currently expressed using Observable.
A Sighting is saying that something was observed that has been identified as of potential interest by an Indicator. Kind of like a police APB.
sean
From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Cory Casanave <cory-c@modeldriven.com>
Date: Wednesday, October 28, 2015 at 5:18 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: "Thompson, Dean" <Dean.Thompson@anz.com>, Terry MacDonald <terry@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: RE: [cti-stix] Top-level Sighting Object from last meeting
Must a sighting have an indicator or can you observe something “ad hoc”?
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Wednesday, October 28, 2015 2:57 PM
To: Jordan, Bret
Cc: Thompson, Dean; Terry MacDonald; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Top-level Sighting Object from last meeting
Agree 100% and I think this also nerds to be considered as we decide what is "mandatory" and what isn't in the sighting.
We are looking at potentially having to feed tens of millions of sightings a day to one system in some
MSSP situations. They have to be as small and compact as possible. Ideally, just an ID and as little superfluous info as possible alongside it.
Sent from IBM Verse
Jordan, Bret --- Re: [cti-stix] Top-level Sighting Object from last meeting ---
From: "Jordan, Bret" <bret.jordan@bluecoat.com> To: "Thompson, Dean" <Dean.Thompson@anz.com> Cc: "Terry MacDonald" <terry@soltra.com>, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>, cti-stix@lists.oasis-open.org Date: Tue, Oct 27, 2015 3:23 PM Subject: Re: [cti-stix] Top-level Sighting Object from last meeting
I think the vast majority of sightings will be more or less auto generated. There may be a need to support sightings of other higher level objects, but the quantity or volume of those will be really small in relative terms.
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 27, 2015, at 15:13, Thompson, Dean <Dean.Thompson@anz.com> wrote:
Hi!,
Does this depend on what is producing the sighting object ?, for example the first option appeals to me because from an ability to auto-script and generate it could be potentially easy to make those links of observations to a sighting object. With regards to “Threat Actor’s” and “TTP’s”, doesn’t it get a little hard because (based on the experience I have had), you have more softer definitions you place into those top level objects, they are not straight out IP addresses, MD5’s or email addresses.
Do others seeing the sighting object as being a construct which would more times than not be something that is auto-generated by various systems, rather than a construct put together manually which include thought and analysis ? (that’s not to say that you couldn’t do that, just that it is a lot harder).
Personally, I prefer option 1.
Regards,
Dean
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Terry MacDonald
Sent: Tuesday, 27 October 2015 9:57 AM
To: Terry MacDonald; Jason Keirstead
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Top-level Sighting Object from last meeting
Hi All,
One other thing I wanted to highlight was a point raised by Aharon late last week in the STIX meeting. We need to discuss what exactly we want the Sighting Object to be able to reference. As I understand it the available options are:
· Should a Sighting Object only reference ‘detected’ information (e.g. Observable Instances only – most similar to an Indicator)
OR· Should a Sighting Object reference any other top-level Object (e.g. Threat Actor’s, TTPs, etc). This will be the most flexible and least restrictive for the future.
OR· Should a Sighting Object reference some top-level Objects based on STIX model (e.g. Threat Actor’s, TTPs, Indicators, Incident, Report)
My personal preference is for the first option – but I am very interested in what others think. I think we need to scope the Sighting object and discuss its purpose fairly early on to work out exactly where it will fit in the model.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Terry MacDonald
Sent: Tuesday, 27 October 2015 9:21 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Top-level Sighting Object from last meeting
Hi Jason
- What is "Alternative_ID" ?
The Alternative_ID was taken from the IndicatorType object. From that object’s description it ‘Specifies an alternative identifier (or alias) for the cyber threat Indicator.’. The idea was to allow the Sighting to have a reference of some kind, referring back to the ID that the tool that identified it had given it. It may not be useful in the Sighting context but I wanted to include it just in case. TBH we may want to think more about how we handle ‘aliases’ in general across the whole STIX model…
- Can you add to the proposal, which fields would be mandatory, and which optional? It's unclear to me. I presume a subset is mandatory, but not all.
Yes, my thinking was that a subset of the Sighting fields would be mandatory. I’ve suggested some below but would really like to see what everyone else thinks.
Suggested Mandatory Fields
· Version
· Title
· Timestamp / Time Period
· One or more referenced objects (i.e. idref) – (This would be done via Top-level relationship object)
Suggested Optional Fields
· Sighting Count
· Timestamp / Time Period
· Victim Organization information
· Producer Organization information
· Sighting Confidence
· TLP / Data Markings
· Alternative Sighting ID
· Sighting Type
· Description
· Short Description
Mark’s other post earlier today reminded me that I had earlier requested a Sighting object last year (https://github.com/STIXProject/schemas/issues/306). In there I even drew a nice updated STIX model diagram to include where I personally saw the Sighting object located (thanks to Bret for the visio). But this may help provide more context?
<image001.jpg>
Please note this reflects my own personal viewpoint.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Tuesday, 27 October 2015 8:34 AM
To: Terry MacDonald <terry@soltra.com>
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Top-level Sighting Object from last meeting
Questions
- What is "Alternative_ID" ?
- Can you add to the proposal, which fields would be mandatory, and which optional? It's unclear to me. I presume a subset is mandatory, but not all.
-
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
----- Original message -----
From: Terry MacDonald <terry@soltra.com>
Sent by: <cti-stix@lists.oasis-open.org>
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Cc:
Subject: [cti-stix] Top-level Sighting Object from last meeting
Date: Mon, Oct 26, 2015 2:00 PM
Hi All,
Given the flurry of discussions about features for STIX v2.0, it’s probably the right time to resend the top-level STIX Sighting Object conversation starter out again. So here are the slides. Please feel free to comment/feedback/complain/call me names.
Please note – the strawman UML model is an abstraction based on the use of the Sighting Object only for Observable Instances; it assumes that Indicators will similarly be restricted to only allowing Observable Patterns. The idea being that Indicators = ‘things to look for’ and Sightings = ‘things we’ve found’.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.