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.
Capability
2.0
2.x
Never
Relationships
Standardized
Relationships
Relationships
pre-defined in STIX
X
User-Defined
Relationships
Ability
to use relationships that were not pre-defined in STIX
X
Indicator
Use Cases
Indicators
Basic
indicator object
X
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
X
Sightings
Ability
to create and share sightings of indicators, however it's done
X
Incident
Use Cases
Incident
Basics
Just
the basics needed to track incidents
X
Asset
Stub
A
stub of an asset model, abstracted out of Incident, likely a pointer
X
Complete
Asset Model
A
more complete asset model that defines many fields
Yes, ideally via referencing something else
Advanced
Incident
Impacts,
detailed analytics, etc.
X
"Investigation"
(pre-incident)
Something
to track "events", "investigations", and other activity that may not be an incident yet.
X
Analysis
Objects
Attack
Patterns
See
STIX 1.2 AttackPatternType
X
Exploits
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
X
Malicious
Infrastructure
See
STIX 1.2 InfrastructureType
X
Malicious
Tool
See
STIX 1.2 ToolType
Just the basics
Malware
See
STIX 1.2 MalwareType
X
Persona
See
STIX 1.2 PersonasType
(was just an identity)
X
Victim
Targeting
See
STIX 1.2 VictimTargetingType
X
Configuration/Misconfiguration
See
STIX 1.2 ConfigurationType
X
Vulnerability
See
STIX 1.2 VulnerabilityType
X
Weakness
See
STIX 1.2 WeaknessType
X
Attribution
& Tracking
Threat
Actor
See
STIX 1.2 ThreatActorType
X
Campaign
See
STIX 1.2 CampaignType
X
Intrusion
Set
Representation
of intrusion sets, separate from actors and campaigns
Undecided
Response
Actions
Course
of Action
See
STIX 1.2 CourseOfActionType
X
Automated
Course of Action
Structured
representation for automating courses of action
X
Data
Markings
Object-Level
Markings
Markings
applied to a complete top-level object (Level 1 Markings)
X
Field-Level
Markings
Markings
applied to individual fields within objects (Level 2 Markings)
X
TLP
Marking Definition
Representation
of a TLP marking
X
Copyright/TOU
Marking Definition
Representation
of Copyright/TOU markings
X
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
X
Reports
Report
object
X
Internationalization
Support
for STIX content in multiple languages/localizations
X
Basic
Identity
Small
set of critical properties
X
Full
Identity
Extensive
identity representation, similar to CIQ
X
References/Sources
References
to non-STIX content and information sources
X
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
X
Versioning
Ability
to version and revoke content
Undecided, leaning yes
Vendor-Defined
Fields
Definition
and conformance for how vendors can extend STIX
X
Representing
Confidence
Representation
of confidence in the accuracy of information
X
Representing
Impact / Potential Impact
Representations
of actual or potential impact of threats (e.g. for malware)
X
Custom
Vocabularies
Ability
to use custom (non-standard) vocabularies in places we have standard vocabularies defined
X
Opinion/Assert
Object
Ability
to represent opinions / assertions about STIX content created by others
X
STIX
Request/Response
Ability
to create asynchronous STIX requests and responses for information beyond a single TAXII server
X
Generic
Tagging
Ability
to tag STIX top-level objects with generic text
X
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.
-Mark
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.
Cheers
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:
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.
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.
John
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.