Mapping SIEM Ingestion Namespace to SOAR Case Environment in Native Dashboards

Question

Hi everyone,I'm building a Native Dashboard that tracks total ingested data volume (GB) grouped by Namespace, using the standard pattern:ingestion.component = "Ingestion API"$Namespace = ingestion.namespacematch:    $Namespaceoutcome:    $Total_GB = math.round(sum(ingestion.log_volume) / math.pow(1000, 3), 2)order:    $Total_GB descThis works great for a Namespace-level breakdown. However, I'd like to roll this up further — specifically, I want to group/aggregate this ingestion volume by SOAR "Environment" (case.environment), so I can see total GB ingested per Environment rather than per individual Namespace.The challenge: ingestion.namespace (SIEM) and case.environment (SOAR) appear to be two separate data sources/concepts, and I haven't found a native field that joins them directly in dashboard queries (similar to the "joining case and case_history is only supported for one case and one case_history event" limitation I ran into when trying to join case and case_history data).Questions:1. Is there a supported way to join/correlate ingestion metrics with SOAR Environment data directly in a Native Dashboard query?2. If not, would using a Data Table (custom Namespace → Environment lookup) be the recommended workaround? If so, is there a documented pattern for referencing a Data Table inside a dashboard YARA-L query?3. Alternatively, is there a recommended naming convention or existing sync mechanism (similar to how SOAR Environments can be mapped to SIEM Namespaces via connectors) that would let these two roll up cleanly for reporting purposes?Any guidance, sample queries, or pointers to relevant docs would be greatly appreciated!

citreno · Answer

Hi,First thing, I would really caution of using namespaces too much, because they are an alising container and they are very often misused as a data labeling mechanism instead (ingestion labels are designed for that pre-ingestion, data labels post-ingestion). Essentially with namespaces lets say you tag your palo logs which have user names, but your AZURE_AD_CONTEXT logs are not tagged then this will break the aliasing of username to windows sid for example. Now that said there is a limitation where the ingestion table itself doesn’t contain ingestion labels, so you sort of have to use namespace to break things down for metering but just beware and study aliasing behavior.Chris martin has a great set of blog posts including this Entity Merging post that was excellent and has a few references for some fundamental concepts. Essentially you’re getting to a point to meter volume per environment and use namespace because SecOps forces you to since that’s the field included, but you may end up losing on some great features (aliasing, enrichment) if the namespaces aren’t tuned right because namespaces were originally designed to be an aliasing container (think M&A where there are IP or hostname collisions), but then due to a limitation became a way to meter data. It would be ideal if the ingestion tables include ingest labels but I believe that remains a feature request. It’s a whole thing:) Metering by ingestion label is nearly impossible today, only a near approximation with dashboards. Cloud monitoring may be more friendly but i’m not 100% sure.There’s no obvious ways to split out environment and join them, there could be some workarounds to do joins, but I wouldn’t recommend them. Data tables could work but I think a simple convention will serve you better unless you have some more complex logic.Generally namespaces and environments don’t map cleanly because one is a SIEM construct and one is SOAR which really only takes a handful of alerts and would tag an environment. There’s some post SIEM processing (i.e. an alert can move environments) that just make coupling this impractical.Instead what I would do is use the namespace for your environment name and just map them one to one in the SOAR connector. Something like this below. Namespace are environment names and vice versa. That would be the simplest solution and convention, but let me know if i’m failing to capture something in the use case. Let me know if that works or if you’d like some more details, I haven’t played with Data Table joins in dashboards yet but could get you something if you do need it.

Sign up

Login with SSO

Login to the community

Login with SSO