[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [EXT] Re: [cti] Working call notes Nov 6, 2017
I support 1+5 with the simple caveats I spelled out on the phone, namely:
1) We be super careful with conformance language 2) We not do something in interop that then makes it somehow required.
Bret
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Sent: Tuesday, November 7, 2017 2:54:35 PM To: Wunder, John A.; cti@lists.oasis-open.org Subject: [EXT] Re: [cti] Working call notes Nov 6, 2017 I think Option 1+5 seems a reasonable approach.
regards
Allan
From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Unfortunately the slide deck I presented seems to have disappeared, computers are hard! But, here are the options we talked through on the call that are referenced from the notes that Sarah sent. Note that the order is different than my earlier e-mail.
Option 1: Add language to the data markings portion of the specification to specify that markings are informational from a STIX perspective. “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.”
Option 2: Defer including IEP for STIX 2.1 and take the time to address the implementability and verifiability issues that have been brought up with IEP
Option 3: Add a property to data markings to specify whether consumers must understand them or not (i.e. may_understand vs. must_understand) <- Proposed by Mark Davidson on the call
Option 4: Specify that TLP is always a must_understand and IEP is always a may_understand. <- Proposed by Chris Ricard on the call
Option 5: Add the list of markings that must/may be understood to TAXII to specify as part of a TAXII collection or channel. <- Proposed by Terry MacDonald on the call
John
From: <cti@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Here are the notes from the working call we just finished.
Sarah Kelley Senior Cyber Threat Analyst Multi-State Information Sharing and Analysis Center (MS-ISAC) 31 Tech Valley Drive East Greenbush, NY 12061
518-266-3493 24x7 Security Operations Center SOC@cisecurity.org - 1-866-787-4722
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments
is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]