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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] Observable Patterning


Hi Bret,

A good point. The rationale behind the Sighting object is specifically just so that people can report what they've seen. The Incident object represents the fact that the producing organization officially responded in some way; that their Incident Response process was enacted. I see an Incident object as a collection of details describing a situation, and one of the details collected is the list of Sightings objects that are part of the Incident.

The Sighting object would be related from the Incident object with the top-level relationship object I've been banging on about for the last year :). This would allow producers to easily add new Sightings to existing ongoing Incidents as simply as sending the Sighting object and a corresponding Relationship object describing the link. It would also open up the possibility of 'shared Incidents', where a group could all pool together their Sightings, patterns, etc to better describe and track a global incident of some kind (think Shellshock or some other vulnerability with a logo).

Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant





On 22 September 2015 at 08:58, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
The only concern I have is making sure the sighting object does not begin to look like an incident object.   


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 Sep 21, 2015, at 16:39, Terry MacDonald <terry.macdonald@threatloop.com> wrote:

I would have to agree In principal this sounds like a sensible idea, but I share the same concerns that Jason has around how this will have knock-on effects with other downstream protocols.

Ivan, I liked your issue #381 (https://github.com/CybOXProject/schemas/issues/381). It does make sense to pull out the 'patterning' structure to a separate structure, and I agree that having it within STIX makes sense. I think a nice STIX alignment could be as follows:
  • top-level STIX Indicator object that uses the patterning construct described in #381 to describe what people should look out for (describe clues to monitor for)
  • new top-level STIX Sighting object that uses CyboX Observable Instances to describe what people have seen (describing history)
This would give a nice separation of functionality between a STIX Indicator and Sighting, making it easier for people to add third-party relationships between sightings and indicators, and would make it much easier for people learning STIX to get their head around. 

The patterning construct in #381 reminds me quite a bit of the STIX ObservableComposition - possibly further confirmation that STIX is the right place for it to sit?


Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant





On 22 September 2015 at 04:33, Kirillov, Ivan A. <ikirillov@mitre.org> wrote:
Agreed, that’s definitely the question we need to be asking with regards to where patterning should live. I think this ultimately comes down to whether having a single patterning implementation is useful in multiple contexts, i.e., if a CybOX pattern is used in a MAEC or DFAX instance (both users of CybOX), does it (or can it) signify something else than if the pattern is used in STIX instance? For example, a pattern could potentially be used to describe a set of filenames created by a particular malware instance in MAEC. However, this could also be done in a MAEC-specific manner, without needing all of the heavyweight structure and semantics of an Indicator-based pattern. My feeling is that trying to support different contexts with a single Indicator-focused pattern structure is going to be messy and more trouble than it’s worth.

Regards,
Ivan

From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead
Date: Monday, September 21, 2015 at 2:04 PM
To: Ivan Kirillov
Cc: "cti@lists.oasis-open.org"
Subject: Re: [cti] Observable Patterning

"Regarding 2), it seems to me that patterning is inherent to Indicators, and thus should be part of STIX. I just can’t see the use case for a CybOX Observable with a pattern that stands on its own, or is used in a non-Indicator context. This would also serve to greatly simplify CybOX, as it would mean that CybOX can ONLY capture instances of cyber data.
"

While I tend to agree, I am curious if moving patterning to the Indicator level (which implies removing existing patterning from CybOX) would affect other non-STIX uses of CybOX (such as the DFAX standard I recently found out about). If the non-STIX users of CybOX also need patterning, then it seems to push for patterning to be part of CybOX, not STIX.

-
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


<graycol.gif>"Kirillov, Ivan A." ---09/21/2015 02:47:51 PM---Relaunching this as a separate thread based on Jerome’s suggestion, so as to not further hijack the


From: "Kirillov, Ivan A." <ikirillov@mitre.org>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 09/21/2015 02:47 PM
Subject: [cti] Observable Patterning
Sent by: <cti@lists.oasis-open.org>





Relaunching this as a separate thread based on Jerome’s suggestion, so as to not further hijack the discussion around Bernd’s suggested refactoring.

I think there are a few broad questions around this topic that we can touch upon here:

1. What capabilities should STIX/CybOX patterning have?
2. Where should STIX/CybOX patterning live?
3. Should patterns have their own implementation/structure, or continue to be embedded in Observables/Objects?

As far as 1) I would say the following, as a straw man:

* Conditional operators
* AND
* OR
* NOT
* Basic temporal operators
* FOLLOWED_BY
* WITHIN
* String matching
* EQUALS
* DOES_NOT_EQUAL
* CONTAINS
* DOES_NOT_CONTAIN
* Basic arithmetic operators
* >
* <
* >=
* <=
* Regular Expressions
* PCRE compatible
* Variable substitution

Regarding 2), it seems to me that patterning is inherent to Indicators, and thus should be part of STIX. I just can’t see the use case for a CybOX Observable with a pattern that stands on its own, or is used in a non-Indicator context. This would also serve to greatly simplify CybOX, as it would mean that CybOX can ONLY capture instances of cyber data.

With regards to 3), I see lots of advantages to having a separate structure for patterns, which I’ve documented in the corresponding CybOX issue [1]. The short of it is that it will get rid of the instance/pattern duality, allow for the creation of a domain-specific patterning language (necessary for more complex pattern expressions), and also give us the flexibility to move patterning out to wherever makes the most sense (whether it’s STIX or somewhere else).

[1] https://github.com/CybOXProject/schemas/issues/381

Regards,
Ivan



---------------------------------------------------------------------
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





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