Re: [cti-stix] Conceptul model for sighting

[Jerome Athias <athiasjerome@gmail.com>]

So for the reflection on where to put/attached the sighting (one top
level 'object' or each objects),
I think this should be linked to the CybOX discussion regarding
Observables instances vs patterns

and the clarification of the Observation concept (thanks Cory ;-))
would make it easier.

To Bret's approach, I would like to add the time*

1) What: Reference to what it is we are sighting
2) Who: The person / organization that is making the sighting
3) A count of the number of times it was seen.
4) When*

KISS:

{
"type": "sighting",
"id": "foo.com:sighting-1234-1234-1234-1234",
"idref": "abc.com:indicator-4321-4321-4321-4321",
"count": "1222"
"producer": "tom and jerry"
"timeframe": between monday and tuesday
}



2015-10-22 17:27 GMT+03:00 Bush, Jonathan <jbush@dtcc.com>:
> 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.
>
>
>
> From: Cory Casanave [mailto:cory-c@modeldriven.com]
> Sent: Thursday, October 22, 2015 10:06 AM
> To: Bush, Jonathan; 'Jordan, Bret'
>
>
> Cc: cti-stix@lists.oasis-open.org
> Subject: RE: [cti-stix] Conceptul model for sighting
>
>
>
> 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
>
>
>
> From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
> On Behalf Of Bush, Jonathan
> Sent: Thursday, October 22, 2015 8:48 AM
> To: 'Jordan, Bret'; Cory Casanave
> Cc: cti-stix@lists.oasis-open.org
> Subject: RE: [cti-stix] Conceptul model for sighting
>
>
>
> 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.
>
>
>
> 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 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 21, 2015, at 15:17, Cory Casanave <cory-c@modeldriven.com> wrote:
>
>
>
> 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>
>
>
>
>
> 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.
>
>
> 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.