On Thursday, 29 October 2015, Davidson II, Mark S <mdavidson@mitre.org> wrote:
You’ll know the server you got it from, but does that tell you who sent it?
Let’s say you have a TAXII Server for a sharing group. Org1 puts up a sighting, Org2 receives the sighting. How does Org2 know what organization produced the sighting if the sighting information is not contained in the data?
Thank you.
-Mark
From: Jason Keirstead [mailto:Jason.Keirstead@ca.ibm.com]
Sent: Thursday, October 29, 2015 9:26 AM
To: Jerome Athias <athiasjerome@gmail.com>
Cc: Davidson II, Mark S <mdavidson@mitre.org>; Sarah Kelley <Sarah.Kelley@cisecurity.org>; Jordan, Bret <bret.jordan@bluecoat.com>; 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
Question I have been pondering, with respect to trying to keep the mandatory fields as minimal as possible....
If it is assumed that the sighting is going to be reported via TAXII, which I would expect should be the majority of the cases - why do we need to have the producer as part of the message, when it should be able to be implied?
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
Jerome Athias ---2015/10/27 11:26:13 AM---I think we're doing well. I think the location and detection-method could be optional (in an
From: Jerome Athias <athiasjerome@gmail.com>
To: "Davidson II, Mark S" <mdavidson@mitre.org>
Cc: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, 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>
Date: 2015/10/27 11:26 AM
Subject: Re: [cti-stix] Conceptul model for sighting
Sent by: <cti-stix@lists.oasis-open.org>
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.
> . . .
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php