Re: [EXT] [cti-stix] IEP in STIX 2.1 - Discussion + Working Call Topic

I do not think we fully understand what this will mean for products that produce or consume STIX. The language as written basically means one can just drop them on the floor and pretend like they do not exist. I also do not feel like FIRST has addressed all of the feedback that we have given them, through all of the calls we have had on this topic.

To make this work, it seems like we really need a way for a client and server to negotiate and inform each other about the policies that they can support. TLP seemed easier to just filter on as there are only 3 levels that need handling. As such, I was not against including it in STIX. However, IEP is a different animal. It represents an outside standard that we are being asked to effectively bless at some level.

IEP represents a significantly complex matrix of options where most of them can not really be handled in a machine processable way. So if you code up support to parse and store IEP markings, then you will more than likely have to bubble everything up to a human for review.

Bret

Hey all,

Most of you have probably either been involved in the IEP work or have heard the term. In case you haven’t, IEP (Information Exchange Policy) is a language developed by the FIRST organization that’s intended to allow for more specificity and a broader set of policy statements than TLP. In addition to specifying a TLP level (talking about who you can share with) IEP also lets you specify what you can do with the data (e.g. actively block, monitor) and how you have to protect it (e.g. encrypt it in transit). It’s a machine-readable specification with a JSON representation that we can use in STIX.

Awhile back, Terry MacDonald asked if the TC wanted to include IEP in STIX 2.1. What that would mean is adding it as a mechanism that could be used to mark data…i.e., it would be treated similarly as TLP is now. At the time, pretty much everyone was supportive of that idea. Since then, we’ve been working about how exactly to do that. There have been some concerns raised and we want to make sure to fully understand what we’re doing before adding it.

The concerns mainly revolve around how a vendor can truly implement support for IEP. While it’s easy to parse a JSON schema, it’s harder to parse that JSON schema and understand, as a consuming tool, what to do when the IEP policy says you’re not allowed to actively block. It’s easy as an individual to say “don’t put this in my firewall”, but what can a TIP do to ensure that it complies? This is not necessarily different than TLP but IEP does have many more policy statements. Some people have been concerned about the lack of verifiability of the IEP policies in STIX and so don’t feel like it’s ready to be added now. Essentially it would be giving a stamp of approval to IEP and when a tool does something non-compliant (like is configured to send data to a firewall, and sends data marked with “do not block”) the feeling is that people would blame STIX.

On the other hand, there’s also been the view that we could add IEP to STIX with the understanding that it’s informative…much as TLP is now. Tools could parse the IEP and maybe handle some of it automatically or rely on user configuration to handle the rest of it (e.g. as today you can set up TLP filters) but there would be no conformance or interop requirements to validate that tools do it correctly, at least at first. Instead, it would be up to each consuming organization to ensure that the tools it bought allowed it to comply with the sharing agreements, including policies set in IEP. Some language we could add to the data markings section to clarify this both for IEP and TLP would be:

“Data marking support in this standard is present in order to facilitate data interchange within and amongst trust group communities. While the standard defines the methodology to communicate data markings, and also includes standard definitions for select marking types, it does not attempt to define how individual software implementations must or must not behave with respect to any individual marking. Understanding that the behavior of any individual software implementation with regard to data markings is highly context-specific and thus out of scope of this standard, support of any specific marking type is considered OPTIONAL.”

So basically as a TC it seems like we could go down one of two paths:

Take the time to address the implementability and verifiability issues that have been brought up, which probably means deferring IEP until a later release (and potentially getting much more involved in IEP to ensure that it works)
Add the statement above to the data markings section and include IEP as-is in STIX 2.1

Obviously there still needs to be a discussion about these options. Feel free to respond here over e-mail. We’ll also discuss it at the upcoming working call, tomorrow at 3pm EST (note the change from daylight savings time to standard time).

John

cti-stix message