Extension development
for your SIEM
Your vendor’s catalogue covers the most common sources. For everything else — specialised devices, line-of-business applications, local sources — it has to be built. That is what we do, across every platform in our scope.
An unnormalised source is a half-useless source
Ingesting raw logs into a SIEM is not enough. Without field extraction, without mapping to a common data model, a source can feed neither the correlation rules, nor the dashboards, nor the compliance reports. It consumes licence and produces no detection.
A well-built extension solves that once and for all: it turns a proprietary feed into data the whole platform can use — rules, dashboards and reports included. Each vendor has its own mechanics; the principle stays the same.
Microsoft Windows Firewall Observability
A Splunk application built by our teams and published on Splunkbase, filling a gap in the catalogue: giving real operational visibility over Windows Firewall logs, often collected but rarely used.
Event extraction and normalisation, dashboards tracking rules and blocks, detection of configuration changes.
What an Avangard extension contains
Collection and parsing
Sourcetype definitions, field extraction, handling of multi-line formats and timestamps, event breaking.
Normalisation
Mapping to the platform’s data model — CIM on Splunk, ECS on Elastic, ASIM on Sentinel — the precondition for feeding the standard rules.
Dashboards
Ready-to-use operational views, designed to be readable by an analyst who does not know the source.
Detection use cases
Correlation searches and alerts shipped with the application, documented and mapped to MITRE ATT&CK techniques.
Documentation
Installation and configuration guide, description of extracted fields, prerequisites, version compatibility matrix.
Packaging and publication
Validation through the vendor’s inspection tooling, alignment with its requirements, publication on the official catalogue where it makes sense, and version tracking.
Every vendor has its own vocabulary
The principle is identical — making a source usable — but the mechanisms and formats differ. We work across every platform in our scope.
| Platform | What we build | Data model |
|---|---|---|
| Splunk | Applications and technology add-ons, publishable on Splunkbase | CIM |
| Microsoft Sentinel | Data connectors, parsing functions, analytics rules and workbooks | ASIM |
| Elastic Security | Integrations, ingest pipelines, processors and dashboards | ECS |
| OpenText ArcSight | Connectors, notably FlexConnectors for proprietary formats | CEF |
| Wazuh | Decoders, detection rules and integration modules | Wazuh schema |
Line-of-business applications built in house, devices from regional vendors, legacy systems whose format is documented nowhere: these are precisely the sources no vendor catalogue will ever cover, and often the richest in signal for your context.
Private or published extension
Private extension
Built for your use alone and deployed on your platform. You own the code and are free to develop it further.
- Internal sources and proprietary business applications
- Specific detection logic you would rather not expose
- Confidentiality constraints on data schemas
Extension published to the catalogue
Made available to the community under our name or yours, with maintenance and compatibility assured over time.
- Visibility across the global Splunk ecosystem
- Vendor positioning for your organisation
- Sources of general interest, not specific to one client
From log sample to delivered extension
Analysis
Study of real samples and of the source documentation.
Design
Target data model, fields to extract, mapping to the platform schema.
Development
Configuration, extractions, views and saved searches.
Validation
Testing on real data, vendor checks, performance review.
Delivery
Deployment, documentation, publication and version tracking.
A source your SIEM ignores?
Send us a log sample and the source documentation. We will tell you quickly what can be drawn from it and at what effort.