Agreed on all of this Cory. I especially like your thoughts on “simple means something different to everyone”. We need to keep everyone’s base case in mind… so people need to make sure they are speaking up. What is absolutely critical, what is everyone’s minimum viable product (MVP) here?
Also, on data structure, I think that trying to accommodate things like timespan could get very complicated very quickly, and it changes the problem domain significantly.
Bret & Jonathan,
In my experience combining a bottom-up and top-down approach yields the best result. Particularly in a system as complex as STIX which must satisfy multiple use cases and implementation style, “simple” is not always the same from one stakeholder to the next. What is important from both perspectives is clarity on meaning and a consistent and logical representation. Having a map of the concepts helps with clarity, consistency and solving multiple use cases. Bottom up analysis makes sure critical needs are met in as simple a way as possible. Top-down alone can get overly general where as bottom-up alone can get fragmented and limiting. So both is best. The conceptual model I showed is not intended as the CTI schema model, but such a map of the concepts.
With respect to “sighting”, I found the 1.x STIX representation confusing and lacking some of the links I would expect. The proposition represented in the conceptual model is that a sighting is a specific observation corresponding to an indicator that provides evidence for some situation of interest. Such a sighting would take place at a specific time and be reported by identified parties. The expectation is of a single event, if “multiple sightings” are within one sighting report then this changes the meaning as well as the data structure somewhat – for example we would need to allow for a timespan, not just a point in time.
-Cory Casanave
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.
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.
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.