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] STIX MVP

Hey all,

Just as a reminder to respond on this if you haven’t already…as of now, we only have 8 responses. The plan was to discuss it on the call tomorrow so the more people that respond the better.

Just fill out the form below with an X and reply either to the list or to me. Also, if you don’t understand a row, feel free to skip it and we can discuss it on the call.








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

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

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)

Kill Chains

See STIX 1.2 KillChainType and KillChainPhaseType

Malicious Infrastructure

See STIX 1.2 InfrastructureType

Malicious Tool

See STIX 1.2 ToolType


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

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.

Rich Text

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


Ability to version and revoke content

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

Generic Tagging

Ability to tag STIX top-level objects with generic text

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Tuesday, March 29, 2016 at 12:23 PM
To: "cti-stix@lists.oasis-open.org" <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]