Capabilities

Six domains

These are the areas I have worked in long enough to have opinions about, listed with what I have actually done in each and the tooling involved. The first one is where I think the next several years of this field are going, and where I have found the fewest people with shipped experience.

Security data lakes

Overview: Detection over telemetry you own, in formats anyone can read. Events land as Parquet on S3-compatible object storage under an open table catalog; detection runs at stream time as data arrives, and the same engine replays historical data for retro-hunting, so live and historical rules cannot drift apart. Hot, warm and cold tiering runs against the generic S3 API rather than any one vendor's lifecycle feature, so the lake moves without modification.
How I have applied it: I designed and built JuniLake end to end: seventeen containers in one Compose project, ingesting Windows endpoint telemetry, evaluating 2,776 Sigma rules, delivering alerts into a sibling SOC product. In my current role, security data lake work sits alongside detection engineering and purple-team operations. This is the capability I would most want to bring into an organisation that is tired of per-gigabyte pricing and cannot see its own data.
Stack: Parquet · Apache Iceberg / DuckLake · DuckDB · S3-compatible object storage · Sigma · Rust detection engine · NATS JetStream · Fluent Bit · PostgreSQL · Docker Compose

BAS, CTEM & exposure validation

Overview: Breach and attack simulation is only half the job. Most tooling stops at the red cell — the simulation runs, the gap is displayed, and the platform considers itself finished. In a real continuous threat exposure management program the gap is the beginning: who owns it, what the treatment plan is, whether it was actually fixed, and whether the re-test proves it. Adversarial exposure validation is the next step again — continuously establishing which exposures are genuinely exploitable and genuinely being closed.
How I have applied it: I currently lead a global BAS and remediation practice: ATT&CK-aligned adversary simulation validating control effectiveness across detection, prevention and response, with the remediation and risk-treatment lifecycle — assignment, assessment, prioritisation, closure — owned end to end with control owners across technology and the business. I built JuniBas to model that lifecycle properly: an eight-state remediation workflow, re-test mini-engagements, SLA clocks measured in business hours, and a cross-entity audit trail.
Stack: MITRE ATT&CK · Atomic Red Team · CALDERA · OpenAEV · Picus · Cymulate · SafeBreach · CrowdStrike Falcon and Microsoft Defender as validation targets · NIST CSF · Python / Flask · PostgreSQL

Red & purple teaming

Overview: Multi-month red-team engagements with real tradecraft, and the purple-team format where attackers and defenders sit in the same room so detections and playbooks improve during the exercise rather than in a report afterwards. Purple team is where the offensive and defensive halves of my career meet, and it is the work I care about most.
How I have applied it: Red-team engagements and penetration testing across web, mobile, infrastructure and cloud for publicly listed clients; social engineering and phishing simulations; custom endpoint evasion techniques; EDR and control bypass. On the measurement side, ATT&CK coverage assessments that identify which techniques a given estate genuinely detects, and translate that into a prioritised investment case rather than a list of findings.
Stack: C2 frameworks · Cobalt Strike-class tooling · custom loaders and evasion · Burp Suite · Kali · MITRE ATT&CK · Cyber Kill Chain · Diamond Model · OSCP / GXPN / AWAE background

Incident response & digital forensics

Overview: Leading high-severity response when it is actually happening: ransomware in progress, business email compromise, espionage. Containment decisions under time pressure, evidence handled so it survives scrutiny afterwards, and a timeline that answers what happened rather than what is plausible. This is also where my investigation training matters — a forensic timeline and an interview are the same discipline applied to different sources.
How I have applied it: Led high-severity incident response through ransomware, BEC and espionage cases; forensic investigation across platforms including reverse engineering and both static and behavioural malware analysis; built detailed behavioural timelines to support internal investigations, including the insider-threat case that moved me into security in the first place. Trained at the Justice Institute of British Columbia — the institution that delivers police recruit training for the province — in law-enforcement investigation and interviewing.
Stack: Velociraptor — an open-source endpoint visibility and DFIR platform that uses its own query language, VQL, to collect forensic artefacts and hunt across thousands of endpoints at once, rather than one machine at a time · Fleet / osquery — open-source fleet-wide device visibility, and the basis of my JuniFleet fork · CrowdStrike Falcon and Microsoft Defender for endpoint detection, containment and telemetry · Jupyter / JupyterLab — notebooks as the working surface for an investigation: timeline reconstruction, log and artefact analysis over pandas, and a reproducible record another analyst can re-run rather than take on trust · Autopsy · Sysmon · Windows Event Log · Sigma · YARA

AI-native engineering & model sovereignty

Overview: I build with frontier models daily and it has changed how much one engineer can ship — the four platforms on the Research page are the evidence. It has also clarified what the models do not supply: judgement about which decisions matter, and accountability, because a machine cannot take responsibility. Someone still has to vet the work and sign it. The strategic consequence is that organisations and countries should be able to build their own software and control the model that writes it, on their own infrastructure and over their own data.
How I have applied it: Frontier models — Claude and ChatGPT — used heavily in design, implementation and review across four production-grade platforms. Local models run through Ollama and Hugging Face for the cases where data cannot leave the environment, including a pluggable local-LLM drafting seam in JuniSoc that is disabled by default and makes no network calls. Currently studying for the Hack The Box offensive-AI certification, covering prompt injection, model privacy attacks, adversarial machine learning, and AI supply-chain risk.
Stack: Claude · ChatGPT · Ollama · Hugging Face · local inference on commodity hardware · retrieval over self-hosted data · Google Secure AI Framework concepts

Governance, risk & compliance

Overview: The half of security that decides whether technical findings become funded work. Risk treatment from finding to closure with named owners and real SLAs; posture, coverage and risk closure reported to senior leadership and governance forums in a narrative the business can act on. I came to this from the technical side, which I think is the right direction of travel — the risk register is more useful when the person writing it has run the test.
How I have applied it: Currently a manager in the governance and IT risk and compliance function of a Big Four firm, owning the remediation and risk-treatment lifecycle for BAS and red-team findings and reporting into governance forums. Long-standing ISACA member, working toward CISA and preparing for CRISC while gaining the direct experience those designations require.
Stack: NIST CSF · ISO/IEC 27001 · MITRE ATT&CK as a coverage framework · risk registers and treatment plans · SLA and KPI design · executive and board reporting

How I like to work

Approach

Evidence before assertion. If a control is claimed to work, there should be a test that demonstrates it, run on a schedule, with the result visible to whoever owns the risk.

Build the pipeline, embed the standard. Where a community standard exists — Sigma, ATT&CK, Parquet, Iceberg — use it, and spend the original engineering on the production machinery around it. That is a deliberate rule I apply to my own projects, and it is why they interoperate rather than lock in.

Be honest about limits. Every platform I have built ships with its non-goals written down. A system whose constraints are documented is one people can actually plan around.

Stay close to the implementation. I would rather lead technically than manage at a distance from the system — the decisions worth making are the ones you can still defend at the code and architecture level.

Contact

Happy to go deeper on any of these.

Get in touch Email: julien@infrayo.com