Want Better Security?

Dear Security Architect,

My name is Andrew Townley, and I’ve been implementing SABSA® as a basis for security and enterprise architecture since 2005. During that time, one of the startling discoveries I made was that, in fact, there are two types of “security architect” out there. And if you’re anything at all like me…where you understand that security is about more than just technology…

…where you deeply believe that the only way you can be truly effective in your role to enable and protect your organization, is to understand where it’s going and the true risks it faces in getting there…

…where you recognize the value of creating reusable, easy to explain artifacts that control the hydra of the inherent technical complexity of our day-to-day worlds. The beast just waiting for that moment of crisis to snap it’s snake-like jaws and spit chaos across the fevered security response teams battling on front-lines of the issue…

…where you have the foresight to realize there is no possible way you can be successful as a modern security architect without a set of essential communication and interpersonal skills. The same skills allowing you to speak just as easily to the Board and Senior Leadership team – with their decades of business acumen and experience – as you can to all levels of the technical project implementation teams who probably share your own background and skills…

…then, without a doubt:

You are the 1% of security professionals who claim the title of “architect” for the work they’re paid to do.

After all, we do work in an industry that will nearly get into knock-down, drag-out fistfights arguing the nuances and the distinctions between “information security” and “cybersecurity” while the rest of the world stares at us, open-mouthed, wondering, “What the hell is the big deal—isn’t it all the same?”

It’s no wonder when you start talking about an abstract concept like “architecture” that things get all “wibbly-wobbly” in peoples’ heads—especially those outside of security or without a technical background.

The concept of where architecture starts, stops and who owns it has been a struggle to properly identify even within the technology community for years. I mean, have you asked any two enterprise architects to define what they do lately? The ensuing arguments may sound eerily familiar as they ring in your ears—before you get bored and tune out.

At least you’ll have the satisfaction of recognizing it’s not just you faced with this kind of problem.

So why should we think that it’ll be any easier for the security community to sort itself out, just because we’re suddenly thrust into the limelight by weekly – and sometimes daily – news reports of high-profile security incidents and data breaches?

Which brings me to the OTHER “security architect” out there—the one who doesn’t see the world in the way we do. These are the security architects that make a distinction between the “enterprise security architect” and the “cybersecurity architect” or the “infrastructure security architect” and the “IT security architect” because they have a firmly established comfort zone and scope of work they would like to do, and who don’t really have any interest in developing the awareness I described above.

That same awareness which I believe you and I share.

The unfortunate reality of the world…our industry…and the perceptions of the people in the organization’s we try to protect is: we’re hopelessly outnumbered. And, as a result of this sad fact, this bias and limited, technology-focused view of security architecture may even extend into the minds of those leading the security programs we support.

The vast majority of the people we will encounter in our professional careers will think security starts and stops at the Internet, networks and viruses. And that same majority doesn’t really have any interest whatsoever in recognizing that risk is inherent in every action they take – every day – in delivering their individual contribution to the organization. And they would likely prefer to be unaware and unconcerned that the electronic computing devices on which they increasingly depend to make that contribution…

…are a vital part of the overall potential risk that the organization will fail to deliver its products and services to the customer…

…or the risk that key strategic initiatives will deliver less than the expected results…

…or the risk that members of the Finance team will watch piles and piles of otherwise untouchable cash pour out of liquid investments to pay the salaries and operating expenses any unexpected shortfalls in revenue and earnings would require.

In fact, the root of so many of the daily issues we face come back to an observation from around 400 BCE made by none other than Siddhartha Gautama—the Buddha himself:

"All human unhappiness comes from not facing reality squarely, exactly as it is."

When we, as “enlightened” security architects attempt to expound on the virtues of a true enterprise security architecture program that can enable, uplift and protect every single business initiative the organization may ever want to do…

…we often fall into a common trap. And that trap is that we’re more concerned about what we want…

…than we are about the reality of our environment and its impact on what matters to the people to whom we’re trying to “sell” our plans for security architecture.

And what often happens when we try to make our case?

Someone says, “Don’t talk to me about architecture. I just want to pass the next audit.”

Or someone says, “We don’t have time to invest in some heavy, formalized architecture process. Can’t you see we have code we need to deploy?”

Or someone says, “It sounds nice, but it also sounds like you’re trying to get out of doing real, practical security work.”

Or someone says, “We already have a team for that—and it’s not part of security.”

I’m sure there are others that you’ve heard more recently in your own work. But whatever the case, the response is often, essentially, a “no thanks.”

After again failing to successfully make our case, we trudge back to our desk, pound our heads in frustration on whatever happens to be available…

…and we feel just that little bit more of our enthusiasm, drive and zeal softly dim into the dull, grey swirl of the next security request to pop up in our inbox.

As depressing and soul-destroying as the above may sound, the secret I have discovered – along with everyone from James T. Kirk to Steve jobs...from the lasagna-loving cat Garfield to Elon Musk– is that:

If you want to truly win, you need to change the rules of the game you're trying to play.

That’s right. We’re going to change the rules for not only the way the game of security architecture is played. We’re going to change the rules for the game of security itself and the way it’s played in the majority of the organizations across the planet.

Remember, if we’re on the same page so far, it means you’re part of the 1%, so by definition, it also means that the odds are stacked heavily against us right out of the gate.

At this point, you might be asking me: “Andrew, what does this have to do with security architecture?”

My answer is that it’s basically everything to do with security architecture. Because the ability to build “the architecture part” of a successful security architecture program is really a straightforward set of skills you can easily learn. It’s a set of techniques, models and relationships that are reasonably easy to apply and create.

What’s DIFFICULT is actually getting the opportunity to build those security architectures in the first place. Because in order to build them…

…you need to be able to collect the information you need. And in order to get the information you need…

…you need to be able to speak with the right people. And in order to be able to speak with the right people…

…you need to be able to understand their world and what’s important to them. And in order to be able to understand their world and what’s important to them…

