OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-stix] Conceptul model for sighting


I can go with that...


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 22, 2015, at 09:10, Jerome Athias <athiasjerome@GMAIL.COM> wrote:

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.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]