Threat signatures from observers

Elastic Security SIEM
1

External security products, such as endpoint protection etc., often send a threat signature with their alerts ("Trojan.generic.823719237", "CVE-XXX-XXX Joomla SQL Injection"). Where do we put this threat name / signature?

  • event.action would be a generic place to store those. however it feels too generic, as actions for these types of observers are usually things like "quarantine requested", "definitions updated", "running exe in sandbox" and the like. Thus event.action for a detection would be occupied with something like "threat-detected".
  • threat.name, threat.signature: best fit in my opinion. however currently the threat.* fieldset is only used for threat taxonomy in Mitre ATT&CK & co. Its semantics would have to be expanded here.

Am I missing some other place to put this? If not, I'd love to start a feature request to incorporate threat.name or threat.signature into ECS.

2

Hi @nemhods good question. The ECS rule.* fields may be what you're looking for. They are meant to capture the details about the rule that the security product used to generate the alert, and they can accommodate the name and/or signature that you mention. For example, you can use rule.name and rule.description.

In addition, if your security product also includes a classification according to a threat taxonomy such as MITRE ATT&CK™, then you would also populate the appropriate threat.* fields in the alert event.

Please let us know if this answers your question.

1 Like
3

I second what Mike said above.

It's also worth reinforcing that the threat.* field set only uses ATT&CK as an example. Granted, we also use the same naming for the field names. But you're welcome to use it with a different taxonomy. When doing so, if you notice anything is amiss, please let us know what you think could be improved :slight_smile:

4

Thanks for your responses. I wouldn't want to use the existing threat.technique/framework/tactic as they're reserved for ATT&CK mappings.

Unfortunately, the rule.* fields are also already reserved in our scenario. As we're trying to build a SIEM, the rule.name includes the name of the SIEM (watcher/ML) rule that triggered here. Seems like you've run into the same issue with signals, and created signal.rule.* to hold the detection rule name. We might have to move our watcher rule names into a custom field called watcher.rule.name... Is that a good way to go forward?

5

Yes I think it would be a good way forward. This way your 3rd party firewall rule will end up in rule.*, along with all other third party alert details. And you will still have your Watcher rule details in the custom fields at watcher.rule.*. :+1:

6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.