Review: Practical Cybersecurity Architecture
Adam Shostack's review of the book Practical Cybersecurity Architecture
There's an insightful comment, "Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in." Similarly, everybody has both enterprise and product architecture. Some people are lucky enough to be able to design them.
I have to say that because "architecture" is much maligned for being heavyweight, disconnected, and irrelevant in today's world of Dev-Opsy CI/CD moving fast and breaking things. But much like you can only allow things to be broken if you have detection, response, and recovery when things break, you can move faster by when you've thought about the security framework that allows you to do that.
And that brings me to the only book on security architecture that I've ever enjoyed, Practical Security Architecture by Diana Kelley and Ed Moyle.
The property I enjoy most about this book is a focus on what we might call a YAGNI approach to architecture, doing only what is needed to serve some customer need. They're agnostic to SABSA vs TOGAF vs Open Group, drawing on each where it's strong and helpful. Sometimes, I wish they'd make a call (for example, in the application security section, they talk about both NIST 800-160 and BSIMM). But in practice, what they deliver is a good guide to both and a reminder that you likely want to flip through each as a source.
Importantly, the book is short, readable and grounded, and I've learned a lot reading it. it's a good quick reference to make sure you're covering something reasonably. It's also thought provoking in a good way, even when I disagree with it.
And they have a really important bit which improves my thinking about risk management and threat modeling.
For an application, though, the likelihood dimension is exaggerated somewhat. A public-facing application such as the one in this example will likely always be available (or nearly so) to anyone from anywhere. This means that while likelihood is still important in the risk equation, most threats — over a long enough time horizon — have a high likelihood of being relevant... it is significantly easier to focus analysis efforts and mitigation/remediation planning on threats directly, rather than attempting to quantify or qualify likelihood, which, as we discussed, can be challenging to do.
If we can simply set likelihood to "1" then we just look at impact, and it turns out, that looks a lot like bug bars. Bonus, they're now more intellectually grounded. Also, you don't need to believe that all threats will come to pass, you can get the same effect with ".9," or in fact any constant.
Similarly, I learned a lot about scope, and how to use scoping as a tool, which influences my thinking about the threat modeling question of "what are we working on."
All in all, worth your time if what you do touches architecture, and more so if you had thought architecture a dirty word.
(Disclaimers: They interviewed me for the book, quote me, and they sent me a copy. They say nice things about my Threat Modeling book. Also, I'm lucky to count Diana and Ed as friends.)