About 15 or 16 years ago, I was neck-deep in SOA, federated identity and defining my own framework of IEE1471:2000 views and viewpoints that I believed were the most relevant for enterprise (business) architecture, enterprise (technology) architecture and enterprise security architecture. Obviously, I was taking my first baby-steps with SABSA for the last one, but I’d already been left at the alter too many times by TOGAF and her ilk as far as the rest of it went, that I’d more-or-less given it two fingers at that point and worked on rolling my own.
Anyway, about this time, I was pretty dramatically exposed to the whole semantic technology (of which the Semantic Web is the proverbial red-headed step-child), and the warped wheels of my evil brain started to question all those fundamental “truths” of technology. Things like:
Why do we build applications the way we do?
Why do we basically keep re-inventing “new” solutions to the same problems every 30 years with degrading results?
And, the last one, relevant to this email: what if information didn’t “flow”?
I’ve actually done quite a bit of research, experimentation and software development around all these questions over the last 16 years, and some of it will hopefully be revealed soon (of course, you’re reading this, so you’ll be some of the first to know). So, it’s not quite as far-fetched as it might seem.
However, on a much more practical-and-relevant-for-today note, one of the first things we tell you to do as “security” is to map out all the “data” flows, which are really mostly more about the information concepts we’re throwing around the place than they are about the specific ways that information gets represented at each hop it takes. And we do this because this is one way of understanding how little control and classification you really have over the majority of the information processed by your organization every day.
Depressing as it may sound, hard truths still need to be heard.
So, we do our architectural models, we draw all the circles around the boxes to separate our security zones we’re trying to threat model, STRID(E)-ing right along…and then we get our big, 40oz bottle of Pat’s Blue Security, give it a shake, and then spay it all over our diagram…
…step well back, give ‘er a big ol’ belch, loop our thumbs through our “security nerd” suspenders, and wander off back yonder to sit on the porch, dig into some Kansas City BBQ, and listen to the crickets as we watch the sun slowly sink over the plains.
But that’s all the wanna-be security architects who don’t really realize there’s a bit more to it than placing the round controls in the round holes in the infrastructure and the square controls in the square ones.
You’re different, because you realize there’s a bit more to it than that.
On one of the live Q&A calls from the last cohort of the Building Effective Security Architectures program, the subject of information flows came up, because one of the scenarios you’re given for the homework is pretty similar to what you’d see in the real world. Based on the scenario, you’re asked to come up with some architecture elements based on what you already know and what you’ve learned with the material so far.
Anyway, the question came up about how you modeled information flows with the domain models of the Baseline Perspectives™, and I had a pretty easy, yet subtly nuanced answer:
You don’t.
Well, not in the traditional sense, anyway. Because it comes back to what I asked at the top. What if the information doesn’t “flow”?
So, let me expand on this a little bit. Yes, there are ways to transport information, transport protocols are the “carrier” or “packet” protocols that are fixed-purpose and allow the higher level transfer protocols to allow information to be transferred or shared from one “location” to another.
In the real world, If I want to give my phone to my wife (a transfer), I have to pick it up from where it is on my desk and move it to wherever her hand is so she doesn’t drop it. But, unlike the real world where I only have one phone, in the digital world, I’m always “transferring” by making copies, and once those copies are made, then they tend to start accumulating, like clones in some crazy, late-night session of Paranoia from the ‘80s and ‘90s.
That means, you basically have 2 choices: you can chase the clones (like all that money you’re paying for reputation management and content takedown), only to see new ones pop out of the woodwork as soon as you hit it with your disruptor ray…
…or you can focus on identifying and classifying that information and defining some rules about where, when and how it should be transferred around the place. Of course, associating that access control, classification and providence information with the information itself is a wee bit tricky since we’d basically have to break the Internet and all modern operating systems to do it.
Ah, well…something to think about.
Anyway, back to the point. The point is that no matter how many clones of that information you might have transferred around the place on the ever-eager backs of IP packets, that information – from a conceptual perspective – is hardly ever really transferred, as in ownership and accountability, to another party. And if it is, that requires some out-of-band legally-binding business agreements that are way above the pay grade of the lowly technology protocols.
Aaaaaannnnnddddd…the most important thing we need to know about that information is what it is, who owns it and who can consume it (our old friends Classified, Access-Controlled, and Governed). And, if we put information where it logically belongs (hah!), then all that schlepping bits around the place happens at lower levels that are going to do their own thing, no matter what, like mindless automatons…
…bits in…bits out…bits in…bits out…
That means we can, in fact, legitimately corral all our information into one box on our models from a security perspective so we can better understand what it is and what those rules should be—and how, who and what can actually take it out and play with it.
Now, maybe I lost you, and if I did, apologies for that. The program doesn’t get that deep—unless you ask a question like above and I think you’re ready for it.
But what it does do – and we spend a good bit of time on both the theory, the practice and the feedback of doing it – is that it makes sure you have the fundamental basis of understanding and core skills to be able to think differently about architecture and at least follow the majority of what I was talking about. And you can do all that because you have a practical understanding of how security domains and the SABSA governance model work together to help you make sometimes intractable problems actually make sense.
And, like I said yesterday, it’s all about doing it with just those 3 core concepts and by working with them using the 7 principles, 14 practices and 3 Baseline Perspectives of The Agile Security System™, predictably, reliably…
…and quickly.
If you think this might be something you want to be able to do, then you’re running out of time to decide whether you’re going to join the upcoming July cohort of Building Effective Security Architectures—and do it while you can still get the whopping $2,000 discount. Because after Sunday night, the 19th of April at 11:59pm US/Eastern, the price goes up, and there is a direct and measurable cost associated with procrastination.
However, my bit of a deep dive above – or hell, maybe my whole demeanor – might’ve put you off, and you think having your fingernails ripped out with pliers might be a much more preferable way to spend 7 weeks than as part of the BESA cohort, engaging, interacting and learning from your fellow security professionals.
Only you can make that call.
I’m running the course with all the people who’ve registered either way, and we’ve already registered the minimum number of people for a cohort, so I can’t guarantee there’s still going to be a slot if you decide to wait until later.
To join the cohort, you’ll need to visit this link before Sunday if you want the discount:
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
