PROJECTS & CASE STUDIES

Ideas made operational.

Hands-on work across infrastructure, cloud security, identity, and operations. Explore the thinking behind each build.

Projects · 4

Cloud SecurityDevSecOpsInfrastructure as CodeCI/CDNetwork Security

Azure Cloud Security WAF Lab

A cloud security lab that balances threat operations with modern infrastructure engineering. It deploys an Azure Web Application Firewall (WAF) to defend a deliberately vulnerable target (DVWA), while utilizing a DevSecOps CI/CD pipeline to automate provisioning, enforce shift-left security, and validate SIEM telemetry.

The challenge

To effectively study Web Application Firewall (WAF) tuning and SOC telemetry, I needed a realistic, controllable cloud environment. Static labs do not provide the necessary hands-on experience of executing live OWASP Top 10 attacks, observing how a cloud WAF intercepts them, and analyzing the resulting security logs in a centralized SIEM.

The approach

To bridge operational security with cloud automation, I used Terraform and GitHub Actions to provision a Dockerized Damn Vulnerable Web App (DVWA) behind an Azure Application Gateway configured with a strict WAF policy. The deployment is governed by a CI/CD pipeline that enforces shift-left security, blocking exposed secrets and cloud misconfigurations pre-merge, while utilizing passwordless Azure OIDC authentication. Once deployed, the environment serves as a live cyber-range: the pipeline automatically fires controlled web exploits (such as SQL injection) at the target, and an integrated Azure Log Analytics Workspace captures the resulting WAF telemetry, enabling deep SIEM event analysis using Kusto Query Language (KQL).

The outcome

Built a fully functional, repeatable cloud security lab. Successfully demonstrated the ability to execute live web exploits (SQLi, XSS), intercept them at the network edge with a WAF, and perform security event analysis on the resulting SIEM telemetry.

Cloud SecurityAI GovernancePolicy as CodeDevSecOps

AI Policy Gate

A Policy-as-Code deployment gate that blocks non-compliant AI systems before they reach production and emits a tamper-evident audit record for every decision — evaluating each system against the EU AI Act, NIST AI RMF, ISO/IEC 42001, and GDPR, enforced at both the CI/CD and Kubernetes admission boundaries.

The challenge

AI governance is mostly enforced by hand — spreadsheet trackers, email approvals, and portal clicks. There is no executable definition of what must be true before an AI system ships, and no verifiable record of why a deployment was approved. Obligations live in natural-language legal texts scattered across the EU AI Act, NIST AI RMF, and ISO 42001; they cannot be checked at machine speed, and nothing stops a high-risk system from reaching production without a completed impact assessment, bias testing, or human oversight. When an auditor asks "when was this approved, against which policy version, on what inputs?", the answer is reconstructed from memory. The deployed system is never provably the system that was approved — the gap the CAIMOM framework calls EidosTwin versus OusiaTwin.

The approach

I built the control as a deterministic gate rather than a document. Governance obligations are declared once, in machine-readable Rego, and evaluated against a system manifest before deployment. Not every rule belongs to the same framework, so each is routed to the package that owns it: EU AI Act risk-tiering and impact-assessment gating, NIST AI RMF red-team and guardrail checks, GDPR and W3C-PROV data-governance controls, and an internal corporate baseline — 14 controls across four packages, each deny message carrying a stable ID and a citation to the source clause. OPA/Rego was chosen over a hand-rolled rules engine because it is the industry standard and the reference implementation named in the catalogue; a pure-Python engine was still built alongside it as a fallback and as a cross-validation layer, so any divergence between the two fails the build. Enforcement is layered rather than blunt: the same policy logic runs at two boundaries — the CI/CD pipeline via a CLI, and the Kubernetes cluster via an OPA Gatekeeper admission controller — so a non-compliant workload is blocked at provisioning time even if it slips past the pipeline. Environment awareness is built in: dev workloads pass with reduced requirements, production high-risk systems must satisfy the full control set. Every decision produces a JSON evidence record whose own contents are hashed into it, making the decision reproducible, the policy version traceable, and any later tampering detectable.

