[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
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]