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: [cti] Re: [EXT] RE: [cti] RE: [Non-DoD Source] Re: [cti] Working call agenda 10/30/28


Hi Bret,

 

Can you give some reasons why âmedusaâ, as explained by Sarah below, isnât viable (even though it was named after an evil monster â)?

 

BTW, as John pointed out in his mail this morning â his âcurrentâ proposal is more like (c) Â

 

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ Rich

 

From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, October 31, 2018 at 10:25 PM
To: "Kelley, Sarah E." <skelley@mitre.org>, "Mates, Jeffrey CIV DC3/TSD" <Jeffrey.Mates@dc3.mil>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Rich Piazza <rpiazza@mitre.org>, Sean Barnum <sean.barnum@FireEye.com>
Subject: [cti] Re: [EXT] RE: [cti] RE: [Non-DoD Source] Re: [cti] Working call agenda 10/30/28

 

The medusa option is evil.  Can we please not go down that path?  It was voted down unanimously at the F2F. 

 

Bret


From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Kelley, Sarah E. <skelley@mitre.org>
Sent: Wednesday, October 31, 2018 11:13:36 AM
To: Mates, Jeffrey CIV DC3/TSD; Jason Keirstead
Cc: cti@lists.oasis-open.org; Piazza, Rich; Sean Barnum
Subject: [EXT] RE: [cti] RE: [Non-DoD Source] Re: [cti] Working call agenda 10/30/28

 

The âmedusaâ proposal was basically this:

 

 

cid:image003.jpg@01D4711B.84310DD0

Itâs labeled as âSRO++â because we donât currently have a way for an SRO to point inside of an SDO. I believe Rich P.âs suggestion is basically a way to allow that to happen.

 

Thanks,

 

Sarah Kelley

Lead Cybersecurity Engineer, T8B2

Defensive Operations

The MITRE Corporation

703-983-6242

skelley@mitre.org

cid:image006.png@01D0A90C.2B5B2680

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Mates, Jeffrey CIV DC3/TSD
Sent: Wednesday, October 31, 2018 10:45 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: cti@lists.oasis-open.org; Piazza, Rich <rpiazza@mitre.org>; Sean Barnum <sean.barnum@FireEye.com>; Kelley, Sarah E. <skelley@mitre.org>
Subject: RE: [cti] RE: [Non-DoD Source] Re: [cti] Working call agenda 10/30/28

 

I apologize for my rudeness.  I simply wanted to bring up that point that a similar proposal was discussed at the face to face and voted down.

 

Jeffrey Mates, Civ DC3/TSD

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Computer Scientist

Defense Cyber Crime Institute

jeffrey.mates@dc3.mil

410-694-4335

 

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Wednesday, October 31, 2018 10:36 AM
To: Mates, Jeffrey CIV DC3/TSD <Jeffrey.Mates@dc3.mil>
Cc: cti@lists.oasis-open.org; Piazza, Rich <rpiazza@mitre.org>; Sean Barnum <sean.barnum@FireEye.com>; Kelley, Sarah E. <skelley@mitre.org>
Subject: RE: [cti] RE: [Non-DoD Source] Re: [cti] Working call agenda 10/30/28

 

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.




I don't know what 'medusa' is... but thisoption as Rich has proposed below is actually for the most part backwardscompatible with STIX 2.0. The code only needs to look at the relationshipmechanics to determine if it should reach inside the observable to an atomicelement or not.

-
Jason Keirstead
Lead Architect - IBM Security Connect
Caution-www.ibm.com/security

"Things may come to those who wait, but only the things left by thosewho hustle." - Unknown




From:       "Mates, JeffreyCIV DC3/TSD" <Jeffrey.Mates@dc3.mil>
To:       Jason Keirstead <Jason.Keirstead@ca.ibm.com>,"Piazza, Rich" <rpiazza@mitre.org>
Cc:       "cti@lists.oasis-open.org"<cti@lists.oasis-open.org>, Sean Barnum <sean.barnum@FireEye.com>,"Kelley, Sarah E." <skelley@mitre.org>
Date:       10/31/2018 11:32 AM
Subject:       RE: [cti] RE:[Non-DoD Source] Re: [cti] Working call agenda 10/30/28





This is a variant of themedusa option, which was shot down at the face to face because it wasnâta full fix and still broke a fair bit of stuff.
 
