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: [EXT] Re: [cti-stix] Event SDO comments


Terry,


An event will need to record to the COA / Playbook that was taken and what the outcome was.  You are going to want to look at this across the eco-system to know how best to deal with the newest attack.  If everyone is saying that they ran COA 123 and it did not work on Windows 10, then you probably need to figure out why, or look for a different COA that will work on Windows 10 for a given piece of malware.


Bret


From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Sent: Wednesday, August 30, 2017 7:00:40 PM
To: Jyoti Verma (jyoverma)
Cc: cti-stix@lists.oasis-open.org
Subject: [EXT] Re: [cti-stix] Event SDO comments
 
Hi Jyoti,

I think we need to delineate very strongly between actions we've performed (historical) and actions we could perform in the future (playbooks/COA). My reading of your comments is that the Event SDO will potentially conflate those two concepts.

An Event as a concept should simply describe something that has happened that we need to investigate further. If we need to describe ObservedData related to that event, then we should use an external relationship to that ObservedData to allow third parties to also suggest ObservedData that may be the same event. If we need to actually record what we did, then we perhaps need an Action SDO that describes something we've done, and use external relationships to link those together (to allow multiple groups to also show what they did in response to that same event). We could simply have a 'followed_by' relationship between those Action SDOs that would show the sequence in which those Actions were performed. Consumers can then walk the graph to figure out what the sequence of steps each org performed in response to that.

If there is a possible Playbook/COA object that highlights a sequence of steps that affected organisations can perform to remedy the situation, then those should be related via an SRO with a relationship like mitigates, or mitigated-by. The COA too could use a set of related Action SDOs to show a sequence of actions (but that of course depends on what OpenC2 is doing.

Cheers

Terry MacDonald | Chief Product Officer







On Thu, Aug 31, 2017 at 11:47 AM, Jyoti Verma (jyoverma) <jyoverma@cisco.com> wrote:

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,

a.       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.

b.       From user initiated cases – Events could be tied around user initiated cases – example a suspicious email submitted to IT.

c.       Alerts from behavior analytics tools

d.       From Sightings of indicators

e.      

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,

a.       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

b.       Identify if the event is tied to any indicator/IOC – manual/automated investigation

c.       Enrich the event by doing reputation checks, gather additional context – manual/automated investigation

d.       If true positive, the event is escalated to an incident àworkflow/playbook continues

e.       Ticket creation for incident - manual

f.        Blocking of malicious IPs, domains, URLs – manual/automated mitigation

g.       Triage to determine the scope of infection – manual/automated investigation

h.       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]