[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Text-Based Notes of Tuesday Working Call
|
ÂCTI TC Weekly Working Call
Agenda:  TAXII 2x Updates o Working Draft 04 Review o Query proposals o Client User-Agent  Cyber Observables Mini-Group Updates Meeting Notes:  Bret Jordan  WD04 Update  â The review period ends this Friday, end-of-day â What is new in this draft â The TAXII Envelope all media types are now TAXII â Add âlimitâ and âspec_versionsâ filter parameters â Added clarifying text around date added timestamp needing to be millisecond precision â Cleanup on descriptions of error messages  TAXII Query Problem Statement â There is no current way to find the relationships that point at a STIX Object. â The only thing you can do is pull every relationship down and then try and filter then on the client. â We need a way to pivot â I have an indicator or campaign, tell me if anything is linked against it â There are two proposal ideas for doing this Proposal #1 â Create a simple endpoint like: Â{api-root}/collections/{id}/relationships/related/{stix-id}/ â This would result in a very simple database query and URL filtering logic. Something like: Pseudo SQL code: select * from table-objects where type=relationship && (source_ref = stixid || target_ref = stixid) We should define a URL parameter called ?deref=true â This would tell the server to not only send the relationship object, but also the object that it points to â This could also be used for simple queries where you want to ask the server to automatically send the created_by_ref identity as well â Or automatically send you all of the objects from a Report Proposal #2 (Not Mutually Exclusive) Create one or more search endpoints like Â{api-root}/collections/{id}/search/ {api-root}/search/ â These endpoints would accept some sort of âquery or information-request objectâ Summary â We talked about this on the list and there seems to be 6 people that like or prefer a simple solution that we could deploy quickly. â 1 TC member is against proposal 1 as it does not provide all of the features and solve all of the use-cases needed for query â We could easily do both, the simple solution now TAXII 2.1, and the more complex one in TAXII 2.2.  Chris Ricard  Letâs keep it as consistent with previous versions as possible  Jeffrey Mates  I like the proposal â Proposal 1  Gary Katz  I think this is a good start â the Use Cases in the future will need to be developed  Sean Barnum  Proposal 2 has been on the table for a while â I concur with Gary that Proposal 1 would not  Paint us into a corner  Drew Varner  In terms of API, we have a âobjectsâ endpoint â it seems odd to have a ârelationshipsâ endpoint  Bret Jordan  I was trying to get something on paper, we could work on this â get out an WD05  Drew Varner  Would relationships return ârelationshipsâ  Bret Jordan  I was trying to find a way to add a pivot functionality, in a RESTful wayâ and  Can get out quickly  Trey Darley  I am sympathetic to the Jason & Terry proposal â I still want to Crawl, Walk, Run  And having the simple Pivot in the short term would be good.  Allan Thomson  [Tried to get clarification on the Use Cases each proposal would represent]  Bret Jordan  [Gave examples for clarification]  Allan Thomson  I am still somewhat skeptical of this proposal â We are going to spend time adding  To the Specâ and Interop  What is driving this? I get the concept and look-upsâ  Trey Darley  [Gave example of the basic need for pivoting from his [analyst] days and other]  It was a disincentive to implementing TAXII  Allan Thomson  They are treating TAXII as the repository of information, rather than a database  Designed for some of this stuff â you raised an example  It is a product that uses TAXII   Any products should use a database designed to do this  Trey Darley  [Made argument that an interoperable ecosystem should pivot with query]  Allan Thomson  If the majority think there is value is thisâ and they are willing to do the work  Then, I stand aside â If everyone is willing to do the work  My opinion is that it is not a well-defined Use Case  Sean Barnum  Speaking as a Threat Intel provider â this is one of the most fundamental thing â Query  [Gave example of âPushâ model, Gave example of âPull-Queryâ model, &  Gave example of âInteractive-Pivotâ]  That is an hourly, if not minute-by-minute request from our customers  Talked about the way it is now â This is a very real-world very high priority  Gary Katz  Yes, sometimes you have a small enough volume â but, if you are a provider that  Has terabytes of data â you are not going to tell them to go pull everything.  Gave example of PassiveTotal and VirusTotal â They have APIs  Sarah Kelley  We are enforcing the concept of âDoneâ on STIX2â. Should we be implementing  The same thing for TAXII2?  Bret Jordan  Is there anyone other than Allan that is against doing this?  Trey Darley  I remain supportive and I hear Sarahâs concerns â and so I think we may want to POC  Bret Jordan  I do actually have one implementation on this  *************New Topic*********  Bret Jordan  [Outlined the topic brought up by Marlon on User-Agent] â A TC member has asked that we add support for a TAXII Client user-agent element. â This would more easily allow servers to diagnose problems from clients talking to the server. â Should we add support for this? â If so, should this be an optional or mandatory feature?  Jeffrey Mates   Made point of how change from where we are now  John-Mark Gurney  Made point about use of automation for User Agent  John Wunder  Would it be âRequiredâ?  Bret Jordan  Should be a âShouldâ â and would be based on HTTP  John-Mark Gurney  I would agree that it should be a âShouldâ â A lot of HTTP Clients already are using this  John Wunder  I should take a look at the ATT&CK logs to see if it does it â and others  Allan Thomson  [Gave update on Observed Data Mini Group]  Links to Documents Discussed: â Part 1: https://docs.google.com/document/d/1yf8TZCtbF-ldiDAY5-gIvspGmJoJ48uP2FJdir5Xzpc/edit#heading=h.4do73o99e2l7 â Part 2: https://docs.google.com/document/d/12I2vOdPU48VoyNMiE9HOp3AzDZJA8cOnnuomEvbjZbQ/edit#heading=h.t32x0azc539r â Part 3: https://docs.google.com/document/d/1UqmRluGk5Y9j7ZcSdPR5ARTXMxa3C3JswV6Lc3FcZww/edit#heading=h.t32x0azc539r â Part 4: https://docs.google.com/document/d/1_mo0GzMNZIPOeP2gXQaLXEX-6v--CYfpmWvYF4_Y_QM/edit#heading=h.t32x0azc539r  Â Change Summary â Part 1 â 1.5.3 Update description to describe Relationship Targets that can either be SCO or SDO â 1.5.5 Added STIX to Cyber Observable name to make it consistent and understandable. Introduce SCO as defined acronym â 2.7 Added STIX Cyber Observable Identifier that defines explanation of scâidentifier that is used for STIX Cyber observable identification. Mentions that properties in SCO doc defines how the hash is computed â 3.5 Common Relationships. Updated to include SCOs that could be referenced by common relationships. Change Summary â Part 2 â 2.4 Added Fact-List SDO object definition â 2.10 Changed Observed-Data definition to deprecate objects property and add embedded reference to Fact-List SDO â 2.12 Added sco_refs property that points to the list of SCO contained by this report - NOTE: Could point to a fact list object in object_refs instead also if desired. â 3.1 Updated to describe that a relationship can be between Relationship Targets (SCO and SDO) and added properties to handle that Change Summary â Part 3 â Throughout Doc: Change confusing terms that used âobjectsâ to consistent âSTIX Cyber Observableâ or âSCOâ â 1.5.1 Added definition of Cyber Observable Identifier â 1.5.2 Removed as no longer required in this section â 2 Updated type table to correct SCO reference and removed observable-objects as its not required as it is replaced by either an array of SCO identifiers or a relationship object itself â 2.3 Change Reference to Cyber Observable Reference. This is equivalent to an embedded reference to an SDO but this is an embedded reference to a SCO â 2.4. Removed Observable Objects as itâs no longer required. We either point to an SDO (fact-list) or a list of SCOs â 3.1 Added id as common required property for SCOs â 3.1 Added equiv_ids dictionary to capture semantic equivalence map for SCO lookups â 3.2 Removed object references as no longer required here â 3.4 Updated object relationships to only talk about embedded Cyber observable relationships Change Summary â Part 4 â 1.5.3 Added section to introduce hash functions that should be used when computing hashes for SCO â 2.4.1 Deprecated resolves_to_refs SCO direct reln â 2.8.1 Deprecated resolves_to_refs & belongs_to_refs SCO direct reln â 2.9.1 Deprecated resolves_to_refs & belongs_to_refs SCO direct reln â 2.12 Deprecated encapsulates_refs & encapsulated_by_ref SCO direct reln â Throughout Document: - Added in each property section a proposed algorithm for the hash creation for the SCO  John-Mark Gurney  Iâd like to participate in this Mini-Group  Allan Thomson  Weâll make sure you get invited to the next meeting  Gary Katz  I have a presentation on this â we donât have time â I do have a point on how ID set  Allan Thomson  I agree â I thought that from the beginning  The MiniGroup has made progress â It takes everyone to come to the table  With a willingness to compromise  Trey Darley  Come with ideasâ and come with the spirit of compromise Chat Panel: From chris ricard to Everyone: 01:24 PM  Allan - I get a sighting on an indicator, and I want to know more about it. From Allan Thomson to Everyone: 01:24 PM  i would like to respond to trey From sean.barnum to Everyone: 01:25 PM  This sort of pivoting is one of the most fundamental and common needs for TAXII access to threat intel providers From Allan Thomson to Everyone: 01:26 PM  most systems today pull information in complete sets based on periodic polling and do pivoting  once sync-d. From John Wunder to Everyone: 01:33 PM  Iâm not against doing it but I agree w/ Sarah that it should follow the same vetting process From Allan Thomson to Everyone: 01:34 PM  if the vetting occurred then it would show the value of the feature and help justify. From Emmanuelle Vargas-Gonzalez to Everyone: 01:38 PM  The OASIS TAXII client does use the User-Agent From jordan to Everyone: 01:47 PM I am scared silly of doing anything in TAXII that cannot be verified to work first.  Meeting Terminated ******************************************************************************* -- Jane Ginn, MSIA, MRP CTI TC Secretary, OASIS +1 (928) 399-0509 jg@ctin.us |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]