Additional groups (Vulnerability / Threat)

[dainperkins]

Would it make sense to add additional groups for things like vulnerabilities and threats for correlating between various services and getting granular definitions of this type of data?

e.g. vulnerability.id vulnerability.type vulnerability.first.scanned vulnerability.last.scanned vulenerability.status (e.g. open / closed as of current date) vulnerability.description vulnerability.cve vulnerability.severity

---

threat.id threat.name threat.type threat.description threat.risk_score threat.confidence

Thanks /d

[MikePaquette]

@dainperkins I think this makes sense. One idea is that the threat.* namespace/object/prefix would be one of a small number of special re-usable type objects that allow for uses including source.threat.* , destination.threat.* and file.threat.*

I had not thought of vulnerability. in the same way, but perhaps we should? Would you see the `vulnerability.fields always being associated with a host, sohost.vulnerability.*` ? Or were you thinking of using this to import vulnerability scan results into Elasticsearch? Or both :-)? Or others?

[dainperkins]

@MikePaquette Basis was actually looking at my companies products logging capabilities - and how we would represent "Threats" within the ecs framework (and frankly I am so sick of grokking, kv'ing, tweaking, and mutating stuff in logstash I sort of jumped into the idea of this type of standardization with both feet).

Its threat detection, and I had started looking at mixing name spaces like so:

event.id some_id event.type Threat event.original send agent url reference

agent.name PtrX.VA agent.version

threat.id some-id threat.start start time threat.end end time threat.duration duration threat.type product specific classification threat.tactic (ATT&CK) e.g. Lateral Movement threat.technique Pass the Hash threat.technique.reference https://attack.mitre.org/wiki/Technique/T1075 threat.module (Product specific detection module info) threat.description Host Ip attacking destination IP utilizing Pass the Hash techniques threat.severity How bad? threat.confidence How sure?

source.ip
source.port source.hostname source.domain

destination.ip
destination.port destination.hostname destination.domain

user.id user.name

I was thinking of threat and vulnerability from the standpoint of generalizing threat/vulnerability alerts and then using other name spaces as appropriate (e.g. a vulnerability record would also include a device.ip & device.name- no need for src/dst, whereas a threat would as above typically include source / destination / user fields etc...) If every name space contains those things that are intrinsic to the name space mixing and matching as appropriate seems to cover both standardization, as well as searching (show me all vulnerabilities where host.ip = a.b.c.d, show me all network logs where source.ip = a.b.c.d, or show me all logs where source.ip = a.b.c.d - still requires some type of join to eliminate or concatenate disparate fields, but easy to remember)

To be honest I'm still trying to wrap my head around e.g. db normalization vs hdfs, using ECS as device logging schema(s)vs an ECS index schema(s), and how it all plays together.

/d

[MikePaquette]

@dainperkins thanks for the reply. Let's ignore vulnerability.* for now and focus on threat.*

Ah, so you are proposing the threat.* object as containing the details of the "attack" associated with the alert. I was thinking that the threat.* object would hold details of a threat intelligence IOC, either as part of a match (one or more attributes of an event matched an IoC), or as a list of IoC's.

BTW, your approach of "mixing and matching" is exactly how we foresee ECS being used.

Anyhow, now I understand what you are trying to accomplish, and I think that there are indeed some fields that should be added to cover this information. But some of the information you want to add will fit nicely mixing and matching into existing ECS fields.

First, I think the ECS device.* fields are quite relevant here. The "device" name is a bit confusing, but we propose the following ECS definition of device:

A special network or security device used to detect, observe, or create network or security events. This could be a custom hardware appliance or a server that has been configured to run special network or security software. Examples include firewalls, Intrusion detection/prevention systems, network monitoring sensors, web application firewalls, and data loss prevention systems. In ECS, a device is not a host. The device.* fields shall be populated with details of the device, if any, that performs, observes and/or reports a network or security event. Network layer components, such as routers, switches, and other network hops are not considered devices in ECS. Message Queues and ETL components used in processing events or metrics are not considered devices in ECS.

Given that definition, some existing ECS fields should be used for some of your proposed threat.* fields:

The fields highlighted in yellow are not currently covered by ECS fields, and I think they do belong. If it turns out we can't use threat.* for these fields, how do you feel about rule.* or detection.* ?

[webmat]

We are going to work on this soon. If anybody's got ideas of additional fields that may be required, on top of what's already been mentioned, feel free to chime in.

[rhysxevans]

Hi Guys,

Firstly thanks, for doing this.

However I am struggling to determine where within the threat.* definitions / fields I would put details around threat feeds hits. I seem to have the feeling that the current threat feeds are largely geared to the MITRE Att&ck framework, form my reading (And I might be reading it wrong). So I was thinking something along the lines of

threat.ioc.provider: feed_vendor_name threat.ioc.feed: feed_name threat.ioc.type: type_of_ioc (tor exit node, compromised ip) threat.ioc.location: source/destination (refers back to source and destination fields, and respective sub fields)

Any guidance / advice is greatly appreciated

Hopefully as we move forward we would then start populating the other fields within the threat.* definition

Thanks

[webmat]

@dainperkins I think we can close this, right?

[webmat]

Both "threat" and "vulnerability" have been added to ECS (a while ago). Closing :-)