Re: [cti] Re: Patterning Operators

+1 to Mark's comments

On Wed, Oct 26, 2016 at 7:09 PM -0400, "Mark Clancy" <mclancy@soltra.com> wrote:

We need to build for the world we want not they one we have… today the majority of the indicators are simple and basically useless as a result. If we minimize the spec as ‘mvp’ and remove patterning in 18 months we will be nowhere better and still have simple and basically useless indicators with too many avoidable false positive's due to no ability to add context from the patterning.

We don't need stix 2.0 for that world.

Sent from my Windows 10 phone

From: Bret Jordan (CS)
Sent: Wednesday, October 26, 2016 6:32 PM
To: Mark Clancy; Back, Greg; Kirillov, Ivan A.; cti@lists.oasis-open.org
Subject: Re: [cti] Re: Patterning Operators - CONTAINS

You disagree that the majority of indicators today are simples matches? Or do you disagree that for the next 12-18 months we will simple matches still?

Bret

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Mark Clancy <mclancy@soltra.com>
Sent: Wednesday, October 26, 2016 3:23 PM
To: Bret Jordan (CS); Back, Greg; Kirillov, Ivan A.; cti@lists.oasis-open.org
Subject: RE: [cti] Re: Patterning Operators - CONTAINS

Completely disagree. Simple indicators are the root of the problem not something we should encourage. Patterning is the only thing that can make CTI data actually useful to operators. I get tons of complaints about ‘false positives’ because the simple indicator misses critical context that was known and available.

Sent from my Windows 10 phone

From: Bret Jordan (CS)
Sent: Wednesday, October 26, 2016 5:00 PM
To: Back, Greg; Kirillov, Ivan A.; cti@lists.oasis-open.org
Subject: [cti] Re: Patterning Operators - CONTAINS

Given that most Indicators today and probably for the next 12-18 months are going to be a simple match, it really feels like we are trying to solve all of future patterning all at once.

In an analogy, it feels like you are building an amazingly new Mclaren and the rest of STIX is still figuring out how to build horse and buggies for the dirt road. Yes, eventually we will get to super high performance freeways, and when we do, your Mclaren will be there waiting. But maybe we just need something a lot simpler for this first release.

Bret

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Back, Greg <gback@mitre.org>
Sent: Wednesday, October 26, 2016 1:49:39 PM
To: Kirillov, Ivan A.; cti@lists.oasis-open.org
Subject: [cti] RE: Patterning Operators - CONTAINS

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.

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

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

For these reasons, I would prefer a single-purpose operator “INSUBNET” with an ipv4-addr:value or ipv6-addr:value on the LHS and a CIDR block literal on the right. It’s a common enough use case that it’s critical (IMO) for MVP, without us needing to come up with a more general solution.

Greg

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Kirillov, Ivan A.
Sent: Wednesday, October 26, 2016 2:18 PM
To: 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

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

cti message