CTI STIX Subcommittee

Re: [cti-stix] Current thoughts on Event Object

  • 1.  Re: [cti-stix] Current thoughts on Event Object

    Posted 09-13-2017 02:39




    Hi Sarah,
     
    Below is my take on the different objects.

    Object 2&3 can be combined but it might be better to leave them separate since the consumers that work with them are different
    today.
     
     




    Objects


    Purpose


    Producer


    Consumer


    CTI Requirements




    Object1


    Captures data from sensors and is sent to a data analytics platform for further processing
     


    Sensor - 


    Produces events/alerts based on configured threshold rules
    Produces sightings to indicators
     


    Data analytics platform that does further processing on the data





    Event Trigger timestamp - time when the event was seen by the sensor 
    Event sighted timestamp - time when the sighting was made
    Tool that made the sighting/sent the alert
    It could refer to a sighting or an alert or be an independent blob of data (for STIX unsupported notifications)
    Relationship to observed data or sighting





    Object2





    Captures details about an event/alert that needs further enrichment. Object2 might contain:


    Collection of Object1
    Sightings
    Observed data
    Blob of non STIX data - artifact observables

    Object2 evolves to contain enrichment information, relationships to related objects and verdict/judgement 
    IT Ticket/Case creation - Information in this object will be exported to case management tools in case it is a true positive
    Could do some preventative actions






    Data Analytics platform output in form of


    Behavior analytics
    TI fusing with internal data
    Saved searches

    Alerts from Network behavior tools
    Alerts from Endpoint behavior tools
    User initiated ticket



    SOC tools /analysts


    connect to different enrichment providers to gather additional context such as DNS, IP reputation, WhoIs info etc.
    Try to identify if the event is related to a historical event
    If new indicators are discovered/created, share them with threat intel products
     





    Ability to store enrichment information against each artifact of the event. Example: relate 

                      IP->Domain->URL,

                      Domain->registrant,
                      IP->ISP->geographical area, 
                      IP, file hash->malware,   campaign,  threat actor etc.


    2. Ability to relate to other historical records such as logs and flows - from forensic tools.
    3. Ability to relate to older events/incidents


    4. Ability to add judgement/verdict - true/false positive
    5. Assignee - who is working on this event
    6. Assignee notes - notes captured by the analyst/investigator
    7. Property/Relationship to COAs for investigation & or preventative measures





     
      
     
          
     Object3




     IR team gets this object from 


    User ticket/case
    Subset of object2 (with the bad artifacts only)

    and will do the following:


    Preventative actions - block/honeypot bad actors
    Triage - identify affected internal hosts
    Mitigative actions - Apply Segmentation policies for affected resources
    Remediative actions - program access policies, network policies, remove malware, reimage etc.
    Create/Update IT ticket/case






    User ticket/case
    Subset of object2





    IR team/tools to


    COAs to block/honeypot bad actors
    Triage - identify affected internal hosts
    COAs for segmentation
    Execute scripts to program access policies, network policies etc.






    Relationship to Object2, if derived from it
    Property for Affected assets, hosts, servers
    Property for priority/severity
    Property/Relationship to COA with results of the COA execution
    Store timestamps for each of the actions





    Object4


    Subset of Object2 and 3 with relevant details


     


     


     Report or Bundle?




     
    Thanks,
     
    Jyoti Verma
    Technical Leader,
    CTO office Security Business Group,
    Cisco Systems Inc.
     
     

    From: <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
    Date: Monday, September 11, 2017 at 6:40 AM
    To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: [cti-stix] Current thoughts on Event Object


     

    CTI-TC,
     
    I have made an attempt to summarize the discussion to date surrounding the Event object. I have tried to use the diagrams that we’ve been referencing that show several workflows and where I see the various
    SDOs we have been discussing.
     
    I think there are five separate things that we’ve been talking about with regards to “Event”:
     
    Object 1) Some sort of front end device sensing something. You could call this an alert, an event, a log line, etc. 
    Object 2) A somewhat more mature version of the thing above. It
    may be one to one, but it may not be. There may be many of Object #1 that make up one Object #2. 
    Object 3) A way to document an incident/investigation that is either ongoing or concluded. This may (or may not) have come from an evolution out of an Object 1 or 2. Likely, most IR tools will not use Object
    3 directly, so it should probably be a sort of summary object that can allow the results of an IR investigation to be linked back to all the related data (like Objects 1 and 2, but also Actors, malware, etc)
    Object 4) Some sort of automated method of reporting, for cases such as mandatory reporting (like to US CERT). 
    Object 5) A way to group a bunch of related data together. 
     
    I see these as five distinct SDOs. Objects 1 and 2 are very similar, and
    could be represented by one SDO, but if that was the case, then the SDO would need to have a relationship type of “this arglebargle is one of many arglebargles that make up this larger arglebargle”.
     
    Object 1 has a lot of logistical overlap with a Sighting. There would need to be some sort of deconfliction between what properties were trying to be represented by Object 1 to make sure it wasn’t just a duplicate
    of Sighting (which, by definition, is something that was ‘seen’, just as Object 1 was described to be). This could also just be an Observed Data object, if the it wasn’t actually “sighted”.

     
    Object 2 is something that would likely be looked at by a SOC analyst. It isn’t really something that involves IR, but rather “is this thing my sensor generated good or bad?”
     
    Object 3 is for your IR people or your CERT. 
     
    Object 4 is likely distinct from the Report object as we have it now, as it’s not likely to be in the same vein as a ‘published report’, but rather, “Here are the series of questions that US CERT makes me
    answer every time we have an ‘incident’”. 
     
    Object 5 is basically what MISP has been asking for. 
     
    I believe Objects 1-3 roughly correlate to the first three objects from the FireEye proposal of “Event”, “Alert”, and “Investigation”. Object 5 is closer to their “Grouping” object. 
     
    All that being said, many of these tasks are not currently done in STIX (if not most of them). In the diagram, we have the TIP (in green) as being a separate object that lives alongside the workflow, but isn’t
    really IN the workflow. That being said, if we added objects 1, 2, 4, and 5, I think it could allow for easier data flow into/out of a TIP. (I don’t think the IR object will ever be used directly by the types of tools that produce that data, but maybe
    I’m wrong.) 
     
    Personally, I think the Event object as it currently stands is somewhat of a combination of Object 2 and Object 3. If people agree that these are really separate objects, I think we could scope out a few properties
    and turn the current Event object into Object 2 or Object 3 fairly easily (or easily split it into two objects). I think Object 1 is out of scope for 2.1 (unless it’s already covered by sighting/Observed Data). I think Object 4 is out of scope for 2.1. I think
    Object 5 will be covered by the “collection vs. report” debate/object, for which we should soon have a proposal.

     
     

     
     
    Thoughts are appreciated.

     
    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.


    . . . . .
    .....



    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.


    . . . . .