Detection Engineering Foundation

Overview

Most organisations collect logs. Few analyse them effectively. The gap between “we have logs” and “we have detection capability” is wider than it looks: it requires the right log sources, a working collection pipeline, normalised and enriched data, and detection logic that finds real threats rather than generating noise.

Building that foundation takes expertise and time that most engineering teams don’t have to spare. Opcode’s Detection Engineering Foundation engagement does it for you: design the architecture, build the collection pipeline, engineer the initial detection rule set, document everything, and hand it over. Your team owns and operates it after; Opcode builds the foundation they need to be effective.

What’s included

Log source selection and prioritisation: Not all logs are worth collecting. Opcode identifies the sources that matter most for detection in your environment (cloud control plane, identity provider, endpoint, network edge, and application logs) and prioritises based on threat coverage and data volume.
Collection pipeline design and build: End-to-end log collection pipeline designed and built for your environment. Cloud-native where possible: AWS (CloudWatch + OpenSearch), Azure (Microsoft Sentinel), or GCP (Chronicle). Includes normalisation and field enrichment so detection rules have consistent, queryable data.
Detection rule development: A minimum of 20 detection rules engineered for your environment, covering the threats most relevant to your industry and technology stack. Rules are written with documented logic, tuning guidance, and false positive mitigation built in.
Detection runbook: Analyst runbook covering alert triage workflow, investigation steps for each detection category, escalation criteria, and evidence collection guidance. Written for the person who will run the system, not a generic template.
Handover and knowledge transfer: Full handover session with your team. All infrastructure as code, detection rules, and documentation transferred. Your team leaves the engagement able to operate, tune, and extend what was built.

Supported platforms

AWS: CloudWatch Logs, OpenSearch (managed), GuardDuty integration
Azure: Microsoft Sentinel, Log Analytics workspace
GCP: Chronicle Security Operations, Security Command Center

One primary platform per engagement. Multi-cloud environments can be scoped on request.

What your team owns after engagement

Everything. Opcode does not retain access or ongoing involvement unless separately engaged. Deliverables include:

Infrastructure as code for the collection pipeline (Terraform or CloudFormation)
All detection rules with logic documentation and tuning notes
Detection runbook in Markdown, ready to add to your internal wiki
Data flow diagram and architecture documentation
30-day post-handover support window for questions

How it works

Scoping: Define the platform, environments in scope, existing log sources, and detection priorities. Review any existing tooling or partial implementations.
Architecture design: Draft detection architecture reviewed and approved with your team before build begins. No surprises.
Pipeline build: Collection infrastructure deployed and validated. Log sources connected and verified. Data quality checks completed.
Rule development: Detection rules developed, tested against historical log data, and tuned to reduce false positives before handover.
Handover: Full documentation delivered. Knowledge transfer session with your team. 30-day support window begins.

Who this is for

Organisations that have been told they need a SIEM or detection capability but don’t know where to start
Engineering teams that collect logs but have no process for analysing them
Security teams that want detection capability without creating a dependency on a managed service provider
Organisations preparing for ISO 27001, CPS 234, or ISM compliance requirements that include continuous monitoring controls
Companies that have outgrown their current logging setup and need a proper foundation before scaling