Re: [cti] RE: Patterning Operators - CONTAINS

[John-Mark Gurney <jmg@newcontext.com>]

Back, Greg wrote this message on Wed, Oct 26, 2016 at 19:49 +0000:
> 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.

Forgot to address this issue in my email.  IN is not the same as
CONTAINS.  a IN (x, y, ...) is short hande for a == x OR a == Y ...,
and so not a proper set operation.

This means that we cannot repurpose IN w/o having confusing change of
behavior of the IN operator.  As Jason pointed out, Oracle uses a new
operator to handle IP subset identification.

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

It's easy to make simple cases fail.  I worked at nCircle when we were
doing IP/CIDR matching, and it isn't an easy task.

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

The first standard use for this is black lists.  Is this IP part of a
C&C network.

The second are things like, does the interface of this machine have
this IP on it's local subnet:
network-interface:network ISSUPERSET '192.168.1.5'

-- 
John-Mark