A SIEM deployment is not finished when the logs start to flow. Collected logs become alerts only when someone has decided what to detect, built and tested the logic, and tuned the results. In a partner-led deployment, that work often falls to you, and it lands before the organisation sees a first useful alert.
Picture a municipal IT team of four, eight weeks before an audit, working with the partner who runs their SIEM. The logs arrive on day one. The detection rules have to come from somewhere, and every week spent writing them is a week not spent on the risks specific to that municipality.
The Day-One Detection Pack gives that partner a starting point: 63 detections, selected by Guardsix Security Research from the library of 622 it maintains. Your first service starts from a defined baseline instead of a blank page.
The pack gives you:
The pack is cut from the library Guardsix Security Research maintains, so the logic stays open for you, and for an auditor, to inspect.
More detections do not automatically mean better protection, because every detection depends on the right telemetry and the right context. Some need technologies an environment may not use. Others pay off only after tuning.
Enable everything at once and analysts spend their first weeks managing alerts instead of investigating the ones that matter. For a partner, those are also the weeks in which the organisation decides whether the service is working. The pack starts with a focused baseline, and you expand it with purpose.
Guardsix Security Research evaluated the library against three considerations, aiming for a baseline that works across commonly deployed environments from the first day.
The pack prioritises behaviours from the stages of an intrusion where early detection gives analysts room to investigate and respond: credential access, privilege escalation, persistence, lateral movement and discovery.
A day-one detection has to earn the analyst attention it creates. Rules that depend heavily on organisation-specific context come into play later, once you can supply that context and the tuning that goes with it. They keep their value and make more sense once the environment can support them.
A detection runs only when its data is available. The pack covers Windows, Active Directory, Microsoft 365 and Azure, which sit at the centre of many organisations’ security monitoring. You can begin detecting without adding specialised monitoring technology first.
The 63 detections map to 10 techniques and sub-techniques in MITRE ATT&CK, the public catalogue of attacker behaviour.
| ATT&CK ID | Technique | Primary tactic |
|---|---|---|
| T1047 | Windows Management Instrumentation | Execution |
| T1021.001 | Remote Desktop Protocol | Lateral Movement |
| T1543.003 | Windows Service | Persistence |
| T1547.001 | Registry Run Keys / Startup Folder | Persistence |
| T1053 | Scheduled Task/Job | Persistence |
| T1098.002 | Additional Email Delegate Permissions | Persistence |
| T1110.001 | Password Guessing | Credential Access |
| T1003 | OS Credential Dumping | Credential Access |
| T1087 | Account Discovery | Discovery |
| T1526 | Cloud Service Discovery | Discovery |
Detections that need less common telemetry, or tuning to decide whether an alert is useful, sit in the wider library. The Use Case Navigator, described below, shows what you can expand into.
The 63 detections come from the same library of 622 that Guardsix Security Research maintains, so there is no second rule set to keep in step. Detection-as-Code (DaC) makes that possible. Each detection lives as a structured YAML definition that holds the logic alongside the details needed to manage it: identity, version, required log source, trigger conditions, risk level and evaluation window.
That structure lets the team review, update, version and reuse each detection as the library grows. When a query, threshold, risk level, required telemetry or evaluation window changes, the change goes into the YAML source and ships as a new version of the same rule.
Three components share the work:
The pack is a selection from this library, so the baseline can follow as the underlying detections improve.
A versioned manifest defines the pack. It lists the 63 selected detections by rule ID and file path, so the pack stays in step with the rules in the repository instead of duplicating them. In the repository, the pack’s folder is named day-1.
The manifest lists the Alert Rules integration, version 7.0.0 or later, as a dependency, so check that it is in place first. Then work through these steps:
The --pack option takes the name of the pack’s folder, and --packs-dir points to the Packs directory.
A trusted baseline is one you can inspect. The manifest in the public Guardsix OSS detection-rules repository names every detection in the pack, and the YAML definitions beside it show the logic and metadata behind each one.
If you prefer a browser to raw YAML, the Guardsix Use Case Navigator lets you search rules by name or description, inspect each rule’s detection query and MITRE ATT&CK mapping, and see technique coverage as a dashboard and heatmap. It reads directly from the rules published in the repository, so it stays current with each release. The two answer different questions. The pack tells you where to start. The Navigator shows what else you can detect as the environment and the detection strategy change.
The short video below follows one rule from the repository to a search in Guardsix SIEM. You copy the rule’s detection query from the Navigator and run it as a search against your own logs, which is a way to test a rule’s logic before you deploy anything. Deployment itself runs through g6-alert, as described above.
For a partner, the first weeks of a deployment decide how the service is judged and how quickly it can grow. The Day-One Detection Pack gives you four things to build on.
Time to first useful alert should not depend on how many hours your engineers can spare. Each deployment starts with 63 selected detections, so engineering time goes into fitting the baseline to the environment rather than assembling one.
A versioned manifest defines the same set every time. That gives you one starting point across the organisations you serve, the same review step in each, and a consistent first service to describe, support and improve. Your own detection content, runbooks and dashboards go on top.
The review is where your expertise shows. You check the baseline against each environment before you run the install command, and that review and the tuning that follows are services you can package in your own way. If you resell Guardsix SIEM, the manifest and the Navigator also give your pre-sales engineers something concrete to show before a deployment starts.
Land on the first job: a trusted baseline and evidence you can show an auditor. Expand when something changes, such as an incident, an audit finding or a new network zone. The Navigator shows the detections behind each security use case and ATT&CK technique, so follow-on detection work has a defined scope when the conversation starts.
Node-based pricing follows infrastructure, not ingestion. A quote built on nodes does not move when an organisation’s log volume grows or retention extends, so a growing estate does not turn into a pricing conversation you did not plan for.
When you talk to an organisation about the pack, three lines carry the story:
The Day-One Detection Pack is one example of how Guardsix SIEM shortens the path to value for partners. Open the Guardsix Use Case Navigator to see the full library, open the Day-One Detection Pack manifest and review it against a deployment you are planning.
Then discover how the Guardsix Collaborate partner programme supports your time-to-value and helps you build a stronger commercial model. Your first deployment starts with 63 detections you can read, tune and build on.