Detection Lake brings Sigma rules, threat indicator scans, anomaly detection and vulnerability intelligence into your SecOps Platform. Turn log activity and published threat information into evidence your team can investigate and prioritize.
Four detection methodsEvidence behind the result
From input to evidenceIllustrative workflows
Input & contextWindows process events
Command linepowershell -enc …
Indexed logs with the fields the rule needs.
Product actionEvaluate the Sigma rule
Test the pattern. Deploy it against compatible log data.
Runs on the configured schedule
Usable outputRule findingEncoded PowerShell
Severity
High
Context
Matched event
Open the alert and examine the activity that matched.
A pattern match gives the analyst a concrete event to investigate. It does not establish malicious intent by itself.
Different inputs, different evidence. Published advisories are assessed separately from your logs; response follows your configuration.
01 - Detection Rules
Put a known pattern to the test.
Write or import a Sigma rule, test it against compatible log data, then deploy it on a schedule. Keep rules in Git when you need a versioned source. Your team can inspect what a rule matches before making it part of detection coverage.
Rule example Sigma
title: Encoded PowerShell
logsource:
product: windows
category: process_creation
detection:
selection:
CommandLine|contains: ' -enc '
condition: selection
level: high
1
Import or author
Use built-in rules, upload YAML or sync a repository.
2
Test the match
Read test results and check the available log fields.
3
Deploy deliberately
Choose the rules to activate and set their scan interval.
You control activation. Automatic deployment is off on a fresh installation. Deployment settings can change that behavior; test and deploy actions require the appropriate permissions.
02 - Threat Intel
Give your indicators somewhere to look.
Bring indicators from a URL, an S3 source or a manual upload. Select the log indices and fields to scan, then set the schedule. A finding connects an indicator to the event it matched, so the analyst has a starting point for investigation.
IP indicator203.0.113.48Synthetic example
Your feedIndicator selected
Scan against chosen indices.
→
Log fieldsource.ip
Compare the field to the indicator.
→
FindingMatched event retained
Inspect the source and document.
Choose IP, domain and hash fields that exist in your logs. The scan uses those mappings; alert generation is configurable.
03 - Anomaly Detection
Notice a change without writing a signature.
Anomaly Detection learns patterns in numerical features from selected log data. Start with a template such as Failed Login Spike, choose the indices and interval, then inspect deviations with their anomaly grade and confidence.
Failed Login SpikeIllustrative measurement
Failed login volume
Learned patternObserved volume
Deviation found
Review the change.
Grade describes the anomaly. Confidence describes the model’s certainty.
A deviation is an investigation lead, not a verdict that an attack occurred.
Results depend on your data and detector configuration. This diagram is a conceptual example, not a live product chart.
04 - Vulnerabilities
See the evidence behind the priority.
Advisories from enabled sources are merged into one record per CVE. Known exploitation, severity and exploitation likelihood contribute to an explainable risk score, alongside other available signals. Read the reasons behind the rank before deciding what deserves attention.
Vulnerability corpusSynthetic records · modeled scores
NVDCISA KEVCERT-EU
Advisories merge by CVE ↓
RiskIllustrative record
Select a record to inspect why it ranks here.
Review the available signals and reporting advisories before acting on a score.
Example CVE ACritical
86/ 100 risk score
CISA KEV listedYes
CVSS severity9.0 / 10
EPSS likelihood50%
Ransomware linkYes
The ransomware signal raises this record above an otherwise identical KEV-listed example.
Example scores use only the signals shown. The full corpus can also include source corroboration and disclosure recency.
Rank the evidence, not just severity.
CVSS describes severity; EPSS estimates exploitation likelihood; CISA KEV identifies known exploitation. Their combination gives your team a more informed priority.
Know what the list establishes.
This is published vulnerability intelligence. Confirming which of your assets are affected belongs to Defensum and your scanner data.
05 - From evidence to action
Make the next step deliberate.
Review the finding, confirm its context and choose the response that fits. Detection methods expose different kinds of evidence; they do not all run the same automatic response sequence.
1
Investigate rule findings
Rule findings can appear in Alerts with their detection context. Follow the evidence into your investigation workflow.
Opt in to notifications for meaningful vulnerability changes. Enable Casebook case creation or Automatio playbook dispatch for the transitions you select.
Detection Lake is a SecOps Platform module. Access and actions depend on your license, permissions and configuration. Advisory notifications are off by default.
For detection engineering across your existing SIEM estate, explore Virtus Optimus, a separately licensed module.
Questions about Detection Lake.
1Do we have to write every rule ourselves?
No. Use built-in Sigma rules, upload your own or sync a Git repository. Test the rules against compatible log data and confirm deployment settings before activating them.
2Can we use our own threat indicators?
Yes. Configure a source or upload indicators, then choose the indices, IP/domain/hash field mappings and scan schedule.
3Does a high vulnerability score mean we are exposed?
No. It ranks published vulnerability intelligence using available risk signals. Confirm asset exposure with Defensum and your scanner data. Review the available signals and their sources before acting on a score.
4Does every detection automatically open a case?
No. Case creation and response depend on configured triggers and enabled capabilities. Advisory notifications are opt-in; case and playbook actions are configured for individual transitions.