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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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


Subject: Re: [cti-stix] Event SDO comments


Thanks Jyoti, this is helpful.

 

I wonder if we can address some of these already:

 

2. Event sources...I believe we have a decent ability to capture this now:

- You can use a relationship to show that an indicator/etc triggered an event

- You can use the detection_mechanism field to indicate that it was reported

- You can include raw observed_data

- You can include related events

- Given our scoping out of the SIEM alert use case for 2.1, I think some of this might also be external data. In that case, you could use external references.

3. You can capture the artifact list in the related observed_data (relationship name is currently “reported-on”, though that could change)

4. Assignee can be captured in the “contacts” property. We can’t capture priority, though there are so many different vocabs/mechanisms for that that I’m not sure we ever could in a standard way.

5. You can add a related COA that mitigated or could mitigate the event (two separate relationships), but not much else. This is a weakness, as Bret has pointed out, but we also don’t want to write ourselves into a corner given that COA stuff is still evolving so much. IMO it would be smart to scope that more advanced stuff out for now so we don’t break things for future releases, as we figure out what COA/Playbook/Action might look like.

 

I think the broader question we have to answer is whether we want to address all of these needs in our 2.1 event proposal, or if (as Sean has suggested, and I agree with) we focus on the threat intel use case for events and acknowledge that people do a lot of IR stuff internal to their SOC that we can’t represent.

 

John

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com>
Date: Wednesday, August 30, 2017 at 7:47 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Cc: "Jyoti Verma (jyoverma)" <jyoverma@cisco.com>
Subject: [cti-stix] Event SDO comments

 

I went through the evolving Event SDO here and I have a few comments that I thought I should summarize.

 

  1. Event definition – An event describes anomalous activity that could potentially lead to the initiation of an investigation or further analysis – this looks good
  2. Event sources - need a property to call out the source of the event. Examples,
    1. From SIEM tools - Raw/processed logs/alerts sent to a SIEM where correlation and analytics is done over the data. SOC analysts can define searches/queries on top of this data to get alerted when certain thresholds are crossed. This is one source of events.
    2. From user initiated cases – Events could be tied around user initiated cases – example a suspicious email submitted to IT.
    3. Alerts from behavior analytics tools
    4. From Sightings of indicators
  3. Event artifacts – events typically contain information about the IP, URL, domain etc. These artifacts could be external or internal observables. Need a property to capture the artifact list
  4. Events get assigned to Tier 1/Tier 2 analysts and are flagged with a priority based on certain criteria – towards that, need properties to capture assignee and priority.
  5. Once an event is picked up by the SOC analyst, investigative, mitigative and remediative actions are performed à essentially the event goes through a series of COAs/playbook/workflow steps. Example,
    1. Identify if the event is tied to a malware, campaign etc. – manual/automated investigation – if so apply relevant actions; perhaps link to a different playbook/COAs
    2. Identify if the event is tied to any indicator/IOC – manual/automated investigation
    3. Enrich the event by doing reputation checks, gather additional context – manual/automated investigation
    4. If true positive, the event is escalated to an incident àworkflow/playbook continues
    5. Ticket creation for incident - manual
    6. Blocking of malicious IPs, domains, URLs – manual/automated mitigation
    7. Triage to determine the scope of infection – manual/automated investigation
    8. Mitigation and remediation COAs – manual/automated

 

I believe that an event is very closely tied to a playbook/COAs and there should be a placeholder to capture the COAs performed in the context of an event. This could either be captured as relationships or activities or both.

 

My 2 cents,

Jyoti



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