Open defendable-forfot opened 2 years ago
Pinging @elastic/security-external-integrations (Team:Security-External Integrations)
The identities issue has come up elsewhere. This is not a trivial issue to solve and we think depends on changes to kibana that would allow user-provided pipelines to allow the user to correctly copy values across to the appropriate ECS field. The problem here is that the Cisco notion of an identity spans multiple concepts in the ECS and is user-configurable, so no single generic solution will fit all cases.
For the message suggestion, can you provide some examples of messages that should be parsed into related.hosts
?
For clarity, can you provide an example of the behaviour you are describing for the destination.domain
|related.hosts
issue?
At least on our end we have only observed the identities containing actual hosts, but I see how the definition of the field provided by Cisco could lead to further issues as it is not set on being a host specifically.
Regarding the message question:
The message field will typically look something like this in our logs:
\"2022-00-00 00:00:00\",\"DESKTOP-XXXXXX1\",\"DESKTOP-XXXXXX1\",\"127.0.0.1\",\"8.8.8.8\",\"Blocked\",\"1 (A)\",\"NOERROR\",\"website.url.com.\",\"Malware\",\"Roaming Computers\",\"Roaming Computers\",\"Malware\"
Included within the message field is the host related to the observation DESKTOP-XXXXXX1
, we believe this could be added to related.hosts
. However, the host observed in message
, second and third value, is identical to the value in cisco.umbrella.identities
. I'm unsure how message
may look like if other values were to be provided by Cisco within the identities field.
Regarding the destination.domain
|related.hosts
question:
In the same document that is used as the example above, we can see that the value in the destination.domain
: website.url.com also populates related.hosts
for some reason. To specify: the value found is related.hosts
is website.url.com.
Would you be able to provide a sanitised event for the example above rather than a hand-crafted one; I am unable to parse the construction that you have there.
Sorry for the somewhat late response, hopefully this is better:
"2022-10-12 10:19:07","Company Hostname","Company Hostname","192.168.0.0","10.10.10.10","Blocked","1 (A)","NOERROR","malicious.com.","Advertisements,Malware","Roaming Computers","Roaming Computers","Malware"
Can I confirm that the background of this is that you are running filebeat directly and not via agent? I am unable to get the cisco_umbrella integration to ingest this message, but can get the filebeat cisco module to ingest using the umbrella fileset if I let it know that the message is a dnslogs message. In that case I get this document
{
"@timestamp": "2022-10-12T10:19:07.000Z",
"cisco.umbrella.blocked_categories": "Malware",
"cisco.umbrella.categories": "Advertisements,Malware",
"cisco.umbrella.identities": [
"Company Hostname"
],
"cisco.umbrella.identity_types": "Roaming Computers",
"cisco.umbrella.policy_identity_type": "Roaming Computers",
"destination.domain": "malicious.com.",
"dns.question.type": "1 (A)",
"dns.response_code": "NOERROR",
"dns.type": "query",
"event.action": "dns-request-Blocked",
"event.category": "network",
"event.dataset": "cisco.umbrella",
"event.module": "cisco",
"event.original": "\\\"2022-10-12 10:19:07\\\",\\\"Company Hostname\\\",\\\"Company Hostname\\\",\\\"192.168.0.0\\\",\\\"10.10.10.10\\\",\\\"Blocked\\\",\\\"1 (A)\\\",\\\"NOERROR\\\",\\\"malicious.com.\\\",\\\"Advertisements,Malware\\\",\\\"Roaming Computers\\\",\\\"Roaming Computers\\\",\\\"Malware\\\"",
"event.type": [
"connection",
"denied"
],
"fileset.name": "umbrella",
"input.type": "log",
"log.offset": 0,
"message": "\"2022-10-12 10:19:07\",\"Company Hostname\",\"Company Hostname\",\"192.168.0.0\",\"10.10.10.10\",\"Blocked\",\"1 (A)\",\"NOERROR\",\"malicious.com.\",\"Advertisements,Malware\",\"Roaming Computers\",\"Roaming Computers\",\"Malware\"",
"observer.product": "Umbrella",
"observer.type": "dns",
"observer.vendor": "Cisco",
"related.hosts": [
"malicious.com."
],
"related.ip": [
"10.10.10.10",
"192.168.0.0"
],
"related.user": [
"Company Hostname"
],
"service.type": "cisco",
"source.address": "192.168.0.0",
"source.ip": "192.168.0.0",
"source.nat.ip": "10.10.10.10",
"source.user.name": "Company Hostname"
}
Is your suggestion that we should be putting the contents of related.ip
into related.hosts
as well?
Yes we are running Filebeat directly and not through Agent.
In regards to the second question, no, I am not suggesting that the contents of related.ip
should populate related.hosts
. "Company Hostname" should populate related.hosts
instead of the domain, as "Company Hostname" is an actual host.
Hi! We just realized that we haven't looked into this issue in a while. We're sorry! We're labeling this issue as Stale
to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1
. Thank you for your contribution!
We are ingesting Cisco Umbrella data into our Elasticsearch for search, detection in Elastic Security and visualization through Kibana. However, we have noticed a few specific fields where the Cisco module does not optimally utilize ECS.
Note: we are running filebeat version 8.1.3, but have noticed that none of the newer releases solves our issues.
Umbrella
Additionally, we believe the ECS specification should be improved with the introduction of a new field within the Related fields section. Certain third-party data sources, the Cisco module included, send events where multiple URLs are present. An optimal solution would be to add this data to a related.url field.
This is a copy of https://discuss.elastic.co/t/cisco-filebeat-module-umbrella-improve-ecs-utilization/315127, as I was recommended to post this as a GitHub issue instead.