…you need to develop a whole host of skills and knowledge that the AVERAGE “security architect” has never even heard of—let alone would think had anything to do with building architecture.

When I realized all of this. When I finally understood what the real barriers were to doing the work I knew needed to be done, because I believed that taking a control-based or threat-based approach to security…

…wouldn’t do anything—other than burn out my body and my brain trying to keep up chasing an ever-growing tsunami of control frameworks, libraries, vulnerabilities, automated exploits and the inevitable evolution of the technology becoming more deeply embedded in our daily lives…

I decided I’d had enough. There had to be a better way.

And I found that better way in the SABSA methodology and framework, originally developed and refined by John Sherwood, David Lynas and Andy Clark, into the independent, globally adopted and comprehensive approach maintained by the SABSA Institute today. I met the authors, was personally mentored by them, and eventually used that knowledge and experience to teach over 200 people the official SABSA Foundation training. And I worked tirelessly to integrate it into my own architecture work, on behalf of myself and my customers.

But the answer, while correct…was still too hard. It was still too big. It was still too easily misunderstood. And that meant:

It was still too hard to get the buy-in and support necessary to build business-driven security architectures—even using a proven and globally adopted methodology.

A methodology that the vast majority of people we’ll meet will have never heard of—and which, even if they have, will probably have gotten the wrong message about what it is, where it came from and what it really takes to make it work.

And that’s when I knew I needed to find a way…that "better way” I mentioned before…to deliver all of the value and promise of SABSA…

…with a lot less effort…

…and with a lot less formality…

…and in a lot less time.

Finally, after 14 years of development, practice and implementation, the result is something I call The Agile Security System™. This reliable, repeatable and robust system for delivering business-driven and risk-proportional SABSA security architectures has been battle-tested in organizations around the world as part of Archistry’s customer engagements.

The Agile Security System includes basically everything I’ve learned about delivering robust security architectures that stick…that are actually used across the security teams who build them…and which are the glue that keeps security strategy and security operations connected and aligned. And until not that long ago, it was only something you could learn, directly from me, as part of Archistry’s long-term consulting and security transformation program engagements requiring a minimum investment of at least $350,000, and often lasting a year or more.

However, since July of 2019, I’ve formalized everything I do into an accessible set of 7 principles, 14 practices and 3 Baseline Perspectives™. Together, these are the 3 major components that ensure that real, business-driven security architectures can be developed, maintained and used as the basis of security activities…

…at ANY level…

…and at ANY time…

…security input is required.

That means that you can use the system to establish security architectures across all 6 layers of the SABSA Architecture Framework at the enterprise, program, project, change…and even on the back of a pizza napkin while huddled around an incident-response conference call.

And it also doesn’t matter if your organization is using a traditional, waterfall-esque SDLC, Agile or DevOps project delivery approach—or anything in between. In every case I’ve seen, across dozens of organizations and within a myriad of different verticals – from Banking to Energy to Internet to Manufacturing – the principles and practices will still apply. And because it’s a system…it’s a system for consistently building security architecture to make sure you don’t get lost…

…that you’re not distracted by operational demands on your time…

…that you’re not lost in the world of technology and security controls…

…that you’re not wasting your time building models and writing documentation you know nobody will every actually read…

That means it’s also a system that keeps you safe.

If you follow the system…if you’re guided by the principles…if you apply the practices…if you visualize your organization using the Baseline Perspectives…then it’s almost impossible for you to fail to deliver security architectures that provide the essential foundation for an effective security program…

…that clearly, traceably shows how you, as security, are enabling and protecting your organization—and without any question as to the value you provide for the budget you have.

And if you can do that…

If you can do that, then it means that you’re well on your way to building the credibility and trust required to deeply embed a risk-based mindset, to “shift security left” and to say farewell forever to the perception of security as the Department of NO within the organization you’re trying to keep safe.

If you’re ready to shift the way you think about doing security architecture…to stop being frustrated by the lack of progress or the lack of recognization of the security team by the rest of the organization…

…then maybe this is the right system that can make all the difference and unlock the potential for you to…

Grow Your Experience, Advance Your Career And Become A Better, More-Respected Security Architect

Right now, we’re getting ready to run another cohort of students through our flagship, 7 week Building Effective Security Architectures (BESA) online education experience. If you think it might be the right fit for you, here’s some of what you’ll find once you’ve enrolled:

Build Actionable, Business-Driven Security Architectures WITHOUT Understanding SABSA to The Nth Degree!

And, ultimately, that's been the primary driver behind the creation of The Agile Security System from the very beginning.

• A sure way to recognize your security program is going nowhere (and the one simple fix that will completely turn things around).
• The single most violated principle of The Agile Security System that can reduce our effectiveness in building security architectures by up to 80%! (But remembering to do just one thing will make all the difference in the world.)
• A perpetually vexing question for even the most experienced security architects (including a detailed description of the implications – both for…and against – the choice you will regularly face).
• The 8 most fundamental decisions you will need to make about your security program that will have the biggest impact on your ability to protect and enable your organization (not to mention having a huge impact on your overall attitude towards the work you do every day).
• The “lucky" seven elements that form the foundation of effective security architectures (and the exact questions you’ll ask to reliably and repeatably transform these into the architecture models you’ll later permanently brand in the brains of the delivery teams you support).
• One-and-only proven-effective way to make sure you ALWAYS get the answers you need to build truly effective security solutions. (It’s no coincidence that it’s also the fastest way to gain the credibility and trust of the business you know you need to have.)
• A simple “laundry list” of things you must remember to do – every time – when you’re  speaking to ANY security customer (with specific references to the elements that are built into the system to ensure you don’t forget)
• The vital importance of being able to instantly recognize and classify the very words you read every day in building effective security architectures.
• Exactly what to do – and how to do it – so that you don’t leave an interview with a stakeholder without learning one damn thing. (It’s a trap even experienced architects and analysts fall into far too often, but once you know what to do, it could literally change your whole life!)
• A simple, 3-second “trick” which 100% eliminates getting totally lost in architectural requirements gathering (and boring the shite out of the stakeholders we’re trying to impress).
• Why chasing the rainbow of MECE when interviewing stakeholders can be the fastest way to kill your credibility.

