Review build, not published. Items marked to confirm need your input before launch.
TheSefaWay
Get in touch

Microsoft security platform engineering

Microsoft security engineering that holds up to review.

TheSefaWay designs and builds Microsoft Sentinel platforms, detection release pipelines and incident automation. Every change is versioned, tested in a lab before it reaches production, and documented so your team can run it without me.

Discuss a project See selected work →

Platforms and tools I work with

  • Microsoft
  • Microsoft Sentinel
  • Azure
  • Azure Arc
  • Azure Monitor
  • Azure Lighthouse
  • Microsoft Entra ID
  • Logic Apps
  • KQL
  • GitHub
  • GitHub Actions
  • ServiceNow
  • Windows
  • Linux
  • Model Context Protocol

Release model

Nothing reaches a tenant without passing the gate before it.

How a detection moves through the release model I build.

Detection · lifecycle5 stages · 4 gates

  1. dev/

    Author

    Rule written as code, with a stable identity derived from its rule ID.

  2. Peer review
  3. lab

    Validate

    Run against simulated attack telemetry. Results recorded, not remembered.

  4. Evidence
  5. v1.0.0

    Release

    An immutable, versioned copy joins the catalogue. No tenant changes yet.

  6. Code owner
  7. manifest

    Distribute

    A per-destination manifest pins which version lands where.

  8. Approval
  9. GET only

    Verify

    A read-only drift report compares what is deployed with what was released.

Services

Services.

Focused on the Microsoft security stack, where I do my deepest work. Engagements are scoped around a concrete outcome and end with something your team owns.

01

Sentinel platform engineering

Workspace architecture, environment separation and the telemetry that feeds it. I build collection with Azure Arc, the Azure Monitor Agent and data collection rules, covering Windows security events, DNS and Syslog/CEF sources, filtered so you pay for signal rather than noise.

  • Dev, lab and production workspaces with a clear promotion path
  • Data collection rules and cutovers planned to avoid collection gaps
  • Delegated access across tenants with Azure Lighthouse and GDAP, scoped to least privilege
  • Naming standards and onboarding checklists that make the next tenant faster

02

Detection content delivery

Analytics rules treated as a product with releases. I set up the repository, pipeline and review gates that move detection content from authoring to validated, versioned deployment, including across multiple tenants.

  • CI/CD with federated identity, so the pipeline stores no secrets
  • Separate lifecycle and distribution, so each destination gets a pinned version
  • Deterministic rule identities and read-only drift reporting
  • A detection validation lab and a written validation record standard

03

Response automation and integration

Incident workflow that holds together across tools. I connect Sentinel to ServiceNow and build automation rules and Logic Apps with explicit approval steps wherever an action changes something.

  • Incident sync with severity mapping and owner assignment
  • Approval-gated containment workflows
  • Runbooks and an incident taxonomy your analysts will actually use

Selected work

Selected work.