Jeffrey Mates, Civ DC3/TSD
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
jeffrey.mates@dc3.mil
410-694-4335
 
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent:
Wednesday, October 31, 2018 10:23 AM
To:
Piazza, Rich <rpiazza@mitre.org>
Cc:
cti@lists.oasis-open.org; Mates, Jeffrey CIV DC3/TSD <Jeffrey.Mates@dc3.mil>;Sean Barnum <sean.barnum@FireEye.com>; Kelley, Sarah E. <skelley@mitre.org>
Subject:
Re: [cti] RE: [Non-DoD Source] Re: [cti] Working call agenda10/30/28

 
All active links contained in thisemail were disabled. Please verify the identity of the sender, and confirmthe authenticity of all links contained within the message prior to copyingand pasting the address to a Web browser.





I could get behind this idea, or some variantof it. It is a variant ofwhat John Wunder proposed at the F2F.


-
Jason Keirstead
Lead Architect - IBM.Security

Caution-Caution-www.ibm.com/security < Caution-Caution-www.ibm.com/security > 

"Things may come to those who wait, but only the things left by thosewhohustle." - Unknown





From:      
"Piazza,Rich"<rpiazza@mitre.org>
To:      
Jason Keirstead<Jason.Keirstead@ca.ibm.com>,"Mates, Jeffrey CIV DC3/TSD"<Jeffrey.Mates@dc3.mil>
Cc:      
"cti@lists.oasis-open.org"<cti@lists.oasis-open.org>,Sean Barnum <sean.barnum@FireEye.com>,"Kelley, Sarah E."<skelley@mitre.org>
Date:      
10/31/201811:15 AM
Subject:      
Re: [cti]RE:[Non-DoD Source] Re: [cti] Working call agenda 10/30/28






I have a compromise suggestion â and asa compromise â Iâm sure no onewill like it, but here goes.

As I looked at the various examples thatSean and John came up with, I wasstruck on how similar they really were. As Sean said, the semantics isbasically the same.  It seems to bethere are two main issues here:

  • Should we change observed_data in a minorrelease?
  • How can we have relationships between SDOsandsimple cyber observables

 
Here is the idea:
Letâs extend the idea of an identifierto allow references to individualcyber observables within an observed_data.
Use the key in observed_data to refer toan individual cyber observable.

             
observed_data-3f708258-8c84-4b31-acd9-ff479618f88c.0

For instance:

{

 "type":"bundle",

 "id":"bundle--44af6c39-c09b-49c5-9de2-394224b04982",

 "objects":[

  {

    "type":"observed_data",

    "id":"observed_data-3f708258-8c84-4b31-acd9-ff479618f88c",

 

    "objects":{
     
"0":{

 

         "value":"joebob@example.com",
         
"type":"email-addr"
      }

 

    }

 

    "spec_version":"2.1",

 

    "created":"2018-04-16T20:03:48.000Z",

    "modified":"2018-04-16T20:03:48.000Z",

  },

  {

    "type":"threat-actor",

    "id":"threat-actor--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",

    "spec_version":"2.1",

    "created":"2016-04-06T20:03:48.000Z",

    "modified":"2016-04-06T20:03:48.000Z",

    "name":"EvilOrg"

  },

  {

    "type":"relationship",

    "id":"relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a",

    "spec_version":"2.1",

    "created":"2015-07-01T00:00:00.000Z",

    "modified":"2016-07-01T00:00:00.000Z",

    "source_ref":"threat-actor--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",

    "target_ref":"observed_data-3f708258-8c84-4b31-acd9-ff479618f88c.0",

    "relationship_type":"uses",

    "start_time":"2015-07-01T00:00:00.000000Z",

    "stop_time":"2016-07-01T00:00:00.000000Z"

  }

 ]

}

 

 


I can see some problems with this approachimmediately, like how do we dealwith the refs to other cyber observablesin the same observed-data.
But I see this as solving the relationshipissue, without really changingobserved_data.  Maybe someone can improveupon the basic idea.

              Rich P.

From:
<cti@lists.oasis-open.org>on behalf of Jason Keirstead<Jason.Keirstead@ca.ibm.com>
Date:
Wednesday, October 31, 2018 at 9:44 AM
To:
"Mates, Jeffrey CIV DC3/TSD" <Jeffrey.Mates@dc3.mil>
Cc:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>,SeanBarnum <sean.barnum@FireEye.com>, "Kelley, Sarah E."<skelley@mitre.org>
Subject:
Re: [cti] RE: [Non-DoD Source] Re: [cti] Working call agenda10/30/28

