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