Now, if you’re a consultant (or were a consultant in a previous life), you’ve probably run across the term MECE (actually pronounced as if it rhymes with Reese). And it’s something that was originally defined by McKinsey, and which has been picked up as an an analysis tool in many other contexts. What it means is Mutually Exclusive and Collectively Exhaustive, and it’s a way of organizing information along those terms so that you have buckets that don't overlap, and you’ve fully identified the problem space of whatever it is you’re trying to solve. Unfortunately…the issue is that, at least in the early stages of stakeholder interviewing and requirements analysis…

You Might Have No Idea What The Real Problem Is You're Trying To Solve

And that’s a bad thing, because, just like getting ahead of yourself in other situations, prematurely playing the MECE card is one of the things that could get you tossed out of an office with a sore backside quicker than you can say it.

• The “rookie” mistake even seasoned architects make that is behind the real reason security is seen as The Department of No (and why nobody wants to talk to you because they think you’re going to stop their projects—even before they ask you for anything).
• Why “NO” is actually the BEST answer you can get from you security customers (and some simple ways you can make sure you get it).
• The correct way to prevent the WORST possible answer to a question you ask a business stakeholder (and the techniques you can use if you inadvertently get this answer—despite your best efforts to prevent it).
• How to avoid the biggest source of confusion when trying to build SABSA’s Contextual Architecture. (It’s not just you…it’s part of the way things work, so what you need to understand is why you’re probably getting confused and exactly what to  do about it if you are.)
• The things you learned in grammar school (and probably forgot long ago) that will make a critical difference to the quality of the security architectures you will develop.
• The ugly little secret behind why people say things they don’t always mean (and a killer technique that can make sure you’re not going to be sitting in front of the TV when you thought you’d be “dancin’ the night away” with the girl (or guy) of your dreams).
• The fastest known way to identify what your real security requirements will be (for example, from just a first-pass read of any project charter).
• How to build a picture of our organization so rich and vivid, our customers will think they’re wearing 3D, augmented reality glasses!
• The surprising psychological links between what we need to do to build high-quality, business-aligned security architectures and simple things we do every day (like brushing our teeth and wiping our backside).
• The simple technique to make sure we never end up on the arse-end of any assumption we’re going to need to make as a security architect.
• The single, “oh my God” obvious way to make sure your architecture models don’t end up gathering dust in the corner (or being used to potty train your boss’s new puppy!)
• Two different ways of understanding what’s really important to your security customers (and why it doesn’t matter one bit which one you ultimately choose).
• How architecture layers – one of our most useful tools – can become deadly, horizontal silos that drown our creativity and effectiveness as security architects.
• Exploding the myth that you need sophisticated tooling to build sophisticated security architectures. (In fact, you’ll want to actually ELIMINATE some of your architecture development tools as quickly as possible.)
• Why it’s so important to clearly differentiate an “enemy” from an “adversary” when it comes to building security architectures.
• A quickie, “idiot’s guide” to how to conduct a stakeholder interview (so they actually WANT to talk to you, and so you’ll also have the best chance of them answering your emails).
• An “almost magic” way to isolate the architecture of a project, service or solution so that it AUTOMATICALLY aligns and complies with the established enterprise security policies (without tons of extra work, and with complete support for either more relaxed or more restrictive security requirements).
• The correct way to build a useful architecture model of any organization on the planet that you might ever encounter (that’s based on 30+ years of proven industry practice and analysis)
• Why the ultimate success and effectiveness of your security program will live and die by these key decisions (including the most common reasons we often make the wrong choices, destroying our credibility in the process)
• Your 7 most critical security customers (and exactly what you need to know to get them to invite you to meetings).
• The “big lie” of what it takes to build an enterprise security architecture. (You’ll personally lay this bare as you have the opportunity to create a real, enterprise security architecture in just 2 hours!)

This Is NOT Your Typical Online Training Course

We both know that online training is a hit-and-miss sort of thing. In fact, I’ve personally spent a many thousands of dollars on online training courses myself. And the worst part is, some of them, I haven’t even ever started—or, if I did, I might’ve gone through a few of the modules, gotten sidetracked, or had some kind of crisis, and never made it back to them—despite all the best intentions in the world (and, I’m sure that I will complete them at some stage…but when? Who knows.)

And at the other extreme was one online courses in particular that was supposed to take 8 weeks, but that I managed to finish in just two weeks of dedicated, highly-focused effort.

What was the difference?

Well, while they were both “go at your own pace” courses where I could Netflix binge if I wanted to, the primary difference for me between the ones I devour and the ones that are collecting virtual dust in my bookmark collection is that I had an immediate problem in that area to solve. They were critical, key skills that I needed yesterday, and so, when presented with the means to solve the problem I was facing, I did everything I possibly could to solve it—as fast as I could.

However…

This is only part of the story – and I’m sure, if you’ve ever done online training, you have a similar tale to tell – because the one thing missing was…

Feedback.

While I'd ripped through all the materials, I still wasn’t quite sure I was really “getting it.” I mean, hey, I thought I was…

…but I couldn't validate it.

And, in fact, in the one that I got the most value from, there wasn’t even any way to ask questions about the materials at all—or get any kind of guidance about where I was close, but where I just needed a minor push in a slightly different direction to make all the pieces fall in place.

You might be thinking to yourself:

“Yeah, that’s EXACTLY why I hate online training courses!”

So maybe you’re also the type of person who prefers a more direct, instructor-led experience where you can ask questions in person, and you can practice your new skills as part of workshops and exercises presented in a live training environment.

