RE: [cti] Re: Patterning Operators - CONTAINS

["Back, Greg" <gback@mitre.org>]

I don't think anyone has suggested removing patterning entirely. 
I don't think that basic indicators are (basically or otherwise) "useless". 
I sincerely hope that removing some parts of patterning now doesn't mean we have to wait 18 months for another chance to add them.

I certainly agree that there are things that would be valuable to represent as indicators, that can't be represented with simple patterns. For example, malware that creates an executable file with a random name and adds a registry key that runs that file on startup. But even that scenario can't be represented using the current patterning language, which can't express relationships between two different property values.

The biggest issue with patterning right now, in my opinion, is the lack of clear definitions on what the "context" is that any pattern should be evaluated in. Network Sensors, host-based agents, and SIEM tools all have different operating models. Determining what counts as the "same observation" vs. "different observation" has profound implications on the way patterns are currently constructed. For a lot of patterns, the context seems underspecified to me, in the "do what I mean, not what I say" sense.

Having an "all or nothing" attitude towards patterning violates the spirit of MVP and iteration based on the collective experience we get from seeing prior versions used in practice.

Greg

> -----Original Message-----
> From: Mark Clancy [mailto:mclancy@soltra.com]
> Sent: Wednesday, October 26, 2016 6:09 PM
> To: Bret Jordan (CS) <Bret_Jordan@symantec.com>; Back, Greg
> <gback@mitre.org>; Kirillov, Ivan A. <ikirillov@mitre.org>; cti@lists.oasis-
> open.org
> Subject: RE: [cti] Re: Patterning Operators - CONTAINS
> 
> We need to build for the world we want not they one we have... today the
> majority of the indicators are simple and basically useless as a result. If we
> minimize the spec as 'mvp' and remove patterning in 18 months we will be
> nowhere better and still have simple and basically useless indicators with too
> many avoidable false positive's due to no ability to add context from the
> patterning.
> 
> We don't need stix 2.0 for that world.
> 
> 
> 
> Sent from my Windows 10 phone
> 
> 
> 
> From: Bret Jordan (CS) <mailto:Bret_Jordan@symantec.com>
> Sent: Wednesday, October 26, 2016 6:32 PM
> To: Mark Clancy <mailto:mclancy@soltra.com> ; Back, Greg
> <mailto:gback@mitre.org> ; Kirillov, Ivan A. <mailto:ikirillov@mitre.org> ;
> cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org>
> Subject: Re: [cti] Re: Patterning Operators - CONTAINS
> 
> 
> 
> You disagree that the majority of indicators today are simples matches?  Or
> do you disagree that for the next 12-18 months we will simple matches still?
> 
> 
> 
> 
> Bret
> 
> 
> 
> ________________________________
> 
> From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Mark
> Clancy <mclancy@soltra.com>
> Sent: Wednesday, October 26, 2016 3:23 PM
> To: Bret Jordan (CS); Back, Greg; Kirillov, Ivan A.; cti@lists.oasis-open.org
> Subject: RE: [cti] Re: Patterning Operators - CONTAINS
> 
> 
> Completely disagree. Simple indicators are the root of the problem not
> something we should encourage. Patterning is the only thing that can make
> CTI data actually useful to operators. I get tons of complaints about 'false
> positives' because the simple indicator misses critical context that was known
> and available.
> 
> 
> 
> Sent from my Windows 10 phone
> 
> 
> 
> From: Bret Jordan (CS) <mailto:Bret_Jordan@symantec.com>
> Sent: Wednesday, October 26, 2016 5:00 PM
> To: Back, Greg <mailto:gback@mitre.org> ; Kirillov, Ivan A.
> <mailto:ikirillov@mitre.org> ; cti@lists.oasis-open.org <mailto:cti@lists.oasis-
> open.org>
> Subject: [cti] Re: Patterning Operators - CONTAINS
> 
> 
> 
> Given that most Indicators today and probably for the next 12-18 months are
> going to be a simple match, it really feels like we are trying to solve all of
> future patterning all at once.
> 
> 
> 
> 
> In an analogy, it feels like you are building an amazingly new Mclaren and the
> rest of STIX is still figuring out how to build horse and buggies for the dirt
> road.  Yes, eventually we will get to super high performance freeways, and
> when we do, your Mclaren will be there waiting.  But maybe we just need
> something a lot simpler for this first release.
> 
> 
> 
> 
> Bret
> 
> 
> 
> 
> ________________________________
> 
> From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Back,
> Greg <gback@mitre.org>
> Sent: Wednesday, October 26, 2016 1:49:39 PM
> To: Kirillov, Ivan A.; cti@lists.oasis-open.org
> Subject: [cti] RE: Patterning Operators - CONTAINS
> 
> 
> I strongly support any plan that makes the LHS always be an object path and
> RHS always be a value, so I would be OK with this.
> 
> 
> 
> I'm a little concerned for three reasons:
> 
> 
> 
> -          There's already the IN operator, where the RHS is a set (in this case, a
> literal set of values vs the more-abstract notion of a CIDR block). I agree
> there's some risk/complexity in allowing a "special" case of IN to be where
> the LHS is an ipv4-addr:value or ipv6:value, and the RHS is a CIDR block, and
> for this reason separate operators are OK. But I expect a lot of people to
> want (ipv4-addr:value IN "192.168.0.0/16") to work if both IN and INSUBSET
> support arbitrary sets.
> 
> -          The "set" semantics are not entirely clear. A single IP address is not a
> subset of anything. *The set consisting of* a single IP address may be a
> subset of a larger set of IPs. Also, what If I want to represent a more arbitrary
> set of IPs where the last octet is 255 (X.X.X.255 or netmask
> 00000000000000000000000011111111) or more complex bit patterns? It's still
> technically a "subset", but not really representable using CIDR/IP-literal
> notation.
> 
> -          The examples currently in the document (ipv4-addr:value ISSUBSET
> '192.168.10.0/8' and '192.168.10.0/8' ISSUPERSET ipv4-addr:value) actually
> mean the same thing, so I would be concerned about duplicate ways of
> expressing the same thing. I can't think of a good use case for the
> ISSUPERSET version in the message below when it comes to STIX indicators
> matching observed data. You won't often observe a CIDR block, except
> maybe in the case of "this AS is assigned this CIDR block", which could be
> expressed as a pseudo pattern "find me a AS whose assigned IPs contains
> 1.2.3.4".  But I don't think the current autonomous-system object supports
> this data.
> 
> 
> 
> For these reasons, I would prefer a single-purpose operator "INSUBNET"
> with an ipv4-addr:value or ipv6-addr:value on the LHS and a CIDR block literal
> on the right. It's a common enough use case that it's critical (IMO) for MVP,
> without us needing to come up with a more general solution.
> 
> 
> 
> Greg
> 
> 
> 
> From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of
> Kirillov, Ivan A.
> Sent: Wednesday, October 26, 2016 2:18 PM
> To: cti@lists.oasis-open.org
> Subject: [cti] Patterning Operators - CONTAINS
> 
> 
> 
> As we briefly mentioned on last week's TC call, one of the open issues in the
> Patterning specification is around the CONTAINS Comparison Operator:
> 
> 
> 
> Set Operator
> 
> Description
> 
> Example
> 
> a CONTAINS b
> 
> a and b MUST be either an Object Path that uses either the ipv4-addr or ipv6-
> addr Object to specify an IPv4 or IPv6 address value OR a string that
> represents a particular IPv4 or IPv6 address. b MUST be wholly contained
> within a.
> 
> '192.168.10.0/24' CONTAINS ipv4-addr:value
> 
> 
> 
> The issues around this operator are two-fold:
> 
> 
> 
> 1.       Unlike all other Comparison Operators, CONTAINS supports Object
> Paths in both arguments (i.e., not just on the left-hand side). This was done
> intentionally, to permit the expression of patterns around blacklisting (e.g.,
> that a particular IP address falls into a particular CIDR range), as well as testing
> whether a particular subnet contains a specific IP address:
> 
> a.       '192.168.10.0/24' CONTAINS ipv4-addr:value
> 
> b.       ipv4-addr:value CONTAINS  '192.168.10.0'
> 
> 2.       There's been some consternation around the name "CONTAINS" -
> some find it confusing because they think it's a substring operator (as in
> many programming languages), others just don't think it's clear enough. On
> the second point, the issue with changing the name to something more
> specific (e.g., INSUBNET) is that also changes the abstract nature of the
> operator, meaning that it can't be used with additional Cyber Observable
> Objects in the future.
> 
> 
> 
> An idea that Trey, John-Mark, and I have kicked around is to replace this
> operator with two generic set operators, ISSUBSET and ISSUPERSET:
> 
> 
> 
> a ISSUBSET b
> 
> b MUST be a subset of a.
> 
> ipv4-addr:value ISSUBSET '192.168.10.0/8'
> 
> a ISSUPERSET b
> 
> b MUST be wholly contained within a.
> 
> ipv4-addr:value ISSUPERSET '192.168.10.0'
> 
> 
> 
> That way we can still support the blacklisting use case, consistently have
> Object Paths on the left-hand side of every operator, and also retain a level
> of abstraction that permits use with future Objects. Any thoughts on this?
> Does this seem like a preferable alternative to CONTAINS?
> 
> 
> 
> Regards,
> 
> Ivan