|
The best use case I can think of for automated non-observable (non-indicator?) sightings is TTPs: for example, a virus scanner might say they found a piece of malware (TTP/Malware) or an application security firewall might say that it saw some SQLi attempts
(TTP/Attack_Pattern).
I don’t know what I’m suggesting here, just a use case I thought I’d throw out. I do like the idea of having some kind of “not quite incident but kinda like incident” construct to represent things like this and limiting Sighting to just things
we have an observable for, but I can imagine the objection people have when they wonder whether to produce a “Sighting” or an “Event” or an “Incident".
John
I agree with that as well. In fact, as I read your statement Bret, I thought “if this isn’t the case, what are the chances that anyone would ever really use them?”.
There would simply be too much manual data entry to be practical. These are the kinds of call-outs that we all need to identify and keep in mind. In this particular
situation, it may not change how we design the object, but I suppose it could in some less-than-obvious way.
Great stuff…
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.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
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.
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)
· 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.
· 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.
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
- 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
· Timestamp
/ Time Period
· One
or more referenced objects (i.e. idref) – (This would be done via Top-level relationship object)
Suggested Optional Fields
· Timestamp
/ Time Period
· Victim
Organization information
· Producer
Organization information
· Alternative
Sighting ID
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?
Please note this reflects my own personal viewpoint.
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
- 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.
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
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.
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email
and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
|