And, as someone who taught over 200 people the official SABSA Foundation certification course for 5 years, I do know what you mean. That connection you can make with the instructor…the way you can ask relevant questions about problems you’re facing right now, back at the office, that are related to the course materials…the way you can engage and build professional relationships and expand your network with the fellow participants in the course.

Yep. All those are extremely valuable side benefits you get from a live environment—in addition to whatever value you get out of the materials and what skills you manage to practice.

From my experience, however – and this is validated nearly every day in the conversations I've had with people who have done live training on complex topics – there's still a problem.

The problem with live training is that…

…it feels like you’re drinking from the firehose.

There’s often nearly 8 hours of training – over 3 to 5 days – and, by necessity, it’s a self-inflicted “death by powerpoint” kind of affair.

And the slides…yeah. Many times, there’s so much information crammed onto the slides that it seems like you’re basically reading a book instead of getting a training course. Even though you have notes, it’s still hard to keep up.

Then there’s the workshops and exercises. If you’re lucky, you’re with a good group, or at least the instructor can move you around between groups if things go awry. If you’re not, you’re stuck with the same 3-5 people for the week, and either it gels perfectly, or there’s ample representation of the extremes of the people who:

1. Think they know everything, and
2. The people who just refuse to participate and engage.

So, some of the potential value you get out of a live training is actually going to get lost in the shuffle. Because if you, personally, don't get to practice the skills and techniques you’re trying to learn, you’re going to struggle to remember exactly how to do it once you’re back at your desk…and you’re not going to get the validation and feedback on your own practice that you’d expect from a live training environment.

Getting The Best of Both Worlds

Maybe I’m the only one who instantly hears some classic Van Halen when I read the above heading, but it’s really what we’re after here. What if…you could combine the two, so that you get the advantages of the live workshop and the good things about online training all in one package?

One of my favorite stories in the book, The Blue Ocean Strategy, is about the genesis of Cirque du Soleil. It's a classic example of innovation in an industry by challenging the assumptions about what makes the industry special.

In case you aren’t familiar with the story, the short version is that the founders of Cirque du Soleil wanted to have a circus, but when you look at the biggest – and most unpredictable – cost of the typical circus, what you find is: it’s the animals. The feeding them…the cleaning up after them…the carting them around the place.

It just all adds up—and pretty quickly too.

So they eventually looked at the numbers and said, what if we could have a circus without the animals? What would that look like?

And eventually, you end up with a worldwide phenomenon that’s a household name (even if a lot of people can’t spell it).

So, that’s exactly what we’ve done with the structure and format of our flagship Building Effective Security Architectures learning experience. We’ve tried to get rid of all the bad stuff, and make sure we were able to bring together the best from online training and the in-person workshop so that you would have the greatest possible opportunity to internalize the skills you want to develop in a way that enabled you to put them into practice as quickly as possible.

Now, I can’t take credit for innovating this delivery model. I first experienced it myself going through a couple of training courses run this way by my friend Danny Iny. This is actually a good thing for a couple of reasons. First, it means that I didn’t just make it up out of the blue. It's been developed by one of the leaders in independent, online education, and someone who was an invited speaker at Google to talk about the future of learning – both online and in the real world – based on his thoroughly-researched book, Leveraged Learning.

The second reason is: it works. It's a model that's been proven to work across a number of different industries, and it’s backed by hard-core behavioral science and psychology research on the way people learn best.

My goal with adopting this format for our flagship program is actually pretty simple. I want you to:

• Be able to practice the techniques you’ll learn in the program on an individual basis so you can make sure you don’t get pushed out by the loudest voice at the flipchart.
• Have the freedom to plan the way you will complete the coursework within the overall skeleton of the program schedule so that you’re not overwhelmed by information overload.
• Get direct feedback on your own understanding and applications of the skills and material you will learn in the program so that you’re not left wondering if you really "get it.”
• Have an opportunity to get immediate, live answers to questions you care about from both myself and the members of the cohort so you can solve your problems, complete your assignments and deepen your understanding.
• Engage directly with me on a 1 to 1 basis so that you can get my perspective on either the work you’ve done or how to apply these techniques to what you do every day to maximize the value you get from the course.
• Develop your professional network by having the opportunity to make individual, personal connections with other security professionals around the world who are experiencing the exact same things at the exact same time as you are so that you expand your safety net and source of ideas about how you do your job.

So, in putting together this program, I’ve not only made every effort to give you the highest quality and most practical material on building security architectures to enable the security programs of your organization, I’ve also worked hard to make sure that you have a learning environment that’s specifically designed to give you the best chance possible to really understand, internalize and be able to apply the material—almost from the moment you first encounter it…

…not days later when your brain is full and you can hardly remember what we talked about at the beginning.

And finally, the format of the program means that your support network continues far beyond the completion of the core content. You will have access to the materials and the members of the cohort FOR LIFE (or, at least as close to it as I can possibly control).

That also means that you get immediate access to any future updates and enhancements to the program or the materials as we continue to evolve our practice and learn from you, the individual members of the cohort.

So now, let's take a few minutes to talk about the…

Program Content And Delivery Model.

The program consists of 4 modules that are delivered over 7 weeks. The first module is special and is completed in half the time of the other 3, because its purpose is to establish a foundation on which the main program content will build.

During the first week, you will also be given a Level Setting exercise that asks you to complete a security architecture task based on what you know right now and using whatever techniques you prefer. Then, the week after the last module has been completed, you will be asked to complete a second Level Setting exercise so you can compare your efforts and be able to judge for yourself what you were able to get from the program.

Here’s a brief overview of each of the program modules and what will happen each week so you can see how this hybrid approach works in practice, and you can get a feel for what the experience will be like once you choose to enroll.

Foundations (1 week)

