| 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.
Think:
{ "type": "sighting", "id": " foo.com:sighting-1234-1234-1234-1234", "idref": " abc.com:indicator-4321-4321-4321-4321", "count": "1222" "producer": "tom and jerry" }
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."
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. Regards,
Cory Casanave <image003.jpg>
|