Jeff the problem is not re-using objectsinternally in a single server.

It is the problem of re-using objects across the entire ecosystem of thousandsoftools and hundreds of thousands of instances of said tools. That isnotsomething that will be able to realistically occur with this model.



-
Jason Keirstead
Lead Architect - IBM.Security

Caution-Caution-www.ibm.com/security < Caution-Caution-www.ibm.com/security > 

"Things may come to those who wait, but only the things left by thosewhohustle." - Unknown





From:        
"Mates,JeffreyCIV DC3/TSD" <Jeffrey.Mates@dc3.mil>
To:        
Jason Keirstead<Jason.Keirstead@ca.ibm.com>,Sean Barnum <sean.barnum@FireEye.com>
Cc:        
"cti@lists.oasis-open.org"<cti@lists.oasis-open.org>,"Kelley, Sarah E." <skelley@mitre.org>
Date:        
10/31/201810:39AM
Subject:        
[cti]RE:[Non-DoD Source] Re: [cti] Working call agenda 10/30/28
Sent by:        
<cti@lists.oasis-open.org>







My concern is that the current approach does nothing to even allow producerstoattempt to minimize duplication of static factual entries.  EverytimeI want to say I saw an IP address right now I need to create bothan observeddata for it and a sighting.  If I want to say that thisIP resolvedto an FQDN I need another observed that contains it and theFQDN.  IfI want to say that the FQDN was part of someoneâs infrastructureI needYET another copy of that FQDN to make that relationship.

With this at the very least I can keep referencing the same IP and FQDNifI choose to do so.  In most cases systems wonât bother doing thisoutsideof a single STIX message unless theyâre configured as a TAXIIserver aswell.

If you do have a TAXII server then itâs vital to be able to re-use asmanySTIX objects as possible.  Otherwise asking for them by ID andlookingup references to them is meaningless.

Jeffrey Mates, Civ DC3/TSD
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
jeffrey.mates@dc3.mil
410-694-4335


From:
cti@lists.oasis-open.org <cti@lists.oasis-open.org> OnBehalfOf Jason Keirstead
Sent:
Wednesday, October 31, 2018 8:15 AM
To:
Sean Barnum <sean.barnum@FireEye.com>
Cc:
cti@lists.oasis-open.org; Kelley, Sarah E. <skelley@mitre.org>
Subject:
[Non-DoD Source] Re: [cti] Working call agenda 10/30/28


All active links contained in this email were disabled. Please verify theidentityof the sender, and confirm the authenticity of all links containedwithinthe message prior to copying and pasting the address to a Web browser.







What I see missing from this proposal is how we are going to avoid theproliferationof thousands / millions of duplicate entries for static,factual objectssuch as IPs, URLs, Hosts, and file hashes in the CTI ecosystemif we godown this path.

How many instances of "8.8.8.8" or will there be in the wildthata CTI repository will have to store to maintain this graph? Tens ofthousands?Millions? Every time a new data source wants to link an observationto anIP they will have a new UUID.. its not like they will very oftenbe ableto refer to an existing one, as there is no "global repositoryof STIXobjects" that exists anywhere.

We will have so, so much duplication. The number of top level objects thathaveto be tracked among all third parties will explode exponentially.

I am fully aware that internally some software has to do some things likethisanyway for certain analytical use cases - our own teams do this. Thatisnot the point. The purpose of STIX is not to emulate a graph database.Ifit was, we could all just switch to Gremlin.

-
Jason Keirstead
Lead Architect - IBM.Security
Caution-Caution-Caution-www.ibm.com/security
<Caution-Caution-Caution-www.ibm.com/security>

"Things may come to those who wait, but only the things left by thosewhohustle." - Unknown





From:        
SeanBarnum<sean.barnum@FireEye.com>
To:        
Jason Keirstead<Jason.Keirstead@ca.ibm.com>
Cc:        
"cti@lists.oasis-open.org"<cti@lists.oasis-open.org>,"Kelley, Sarah E." <skelley@mitre.org>
Date:        
10/30/201802:38PM
Subject:        
Re:[cti]Working call agenda 10/30/28
Sent by:        
<cti@lists.oasis-open.org>