In this module, you’ll be introduced to the 7 core principles, the 14 practices and the 3 Baseline Perspectives™ of The Agile Security System. In addition, you’ll also be given a whirlwind tour of the SABSA® methodology, which is the common foundation for everything Archistry does.

Once you've been given the overview, you’ll get your first Level Setting exercise, which must be completed prior to the start of Module 1.

Additionally, before the start of the Foundations module, you will be given access to the learning environment and an invitation to a dedicated Slack workspace where you can interact with the cohort – including me – for the duration of the program—and beyond.

Module 1 – Back to School (2 weeks)

In this module, we will begin to see how the principles and practices of the system start to fit together and guide our thinking and approach to the task of building architectures. We talk about how the 3 Baseline Perspectives are used to give you an understanding of the organizations we’re trying to protect and how they’re used to facilitate the communication of what we need to do – and what we are doing – as security to support and enable our security customers to achieve their objectives.

A key element of this module is a deep dive on SABSA’s domain concept, because the domain is something we will use quite extensively as part of applying the system and structuring the work we need to do. In particular, we cover some extensions to SABSA’s core domain concepts that Archistry has developed through the course of our own architecture work assisting our customers with their SABSA adoption efforts.

The module content is divided into two primary sections. The first part will deliver a set of core content and a set of practice exercises on that core material. These practice exercises will be completed during the week, and they will be sent out for a peer review by other members of the cohort over the weekend. This means that you get direct feedback from your peers, and you can also get different perspectives and alternative approaches to solving the problem that you may not have considered.

Following the peer reviews each week, we will gather everyone together for a live Q&A call conducted via Zoom, complete with video if you wish, that will also be recorded and become part of the unique content of your individual cohort experience with the course.

The second week will give you some additional content that builds on the first week of the module and a more “real world” module assignment that you will need to complete before the weekend. As before, peer reviews will be conducted of the module assignment – generally by different members of the cohort than reviewed your practice exercises – so that you again can get immediate, direct feedback and suggestions from the rest of the cohort members to further cement and solidify your understanding of the module materials.

The last event in each module is a live, wrap-up Q&A call where you have the opportunity to ask me anything about the content or the materials so far. In the past, sometimes this may be a walkthrough of a specific solution, or a live “over the shoulder” session of me working on part of a similar problem of the module. But the purpose of the call is really to make sure that you have a clear handle on the content we’ve already covered so you’re ready to move forward.

Module 2 – A Brief Business Primer (2 weeks)

In this module, we’re going to cover the fundamental concepts of business. Why? Because, based on my own experience working with security architects over the years, the lack of basic business knowledge is one of the biggest reasons security professionals have a hard time not only with engaging with the business in the first place, but it’s also the primary reason behind our struggles to express what we do “in business terms” so that we are better able to get what we want—including budget, staff and shiny new technology controls.

So that’s what we’re going to do. We’ll look at core concepts like profitability, business and operating models and some important thinking from HBR, Bain & Co. and even “real” enterprise architecture to help you better understand how to position and prioritize the capabilities your security architecture provides the business.

Like Module 1, the format and structure are the same. There’s 2 live Q&A calls, and there’s a set of practice exercises, a module assignment and 2 sets of peer reviews over the weekends.

Module 3 – Building Architectures (2 weeks)

In this module, we’re going to apply everything we’ve done so far in the program and focus on understanding the fundamentals of architecture, how it relates to strategy and governance, and walk through an extended case study that demonstrates the step-by-step approach to solving problems with The Agile Security System—and, not surprisingly, building SABSA security architectures at the same time.

This module is the longest, and most intense module of the course, because it's where everything comes together. It shows you how to integrate the system into common Agile and DevOps delivery, and how to deal with the problems of synchronizing security control capabilities with the requirements of supporting hundreds of daily deployments with the right security solutions. Not to mention how to tear apart a security policy, a control framework like the NIST CSF or an annual report to extract a useful and functional security architecture hidden inside.

Following the second live Q&A call of the module and the conclusion of the core content, you will be given your second Level Setting exercise, along with all of the key worksheets, templates and supporting documentation of The Agile Security System so you can apply whatever aspects you feel relevant.

Note that while this second Level Setting exercise can be completed in a couple of hours, you will have the entire week following Module 3 to complete the exercise, and, because there’s no right answer, you are free to engage with myself and the rest of the cohort on Slack if you have any questions or problems along the way.

Why You Shouldn’t Take This Program

Right now you might be thinking to yourself, “Hey, this sounds like it might be interesting.” Or you might even be saying, “Wow! This sounds fantastic! Where’s the Enroll Button?” Or you might be stuck in the middle of the road, trying to figure out if this is the right use of 7 weeks of your time and a chunk of your cold, hard cash.

Regardless of what you’re thinking, I want to make sure you have a crystal-clear picture of what you might be considering getting yourself into. There’s a saying that goes, “Africa’s not for sissies,” and the same may well be said about this program. It’s certainly not for everyone, and here’s just a few reasons why…

It’s a lot of work.

It’s 5-10 hours a week, and if you’re trying to moonlight this program in addition to a full-on, hectic work schedule without any support from your management, then I can tell you from the experience of past cohort members, “it will almost break you.”

So if you feel there will be an issue allocating the time required, then I’d urge you, hand-on-heart, to sit this one out. I don’t want you to struggle, and I certainly don’t want you to be overwhelmed by the additional intensity and deadlines of this program on top of all the other commitments you’ve already made. It’s not good for you, and, ultimately, it’s not good for me either, because I won’t be able to deliver what I’ve promised if you’re not able to do the work.

It’s not official SABSA Training. 

We’re only going to cover a specific sub-set of SABSA, and, actually, you might learn things here that you’ll have  to “unlearn” if you want to successfully pass the SABSA Foundation Certification exam. I don’t know, because I haven’t taught it since 2016, and I also don’t know what the test questions are. But if you're looking for a way to give you some kind of official SABSA certification, then this program most emphatically is not for you. To get that, you should go to the SABSA Institute website and find an official course near you.

