Patterning Operators - CONTAINS

["Kirillov, Ivan A." <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:

 

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