I would realistically and truthfully argue that â
theproposalas submitted does not contain a very large number of significantbreakingchanges to the spec.â
There are 5 substantive changes.

  1. Observables keep their same typestructurebut are now TLOs
    • Semantically the same thing (a file isstilla file, a domain-name is still a domain-name, etc)
  1. Observed-data.objects now containsreferencesto the observable objects rather than defining them inline
    • Semantically the same thing (observationsstillspecify the observables they observed)
  1. Observed-data.objects can now containreferencesto relationships
    • Semantically the same thing (the relationshipswerealready there as properties on the observable objects)
  1. Inter-Observable relationshipscurrentlyexpressed as properties on source object are broken out intoRelationships
    • Semantically the same thing
    • Is needed anyway for numerous reasons
  1. Extensions are possible on allSTIXobjects
  • NO change in overall semantics (each typeofobject still represents the same thing) just in how they are structured
  • NO substantive change to any STIX Objectsotherthan observed-data
  • NO substantive changes to any ObservableObjecttypes except breaking out relationship properties that should berelationships

Iwould argue thatthis is nowhere close to âan order of magnitude largerthan the totalcombined changes we have done thus far in 2.1 specâ.

I used the term FUD in its literal sense âfear, uncertainty and doubtâ.Duringthe F2F, you expressed your fear, uncertainty and doubt by makingthe assertionthat Option1 would require âmassiveâ change to the specificationsandthat the  months of effort it would take to do that made it anon-starterto even consider Option1. This was not âsimply stating thefactsâ. Thiswas an assertion of an opinion without any factual evidencein support.I was doubtful of this assertion but did not feel it wouldbe appropriateto argue strongly against it without having actual evidencerather thanjust words to throw around. That is why I took the time toreview and revisethe STIX specs for Option1. In the end, I believe thereferenced moddedspecifications demonstrate that Option1 does NOT representâmassiveâ changeto the specifications (in fact it proved out to be evenmuch less than Ianticipated) and did NOT take months to do (I did it alonein a few daystime).

This concrete evidence-based approach is also the approach we all agreedtotake in evaluating the technical issues involved in supporting requisiteSTIXuse cases.
I would assert that the evidence presented at the technical level alsoclearlydemonstrates the need for change and that Option1 is the only optiononthe table that supports the needed change.

Obviously, we can disagree on what is a minor vs major release.
I would suggest that the limited and localized nature of substantive changesrepresentedin this proposal clearly would be allowable in a 2.1 or 2.2release.

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com


From:
<cti@lists.oasis-open.org> on behalf of Jason Keirstead<Jason.Keirstead@ca.ibm.com>
Date:
Tuesday, October 30, 2018 at 12:32 PM
To:
Sean Barnum <sean.barnum@FireEye.com>
Cc:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>,"Kelley,Sarah E." <skelley@mitre.org>
Subject:
Re: [cti] Working call agenda 10/30/28


Sean - I don't think anyone could realistically argue that the proposalassubmitted does not contain a very large number of significant breakingchangesto the spec. Said changes are an order of magnitude larger thanthe totalcombined changes we have done thus far in 2.1 spec... I wouldhardly callit "FUD", it is simply stating the facts.

One thing that has yet to be discussed in the TC is the scope to whichachangeset can even be considered for a minor vs. a major release.

I would argue that this changeset and the breakages within are substantialenoughthat it should only be being discussed in the scope of a major change(STIX3.0).

-
Jason Keirstead
Lead Architect - IBM.Security
Caution-Caution-Caution-www.ibm.com/security
<Caution-Caution-Caution-www.ibm.com/security>

"Things may come to those who wait, but only the things left by thosewhohustle." - Unknown





From:        
SeanBarnum<sean.barnum@FireEye.com>
To:        
"Kelley,SarahE." <skelley@mitre.org>, "cti@lists.oasis-open.org"<cti@lists.oasis-open.org>
Date:        
10/30/201812:33PM
Subject:        
Re:[cti]Working call agenda 10/30/28
Sent by:        
<cti@lists.oasis-open.org>









All,