You may balk at the amount of “non-security” content and time spent.

If you’re looking for a solely-technical, jargon-filled security architecture development course, then this isn’t for you either. This is not a technical program, and, for the most part, it's about “the other skills” you need to have as an architect beyond the basics of modeling, memorizing control libraries and remembering security solution blueprints on demand.

Sure, there’s some “technical” theory, both about architecture and SABSA, but there’s also 12 lessons in Module 2 that have absolutely nothing to do with “architecture” per se, and instead give you a crash-course on understanding what’s happening in the minds of our most important security customers.

Weekend work might be an issue for you—especially if you have a family.

This program potentially is a 1x7x49 investment of your time and energy. There are required activities to be done over each weekend for the 7 weeks of the program, and that also includes being able to allocate 5-10 hours out of each working week too. Some people don’t have the flexibility to do this. And that's totally OK. I have a young family too, and weekends are…hard.

However, if you want to improve your security architecture chops, it isn’t going to happen by magic. It takes work. Lots  of work. And, just like our print Security Sanity™ newsletter, this program isn’t for tire-kickers (there's no guarantee, and no refunds). It’s for people who are ready to take their careers to the next level and who are aware of – and committed to doing – the work required to get there.

My name isn’t John Sherwood, David Lynas or Andy Clark.

While they’re dear, personal friends of mine; I learned SABSA from and I did SABSA implementations shoulder-to-shoulder with David; and I’ve been personally mentored by all three of them in different areas of my life and career since 2005, I’m not them. I didn’t write the SABSA Blue Book. I didn’t write the SABSA Training materials (well, except for the first attempt at the official SABSA-TOGAF integration special seminar, but that's a story for another day). And, in fact, the only official certification level I have in SABSA is the SCF Foundation. So if you're impressed by names, titles, certifications and all that jazz – and its a show-stopper for you – then it’s clear that I’m probably not going to be able to teach you much of anything.

My delivery style might drive you bonkers.

Let’s just say that I've been told I'm an “acquired” taste—much like the first time you got into booze. It just takes a bit of getting used to before you can appreciate it.

While this isn't true of everyone, it’s probably a good idea to go have a quick read through random posts on the Archistry blog to get a feel for the kind of viewpoints on everything from dead frogs to security architecture to the latest security buzzwords like “Zero Trust” before you get yourself into this and then balk at what you see, because…

There’s no guarantee or refunds, and full payment must be made before the course starts.

That’s right. I used to do a double-your-money-back guarantee and had a whole set of interventions built in to make sure you had all the hand-holding you required to be successful in this course. However, what’s become clear over the last couple of years is that the people who need this…the people who require a guarantee…they’re really not the kinds of customers I want to help, and in some cases, they’ve turned out to be the types of customers I can’t actually help—because they either weren’t ready or because they weren’t able to commit to doing the work.

Again, if this is a problem for you, or, certainly, if you don’t believe that I’m qualified to teach you the things I’ve talked about so far in this letter, then by all means: don’t bother enrolling in the course. I don’t want either of us to waste our time and energy.

What I can promise you is that I know the system works, and I know that people who have put the time and effort in to doing the work required for the course have been able to dramatically change the way they work, and they’ve become much more effective at delivering architectures that truly support their organizations.

It’s all here for the taking, but the knowledge and skills I teach in the program are not going to magically sprout in your brain like wildflowers after the first spring rain. It takes time, it takes effort, it takes commitment, and – most importantly – it takes an open mind about what the role of a security architect – and security architecture itself – are in the context of your organization's security program.

You don’t even have to wait. You can start building business-driven security architectures RIGHT NOW!

Now I know that if you’re all excited to get started learning about The Agile Security System, and you’re chomping at the bit to get started changing the way you do architecture TODAY…

…it can be somewhat of a let-down to realize that there’s still a pretty long time between today and when the next BESA cohort kicks off—even if that’s tomorrow, because it's still a 7-week program, and you’ve still got a lot of work to do before you can get started.

That’s why, as an extra special “getting started” bonus to allow those eager-beavers who’ve had some exposure to SABSA already to dive right in and start shifting their thinking about security architecture and how to do it…

I’ve added in your very own copy of the Getting Started with The Agile Security System eBook to the core materials you get with the BESA program!

You might be wondering why I’d do this if the whole point of the BESA program is to learn how to build more effective security architectures with The Agile Security System. You might be thinking that this undermines the value of the program…

...and that it might “give away” a good portion of what you’re going to learn.

However, while it’s true that there’s some obvious overlap in parts of the program, I can tell you from previous experience that people who’ve already been applying The Agile Security System for months on their own thanks to both working with me individually and being a subscriber of the Security Sanity™ print newsletter…

…still LOVED the program.

And the still learned a lot.

Because, let’s face it. This Getting Started eBook is short, focused and to the point. There’s no fluff, and it assumes you have the ability to fill in the blanks and start from what you already know. If anything, it will help you get MORE value out of the BESA program than everyone else who went through it before without access to this eBook simply because you’re already primed to think differently in some specific ways…

…and you’ve had a chance to think about how you’d use and apply The Agile Security System in your own work before.

Everything else will already have a skeleton ready and waiting for you to enhance and train based on everything else that you’ll be exposed to and practice during the 7-weeks of the program.

Ultimately, it just gives you one more resource to help you get the most value you can out of the BESA program, because here’s a very small glimpse of what you’ll find inside this eBook that will be delivered to you immediately on your registration via the Archistry Learning mobile app:

• Why The Agile Security System is different than any other approach to building security architecture. See Page See Page 27.
• The one simple “tweak” I had to make when I taught SABSA Foundation to make the power of SABSA’s standardized RACI really “click” for delegates (which worked so well, other instructors ended up stealing it too). See Page 45.
• Why we’re often forced – kicking and screaming – into doing “bottom-up” architectures (including what we’re really supposed to be doing when we do it). See Page 69.
• A “hidden” truth about the nature of the “deliverables” defined by SABSA (something that both gets unsuspecting architects in hot water and nearly assures the ultimate destruction of many SABSA adoption efforts). See Page 22.
• Why we need attributes as a security architect. See Page 36.
• The only tool you’ll ever need to clearly, easily and quickly define the scope of the security architecture you’re working on. See Page 54.
• Want a more effective security program? Just do this. See Page 18.
• The only legitimate way to achieve – and maintain – true “business alignment” with a security program of any kind. See Page 17.
• Why there’s really no such thing as either “top-down” or “bottom-up” when it comes to doing security architecture. See Page 72.
• Unlock the critical relationships between domains and the systems of “systems thinking” or synthetic thinking. See Page 31.
• How you can realistically apply SABSA successfully while ignoring the rest of the 20+ frameworks it defines (illustrating that it’s no wonder you were a bit lost after the 5-day firehose of SABSA Foundation). See Page 25.
• Why it’s a really bad idea to conflate the concepts of value, price and cost when you’re talking about security architecture—or anything, for that matter. See Page 49.
• A detailed guide to building out a physical Architecture Wall™ that will beg to be updated, foster engagement across your team and help you stay focused on what’s really important about your organization’s security architecture. See Pages 83-84.
• What’s CRUD got to do with it? It’s probably not what you think, and it has nothing at all to do with databases. See Page 33.
• How The Agile Security System extends the core SABSA domain concept to make it even more powerful than it already was. See Pages 30-35.
• The drop-dead-obvious relationship between the discovery of the domains in your architecture – new or already there – that allows you to begin to start “seeing” architecture in your head. See Page 35.
• How to discover the network of attribute relationships in any architecture (just use this one simple tip, and you’ll have more connections between attributes than you’d imagined were possible). See Page 98.
• How a “handful of paper” just may well be the only kind of security architecture documentation you really need. See Page 82.
• …and much, much more, including who our 7 basic types of security customers are and how to figure out what they’re expecting from us (see Page 79)…why “standard templates” for security architecture are the Devil you actually never want hanging around your neck (see Page 81)…the single biggest mistake people make that ultimately leaves SABSA sitting on the scrap heap of your security program (see Page 22)…the 8 most important attributes you’ll ever meet as a security architect AND which you won’t find mentioned in the BESA program at all (see Page 41)…the 3 things to look for to measure your progress as a security architect, regardless if you’re using SABSA and The Agile Security System (see Page 86)…and the surprising “secret” as to why being curious is one of the most important habits a security architect can have right there on Page 19!

What’s Inside the Book

Even though I said it’s a small book, it packs 15 chapters and 7 different appendices into just 105 pages. So, in case you want to get a structured breakdown of what you’ll find in the book instead of just a glimpse of the highlights I’ve covered above, here’s what you’ll find inside.

Chapter 1 gives you an overall introduction to the purpose and structure of the book. It tells you what it is, and what it isn’t. And one of the things it isn’t is a replacement for a deeper introduction and education on SABSA and The Agile Security System like you’ll find in the flagship Building Effective Security Architectures (BESA) program or the official SABSA training.

Chapter 2 introduces you to The Agile Security System itself. It talks about where it came from, why it’s necessary, and some immortal caveats about what it takes to build effective architectures fast. You also get a bit of an overview of my own personal journey from where I started as a fresh graduate with a degree in Computer Science to where I am now—including some of the major milestones and influences that got me from there to here.

Chapter 3 provides the quickest, most condensed and up-to-date introduction I’ve ever given to SABSA—including where it came from, what it is (and isn’t), and what it does to add to the discipline of security architecture. I provide my current definition of what security architecture is, and then I talk about the three core concepts of SABSA and why they’re so important.

Chapter 4 talks about my own journey and evolution in the way I understand and apply SABSA. It talks about my first generalization and integration of the core SABSA materials into a unified framework, and describes what I was trying to accomplish by doing it. I then talk about swinging back, full circle, to SABSA’s security roots and how everything that’s in SABSA is inherently a part of The Agile Security System too—all in one handy, easy to remember diagram.

Chapter 5 walks you through the most important part of SABSA—both to me and The Agile Security System and to the discipline and practice of security architecture as a whole. I talk about how SABSA embraced and clarified the the current state-of-the-art, and then I describe how I’ve both relaxed and extended the domain concept in my own work and evolution as an architect.

Chapter 6 brings us to attributes, probably the second most commonly recognized aspect of SABSA behind the iconic Architecture Matrix. In this chapter, I talk about how attributes work, how they relate to prior art, and, most importantly, how you can learn to create attributes almost effortlessly, no matter what you happen to be working with. Also, since you can’t talk about attributes without talking about how you measure how much of them you have, I summarize the essentials of SABSA’s Performance Management Framework (PMF) and talk about the way attributes are used to express your organizational risk appetite.

Chapter 7 ties everything together by introducing you to the SABSA Governance Model. Now, if you’ve been through the Blue Book or the SABSA Foundation training, you’ll see some things that are familiar. However, you’ll also probably see some things that you might not expect too—because there’s a whole lot more to the SABSA Governance Model than just defining the relationships between the core phases of the SABSA Lifecycle. I don’t even mention that at all in the book, actually.

Chapter 8 introduces what I believe is the most fundamental domain relationship, that between a customer and a supplier. However, these aren’t fixed entities. In fact, and fully in accordance with the SABSA Governance Model and the Entity and Trust Framework, each of these are roles that get assigned to the right actors at the right time so you can truly unpack and uncover what is really happening to deliver value in your organization.

Chapter 9 presents the core domain framework I defined with The Agile Security System based on literally decades of architecture work in the field. I got tired of always drawing almost the same domain models every time, so I defined the Baseline Perspectives™ as a way to short-circuit that work and help me stay focused on what’s really important “inside” the lines. And, if it works for me, it’ll work for you too—especially based on the comments and feedback I’ve gotten from the many people using them every day as part of their own architecture work.

Chapter 10 cuts to the chase about what’s important to capture as part of developing and documenting a security architecture at any scope or scale. It connects the dots between what we’re trying to do as we're capturing and defining security architectures with general systems theory, so that we can have an over-arching formalization to help us do what we’re trying to do without getting stuck in the weeds and overwhelmed with detail. Most importantly, this chapter talks about the two essential modes of thinking every architect must use—and which one is actually the most important and relevant for creating successful architectures.

Chapter 11 provides a high-level overview of what’s required to do architecture the “right” way—starting from the top, as close to the business as possible and working our way down through SABSA’s architecture layers. In the process, it gives some fundamental questions every architecture must answer and then talks through how the Principles, Practices and Perspectives are used to make sure you don’t miss anything important.

Chapter 12 starts at the bottom and talks about what’s involved in doing “bottom-up” architecture. Whether we like it or not, there’s still a time and a place to do it—whether it’s “proper” architecture or not. It’s still useful, and there’s still valid reasons for doing it. This chapter talks about what it’s for, why you’d do it and what to do to make sure the tedium and overwhelming boredom often involved in doing this kind of exercise doesn’t suck the life out of you as a high-value security architect.

Chapter 13 presents what I call the “middle out” or Architecture Archaeology approach to discovering the architecture inherent in anything you’ll ever encounter. It’s fair to say that it’s potentially a superset of the other two, but the purpose of doing it this way vs. the others is very clear, and something I talk about extensively in this chapter. I also tell you why once you start, it might be the only kind of architecture you’ll do from now on too.

Chapter 14 dives into the heart of what many people think is where the whole “security architecture” thing starts and stops. It tells you how to effectively communicate the architectures you build, because going to all that trouble to do it isn’t going to make much sense if nobody but you is able to use it. This chapter talks about the importance of matching your message to your audience, and I present the most important groups of security customers  we normally need to address, along with some tips and guidance on exactly what to say to them when we do it.

Chapter 15 closes the book with some ways to measure your own progress as a security architect and gives you several options and potential “next steps” to continue your skill development and evolution as a security architect.

Appendix A presents the Enterprise Baseline Perspective™ model, including the domains and core relationships that describe the value delivery network of your entire organization, whether it’s large, small and whether it’s for-profit, non-profit or public sector. I’ve successfully used these models in all of those environments.

Appendix B presents the Service Baseline Perspective™ model. This perspective is one of two ways you can take a “slice” through your organization at any scope to match your architecture iteration and ensure that you’re not overwhelmed with excessive or irrelevant details. At the same time, everything you reference in this model automatically has a “home” in the Enterprise Perspective, so it’s impossible for you – or your security customers – to ever get “lost” when talking about something you’re working on.

Appendix C presents the Value Stream Baseline Perspective™ model. Like the Service Perspective, the point of this model is to allow you to “slice and dice” your organization to focus on what’s relevant and important. In particular, this model covers all aspects of your organization, where the Service Perspective may not always be the perfect fit, depending on the nature of the project or problem you’re working on. This way, you have everything you need to deal with the normal architecture iterations that are most commonly done by security architects in one or the other of the two Perspectives.

Appendix D presents the External Baseline Perspective™ model. The purpose of this perspective is to allow you to model the way your organization interacts with the outside world. Not all aspects of your organization do this directly, so this Perspective helps you “zoom in” on the parts that do so you can delve in to the nature of those interactions and identify their implications from a security perspective.

Appendix E defines a set of 55 attributes that repeatedly come up in my own security architecture work. These attributes intersect with the attributes defined by the Blue Book and the official SABSA materials in their names, but the definitions are different to reflect the way I use the three core concepts of SABSA in my own architecture work. These attributes are part of the Reference Architecture I built for the Archistry Execution Framework, but they’re so common that I find it almost impossible not to need them in almost every engagement.

Appendix F provides a set of default Attribute Patterns – recurring relationships between attributes that are inherent in the attributes themselves – that I’ve defined over the course of my architecture work. Sometimes these patterns are the perfect fit for helping you prioritize and place the relevant attributes in your own architecture models, and sometimes they’re close, but they’re definitely not the droids you’re looking for every time. That’s ok, because this appendix also talks about how to use, extend and transform these patterns to make them fit your own architecture projects too.

Appendix G defines each of the core domains included in any of the Baseline Perspective models. While simply drawing a box can potentially define a new domain, they aren’t much good to you if you can’t describe what’s inside them—so you can know what isn’t. These definitions also provide a starting point for you to use as the basis of your own domain definitions so there’s no confusion as to what you’re talking about in your security architecture and why it’s important to the organization.

Well, here it is. Decision time.

Bear in mind: if you click the button below, you acknowledge that you have read and understand the terms of this offer, specifically that there are NO REFUNDS and NO GUARANTEE that you will achieve any results of any kind by participating in this program.

So, if you've read all of the above, you understand the amount of work that's involved in joining the program, you're prepared to make the commitment to 5 to 10 hours per week – including a commitment to support the cohort by doing your assigned peer reviews over the weekends – and you're certain you're ready to join the next cohort of Building Effective Security Architectures, then go ahead, and click on the button below to...

ENROLL NOW!

I look forward to having you in the program,

Andrew S. Townley
Archistry Chief Executive

P.S. There are a maximum number of slots for the program, so there's no guarantee that there will still be enough space left in the cohort should you decide to wait until closer to the deadline. Further, I fully reserve the right to change the quoted price of the program AT ANY TIME prior to the start of the cohort, so the only guarantee you will have of getting the current pricing is by submitting the payment form on the next page. Don't be surprised if it changes the next time you come back if you're unsure whether you're able to commit to the terms of the program.

Complete Your Registration For The Program Below