Security as a systems property
My security work is primarily architectural: identifying trust boundaries, determining what evidence a system can actually rely on, designing controls that fail safely, and preventing implementation details from quietly weakening the intended security model.
Architectural Focus
Security Certification
Served as a security certifier responsible for evaluating cross-organizational architectural proposals. Focus included preventing systemic vulnerabilities before code was written, evaluating cloud readiness, and ensuring architectural alignment with enterprise security policy.
Threat Modeling
Structured analysis of complex distributed systems across several dimensions including identity spoofing, data protection, network trust, external dependencies, failure modes, and abuse cases.
Identity & PKI
Extensive experience handling cryptographic signatures, certificate issuance, X.509, domain validation (ACME), Decentralized Identifiers (DIDs), and managing key lifecycles mapped to cryptographic transparency logs.
Cloud & Sensitive Data
Evaluating cloud readiness and security review of highly sensitive data paths, ensuring correct encryption, memory handling, and data minimization in global distributed environments.
How I think about secure systems
1. Claims should not exceed guarantees
If an implementation cannot enforce a property, the specification should not claim it. Trust stems from provable guarantees, not optimistic assertions.
2. Authoritative state should never outrun evidence
Systems must not report success prematurely. In Agent Name Service, the "seal-before-success" invariant guarantees that a system never returns a success response unless cryptographic evidence is irreversibly persisted.
3. Fail closed at trust boundaries
An outage, parsing failure, or missing dependency must not silently result in weaker verification. Fallback mechanisms are often exploited by attackers forcing failures in primary validation paths to achieve a downgrade.
4. Compatibility is part of protocol design
Backward compatibility must be maintained without sacrificing security properties of newer implementations. Downgrade resistance must be explicitly engineered.
5. Security failures hide in composition
A control can be correct locally and still fail across a multi-step workflow. The evidence produced at the end of a process must faithfully carry the result that was actually verified at the trust boundary.