Yesterday I had a brilliant (and, fortunately, public) reminder of how often the life of a security architect is effectively lost in a wasteland of “architecture” that people genuinely believe is a useful depiction of the state of the world—or an organization. This time, the example was provided on Twitter with a brief “IT architect game” challenge emitted with a tweet that included effectively the kind of PowerPoint/Visio “architecture” we’ve all seen before.
If we’re lucky, we don’t see it that often, but the reality – at least for a clear majority of people I talk to and customers we’ve worked with – is that this is about as much architecture as you’re ever likely to see when you’re asked the apparently simple question…
Is it secure?
Which, as you might’ve heard me say before, is clearly the wrong question. A much better question (and one we need to train our customers to ask) is:
How secure is it?
Now, in this case, the current state abstraction, as he called it, was a set of 19 icons with labels, no interconnection information directly supplied on the diagram, and it included a mix of “cloud”, virtual machines, applications, users and infrastructure.
To be fair, since this was a public game, it was apparently a pale imitation of the actual environment, but…unfortunately…I’ve seen diagrams that weren’t nearly this complete slapped on a PowerPoint slide and included as the solution architecture from the technology team where they expected a big rubber stamp with a green check mark…
…instead of “REJECTED 4F” in big red letters slapped all over the page.
I’m going to summarize things in this email, because I’m going to come back to this example in a couple other ways I’ll tell you about later. However, I think you have a picture clear enough in your mind of the type of thing I’m talking about.
One of the biggest problems we have as “proper” security architects is that we know a diagram like I describe just isn’t good enough. And, despite vehement beliefs to the contrary, it’s not architecture either. At best, it’s a context diagram model for the infrastructure solution components, and at worst, it’s a couple of lines, a cartoon brick wall, a cloud or 3 and some servers and networking icons sprinkled around the place.
In this case, what was represented was constrained to the Physical and Component layers of the SABSA model, and there really wasn’t much else. Yes, there was an icon for a physical network and an icon for a wireless one—along with the requisite “Internet cloud”. Basically, it doesn’t tell you much.
But here’s where I see 90% of security teams go wrong—just like played out in real time on Twitter yesterday. Using this diagram – and ONLY – this diagram…
…the armchair architects started tearing it apart as having a bunch of things missing that were required to make it “secure.”
Now, if you’ve gone through the SABSA training, read the book, read some of the old Archistry blog posts, and certainly, if you’ve read these emails very long, you’ll know that there’s no definitive definition of what “secure” actually means.
Unfortunately, people equate “secure” to some magical level of conformance with the CIS Common Controls…or some other framework…as well as some kind of “best practice”…um…”requirements”…they have in their head about the way the world should be.
Being the bearer of a bloody-big bucket of ice cold water, I have to tell you:
They ain’t requirements. They’re assumptions.
And they aren’t anything else.
Now maybe…just MAYBE…you’ve had a couple of conversations with people about what they’re trying to achieve, and maybe…maybe…that’s in the back of your mind when you’re looking at this kind of diagram…
…but that still don’t make it architecture, Jack.
Because architecture is the outcome of decisions you make – as the architect – about how to resolve the conflicts and constraints inherent in the entire CONTEXT of the problem you’re trying to solve.
It’s not a diagram.
It’s not your assumptions about what should be.
It’s not trying to build a solution by treating infrastructure components as lego bricks.
It’s a structured process of analysis, thinking and decision-making that’s neigh-on IMPOSSIBLE to do effectively based solely on a diagram like I mention.
…and yet, they did. They had a merry chase…building VLANs and specifying VM hosts…and routing tables and IP addresses….backup devices…protocols and ports…and additional security controls…
…before declaring the resulting target state a sight more “secure” than it was to start with.
Now, before you get all upset and tell me these things are necessary, I’m going to agree with you. Yes, they’re necessary—at some point.
But from an architecture perspective, they’re in the weeds, and they’re not the kinds of things you should be worried about when you’re evaluating the “secure-ness” of anything.
Unfortunately…the above ends up being a lot of what our world looks like.
Get a diagram…probably just before the solution goes live—if we’re lucky and it hasn’t already done so…
…have a chance to ask a few questions…
…compare a checklist of controls…
…add a few hygiene elements that are missing…
…and let it go.
Rinse. Repeat…
…and retch our guts out in the bathroom after the meeting because we know this just isn’t right…
The thing is…we might not really realize how simple the solution can be to fix it.
The solution actually isn’t The Agile Security System™, SABSA, TOGAF or anything else.
The solution is…you.
Because the tools you need are there. You just need to pick them up. You need to have the motivation and the will to use them—even when you’re not “allowed” to do architecture.
Because all the tools, frameworks, models, reference architectures, control libraries, Visio stencils and all that crap won’t help if you don’t first realize that the biggest enabler of architecture…
…is the decision that architecture – REAL security architecture – is important.
And that decision can only be made by you.
Not your boss…not your organization…not the ERM team…not…anybody else.
You.
When you make that decision, of course I can teach you how to use the tools I’ve developed over the last 14 years…tools that are based on…tools that quite literally stand on the shoulders of giants. In this case, it’s the work John, David and Andy did to publish SABSA and build the institute and create the certification program.
…but you don’t need to know SABSA…or be certified…to learn how to do this.
And you CERTAINLY don’t need those things in order to make the decision you need to make…
…the decision that you’ve had enough of dealing with these crappy diagrams that are actually WORSE than starting from a blank sheet of paper every time.
When you’ve made that decision…and if you want to learn the fastest, easiest and most effective way I know to create proper, business-driven security architecture that shouts the value it delivers at the top of its lungs loud enough to shatter the glass of the windows of the CEO’s office…
…then here’s the link you need: https://archistry.com/besa
But you’d better be quick. The registration for the program closes next Friday, the 21st, and that means you only have 9 short days to get things organized and join.
Is it cheap? No.
Is it going to solve all your architecture problems? No.
Is it going to give you a magic machine that’ll do the work for you? No.
But what it will do – if you show up, watch the videos, do the exercises, complete the peer reviews, attend the live Q&A sessions each week, and fully leverage the 24×7 Slack workspace and access to me reserved exclusively for members of the cohort – is give you everything you need to…
…build real architecture…
…build credibility with your peers and the rest of your organization…
…build practical, actionable skills you can immediately use to drastically change the way you work every day.
The decision is yours.
Here’s the link again if you’re ready to quit wandering in the architecture wasteland and listening to armchair architects tell you how you should be working and what you should be doing to keep your organization safe:
We’ll be there—with or without you.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
