Links to review from TC call

All,

Thanks for dialing to the working call this week, either Session #1 or Session #2. Hopefully you find these useful, in particular if you aren’t always able to keep up with all the conversations.

I’ll apologize in advance for the long e-mail. As we mentioned, there are a few topics that we’re still finalizing for STIX 2.1. If you have time, it would be great to get more feedback on this. The timelines are important: in order to get 2.1 and all the stuff that’s done out in a reasonable time, we’ve timeboxed the remaining conversations. If, after the timeline is up, we still don’t have good consensus then we’ll defer the topic to 2.2.

I know there are a lot of topics here. If you only have limited time, start at the top and work your way down (feel free to skip topics that don’t apply to you).

Thanks!

John

Malware

Malware is close to done and open for review. Please review the current approach here: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.73mue8q00k8 and provide feedback. Considering how critical it is, we want to make sure to get it in 2.1.

Assertion

The assertion capability is intended to capture a set of assertions made by an information source about a STIX Object, such as a categorization or a threat (risk) score. The running consensus now, based on the F2F and working call, is to focus on:

a capability for producers to provide this data about their own objects
providing data on observed-data and indicator
Threat score and categorizations from an open vocab

Thus, the current proposed approach includes a set of properties on the indicator and observed-data objects, which could be added to other objects in 2.2+. Please review th

Timeline: 2 more working calls

Action: Review the proposal linked below and respond on the list with whether you agree with the approach, have changes/suggestions, comments, etc. In particular, what other values should be added to assertion-category-ov? Alternatively, should we just defer this topic until 2.2+?

Link (Working Concepts): https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.qxvz3vox3ksj

Incident/Event

The incident/event object is intended to capture information about suspicious activity, including incidents. We’ve gone back and forth on this topic over the next few weeks, so the running consensus now based on the F2F is to focus on a minimal capability leveraging the Grouping object. The Grouping object would have a context field with a value of suspicious-event to indicate activity that’s suspicious. There wouldn’t be any other structured fields, just a set of references to other content that are a part of the suspicious activity.

Note that this object is the same Grouping object that we discussed a few weeks ago with the MISP team. They’re sending across similar groupings of content, including suspicious activity. To meet some of their requirements, there’s also a label on Grouping to indicate when information is preliminary.

Timeline: 2 working calls, starting after Assertion finishes

Action: Review the approach linked below. Would that work for your minimal use case? Should we just defer the entire concept until a later release? Should we hold up 2.1 (perhaps significantly, given how little progress we’ve made recently) to spend more time on this topic and get an object with more structured fields? Also, review the e-mail that Sean sent and provide comments.

Link: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.t56pn7elv6u7

Infrastructure

The infrastructure object/capability is intended to capture information about, primarily, adversary infrastructure (C2 servers, e-mail relays, malware delivery sites, botnets, etc.). We’ve also gone back and forth on this topic a bit, with some pretty big disagreements on approach:

Do we need infrastructure at all?
Would the object capture individual pieces of infrastructure, or a collection of infrastructure used together?
Is the best approach via a new SDO, or is it something in Assertion or some other capability?

Given the still large disagreements, it seemed like the best approach was to focus on modeling different reports using the different proposals. If you’re interested in this topic, we could use your help modeling and talking through the approaches. If you’d rather wait until there’s something more complete to review, we should be ready in about a month.

Timeline: 2-3 more working calls, starting after Incident/Event finishes

Action: Send in any reports that you think capture infrastructure information. If you want to get more involved in actually modeling, join the #infrastructure channel on Slack or reach out to myself, Bret, or Rich Struse.

Link: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.maky5z1n51ds

Socket Address

There’s a new object that was added to capture some malware information, Socket Address. There are still some open questions about it, in particular how/whether to restrict the protocols to only those relevant at layers 3/4.

COA

COA (in particular automated COA) is being discussed in a mini-group. Their working document is here: https://docs.google.com/document/d/1zXV5WEmyLUbKiSpuHgywu5-LLrJVd91d7OP3nQBB7qM/edit

They could use, in particular, feedback on the roadmap and which capabilities are most important near-term.

IEP

I spoke to the FIRST folks recently, and they’re hoping to have an update to IEP (Information Exchange Protocol), or TLP++, soon. That update will be a bit more focused and will allow consuming specifications to indicate more about what IEP means for that specification. Once that gets sent out, please review it and we can decide whether to discuss on a working call to include for 2.1 or to defer to 2.2.

John

cti message