Cyber Operations · Intelligence · Special Situations
When the normal process stops producing clarity.
Personally led technical operations and intelligence for executives, counsel, investors, and technical leaders when the problem is sensitive, adversarial, cross-disciplinary, or time-critical.
01 · Cyber Operations
Find the intrusion. Test the defenses. Restore confidence in the evidence.
Work can begin during an active incident, after another team has declared it contained, or before an adversary arrives. The mandate is defined by the operational question and the evidence required to answer it.
Authorized Red Team & Adversary Simulation
Objective-led testing of attack paths, identity, cloud, endpoints, controls, and detection under written rules of engagement.
Incident Response & DFIR
Forensic acquisition, timeline reconstruction, endpoint and identity analysis, breach scoping, malware triage, persistence analysis, containment, and recovery.
Threat Hunting, Cloud & Identity
Hypothesis-driven hunting across authentication, control planes, workloads, endpoints, and telemetry when alerts are insufficient or the scope is uncertain.
Exposure & Attack-Surface Assessment
What an external adversary can discover, reach, exploit, or combine, and which paths materially change the outcome.
Offensive work begins only after written authorization, verified scope, and agreed rules of engagement.
02 · Intelligence & Investigations
Collect lawfully. Corroborate aggressively. Separate what is known from what is inferred.
Open-source intelligence is useful only when collection is documented, sources are cross-checked, confidence is explicit, and the result changes a decision. The work is scoped to cyber, corporate, transaction, vendor, threat, and technical matters.
Open-Source Intelligence (OSINT)
Source-documented public research that maps organizations, infrastructure, ownership, relationships, claims, and material gaps.
Digital Footprint & Exposure Mapping
Domains, cloud assets, repositories, public documents, exposed services, identities, and other observable signals assembled into a defensible picture.
Threat Intelligence & Attribution Support
Infrastructure, behavior, tooling, timing, and campaign links evaluated with explicit alternatives and confidence, without manufacturing certainty.
Technical Dispute & Litigation Support
Public-source evidence, technical timelines, claim testing, and expert analysis that counsel can challenge before relying on it.
Purpose, authorization, jurisdiction, and licensure are reviewed before collection begins. Public and lawfully available sources only. No pretexting, unauthorized access, covert surveillance, or services requiring a private investigator license.
03 · Private AI & Infrastructure
Private AI that is actually private, operable, and useful.
Architecture through validation: hardware, models, inference, RAG, integration, isolation, hardening, and evidence that the deployed system behaves the way the design claims.
Local & Air-Gapped Deployment
Models and inference on customer-controlled hardware for sensitive, disconnected, or sovereignty-constrained workloads.
Private RAG & Integrations
Retrieval, document flows, enterprise integrations, identity, access, and operating boundaries designed around the real workload.
Isolation, Hardening & Exposure Testing
Data paths, model endpoints, admin surfaces, plugins, telemetry, supply chain, secrets, and failure modes tested against the intended custody model.
Architecture & Hardware Validation
Right-size compute, storage, networking, resilience, model choice, and operating cost before capital is committed.
04 · Incident Closure Review
The incident is contained. That is not the same as closed.
Typically $20,000–$30,000+ depending on scope · scoped after intake
Before the board accepts closure, before regulators or customers are told, and before the insurance narrative hardens, an independent review tests whether the evidence supports contained, eradicated, and closed.
I examine the investigation record, containment and eradication evidence, scoping decisions, and what was not looked at. The written conclusion states whether closure holds, holds only with named conditions, or does not hold and what remains open.
05 · Other Special Situations
Problems that fit no service catalog.
Two credible teams with technically conflicting explanations for the same failure.
A vendor dispute where the technical facts decide the commercial outcome.
Evidence that must be acquired or reconstructed before anyone can say what happened.
A threat, actor, company, or exposed system that must be mapped across cyber and public-source evidence.
A technical question in litigation that needs an answer able to withstand challenge.
A failed implementation, a disputed remediation plan, and a large invoice that depends on the explanation.
A consequential technical claim nobody independent has tested.
06 · The Stance
What the evidence supports, what it does not, and what to do next.
I do not advocate for a predetermined technical conclusion. Fact is separated from inference, assumptions from evidence, and material unknowns from noise. Alternative explanations are tested rather than edited out.
Depending on the mandate, the output may include an evidence record, attack-path findings, an incident timeline, intelligence assessment, remediation priorities, a technical architecture, or a signed executive conclusion.
Where the evidence is insufficient, that is the finding, together with what it would take to know.
Scoped after intake · expedited timelines available