Services

What an Oakdale engagement delivers

Four capabilities, each scoped to a defined outcome and handed over with the documentation your team needs to run it. Most engagements combine two or three.

Microsoft security architecture

The Microsoft security stack is rarely a single product decision. Sentinel, Defender, Purview and Entra overlap, duplicate each other's telemetry and bill in different ways — the value is in designing them as one system rather than four procurement exercises.

Engagements typically start with the workspace and tenant topology, because those decisions are expensive to reverse, then work outwards through log source onboarding, detection content, access model and data protection policy.

What it covers

Sentinel workspace topology, retention and commitment tier modelling
Log source onboarding — Entra ID, Defender, firewall, activity logs, third-party APIs
Analytics rules, automation rules and SOAR playbooks
RBAC and PIM access model, including Sentinel unified RBAC
Defender for Cloud plan selection, Azure Policy deployment and CSPM posture
Purview data labelling, sensitivity policy mapping and DLP integration
Deduplication design where Defender XDR and Defender for Cloud both feed Sentinel

Microsoft Sentinel
Defender XDR
Defender for Cloud
Purview
Entra ID

Azure platform & landing zones

A landing zone is easy to stand up and hard to live with. The decisions that matter — management group structure, subscription boundaries, network topology, identity model, policy inheritance — are the ones that quietly constrain every workload that lands afterwards.

The work here is CAF-aligned but not dogmatic: the reference architecture is a starting point, and the design has to survive contact with the organisation's actual operating model, funding structure and delivery teams.

What it covers

Management group hierarchy and subscription / product model
Platform and application landing zone design
Hub-and-spoke or vWAN network topology, private endpoint and DNS strategy
Azure Policy guardrails, initiative design and exemption process
Identity and access model across platform and workload subscriptions
Naming, tagging and cost allocation standards
Onboarding path for new workloads and partner integrations

Azure Landing Zones
CAF governance
Network topology
Azure Policy
Private DNS

Infrastructure as code & platform engineering

Most Azure estates do not fail on Terraform syntax. They fail on module sprawl, state that nobody dares touch, service principal secrets in variable groups, and pipelines only one person understands.

Delivery here is GitHub-first and secretless by default: reusable workflows, environment protection rules, OIDC federated credentials rather than stored secrets, and Azure Verified Modules where they fit rather than bespoke modules for their own sake.

What it covers

Terraform module structure, composition and remote state design
Azure Verified Module adoption and gap assessment
GitHub Actions reusable workflows, environments and approval gates
OIDC federated identity and managed identity patterns — no stored secrets
Repository structure, branching model and PR review standards
Pipeline security — least privilege, drift detection, plan review
Migration path from click-ops or Azure DevOps where one exists

Terraform
Azure Verified Modules
GitHub Actions
OIDC
Managed identities

Security operations & threat detection

A SIEM that produces more alerts than anyone can triage is worse than no SIEM, because it manufactures the appearance of coverage. Detection work should reduce the volume reaching an analyst while increasing the proportion that matters.

This is written from the position of having done the triage — designing detections, then living with them as the person who receives the alerts at eight in the morning. Rules that are noisy in theory are obvious very quickly in practice.

What it covers

Tiered analytic rule design — high-confidence through to hunting-grade
KQL authoring, review and performance tuning
Watchlist design and enrichment for trusted networks, change agents and privileged accounts
Automation rules and Logic App playbooks for triage and auto-closure
False positive analysis and rule retirement
Detection-as-code via Sentinel repositories and GitHub
Triage runbooks written for whoever holds the pager

Detection engineering
KQL
SIEM / SOAR
Incident triage
Detection as code

Engagement models

Three ways to work together

Whichever shape it takes, the scope, milestones and definition of done are agreed in writing before work starts.

Defined deliverable

A design, an assessment, a migration plan or a detection suite, scoped to a fixed set of outputs and a target date. The most common starting point.

Embedded architect

An ongoing allocation alongside your platform or security team for the duration of a programme — design authority, hands-on build and review, and knowledge transfer throughout.

Advisory retainer

A standing arrangement for design review, second-opinion architecture and escalation support once a platform is live and your team owns it.

Have a platform or security problem to solve?

Send a short outline of what you are trying to achieve and the timescales you are working to.

Start a conversation