[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Re: Observable Patterning
Adding my thoughts to the Test_Mechanism idea. In line with 'one way of doing things', my preference would be for all signature-ish things to be thought of in the same way. In my mind, "signature-ish things" includes SNORT, YARA, and STIX/CybOX patterns. This is a little different than what we have today, where CybOX patterns are separate from Test Mechanisms [1], and Test Mechanisms are intended to identify the CybOX pattern(s). The way I'm thinking would have all signature-ish things become peers. If I'm whiteboarding a use-case for signature/Indicator exchange, it would be something along the lines of: Title: Send a signature Description: An analyst creates a signature/indicator and chooses to share it with partner organizations. Main Success Scenario: 1. Org 1's analyst develops a signature (e.g., SNORT, CybOX pattern) 2. Org 1's analyst decides to share the signature; posts the signature to a TAXII Channel (perhaps as a STIX Indicator) 3. Org 2, which is subscribed to the TAXII Channel, receives the signature (or STIX Indicator) and 3a. The signature (or STIX Indicator) is entered into Org 2's internal review queue to decide whether to deploy the signature (or STIX Indicator) 4. The signature (or STIX Indicator) is acted on - either manually or automatedly - and is discarded or deployed (or some other action) Each one of these steps probably has a one-level-deeper set of steps associated with them (and a bunch of dependiencies/requirement), but at least for me, this is how I understand the workflow from Indicator creation to information sharing. Thank you. -Mark [1] http://stix.mitre.org/language/version1.2/xsddocs/XMLSchema/indicator/2.2/indicator.html -----Original Message----- From: Grobauer, Bernd [mailto:Bernd.Grobauer@siemens.com] Sent: Friday, September 25, 2015 7:02 AM To: terry.macdonald@threatloop.com; Kirillov, Ivan A. <ikirillov@mitre.org> Cc: Davidson II, Mark S <mdavidson@mitre.org>; trey@soltra.com; cti@lists.oasis-open.org Subject: RE: [cti] Re: Observable Patterning Hi, > I don't really see Test_Mechanisms as a candidate for reusing the > patterning that we've been discussing. Each Test_Mechanism rule is a > rule derived from the Indicators, and written in the tools native > language. The principle of having a test-mechanism derive from what is described within an indicator using observable patterns is the intended meaning, but this principle is not always followed: it may be quite complicated to describe in STIX/CybOX, what can be succinctly described in a certain pattern language or the authoring party simply does not want to bother with this -- so the STIX indicator is also used as a vehicle to exchange such a test mechanism, enriched with contextual information contained in the indicator and referenced/referencing STIX objects, but not containing corresponding observable patterns. I would guess that we will continue to see such use of a TestMechanism within an otherwise rather empty indicator (empty with respect to Observables), even if the pattern language is evolved such that in theory it could describe everything that is expressible in any thinkable test mechanism. > It doesn't make sense to me to have patterning in the > Test_Mechanism unless it is natively in the tool that uses the rules. I had made that proposal in one of my emails with the intent of encapsulating complexity. I can see why one would not want to use a test mechanism as container for STIX/CybOX containers -- after all, no other test mechanism would have references out of the test-mechanism blob, whereas a STIX pattern could have many references to objects/object properties defined elsewhere. But I really would like to get rid of AND/OR/...-composition on the level of indicators and push the whole pattern language into (oh no, here it comes) yet another STIX top level object STIX_Pattern or whatever. Then allow STIX_Patterns to reference other patterns for composition, but not Indicators. The reason is that the whole logical and temporal composition is really complicated. The Indicator is absolutely central to STIX, but like I said above, there may be use-cases to communicate things to look out for *without* the use of CybOX and CybOX patterning but via a test mechanism (or, I haven't given up on that idea, a STIX-standardized key/value-pair mechanism for communicating patterns). Now, if we encapsulate the complications of the pattern language in something that is removed from the Indicator level, then one can implement the non-patterning-part of STIX much easier in order to use it for use cases as described above. Also, using STIX for other domains (fraud and what not) as has been mentioned on the list yesterday, could become easier, since for these other domains, the full might of STIX patterns may not be needed ... or such domains may even need something else entirely. (Hm, I just realize that this reasoning would actually support making patterning part of CybOX as a CybOX-pattern-top-level object.) In closing, because I have proposed yet another top-level STIX entity: in one of his mails about a possible top-level targeting object, Aharon was concerned about making things too complicated by adding more and more top-level objects. That is a valid concern, but on the other hand, having huge schema definitions for objects that encompass all kinds of substructures, is also quite complicated. So, while we certainly should have good reasons for introducing new top-level objects, I would say that given the right circumstances, new top-level objects will actually decrease complexity. So, in short: - I fully agree that decoupling patterning and instances is the right way to go. - I would like to encapsulate patterns in a top-level construct that may be referenced by STIX indicators while removing not/and/or composition for indicators. - I am not quite sure yet whether the 'Pattern' top-level object would better be part of STIX or part of CybOX. If we think the patterning is reusable also for extended domains such as a possible SocEngOX (Social Engineering Observable EXchange) language and we think we will want to write things like (SocEng-Observation "Phone call from Mr. Evil") THEN (CybOX Email Object with sender "lucifer.evil@hell.com) then patterning is probably part of STIX rather than CybOX; otherwise, as a cyber-focused language, it might well be part of CybOX. Kind regards, Bernd ------ Bernd Grobauer, Siemens CERT
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]