Blog
Perspectives on security, compliance, and building resilient organisations from the Alvor team.
Latest Articles
AI teams inside ordinary companies now run HPC-class machines holding models and training data. Why the enterprise security stack misses them, and how the NIST SP 800-223 zone architecture applies.
What a System Security Plan is, what goes in one, who requires it (NIST 800-171 and CMMC, FedRAMP, FISMA, Australia's ISM and IRAP), how to write one, and why most SSPs are out of date the day they are signed.
How research computing centres meet NIST SP 800-171 and CMMC obligations for controlled unclassified information on shared clusters: the enclave pattern, scoping, and the SP 800-223 zones it builds on.
Ten enterprise controls, from EDR to change control, and what happens to each on a supercomputer: why it breaks, and the HPC-native control that replaces it, mapped to NIST SP 800-223 and SP 800-234.
How threat modelling gives APRA-regulated entities defensible evidence for CPS 234's design-time control obligations, and a process that fits alongside CPS 230.
How to threat model AI systems: STRIDE extended for LLM applications, the OWASP LLM Top 10 mapped to design-time decisions, and a worked RAG example.
A step-by-step threat modeling guide: scope the system, draw the data flow diagram, mark trust boundaries, enumerate threats with STRIDE, map controls, and decide.
STRIDE threat modeling explained: what each of the six categories means, eighteen concrete example threats, how to run STRIDE against a data flow diagram, and a template.
Eight tools for threat modeling and security design review, compared honestly by a vendor that competes with most of them: who each one is actually for, what changed after the ThreatModeler-IriusRisk deal, and how AI reshuffled the category.
What each of the CISA Secure by Design pledge's seven goals asks of an engineering organization, which practice owns it, and how to tell commitment from a logo.
STRIDE, PASTA, and LINDDUN answer different questions. A side-by-side comparison of what each finds, what it costs to run, and how to choose for your team.
A walkthrough of one representative afternoon: a whiteboard photo becomes an editable architecture diagram, a written design explanation, a STRIDE threat model with mapped controls, and a signed design record before the end of the day.
The workshop is the scaling bottleneck of threat modeling, not the analysis. How an async-first process covers more systems with less calendar: structured intake, diagrams from what exists, proposed threats, and one short conversation where judgment actually matters.
Why security decisions decay faster than the systems they govern, and how a six-heading ADR turns risk acceptances, exceptions, and design calls into precedent instead of folklore.
A 45-item security architecture review checklist across seven sections, from scope to named sign-offs, with the reasoning behind each section and a free printable version.
A practical guide to security design reviews: the six-step process, who needs to be in the room, what a finished review actually contains, and the anti-patterns that turn reviews into theater.
Most agent security guidance assumes a foundation you may never have finished building. This is the tier nobody wrote down.
AI now finds vulnerabilities faster than teams can verify, disclose, and patch them, and attackers hold the same tools. The monthly patch cycle has quietly stopped being enough. Here is what belongs on a 2026 vulnerability management roadmap.
Most guides tell you what a security program should look like. This one tells you how to actually build one - from your first risk register to your first audit - without a dedicated security team.
The 5x5 risk matrix is the most widely used tool in security risk management. It is also one of the least effective. Here is how to build a risk practice that actually drives decisions.
Your first SOC 2 audit does not have to be a three-month panic. A structured, low-drama route to a Type II report: scoping, the control framework, a realistic timeline, evidence, exceptions, and what changes after the report.
Security culture is not built through compliance training modules. It is built through systems, incentives, design reviews, and the small decisions that happen every day in engineering teams. Five mechanisms that work, and how to measure them.
Most third-party risk programs are a spreadsheet of questionnaires nobody reads after they are collected. How to build a tiered, continuously monitored program that genuinely reduces vendor risk, and what CPS 230 and DORA now expect of it.