I definitely like the “state the use case first” approach here. We can’t implement a data design until we know what we plan on doing with it.
On the simplicity suggestion – YES!! Simple, simple, simple. We can always add fields later. Let’s just get this implemented, baked into our products, and then
we can see what we are missing.
On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something
and adds context like who saw it, date, etc…) or have a combined object that carries a count. The former will offer more flexibility, but will mean more object instances. The later is really just a summary of the former, which will be much smaller from a
db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.
Personally, I favor flexibility. We can solve the size issue with technical implementation.
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Wednesday, October 21, 2015 5:42 PM
To: Cory Casanave
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Conceptul model for sighting
I think a better place to start is how people or devices are going to interact with an IOC-Indicator.
1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff. Perhaps as I start documenting an issue I am seeing in my network it could show a
list of potential IOCs that match it. I could then:
a) click a button that says "share a sighting" or
b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.
2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to
see if the IOC is already known. In either case, the device could emit a sighting.
While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object.. It is always easy to add stuff, but it is really
hard to take it away.
I would argue that the bare minimum we need is:
1) Reference to what it is we are sighting
2) The person / organization that is making the sighting
3) A count of the number of times it was seen.
Now yes, there is a LOT more things that COULD be added, and all of them could be added over time. For example (yes this will rub people the wrong way), data markings. I would personally leave them out for now. I would love if we could
get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.
By taking the minimalistic approach we can more quicker and get people using it.
"id": "foo.com:sighting-1234-1234-1234-1234",
"idref": "abc.com:indicator-4321-4321-4321-4321",
"producer": "tom and jerry"
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."
In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more
general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas.