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