OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti-stix] RE: STIX MVP

Thanks Terry and Mark, great feedback. I talked it over with Mark on slack a little and decided to add the columns Terry suggested. This way we can tell whether a “not MVP” vote is really saying do it later or actually saying don’t do it at all. I also saw comments about certain rows not being clear so I added explanations to all of them.

Lastly, if you’re comfortable making them public, please send your thoughts to the list so we can see and discuss them. If not, send them directly to me. I’ll keep track of all the responses I see and update the doc accordingly.

Here are my responses.






Standardized Relationships

Relationships pre-defined in STIX


User-Defined Relationships

Ability to use relationships that were not pre-defined in STIX


Indicator Use Cases


Basic indicator object


CybOX Indicator Patterns

Use of "native" CybOX patterning for indicator patterns

Just the basics

Third-Party Indicator Patterns

Use of Snort, Yara, OpenIOC, and other signature formats as patterns



Ability to create and share sightings of indicators, however it's done


Incident Use Cases

Incident Basics

Just the basics needed to track incidents


Asset Stub

A stub of an asset model, abstracted out of Incident, likely a pointer


Complete Asset Model

A more complete asset model that defines many fields

Yes, ideally via referencing  something else

Advanced Incident

Impacts, detailed analytics, etc.


"Investigation" (pre-incident)

Something to track "events", "investigations", and other activity that may not be an incident yet.


Analysis Objects

Attack Patterns

See STIX 1.2 AttackPatternType



See STIX 1.2 ExploitType (note: NOT ExploitTargetType)

Has been a stub since 1.0, do we continue that?

Kill Chains

See STIX 1.2 KillChainType and KillChainPhaseType


Malicious Infrastructure

See STIX 1.2 InfrastructureType


Malicious Tool

See STIX 1.2 ToolType

Just the basics


See STIX 1.2 MalwareType



See STIX 1.2 PersonasType (was just an identity)


Victim Targeting

See STIX 1.2 VictimTargetingType



See STIX 1.2 ConfigurationType



See STIX 1.2 VulnerabilityType



See STIX 1.2 WeaknessType


Attribution & Tracking

Threat Actor

See STIX 1.2 ThreatActorType



See STIX 1.2 CampaignType


Intrusion Set

Representation of intrusion sets, separate from actors and campaigns


Response Actions

Course of Action

See STIX 1.2 CourseOfActionType


Automated Course of Action

Structured representation for automating courses of action


Data Markings

Object-Level Markings

Markings applied to a complete top-level object (Level 1 Markings)


Field-Level Markings

Markings applied to individual fields within objects (Level 2 Markings)


TLP Marking Definition

Representation of a TLP marking


Copyright/TOU Marking Definition

Representation of Copyright/TOU markings


Consensus "STIX Default" Marking Definition

Representation of a more complete, consensus, "better than TLP" marking

Let another standards body do it

Cross-Cutting Capabilities

Packaging around TLOs (Package object)

STIX "package" object, whatever that turns into



Report object



Support for STIX content in multiple languages/localizations


Basic Identity

Small set of critical properties


Full Identity

Extensive identity representation, similar to CIQ



References to non-STIX content and information sources


Defensive Tools

Representation of information about tools used for defense or to create content.

Just the basics

Rich Text

HTML, Markdown, or some other rich text format for descriptions



Ability to version and revoke content

Undecided, leaning yes

Vendor-Defined Fields

Definition and conformance for how vendors can extend STIX


Representing Confidence

Representation of confidence in the accuracy of information


Representing Impact / Potential Impact

Representations of actual or potential impact of threats (e.g. for malware)


Custom Vocabularies

Ability to use custom (non-standard) vocabularies in places we have standard vocabularies defined


Opinion/Assert Object

Ability to represent opinions / assertions about STIX content created by others


STIX Request/Response

Ability to create asynchronous STIX requests and responses for information beyond a single TAXII server


Generic Tagging

Ability to tag STIX top-level objects with generic text


From: Mark Davidson <mdavidson@soltra.com>
Date: Wednesday, March 30, 2016 at 7:23 AM
To: Terry MacDonald <terry@soltra.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] RE: STIX MVP

At first I wanted the 2.x vs “never” distinction, but I’m now realizing we probably don’t want to spend much time discussing the difference between 2.x/never. It might be useful to capture, but I think the high value distinction is in/out for 2.0.

I think that once we get an in/out list for 2.0 (thank you John for doing this – I can already see it’s going to be a lot of work) I think it might make sense to prioritize this list. There’s a few methods out there, and we’d just have to pick one that’s supported by Kavi/SurveyMonkey/etc. 
Note: I toyed with survey monkey for five minutes and found out there is a “ranking” question we could use – example here https://www.surveymonkey.com/r/VNSPCZL. SurveyMonkey supports emailing the survey (instead of a web link) so I think we could have sufficient access controls.

Thank you.

From: <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry@soltra.com>
Date: Tuesday, March 29, 2016 at 7:41 PM
To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] RE: STIX MVP

I started going through this list today, but there are somethings in here that need further clarification about how much support we’ll aim to support in each version of STIX. For example, I’d be happy to support a fairly simple identity object that specifies some simple information about Identity for STIX v2.0, but I wouldn’t necessarily support the full CIQ implementation of CIQ as part of the STIX v2.0 MVP.


In other words, some of these topics are potentially very large rabbit holes to do down, and yet if we start of with basic functionality then they are achievable for STIX v2.0 first release.


Could we please change the headings in the table provided to be:

·         This release (2.0)             

·         Future releases (2.x)      

·         Not Required


This will allow people to say what they don’t want in there, and to understand that not having things now still means they will happen in the future.




Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com



From:cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Wednesday, 30 March 2016 3:23 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] STIX MVP


Hey everyone,


On our working group call today, one of the things we talked through was nailing down topics for the STIX 2.0 MVP (minimally viable product). To get things started, I put together the following notional checklist after looking at what was in STIX 1.2, our draft for 2.0, and the issue tracker: https://docs.google.com/document/d/1yvqWaPPnPW-2NiVCLqzRszcx91ffMowfT5MmE9Nsy_w/edit#


I have two requests for each of you:


  1. Take a look through that list and make sure it looks complete. Are there any topics that we’ve talked about that I forgot? Keep in mind we don’t want to go into excruciating detail…high-level concepts are MVP, not specific implementations. If you can think of any, suggest them either in the document or as a reply to this message. Also, if you don’t understand some of the rows let us know.
  2. Looking through the items that are there, let us know whether you think we should cover them in STIX 2.0 and, if not, STIX 2.1 (i.e. Immediately schedule them for after the 2.0 release). I’d suggest that rather than adding comments directly into the document you reply via e-mail…copy the table in and fill it out completely, give us a list of things you think MUST be in/out, or something in between. The editors will keep track of those comments and update the numbers in the document as responses come in.

We’ll regroup on the working group call next week. Depending on how many responses we’ve gotten we can hopefully make progress towards marking things definitely yes or definitely no, then talk about the things in the middle. What we discussed on the call is that we’ll get to some rough consensus on a final checklist that we can have an official ballot on.




PS: As I finished typing this up I realized that both STIX co-chairs are out so I’m kind of out on a limb here. Sean and Aharon may have other ideas when they get back, but minimally this approach seems to make sense for the time being to get us all on the same page even if they have a different path towards solidifying it.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]