At the F2F there was a lot of conversation around WHY Option1 may be needed,identifyingand discussing numerous use case scenarios and leading to afairly strongmajority consensus (9-5 of attendees I believe) in favor.To further demonstratewhat was discussed in a fact-based manner and tohelp other TC members whodid not attend the F2F, it was decided to listout a list of some use casescenarios for use cases that STIX should/must(some would argue should whilesome would argue must) support and thenprovide actual JSON examples ofhow that Use Case would be supported withOption1 and how it would be supportedwith Option7 (which is mostly statusquo with a couple very minor changes).It was recognized by all that thelist would not be complete but would atleast give us something concreteto think about and discuss.
That list is located here: Caution-Caution-Caution-https://clicktime.symantec.com/a/1/FLKBcLdshKPGq0GNoSF_536jsS8wPt9vlKrG_E5gRC8=?d=L_12OMnxlWFizS69iQ49FwFfViLdHVj6sx9h7EnGsPenFN-e57gXqTXlJTFY-sc6blTYk5_gUfk6AyCErynbGd2FZNICoun8SaCY9ksdgGmOr5X9LuPCowJdujpImKLXx-aA-DAnnRR-HtuB7r3I-jazF2DXouUcBHALgpv41UgSVFAQWCu_QH0ceiq6Ttq_ONWCy4BlQ6AYiCqRN2uftRWmHx55ll0e3s0-e4aV4VnTkO-RsAEPC2wD5Mx77b7GWHEaxbl8nMF8OxsySjSEOtRQrVWAQbz6zpqrAVV_P6493LHvqiHSwMaT7edk2FOUQHqGjQ85fN-3m9B8nN6OarRfi6jpMXrE3X9a_SFh8mb-AOKgYH0rpwayBR4HH_RpGfhPjabzq1uYE05mD-AkqAlgUuIlVwqyoHmsAn8RAiKixLClaFEKSBWY8GXoP5xE1HUXHd96lCM8_BO0BpSir9e60pBiovNab24gpEq86xF_Mdve6nWNzEpntqZdmewYAuTzidxN-w%3D%3D&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1puPuKVWNSelrWH05yu9It99OuqQGdYo_Et0nmZKAZz8%2Fedit%23
<Caution-Caution-Caution-https://clicktime.symantec.com/a/1/lKgSfWpUJJCB8t16ruEfdEYGwNYJUtCL0wsSYC4VmuU=?d=L_12OMnxlWFizS69iQ49FwFfViLdHVj6sx9h7EnGsPenFN-e57gXqTXlJTFY-sc6blTYk5_gUfk6AyCErynbGd2FZNICoun8SaCY9ksdgGmOr5X9LuPCowJdujpImKLXx-aA-DAnnRR-HtuB7r3I-jazF2DXouUcBHALgpv41UgSVFAQWCu_QH0ceiq6Ttq_ONWCy4BlQ6AYiCqRN2uftRWmHx55ll0e3s0-e4aV4VnTkO-RsAEPC2wD5Mx77b7GWHEaxbl8nMF8OxsySjSEOtRQrVWAQbz6zpqrAVV_P6493LHvqiHSwMaT7edk2FOUQHqGjQ85fN-3m9B8nN6OarRfi6jpMXrE3X9a_SFh8mb-AOKgYH0rpwayBR4HH_RpGfhPjabzq1uYE05mD-AkqAlgUuIlVwqyoHmsAn8RAiKixLClaFEKSBWY8GXoP5xE1HUXHd96lCM8_BO0BpSir9e60pBiovNab24gpEq86xF_Mdve6nWNzEpntqZdmewYAuTzidxN-w%3D%3D&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1puPuKVWNSelrWH05yu9It99OuqQGdYo_Et0nmZKAZz8%2Fedit%253E
It contains links to some submitted Option1 and Option7 examples that claimtodemonstrate support for the use cases.

As very strong proponents of Option1 (proven out operationally across FireEyeeveryday), FireEye submitted Option1 examples for almost all of the usecaseson the list. The 3 out of 20 that we did not provide examples forwere dueto ambiguities in the use case characterizations rather than anyinabilityof Option1 to cover them.
In addition, we are in the process of writing up a brief rationale/justificationforOption1 but it is not yet ready to share prior to todayâs call.

Beyond the question of which option is needed technically there was alsodiscussionof FUD around what level of change/impact would be requiredon the STIXspecifications with at least one party expressing worry thatthe changecould be massive and take months to do.

