Open rhysxevans opened 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.
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
@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.
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...
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
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.
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
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.
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
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
or
Any ideas / thoughts appreciated
Thanks