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



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