elastic / ecs

Elastic Common Schema
https://www.elastic.co/what-is/ecs
Apache License 2.0
995 stars 413 forks source link

Network Classification Fields #742

Open rhysxevans opened 4 years ago

rhysxevans commented 4 years ago

Hi

I would like to be able to classify networks (source and destination etc) into groups.

I'm thinking things like Trusted, Untrusted, unknown etc. (this could be extended to 3rdParty, Local, Company X etc)

Use case is I would like to exclude all traffic from "Trusted" networks from my analysis and concentrate on connection sourced or destined to "Untrusted" networks.

Any idea on which fields would be best for this ?

I was thinking something like

source.network_classification
destination.network_classification

As a by product we may be able to populate something like

network.connection_classification

This would be a product of source.network_classification and destination.network_classification

eg

source.network_classification: trusted
destination.network_classification: untrusted
network.connection_classification: untrusted

or

source.network_classification: trusted
destination.network_classification: trusted
network.connection_classification: trusted

Any ideas / thoughts appreciated

Thanks

d-almeida commented 4 years ago

For my Cisco ASA and Palo Alto logs I have been using *.zone for zone information and *.interface for interface/port.

e.g. source.zone: "OUTSIDE" source.interface: "eth1"

I'm not sure if your logging source offers that though.

rhysxevans commented 4 years ago

I think here I am trying to classify traffic into untrusted/trusted etc , where the "interface/zone" is irrelevant.

IE traffic may be TRUSTED if sourced from the "known" IP's on the OUTSIDE interface

webmat commented 4 years ago

@rhysxevans Thanks for the suggestion, I like it. It also reminds me of a discussion we've had around classifying URLs #412. It's not quite the same thing, but I see them as related.

@dainperkins I'd like your thoughts here on whether you think this is something we could address with risk scores.

dainperkins commented 4 years ago

I would say theres definitely some common ground. In thinking about the generalities I think theres likely a concept of a network zone, and a specific concept of an observer zone, which may or may not be the same (specifically an observer zone is locally significant, and may roll up to 1, or potentially more than one network "zones")

@rhysxevans would something akin to a risk.scope serve your requirements? (if nested under e.g. source / destination - its in a PR now...)

On another similar topic theres been discussion around public/private & internal/external - tho I don't think that directly relates to you issue...

rhysxevans commented 4 years ago

Hi

Would the risk.scope also exist under network aswell ? IE we rollup source.risk.scope and destination.risk.scope into network.risk.scope ?

If so I think it is workable for now

Thanks

willemdh commented 2 years ago

Any news about this? We could definitely use this. With more then 100 zones, it becomes a lot of work to update all rules which have an exception based on a zone, when for example a zone is added or the name updated. If we would enrich some field during ingestion with values trusted vs untrusted we would only have to update the Logstash / Ingest pipeline instead of 200+ rule exceptions. I would go for:

observer.ingress.network.classification
observer.egress.network.classification
network.classification

risk.scope would also work for me when nestable under source / destination and observer .ingess / egress, but I cannot find this field yet in ECS.

dainperkins commented 2 years ago

With a new role at Elastic I should have some time to pick this up again. What I'd like to see (need to check with SIEM team as well) would be a classification field set that could be applied to nearly any logical entity: e.g.

classification.tag: totally open for individual use classification.scope: PCI, PII, HIPAA, Confidential, Sensitive, Public, etc. classification.score: (1-10)

This could apply to host, source, dest, network, etc, tho not sure I would apply to observer as it relates to e.g. a netflow source, but I could be convinced

willemdh commented 2 years ago

Well I need a place to store trusted vs untrusted. As this applies to observeren ingress and egress zones, for me it seems obvious to let it Apply to observeren.ingress and observeren.egress Let me know if u need more convincing.