RE: [cti] Patterning Operators - CONTAINS

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

I interpret the difference to be IN uses the set literal (syntax), while INSUBSET uses a single literal that semantically represents a set of values (like a CIDR block). 

I'm concerned that this distinction will be lost on ... well... almost everyone.

> -----Original Message-----
> From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of
> Kirillov, Ivan A.
> Sent: Wednesday, October 26, 2016 3:03 PM
> To: Piazza, Rich <rpiazza@mitre.org>; Allan Thomson
> <athomson@lookingglasscyber.com>; cti@lists.oasis-open.org
> Subject: Re: [cti] Patterning Operators - CONTAINS
> 
> Good question – from our discussions, it’s primarily because you can
> effectively do the same thing with an OR (though I suppose the same is true
> of IN?):
> 
> 
> 
> “foo:bar ISSUBSET ‘4’ OR foo:bar ISSUBSET ‘5’ OR foo:bar ISSUBSET ‘6’”
> 
> 
> 
> Regards,
> 
> Ivan
> 
> 
> 
> From: Rich Piazza <rpiazza@mitre.org>
> Date: Wednesday, October 26, 2016 at 1:56 PM
> To: Ivan Kirillov <ikirillov@mitre.org>, Allan Thomson
> <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org"
> <cti@lists.oasis-open.org>
> Subject: Re: [cti] Patterning Operators - CONTAINS
> 
> 
> 
> Yes, but can I say “foo:bar ISSUBSET ‘(4, 5, 6)’?  If not, why not?
> 
> 
> 
> From: Ivan Kirillov <ikirillov@mitre.org>
> Date: Wednesday, October 26, 2016 at 3:55 PM
> To: Rich Piazza <rpiazza@mitre.org>, Allan Thomson
> <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org"
> <cti@lists.oasis-open.org>
> Subject: Re: [cti] Patterning Operators - CONTAINS
> 
> 
> 
> The key difference (as Greg pointed out) is that the RHS of IN takes a set of
> literal values (e.g., “4”,”5”,”6”), whereas the RHS of ISSUBSET is a single value
> that can specify a CIDR block (for instance).
> 
> 
> 
> Regards,
> 
> Ivan
> 
> 
> 
> From: Rich Piazza <rpiazza@mitre.org>
> Date: Wednesday, October 26, 2016 at 1:51 PM
> To: Ivan Kirillov <ikirillov@mitre.org>, Allan Thomson
> <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org"
> <cti@lists.oasis-open.org>
> Subject: Re: [cti] Patterning Operators - CONTAINS
> 
> 
> 
> I see the “IN” operator is still in the spec.  How is this different from
> ISSUBSET?
> 
> 
> 
> From: <cti@lists.oasis-open.org> on behalf of Ivan Kirillov
> <ikirillov@mitre.org>
> Date: Wednesday, October 26, 2016 at 3:41 PM
> To: Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-
> open.org" <cti@lists.oasis-open.org>
> Subject: Re: [cti] Patterning Operators - CONTAINS
> 
> 
> 
> The intent is to be broader than network containment matching, though
> that’s the current specified use case. The thought was that if we specify
> network-specific operators (e.g., ISSUBNET) these cannot be re-used for
> similar use cases down the road.
> 
> 
> 
> Regards,
> 
> Ivan
> 
> 
> 
> From: Allan Thomson <athomson@lookingglasscyber.com>
> Date: Wednesday, October 26, 2016 at 1:37 PM
> To: Ivan Kirillov <ikirillov@mitre.org>, "cti@lists.oasis-open.org"
> <cti@lists.oasis-open.org>
> Subject: Re: [cti] Patterning Operators - CONTAINS
> 
> 
> 
> Is the intent to specifically represent network containment. i.e. CIDR
> matching?
> 
> 
> 
> Or is it intended to be broader than just network matching.
> 
> 
> 
> allan
> 
> 
> 
> From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of
> "Kirillov, Ivan" <ikirillov@mitre.org>
> Date: Wednesday, October 26, 2016 at 12:18 PM
> To: "cti@lists.oasis-open.org" <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