Re: [cti-stix] Conceptul model for sighting

[Jerome Athias <athiasjerome@gmail.com>]

I think we're doing well.
I think the location and detection-method could be optional (in an
effort of keeping things as simple as possible)

<source> observed <x> instances of <object>, <time-range> (via
<detection-method>) (at <location>) (with <confidence>) (...)


After let's say two weeks of open discussions in the list, we could
update the github and ask the TC Chairs to present the current
conclusion/proposition during the next meeting. Then submitting it for
an open request for comments for a period of, let's say 1 month before
potential definitive agreement/validation

@Sarah: regarding the relationships 'issue', there's an open
discussion going on to know if we make it as a construct. I will just
add, for now, that if you can't find a 'workaround', that I assume
right now being finding the -relationship path- between top level
object A and the underlying object B, this should be highlighted

@Sarah (and all): did you run the statistics tool? :-)



2015-10-27 14:56 GMT+03:00 Davidson II, Mark S <mdavidson@mitre.org>:
> I’m feeling like the possible use cases mentioned so far might be
> condensable into the following sentence structure:
>
>
>
> “<source> observed <x> instances of <object> at <location>, <time-range>,
> via <detection-method>”
>
>
>
> This has decent (but not complete) overlap with Terry’s proposed fields, so
> maybe it means we are on the right track?
>
>
>
> As a side note, do we know how we are we capturing the outcome of this
> discussion? In the TAXII SC, we’ve been keeping a “Decisions” list [1], with
> links out to more detail as necessary. (Note that decisions does not mean
> that everything in there is set in stone – it just means the TAXII SC has
> general agreement on the principle. For e.g., the REST API, there’s still
> plenty to work on). Once we get most people agreeing on most things for a
> particular discussion, we could document them in a similar fashion and keep
> track of the open items; e.g., if we can’t agree on <Some-Field>, let’s mark
> it as an open question and move on to another topic.
>
>
>
> Thank you.
>
> -Mark
>
>
>
> [1] http://taxiiproject.github.io/taxii2/#decisions
>
>
>
> From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
> On Behalf Of Sarah Kelley
> Sent: Tuesday, October 27, 2015 7:18 AM
> To: Unknown Unknown <athiasjerome@gmail.com>; Jordan, Bret
> <bret.jordan@bluecoat.com>
> Cc: Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>;
> Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave
> <cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org
>
>
> Subject: Re: [cti-stix] Conceptul model for sighting
>
>
>
> I am a huge proponent of letting (almost) anything link to anything. In
> fact, limiting what can have an association/link/relationship with what is
> my current biggest frustration with Stix (we use workarounds to get around
> this limitation).
>
>
>
> I would add the possible use cases:
>
>
>
> My org observed 3 instances of this threat actor hitting our network
>
> My org observed 12 instances of the Poison Ivy TTP on our network
>
> Or even (though weaker):
>
> My org was hit by this particular campaign 27 times
>
>
>
>
>
>
>
> Sarah Kelley
>
> Senior CERT Analyst
>
> Center for Internet Security (CIS)
>
> Integrated Intelligence Center (IIC)
>
> Multi-State Information Sharing and Analysis Center (MS-ISAC)
>
> 1-866-787-4722 (7×24 SOC)
>
> Email: cert@cisecurity.org
>
> www.cisecurity.org
>
> Follow us @CISecurity
>
>
>
>
>
> From: <cti-stix@lists.oasis-open.org> on behalf of Jerome Athias
> <athiasjerome@gmail.com>
> Date: Monday, October 26, 2015 at 10:29 PM
> To: "Jordan, Bret" <bret.jordan@bluecoat.com>
> Cc: Terry MacDonald <terry@soltra.com>, "Baker, Jon" <bakerj@mitre.org>,
> "Jonathan Bush (DTCC)" <jbush@dtcc.com>, Cory Casanave
> <cory-c@modeldriven.com>, "cti-stix@lists.oasis-open.org"
> <cti-stix@lists.oasis-open.org>
> Subject: Re: [cti-stix] Conceptul model for sighting
>
>
>
> I do agree with Terry and Bret last emails and find the thread constructive
>
>
>
> Some use cases for bottom up (without full context for now):
>
>
>
> My org observed 12 instances of this malware artifact today (after AV
> signatures update)
>
> My org observed 100000 hits from this ip address in the last hours (all
> against ssh)
>
> My org observed 5000 times this excel file with macro (coming in emails) in
> the last 10 minutes
>
> My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007
> (against our VPN portal) this week-end
>
> My org observed 3 binaires signed with this stolen certificate this month
>
>
>
>
> On Tuesday, 27 October 2015, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
>
> In terms of volume, I see the Sighting object dwarfing all others, probably
> by several orders of magnitude.  Following the sighting object I see the
> relationship object being the next largest consumer of TAXII volume.  I also
> see the Sighting object along with the relationship object and its
> assertions working in a very social side of threat analysis and discovery,
> where a lot of back and forth takes place.
>
>
>
> Another option I can see is the Sighting object as being a seed for
> additional exploration or automated data enrichment.
>
>
>
> So let's make sure we get this and the relationship object figured out and
> done well.
>
>
>
> Bret
>
> Sent from my Commodore 64
>
>
> On Oct 26, 2015, at 1:45 PM, Terry MacDonald <terry@soltra.com> wrote:
>
> Hi Jon
>
>
>
>
>
>
>
> -          Sensor Alerts – As an example, an IDS or other sensor reports a
> match on some indicator. You will likely have some contextual information
> like times, ip addresses, host names, what indictor was matched, what was
> really seen, which IDS or sensor reported the alert, etc..  You probably
> don’t care about data markings, aggregate sighting information, and other
> fields. You probably do care about having compact efficient messages due to
> high volume.
>
>
>
> This is what I personally (speaking as myself) think of when I think of a
> Sighting. A description of an Observable Instance with some basic extra
> context.
>
>
>
> -          Organizational Sighting Reports – As an example, consider what is
> needed when an organization reports back to an ISAC/ISAO that an indicator
> has been matched (or sighted).
>
>
>
> To me this is no different to the first case. If an Indicator has been
> matched then a new Sighting object will be created under the namespace of
> the Organization. The Organization will then share that Sighting object back
> to the ISAC/ISAO (if the Org wants to) along with a Relationship object
> (also under the  namespace of the Org) that maps the ISAC Indicator to the
> Org’s Sighting Object. This can potentially be accompanied with an Incident
> object or Report object to give extra context if required.
>
>
>
> -          Aggregate Sightings Analysis – Consider the information structure
> that is needed to enable effective analysis of aggregate data from both of
> the above examples.
>
>
>
> In my personal opinion it is up to consumers to use the collected data to
> make their own decisions. Every Organization has their own institutional
> idea of trust. They alone know which sources of information make sense for
> them, their management’s risk appetite, the verticals they operate in and so
> forth. The analysis that one Organization performs to come to the conclusion
> of ‘High’ risk may actually be a ‘Low’ risk in another organization. Each
> Org must be ultimately responsible for its own analysis.
>
>
>
> But, that’s not to say that they can’t outsource that function to other
> organizations. Dedicated third-parties specializing in analyzing Sightings
> to extract TTPs and match those to Campaigns and Actors will become more
> prevalent. These third-party analysis services will provide analysis
> customized to the Organization’s structure/vertical/risk appetite which will
> help them extract the ‘why and ‘how’ from the ‘what’.
>
>
>
> I believe that the separate top-level Sighting object will provide us with
> the basic structure to begin the higher level analysis. I believe that this
> will then help third-parties to generate more ‘upper-level’ STIX data –
> Threat Actors, Campaigns and higher-order TTP in particular.
>
>
>
> Cheers
>
>
>
> Terry MacDonald
>
> Senior STIX Subject Matter Expert
>
> SOLTRA | An FS-ISAC and DTCC Company
>
> +61 (407) 203 206 | terry@soltra.com
>
>
>
>
>
> From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
> On Behalf Of Baker, Jon
> Sent: Saturday, 24 October 2015 2:10 AM
> To: Jonathan Bush (DTCC) <jbush@dtcc.com>; 'Jordan, Bret'
> <bret.jordan@bluecoat.com>; Cory Casanave <cory-c@modeldriven.com>
> Cc: cti-stix@lists.oasis-open.org
> Subject: RE: [cti-stix] Conceptul model for sighting
>
>
>
> The sightings conversation has historically suffered from a lack of shared
> understand of the sightings use cases and an attempt to address all the
> related sightings use cases with one complex model that does not really
> satisfy any single use case very well. I guess I am a fan of a bottom up
> approach focused on the use cases that are seen in the wild today.
>
>
>
> At a high-level I think that we can talk about sightings in several ways:
>
> There are probably others perspectives on sightings to consider as well. My
> recommendation is that we clearly state (use case)  each of the different
> kinds of sightings and that we independently flesh out the information
> requirements.
>
>
>
> At the same time we need to consider what is done today in each of these
> cases and what we think needs to be done in the future. I would like us to
> focus on developing a model for sightings that satisfies today’s needs and
> allows for expansion to what we think the future state should be. When it
> comes to sightings we simply don’t have enough experience to know what is
> really needed beyond supporting what people already do today.
>
>
>
> Thanks,
>
>
>
> Jon
>
>
>
> ============================================
>
> Jonathan O. Baker
>
> J83D - Cyber Security Partnerships, Sharing, and Automation
>
> The MITRE Corporation
>
> Email: bakerj@mitre.org
>
>
>
> 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' <bret.jordan@bluecoat.com>; Cory Casanave
> <cory-c@modeldriven.com>
> 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.
>
>
> ...
>
> This message and attachments may contain confidential information. If it
> appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments is
> strictly prohibited. Please notify the sender immediately and permanently
> delete the message and any attachments.
> . . .