In an attempt to determine if the FUD about massive specification changewasjustified or not we also performed a quick review/revision pass throughall5 parts of the STIX 2.1 working draft specs making appropriate modificationstoimplement Option1. There still is some editorial cleanup required beyondoursuggested changes but we believe our suggested changes fully coverthe substantivechanges required for Option1. We were pleasantly surprisedat the minimallevel of impact and the fact that I was able to completethe review andsuggested revision in only a few days time.
You can find a very brief summarization of the proposal and the changesitinvolves at a high-level and at a spec level as well as links to themodifiedspecs here:
Caution-Caution-Caution-https://clicktime.symantec.com/a/1/aERfTzAV00hza2IrDZBuv-pWeBvWV_aVHbt2URb82Is=?d=L_12OMnxlWFizS69iQ49FwFfViLdHVj6sx9h7EnGsPenFN-e57gXqTXlJTFY-sc6blTYk5_gUfk6AyCErynbGd2FZNICoun8SaCY9ksdgGmOr5X9LuPCowJdujpImKLXx-aA-DAnnRR-HtuB7r3I-jazF2DXouUcBHALgpv41UgSVFAQWCu_QH0ceiq6Ttq_ONWCy4BlQ6AYiCqRN2uftRWmHx55ll0e3s0-e4aV4VnTkO-RsAEPC2wD5Mx77b7GWHEaxbl8nMF8OxsySjSEOtRQrVWAQbz6zpqrAVV_P6493LHvqiHSwMaT7edk2FOUQHqGjQ85fN-3m9B8nN6OarRfi6jpMXrE3X9a_SFh8mb-AOKgYH0rpwayBR4HH_RpGfhPjabzq1uYE05mD-AkqAlgUuIlVwqyoHmsAn8RAiKixLClaFEKSBWY8GXoP5xE1HUXHd96lCM8_BO0BpSir9e60pBiovNab24gpEq86xF_Mdve6nWNzEpntqZdmewYAuTzidxN-w%3D%3D&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1j0gXMp3MFLzHCrudfbDn5NeZSUeBCc8EBsvPsP1epOg%2Fedit%3Fusp%3Dsharing<Caution-Caution-Caution-https://clicktime.symantec.com/a/1/aFSymJ9RCrIl6D5nACYu0AIL4n2s7kuI07U6wMpcczA=?d=L_12OMnxlWFizS69iQ49FwFfViLdHVj6sx9h7EnGsPenFN-e57gXqTXlJTFY-sc6blTYk5_gUfk6AyCErynbGd2FZNICoun8SaCY9ksdgGmOr5X9LuPCowJdujpImKLXx-aA-DAnnRR-HtuB7r3I-jazF2DXouUcBHALgpv41UgSVFAQWCu_QH0ceiq6Ttq_ONWCy4BlQ6AYiCqRN2uftRWmHx55ll0e3s0-e4aV4VnTkO-RsAEPC2wD5Mx77b7GWHEaxbl8nMF8OxsySjSEOtRQrVWAQbz6zpqrAVV_P6493LHvqiHSwMaT7edk2FOUQHqGjQ85fN-3m9B8nN6OarRfi6jpMXrE3X9a_SFh8mb-AOKgYH0rpwayBR4HH_RpGfhPjabzq1uYE05mD-AkqAlgUuIlVwqyoHmsAn8RAiKixLClaFEKSBWY8GXoP5xE1HUXHd96lCM8_BO0BpSir9e60pBiovNab24gpEq86xF_Mdve6nWNzEpntqZdmewYAuTzidxN-w%3D%3D&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1j0gXMp3MFLzHCrudfbDn5NeZSUeBCc8EBsvPsP1epOg%2Fedit%3Fusp%3Dsharing%253E

That link should give you all permissions to not only read but also provideanycomments you feel are relevant.

We are hopeful that this in addition to the forthcoming rationale writeupwillbe helpful for everyone to understand the reality of the issues involvedandthe reality of spec change impact.

Let me know if you have any questions.


Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com


From:
<cti@lists.oasis-open.org> on behalf of "Kelley, SarahE."<skelley@mitre.org>
Date:
Tuesday, October 30, 2018 at 8:50 AM
To:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject:
[cti] Working call agenda 10/30/28


All,

