proposal: define minimal interface for a firewall dashboard's data

[efd6]

In #3102 there has been the suggestion that we add a vendor/product-agnostic firewall dashboard. In order to do this we should define a minimal or near-minimal set of fields that can be expected to be non-empty in a firewall integration's documents.

This will help harmonise the firewall integrations, provide a working direction for a generic firewall dashboard and also help provide a basis for designing and implementing new vendor/product-specific dashboards.

Initial strawman suggestions:

• event.action
• event.outcome
• event.type
• event.category
• log.level
• {client,server,destination,observer}.ip
• {client,server,destination,observer}.port
• {client,server,destination,observer}.geo.*
• {client,server,destination,observer}.as.*
• network.protocol
• network.transport
• network.direction
• network.bytes
• network.packets
• url.domain
• observer.name
• observer.product
• observer.vendor
• cloud.*
• dns.{answers,question}.{class,name,type}
• dns.resolved_ip

It's not expected that all fields will be provided by all packages, but that only a minimal number of visualisations would show "No results found' in normal use. The observer.{name,product,vendor} are intended to allow the user to hone in on specific hosts in their system if they are running a diverse set and so be able to move to the product-specific dashboards when the generic dashboard shows something interesting that needs more detail.

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[jamiehynds]

FYI @paulewing - this is the issue for the firewall dashboard I mentioned. Is there someone in UX responsible for these top-level dashboards, that we could discuss with?

@dainperkins feel free to chime in with thoughts/feedback :)

[dainperkins]

I suspect source/dest (ip, port, geo, as) will be more ubiquitous than client/server... I would consider breaking the 1 dashboard up into a couple

• Overiew/ System (cpu, mem, # connections/s, # translations/s, status logs, thruput on an interface/zone level
  • I'm a big fan of meta-metrics / trending here - conn/s over time, translations / time, alerts / time, with historical trends (think anomaly detection type renderings)
  • device stats (logins, users, etc.)
• Connection details
  • top level trends, maps (meh), top talkers / rare ports / ja3

• NGFW type alerts etc.

  • top level trends, maps (meh), probably depends on the system

  of course Native cloud provider fws probably won't populate all of the system view, which begs the question do those types of iaas/saas get rolled in here or not?

  The observer.{name,product,vendor} for drilldown is perfect, might even add in e.g. cloud.region or something like that.

[dainperkins]

@jamiehynds @paulewing @efd6. Would love to help anyway I can btw, happy to chat, help plan/design, poke SAs for thoughts, herd cats, etc.

[efd6]

Thanks @dainperkins, I've added cloud.* (at least provider and service.name are likely to be informative in context as well) to the list. I missed the server tree, so I'll add that so it's not forgotten (it can be resolved later).

The issue here is for defining what data we can expect to be present in the majority of cases rather than how we will split the presentation.

[dainperkins]

@efd6 this may be me being too caught up in the details, but I wonder if further slicing into dashboard themes as the top cut would make this easier to work thru, so the focus can be not be on ECS fields available, but on fields expected in a specific context from the users perspective. if there's missing pieces that gives teams a good priority list for specific integration ERs to ensure good normalization across the board

Hi level FW (or even Network Security*) Dashboards:

• Connections (should be ubiquitous across all types of firewalls e.g. legacy (asa), ng (pa, ftd), cloud (zscvalar) and cloud providers (gcp,aws)
• System (likely traditional appliance / sw packages - cloud would be limited likely to AAA events)
• Security events (ids/ips, url blocking, malware, etc)
  • not sure if cloud provider fw would likely be providing (e.g. GCP firewall vs ASA, checkpoint, PA or Zscalar)
  • would likely be a secondary link from the main dashboard as most of events will likely show as e.g. blocked connections

*Would it be worth it to transition to more of a Network Security (as opposed to "Firewall Overview") paradigm? theres the potential to provide a central place to show anything that is blocking connections (e.g. Meraki allows l3 rules on Access points) from a network security standpoint, and allow drill down into more specifics...

Event.[catgories] source. destination. observer. network. [protocols]. (e.g. dns, http, tls) url.

• I'm unsure of how well we populate src/dst into client/server across integrations & would likely want to select only connection events as opposed to flows as src/dst & client server are not normalized into an ipfix bi-flow representation

[efd6]

@efd6 this may be me being too caught up in the details, but I wonder if further slicing into dashboard themes as the top cut would make this easier to work thru, so the focus can be not be on ECS fields available, but on fields expected in a specific context from the users perspective.

The intention was that that would be a separate issue.