The outcome

14 controls covering EU AI Act prohibited-tier blocking, high-risk impact-assessment gates, human-in-the-loop enforcement, ISO 42001 mapping, NIST red-team and bias requirements, runtime guardrails, agent kill switches, data provenance, licensing, PII sanitisation, EU data residency, and model-registry signing. Validated against eight synthetic manifests spanning compliant, non-compliant, and edge cases; 18 tests at 86% coverage, lint-clean, running on Python 3.10–3.12 in CI with a dedicated OPA integration job that executes the real Rego and cross-checks it against the Python engine. Ships as an installable package with a four-command CLI, a Docker image that bundles OPA for zero-setup runs, a runnable Kubernetes admission-control demo, and an HTML compliance report for non-technical reviewers. Built against current frameworks — EU AI Act (Reg. 2024/1689), NIST AI RMF 1.0, ISO/IEC 42001:2023 — rather than pre-Act guidance, and the tamper-evident evidence design targets the audit trail those regulations require but most tooling omits.

Cloud SecurityIAMPolicy as CodeDevSecOps

Entra Conditional Access Library

17 production-ready Microsoft Entra ID identity-security patterns as code - Conditional Access, tenant authorization, and PIM - mapped to MITRE ATT&CK and deployed via Terraform and Microsoft Graph.

The challenge

Conditional Access is usually configured by hand in the Entra portal - undocumented, untested, and impossible to review or roll back. There's no version history, no explanation of which attack each policy stops, and one careless policy can lock every administrator out of the tenant. Teams end up with drifted, unexplained rules nobody wants to touch.

The approach

I built each control as a reviewable unit: a Terraform definition, the MITRE ATT&CK technique it defends against, test scenarios, and a rollback path. Every policy ships in report-only mode and excludes two break-glass accounts created before any policy existed. Not every control is a Conditional Access policy, so each is routed to the right tool: Terraform (azuread) for the 15 CA patterns, Microsoft Graph PowerShell for the tenant authorization policy and the two PIM patterns the provider doesn't model. Bicep was evaluated and rejected — its Graph extension has no Conditional Access resource type. Tooling decisions are recorded as ADRs. Patterns are layered rather than blunt: high sign-in risk blocks, medium risk steps up to MFA, and high user risk forces a secure password change — a graduated response instead of one all-or-nothing rule.

The outcome

17 patterns covering legacy-auth blocking, phishing-resistant MFA for admins, risk-based access (Identity Protection), device compliance, location controls, app protection, token-replay limits, OAuth consent restriction, guest access, workload identities, and PIM just-in-time activation with recurring access reviews. 13 deployed and verified in a live tenant in report-only mode; one is code-complete but gated on a separate paid SKU, documented rather than faked. Built against current Entra — the retired "require approved client app" grant is replaced with the app-protection-policy control most references still miss.

CloudIaCGRC

NIS2-Compliant AWS Landing Zone

An open-source AWS Landing Zone built with Terraform, focused on deploying automated security baselines and robust cloud infrastructure controls to meet strict NIS2 & ISO 27001 Annex A regulatory compliance.

The challenge

Eighteen months after NIS2 came into force, almost no public Terraform examples map to it by name — regulated EU teams have CIS and NIST references but nothing tying infrastructure to NIS2 Article 21 obligations.

The approach

Modular Terraform (KMS, S3, CloudTrail, AWS Config, VPC, Organizations, Identity Center, GuardDuty, Security Hub), each resource tagged to the NIS2 measure and ISO 27001 control it satisfies. Validated free on LocalStack Pro, with a single cost-controlled real-AWS run for evidence.

The outcome

Auditable control-to-resource traceability, a full CI gauntlet (Checkov, tfsec, Infracost, terraform test) on every PR, and a reproducible landing zone anyone can stand up with one command.