Today on the working call weâll be discussing the 1` option that discussedatthe F2F in NYC. For those not in attendance, there was a proposal toredesignthe STIX data model and make observables top level objects (knownas option1`). A second proposal was made to just modify observed dataand use thatinstead (option 7). The two options have been modeled here:(Caution-Caution-Caution-https://clicktime.symantec.com/a/1/mvUluJiHE-lus1fJ-CKKbwGCMubBw5TZHPrikLK5w3E=?d=L_12OMnxlWFizS69iQ49FwFfViLdHVj6sx9h7EnGsPenFN-e57gXqTXlJTFY-sc6blTYk5_gUfk6AyCErynbGd2FZNICoun8SaCY9ksdgGmOr5X9LuPCowJdujpImKLXx-aA-DAnnRR-HtuB7r3I-jazF2DXouUcBHALgpv41UgSVFAQWCu_QH0ceiq6Ttq_ONWCy4BlQ6AYiCqRN2uftRWmHx55ll0e3s0-e4aV4VnTkO-RsAEPC2wD5Mx77b7GWHEaxbl8nMF8OxsySjSEOtRQrVWAQbz6zpqrAVV_P6493LHvqiHSwMaT7edk2FOUQHqGjQ85fN-3m9B8nN6OarRfi6jpMXrE3X9a_SFh8mb-AOKgYH0rpwayBR4HH_RpGfhPjabzq1uYE05mD-AkqAlgUuIlVwqyoHmsAn8RAiKixLClaFEKSBWY8GXoP5xE1HUXHd96lCM8_BO0BpSir9e60pBiovNab24gpEq86xF_Mdve6nWNzEpntqZdmewYAuTzidxN-w%3D%3D&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1puPuKVWNSelrWH05yu9It99OuqQGdYo_Et0nmZKAZz8%2Fedit
<Caution-Caution-Caution-https://clicktime.symantec.com/a/1/lKgSfWpUJJCB8t16ruEfdEYGwNYJUtCL0wsSYC4VmuU=?d=L_12OMnxlWFizS69iQ49FwFfViLdHVj6sx9h7EnGsPenFN-e57gXqTXlJTFY-sc6blTYk5_gUfk6AyCErynbGd2FZNICoun8SaCY9ksdgGmOr5X9LuPCowJdujpImKLXx-aA-DAnnRR-HtuB7r3I-jazF2DXouUcBHALgpv41UgSVFAQWCu_QH0ceiq6Ttq_ONWCy4BlQ6AYiCqRN2uftRWmHx55ll0e3s0-e4aV4VnTkO-RsAEPC2wD5Mx77b7GWHEaxbl8nMF8OxsySjSEOtRQrVWAQbz6zpqrAVV_P6493LHvqiHSwMaT7edk2FOUQHqGjQ85fN-3m9B8nN6OarRfi6jpMXrE3X9a_SFh8mb-AOKgYH0rpwayBR4HH_RpGfhPjabzq1uYE05mD-AkqAlgUuIlVwqyoHmsAn8RAiKixLClaFEKSBWY8GXoP5xE1HUXHd96lCM8_BO0BpSir9e60pBiovNab24gpEq86xF_Mdve6nWNzEpntqZdmewYAuTzidxN-w%3D%3D&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1puPuKVWNSelrWH05yu9It99OuqQGdYo_Et0nmZKAZz8%2Fedit%253E) for various use cases.

Please join us to  make this conversation productive and successful.

Thanks,


Sarah Kelley

Lead Cybersecurity Engineer, T8B2
Defensive Operations
The MITRE Corporation
703-983-6242

skelley@mitre.org
< Caution-Caution-Caution-mailto:skelley@mitre.org>

This email and any attachments theretomaycontain private, confidential, and/or privileged material for the soleuseof the intended recipient. Any review, copying, or distribution ofthisemail (or any attachments thereto) by others is strictly prohibited.Ifyou are not the intended recipient, please contact the sender immediatelyandpermanently delete the original and any copies of this email and anyattachmentsthereto. [attachment "image001.jpg" deleted by JasonKeirstead/CanEast/IBM]

 

This email and any attachments theretomaycontain private, confidential, and/or privileged material for the soleuseof the intended recipient. Any review, copying, or distribution ofthisemail (or any attachments thereto) by others is strictly prohibited.Ifyou are not the intended recipient, please contact the sender immediatelyandpermanently delete the original and any copies of this email and anyattachmentsthereto.

 

 

 

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature



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