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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[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>
Date: Tuesday, November 7, 2017 at 1:43 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Working call notes Nov 6, 2017

 

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>
Date: Tuesday, November 7, 2017 at 4:09 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Working call notes Nov 6, 2017

 

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

 

sarah.kelley@cisecurity.org

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]