[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Working Call - Meeting Notes - Searchable Version
CTI TC Weekly Working Call - Text-based notes [Note:Â A separate PDF version with embedded screenshots will be
uploaded to Kavi] Attendees:
Agenda:
Meeting Notes: ÂÂÂÂÂÂÂÂÂÂÂ John Wunder ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ Update on the working draft â when out ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ *** Switched to discussion on Infrastructure & how Observed Data is handled ÂÂÂÂÂÂÂÂÂÂÂ Jeffrey Mates
 [Reviewed the slide deck] Need to be able to pierce the bubble around Observed Data that we constructed  Need one subject OD (Parent_Node) to reference the others (Child_Nodes)  John-Mark Gurney  In that example â It makes sense  Allan Thomson  Did you consider just making it an optional argument on the Observed Data yourself?  [Gave an example of an optional property]  Then, you donât have to have the additional property called out â Alternative way  Jeffrey Mates  We could make that part of the base observable  Allan Thomson  It might make it more elegant  John-Mark Â Iâd like to say that Iâd not like to use the property on the Observable  Sean Barnum  Iâd like it on the Observed_Data, rather than on every single Observable  Not on every class  Allan Thomson  There is a difference between a schema and an instance  [Gave an example]  Sean Barnum  I understand what you were saying  John Wunder  [Explained about the optional property]  John-Mark Gurney  We need a better definition of what âparentâ means â a synonym for ârootâ  [Gave Apache example]  Trey Darley  To John-Markâs point â would that not be the initial entry point into the Observed_Data  That is the definition I was suggestion  Bret Jordan  I generally like what Gary and Jeffrey have done â it will need a little more work  To flush out  Iâd like to see where we agree and where we disagree â if just the little things  We should call those out â High level of agreement  Trey Darley  Iâll be brief and responding to Bret  I would suggest that in the Working Document for 2.2  That Gary and Jeffrey add what this would look like in the Spec  Before we commit  Allan Thomson  This example on the screen is one example  [Gave a multilayered example]  Jeffrey Mates  We assumed a full static analysis â that can include a large graph  You can set any number of Parents, but, you specify a key entry point  Allan Thomson  Then, you would need different Observed_Data objects  Â Gary Katz  [Explained how the multiple layers of the graph data model would work]  Allan Thomson  [Gave example of Web Server, then Web App â As multi-layer]  Gary Katz  There are relationships within it.  Trey Darley  Gary is correct â Within Observed_Data, there is a Graph  Allan Thomson  I was not able to see the Contained_Ref â Now I see it  John-Mark  So that last comment points out that Parent Node is on the wrong object  Really the Infrastructure object should list what it is referring to  [Pointed back to Allanâs example ]â If you have to reference â problematic  Would need to create two references back  Bret Jordan  Other people need to be add to it - for Infrastructure and Malware  John-Mark  That does not change it [gave examples of links back to different Observed_Data objects]  Jeffrey Mates  [Explained why the proposal has the Parent_Node where it is â The logic used]  It also let us have a non-changing state within Observed_Data  We were trying to ensure it was a stand-alone object â that wouldnât break in another way  I wonder if we should make the Parent Nodes an Array of Arrays  John-Mark  That would be a Material Change â I would be concerned about that  I do remember us talking about having only 1 Graph  But, in my reading, I donât see the reference  Gary Katz  It is in there â I cannot remember where  Trey Darley  It is there  [John switched to the slide that shows the text in the Spec]  John-Mark  I donât think we have what a Cyber_Observable relationship is  I donât have a huge objection to relaxing that requirement  If we relax this and allowed multiple roots  Effectively we are in a Tree, not a Graph  Jeffrey Mates  We canât guarantee that it is not A-Cyclic â [Gave example of dropping malware]  John-Mark  You canât delete yourself and then create yourself  Jeffrey Mates  That is where the time factor comes in  Gary Katz  It
depends on how it is modeled  John-Mark  It needs to be understood by machines in real time  Jeffrey Mates  [Gave example of the challenges of automating]  John-Mark  But within the Graph, there is no Timestamp  Trey Darley  [Proposed a solution]  Jeffrey Mates  [Gave example of how the Timestamp is working]  John-Mark Gurney  We are trying to have this Observed_Data do a lot of thingsâ Does it make sense  [Gave several examples]  Allan Thomson  The conversation leads me believe that we are not exactly clear about  What a machine is going to do  We need to be very clear on which Use Cases would work  How do we know that we actually got it right?  John Wunder  [Gave some examples of different Use Cases]  Allan Thomson  [Gave some more examples]  Gary Katz  The whole reason for have the Parent_Node defined â That is what this proposal  Is getting to.  Allan Thomson  To the conversation about Cyclic Graphs â But, the opposite is that if people donât  Understand what they are trying to do  Gary Katz  If people donât know what to do with the data - They shouldnât be working on it  [Gave example of the different personas in the Interop Spec]  Allan Thomson  I get that â The more explicit you are, the better it is for an intended use  Gave an example of using a specific use case in the Spec  What I am saying is that we should add those specific Use Cases to the Spec  Unless you are doing this Use Case â Then you can ignore  John-Mark Gurney  We should make explicit that the Use Case should not be Cyclic Use Cases  These are the roots of all of the trees in this Graph â and they must be listed  Jeffrey Mates  The simpler the better [Gave examples â Firewall vs. mutex, or Firewall vs. IP]  You could link to a mid-point â which is what is important to me  It is a full-blown graph, because we allow extensionsâ  It is up to the appliance to parse it  John-Mark Gurney  I understand what you mean â Posed a question about how you would know  Where you link to a middle point  Jeffrey Mates  We have to remember that it is an exchange not a storage function  John-Mark Gurney  You are using an existing object for something else it was not designed to do  Jeffrey Mates  I think if we use the existing object â then we can use what we have  John Wunder   I think we need to flush out some of these and create some Use Cases  We need to list the types of products that we care about  Then list they types of data that each would need  Trey Darley  It almost suggests that we might want to resurrect the Mini-Group  Gary Katz  I can put together some more examples â We are trying to get to STIX 2.1  To get to closure  Weâve had some side conversations â It is not breaking â It does provide a solution  What do we need to resolve â to close on it  John Wunder  Discussed the properties that became optional â Implications for Patterning  John-Mark & Trey are the best to discuss  Second one I heard today â Is the multi-layered nature of the proposal  The other question â the Cyclic nature  Trey Darley  Next steps? Next working group call? Mini-group? Come up with some examples  While we want to support Malware and Incident â this was initially created  To support Infrastructure  We need to try in running code â We want to make sure we donât break Indicators  John Wunder  If there are no more comments, weâll go on to another topic  With Internationalization â We reference RFCs for language codes  Bret suggested to add some âSHOULDâ statements in there to give some people  Some guidance on how to implement  Â [Asked for comments]  Trey Darley  I believe Bret was going to propose some text  The points Bret raised makes sense  John Wunder  He has proposed text in the email â I donât know that it needs to be a SHOULD  But, Iâm pretty open on this one  John-Mark Gurney  From my brief read, it sounds like what you do out of the RFC â  Examples would help in that case, too.  Allan Thomson  I have a question on the previous topic  Does the Spec have an ability to say whether a File was created or deleted?  It is not actually thereâ.  Cyber_Observables are not actually files â  Trey Darley  2.0 was an MVP â Actions is a reserved term â it is an important capability that  We have always intended to address  Sean Barnum  I was going to point that out tooâ that is one of the things that we are missing too.  We are using relationships â it is less expressive  Allan Thomson  What Iâm observing is that we are going from a definition of âStateâ to a definition  Of âBehaviorâ  Sean Barnum  That is true, when you bring in Actions [Gave example of Cyclic Use Case]  Â It does not invalidate the usefulness for static information  Jeffrey Mates  It is not specifically in there â for how you define an action â Include wrap  John-Mark Gurney  [Made a final comment on how Actions will work]  Chat Panel Discussions  From jordan to Everyone: 12:18 PM I will be on the phone only for the next 15-20 minutes. But I need to drop off of the web portion. From Allan Thomson to Everyone: 12:22 PM technically you can figure out parent_nodes automatically. just look for things that are not connected in the local graph (have 0 parents). its just more explicit From Trey Darley to Everyone: 12:25 PM @Allan: I believe you are correct. From Trey Darley to Everyone: 12:34 PM @Allan: +1 From jmg to Everyone: 12:35 PM you shouldn't/can't have cycles, even in the created file then file deletes itself.. because the file cannot create itself, something else created it, then the file ran and then the file did the delete... if it's cyclic, then you've invented a time machine! From Allan Thomson to Everyone: 12:39 PM +1 to jmg From sean.barnum to Everyone: 12:42 PM Cyclic relationships are the reality of threat intel. We cannot simply say that you are not allowed to express them because of limitations in the current observed data structure and its timestamps. if the structure has limitations then lets fix those limitations rather than attempt to rule out real world CTI use cases From Allan Thomson to Everyone: 12:42 PM we are not describing a state machine including all behaviors. weâre describing artifacts of intel for specific uses. From Trey Darley to Everyone: 12:43 PM Make Arglebargle Great Again! :-P From jmg to Everyone: 12:47 PM minigroup +1 sean, I'm not saying ALL of STIX cannot by cyclic, I'm saying that the data that you observe cannot be cyclic.. you can't observe a file create itself, and delete itself.. something else had to create the file.. a file cannot sprint into existance from no where.. From sean.barnum to Everyone: 12:48 PM I donât think anyone was talking about a file creating and deleting itself. The very valid use case Jeff gave was file A dropping file B which deletes file A. These sorts of cycles are absolutely real in the real world Meeting Terminated *********************************-- R. Jane Ginn, MSIA, MRP Secretary, Cyber Threat Intelligence Technical Committee (CTI TC) OASIS jg@ctin.us +1(928)399-0509 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]