Engineering I have designed and built hands-on. Details are abstracted to protect the environments involved. Each item states honestly where it stands.

  • Validated in test

    Cross-tenant detection deployment with no stored secrets

    A pipeline identity that authenticates through federated credentials, then deploys analytics rules into a separate tenant's Sentinel workspace through delegated resource access. No guest accounts, no tenant switching, and a role that can deploy content but cannot change access.

    Where it stands: deployments into separate test tenants have succeeded end to end.

  • In validation

    A release and distribution model for detection content

    Folders carry lifecycle and manifests carry distribution, so one catalogue can serve several destinations at different pinned versions. Four content classes, from vendor templates to client-specific rules, each get their own validation route, with code-owner review before anything is released.

    Where it stands: repository, workflows and review gate are built; the first full run from authoring to production is in progress.

  • In validation

    Deterministic rule identity and drift reporting

    Rule identities derived from the rule ID rather than assigned by the portal, so the same detection is recognisable in every workspace. A read-only report then shows where a deployed rule differs from its released version.

    Where it stands: implemented and in review.

  • Running

    Additive telemetry cutover to a new production workspace

    Windows security events and DNS telemetry routed to a new production workspace by adding a second data collection rule association, rather than re-onboarding the host. Development kept its live feed for detection authoring while production began receiving the same events.

    Where it stands: both workspaces are receiving data.

  • Validated in test

    Incident sync between Sentinel and ServiceNow

    Automation rules that select incidents for sync by severity on creation and on escalation, so an incident that starts informational and later becomes serious still reaches the service desk. Owner assignment carries across in both directions.

    Where it stands: all three sync scenarios passed in the development environment.

  • In validation

    A delegated access model built on separate planes

    Billing, Azure resource control and directory identity treated as three separate decisions instead of one. Azure Lighthouse handles resource access, GDAP handles the identity plane, and each tier of service gets only the roles it needs.

    Where it stands: read-only delegated access is proven on a test tenant; elevated response actions are still being validated.

  • Proof of concept

    Governed AI access to security tooling

    A gateway that exposes Sentinel data to an AI assistant through a small set of controlled tools. Incident queries are read-only. Containment can be requested but never executed: the tool produces an approval request, and no code path exists that could act on its own.

    Where it stands: a four-stage local proof of concept, from mock server to a real read-only query, built and verified.

Products

Software we build.

Alongside the security work, a small team and I build our own software. Security comes first in everything we ship, starting with Trojan.

Product · 01macOS · Windows · CLI

Available

Trojan

A vulnerability scanner for codebases that runs entirely on your machine.

Trojan finds leaked secrets, risky dependencies and dangerous code patterns, then explains each finding in plain English with the exact fix. It adds AI-assisted penetration testing and one-click security and compliance reports for clients and investors, and it works with MCP.

  • Local-first: no source upload, works offline and air-gapped
  • Findings ranked into five levels by how exploitable and how damaging they are
  • Free scanner, with paid plans for AI testing and reports
Visit trojancli.com →
Detection rules
3,400+
Updated weekly from public advisories
Languages
14
JS/TS, Python, Go, Ruby, Rust, Java and more
Median scan
4.2 s
On a 100,000-line repository
Code sent to servers
0 bytes
Scanning runs entirely on your machine

Early access

Morning

An AI daily assistant.

Early access

Colana

A social space for university students and graduates looking for work.

Approach

Approach.

A typical engagement follows the same order, because each step makes the next one safer.

  1. Map what exists

    Inventory workspaces, data sources, rules, identities and dependencies before proposing change. Nothing gets decommissioned on assumption.

  2. Decide in writing

    Short decision records for anything structural: what was chosen, what was rejected and why. You keep them after I leave.

  3. Build in a lab first

    Detections and response workflows prove themselves against simulated activity before they touch a production tenant.

  4. Promote through gates

    Review, evidence and approval at each step, enforced by the pipeline rather than by good intentions.

  5. Hand over

    Runbooks, onboarding checklists and a clear record of what is proven and what is still being tested.

About

About.

heSefaWay is a founder-led practice. When you work with it, you work directly with the engineer who designs and builds the system.

I am [Public name, to confirm], [title, to confirm]. My work sits where security operations meets platform engineering: Microsoft Sentinel and Azure, the telemetry pipelines underneath them, the delivery systems that keep detection content consistent across environments, and the automation that connects incidents to the people handling them.

Alongside client work, a small team and I build our own software, including the Trojan vulnerability scanner. I work iteratively and test in real environments. I write documentation that is plain, precise and scoped, and I keep the line between what is proven and what is still being tested visible to everyone involved.

Microsoft, Microsoft Sentinel, Azure and Azure Lighthouse are trademarks of the Microsoft group of companies. TheSefaWay is independent and not affiliated with Microsoft. ServiceNow is a trademark of ServiceNow, Inc.

Get in touch.

Tell me what you run today and what you want to be true in three months. I will reply with whether I can help, and if not, who might.

Email
Public email address, to confirm
Book a call
Booking link, to confirm

There is no contact form on this site. Until the address above is confirmed, the contact route is not live.