Onboarding log sources across a distributed SIEM

Guardsix SIEM 7.10 lets you manage log sources centrally and check the result at every collection point. Configure a source once on the Search Head, then see whether it took effect on each node it was meant to reach.

Most on-prem SIEM estates stopped being one appliance a long time ago. A mid-sized health service might run two data centres and twenty-odd sites. An energy operator may keep a segmented zone between the plant network and everything that faces the internet. Provider partners run separate environments for every organisation they serve.

In many cases, these organisations started on a simple, all-in-one SIEM implementation and updated their architecture over time to catch up. But if the process for onboarding new sources did not catch up, it leaves the team repeating the same configuration on each new instance they manage.

That is the work Guardsix SIEM 7.10 moves into one place, for lean teams running against hard deadlines.

What changes

• Create, configure and monitor a log source entry from the Search Head, for any collection point in the environment
• See the result for each collection point, so a partial success is visible when it happens rather than at the next audit
• A record of who changed which entry, where, and whether it took effect
• The Search Head and its collection points keep talking to each other, even where network address translation sits between them

Distributed on-prem is treated as a first-class case here rather than an accommodation, because self-hosted capabilities are roadmap priorities for Guardsix and our allies.

What the work looked like until today

Here are a couple of examples of what onboarding log sources across a distributed SIEM looks like in practice:

• At a regional health service, you might have twenty sites pointed by hand at one of two instances. That sounds like a splitting problem until you look at it closely: some assets at a given site have to reach one specific destination regardless of where they sit, so no site-based rule ever settles it. Every new source is a decision, then a piece of manual configuration, then a note somewhere about which instance got it.

• A Managed Security Service Provider configures each source twice while it runs two instances. The business grows to four instances, and every source now gets configured four times. A team that budgets for work scaling with the number of sources, rather than the number of instances, ends up with a backlog it cannot clear.

This is expensive because of what goes into the onboarding process. A log source entry carries the transport, the port or endpoint, the credentials, and which parser and normaliser apply to what arrives. The processing policy then applies normalisation, enrichment and routing. Enrichment is assigned per log source entry rather than globally, which is useful and also means one more decision for every source you add. Now multiply that chain by the number of instances that need the source.

This process was not unique to Guardsix SIEM. Almost all major self-hosted SIEM solutions work in broadly the same way. Cloud-first vendors offer simpler workflows only to customers who migrate to the cloud, which is a reasonable trade for the organisations that can make it and no answer at all for the ones that cannot.

How log source onboarding works in Guardsix SIEM

The create flow now asks where collection happens as part of creating the entry, so the entry and its collection point are configured together in one pass.

Three collection mechanisms reach Guardsix SIEM, and the difference between them is who opens the connection.

• A collector listens. The source pushes records to a port, and the collector buffers them.
• A fetcher polls. Guardsix authenticates and pulls on a configurable interval, which is how database queries and cloud platform APIs are both handled.
• An agent sits on the host, with a local buffer, for Windows event logs and file integrity monitoring.

A Distributed Collector puts the first of those close to remote sources. It receives records, buffers them locally, delimits individual messages in the parser and forwards them onward for processing. Its job stops there by design: search, dashboards, alert rules and reports all stay on the Search Head, which is what keeps a remote site a collection point rather than a second system to administer.

Be confident it worked, one collection point at a time

Configuring from one place only helps if the result comes back from every place. This matters more in a distributed estate than in a single one because a partial success may go unnoticed.

In Guardsix SIEM, the log source listing carries two things per node: whether each source is active or inactive, and when logs were last collected. Both are visible from the Search Head as well as the node itself. Changes to a template run as an update job against the sources that use it, and those jobs can be seen and removed from the Search Head too.

When a multi-country enterprise migrates to a new environment, what happens when several hundred sources are absent after the cutover? Some may be legitimately dormant. Prior to this release, establishing which were dormant and which were misconfigured was slow, manual work — but that is the work that decides whether an estate is audit-ready three months later.

These kinds of gaps are worth more attention than they often get. Techniques that start with local administrator access and work downward ultimately result in the endpoint tool being the component that goes silent. What is left is whatever already reached the SIEM, from the hosts you believed were reporting.

Find out more about how loading a signed but vulnerable driver to disable the endpoint agent works with our security research team's report on the BYOVD EDR killers.

Get a record of who changed what, and where

Creating a log source on a node from the Search Head is recorded in the audit log, along with changes to devices, device groups, log collection policies, repositories and the data nodes themselves. The record carries the timestamp, the account that made the change, the object it was made against, and the action taken.

Misconduct is not the only failure this guards against. Our allies have gone through implementations where technical consultants left mid-project, leaving with the storage platform half-configured and the architecture options undocumented. Nothing recovers a decision nobody recorded. A change record means the next person inherits what was done and where, instead of starting from a blank page.

Distributed onboarding matters to the institutions society depends on

Cloud-mediated platforms solved distributed onboarding some time ago. They simply put the control plane in the cloud. That is a real answer, and it works for organisations that can put their data there and feel confident about it. But it is not a one-size-fits-all solution.

A distributed on-prem estate does not have that option, and the organisations running one are frequently the organisations least able to undergo a cloud migration. It will not work for a health service holding patient data, a grid operator under state regulation, or a municipality answering to the people who live in it.

For those organisations, a capability that only works from someone else's cloud is not a capability they can use. It has to arrive in the jurisdiction they control, as a release they can plan around, in an estate they operate. That is what an active on-prem roadmap means in practice, and it is why this use case gets real engineering attention rather than a note in the documentation.

Action for existing deployments before 1 January 2027

The root CA certificate that secures communication between Guardsix components expires on 1 January 2027. After that date, components still relying on it cannot establish trusted connections with each other. There is a path for every supported version, and there is time to act before the cut-off date.

Guardsix Fleet users must update the root CA certificate before updating the SIEM. The full guidance for every version, including the sequencing for Fleet, is on our root CA certificate support page.

What to do now

The upgrade paths for this release, including the sequencing for a distributed environment, are in the 7.10 launch post. If you are planning an upgrade around a change to the estate rather than after one, that is the sequence this release was built for.

To see how the platform handles a distributed estate end to end, start with Guardsix SIEM. Sovereign-by-design security is a priority