Dear Security Professional,
Have you ever been frustrated by the conflicting definitions of security architecture or struggled to demonstrate the value of security architecture to the business—or even your CISO? Well, you are not alone. In a recent research interview conducted by Ed Moyle for his upcoming book focused on helping security architects get practical guidance and advice, I shared what I consider are some of the most important things any security architect needs to know…
…so you can avoid the most common mistakes security architects make…
…so you can focus on delivering value to the organization with security architecture…
…and you can forever end the debate as to whether qualitative or quantitive risk assessments are the best way to identify the risks that should drive your security control decisions.
I spoke with Ed a few months ago thanks to the recommendation from John Sherwood, the Chief Architect of the SABSA® methodology—the only proven approach to reliably and repeatably creating and operating business-driven and risk-based security architectures. Ed is writing a new book on security architecture aimed at answering some of these challenges, and he reached out to me for my perspective. Ed was kind enough to allow me to record the interview so that I could share it with you.
Here’s just a taste of what you’ll find in the 8-part interview clocking in at over 50 minutes of opinions, hard facts, war stories and practical advice on what it takes to be a successful security architect in today’s frantic cybersecurity threat environment:
- The sad truth about why something seemingly as straightforward as security architecture is so hard to define (including why the most common definitions cripple security architects from the very first day on the job)
- Why lumping security architecture in with security engineering will never give security architects to do the real work they need to do
- An elegantly simple – yet hardly ever seen – way to capture the essential purpose of security architecture and demonstrate it’s value to the organization (which is something hardly anyone working in a DevOps, Agile or traditional security role would ever discover)
- The architectural impacts of the difference between confidence and arrogance
- What you MUST do if you want to be able to truly enable and protect your organization with a robust security architecture (because it’s the single biggest reason that security architecture programs fail to deliver value—even within the security team, let alone the business)
- A scientifically-proven neuroscience fact that forever renders the argument about qualitative vs. quantitive risk assessments irrelevant (along with the only rules you need to follow to ensure your risk assessments are consistent, reliable and can be defended all the way up to the Chairman of the Board)
- Fundamental laws of the relationship between risk and architecture and how they interact to determine the overall effectiveness of your security program
- Techniques to ensure your security architecture can start being aligned with the business—and reliably stay that way over time, no matter what the CEO decides is the best direction of the organization
- The most powerful way to determine which security controls you actually need for your organization (so you can reduce the overall complexity and cost of your operational security controls)
- How Basel II’s definition of operational risk can leave you with gaps big enough to drive a truck through if you use it as the basis of your security architecture efforts
- Now, I know that if you’re in any kind of financial services organization, you might think I’m crazy when I talk about this. However, while Basel II raised the profile of operational risk in financial institutions, in practice it was still a collection of “other risks” that people found troublesome to manage. In reality, operational risk isn’t a risk silo at all. But that doesn't mean people aren't making critical mistakes every day with their security program because they don't have...
An understanding of the surprising implications and scope of operational risk.
- To make sure you have the right picture of operational risk and how it impacts your security architecture – and your security program as a whole – you'll want to hear what's revealed in Part 3 of this interview.
- The one tool you must deploy if you want to remove subjectivity in any risk assessment (and you’ll never again have to worry whether an impartial assessment was actually performed or not)
- Crazy, “wild ass” risk scenarios and what you should do about them (which is probably not what you expect, and is a lot easier than you’d probably think)
- A foolproof way to ensure that your risk assessments will always protect the business—even when you get it wrong!
- What actionable SABSA security architecture development looks like in practice, including show exactly how all the pieces fit together from top to bottom
- The secret to defining the right security strategy for your entire security program
- Unique contributions of SABSA to the discipline of architecture (and how these 3 critical pieces fit together in your security architectures)
- A guaranteed way to define the right schedule for your cybersecurity risk assessments, no matter what industry you’re in, which technologies you use, or how many endpoints and data centers you operate around the globe
- Why handwritten security architecture documentation triples expensive architecture tools
- A “behind the scenes” look at the origins of The Agile Security System™ and why it was necessary now more than ever
- The single most important thing to worry about in security (which is probably the exact opposite of where you’re spending most of your time today)
- Let’s stop and think about this for a minute. In any given day, do you really know where your time goes? Are you making conscious decisions about your activity – how you spend your time – and your behavior – how you respond to events around you? Or are they purely “interrupt-driven” based on the contents of your inbox or the direction of your immediate manager?
- Failing to take control and make conscious decisions about our activity and behavior is one of the key reasons that we struggle to not only create security architectures that matter to the business. It even undermines the overall effectiveness of the security program as a whole. But it doesn’t need to be this way. In this interview, I describe – in simple, easy to implement terms – exactly…
Where you should be focusing your time and energy as a security architect and why it matters.
- However, it’s probably going to mean doing things differently than you do today, so one of the first decisions you need to make for yourself is what you really want to do as a security architect.
- A fatal trap of the CIS20, TOGAF, COBIT, “best practice” and focusing on “health and hygiene” can suck you into that will destroy your credibility as a security architect
- How to do a valid, fact-based and business-critical risk assessment in less than 10 seconds (without sacrificing accuracy and without relying on intuition and unfounded assumptions)
- The “secret sauce” to embedding risk management and security architecture into the heart of your DevOps and DevSecOps teams (which none of the “experts” will ever tell you how to do)
- Why you won’t ever again need to panic every time a new vulnerability is discovered (and the exact steps you need to take to ensure you’re ready, today and in the future—even for 0-day exploits)
- Something your security operations teams probably aren’t doing today to prioritize their threat intelligence (which would not only reduce their stress levels and fatigue, but it would also directly leverage the work they do to shape and enhance your security architecture)
- A crystal-clear picture of the value an end-to-end, architecture-driven security program delivers (proving that you can practice SABSA every day—from architecture to operations)
- The single biggest security architecture mistake (and how you can easily avoid it by making a few small changes in your approach to security architecture)
- How trying to understand and apply COBIT compares to buying a home stereo from Best Buy (causing it to ultimately fail in being useful to many of the organizations who try and use it)
- They lies “reference architectures” whisper in the ears of security architects (and what you need to know to not succumb to their siren song)
- A critical issue with TOGAF that prevents it from being effective in defining architectures—by design
- If you’ve been exposed to me for a while, you know that TOGAF is far from one of my favorite things. In fact, I think it can even be downright dangerous—especially the way it’s implemented in many organizations. What I’m talking about that prevents TOGAF from being effective in defining useful and actionable architectures isn’t what you might think at all. It’s not because it was developed by committee. It’s not because it’s specified in such a way that virtually anything at all can be described as being developed following the TOGAF method. And it’s not because it’s primarily driven by large consultancies who make most of their money on a “time-and-materials” basis.
- The issue I’m talking about is something that, once you know about it, allows you to…
Avoid blindly following an architecture development process and instead focus on building architecture that actually adds value to the business.
- And, unfortunately, if you’re lost in the maze of the methodology and mindset of TOGAF in particular – even though it also applies to many other frameworks and sets of “best practice” in our industry, not only will you struggle…you’ll be wasting your time and the organization’s money doing things that don’t really matter.
- Why there are so many issues with today’s frameworks and standards (through no direct fault of their authors or contributors other than not having a firm understanding of architecture)
- The reason more than 90% of the Cloud Security Alliance Enterprise Security Architecture has nothing at all to do with cloud (along with why people mistakenly think it’s what they need to follow to operate “secure” cloud environments)
- How the fundamental cloud security issues can be addressed by only 3 SABSA attributes
- What to do when you know you need to create “bullet-proof” security architecture documentation (and exactly the approach and tools I used to create one more than 15 years ago)
- 2 books that should be required reading for any practicing security architect (that most people have probably never even heard of)
- An elegant definition of architecture from Martin Fowler (which remains true no matter what project delivery methodology you use)
- The secret – and often forgotten – purpose behind the birth of the Agile movement (which very few people know, and would likely make many Agile-wannabes curl up in a fetal position sucking their thumbs)
- Why the true job of the architect boils down to just 2 things (which have nothing to do with frameworks like TOGAF or fancy modeling tools—where far too many architects spend their time)
- The 4 critical requirements of effective architecture that are hardly ever delivered—especially in security
- How to clearly define the boundaries between architecture, design and engineering in a way that avoids conflict and redundancy in a delivery team
- …and many more!
Here’s What You’ll Hear In The Interview
In Part 1, Ed lays out his vision for the book he’s trying to write and exactly the problems he sees that need to be addressed for security architecture that motivated him to write the book in the first place. As you’ll see yourself, these are problems that everyone from large established software and hardware vendors face…to the individual, hard-working architect just like yourself.
In Part 2, we get right into the heart of the issue. Why is architecture so hard to define, and why so many people are drawn into a much more limiting view of what security architecture is in particular. Once we establish a definition, then it’s all about the value security architecture can provide in your organization. Using the insights here, you should have some new information you can use to hopefully increase the focus and impact of your own architecture program.
In Part 3, we talk about tangible and direct ways that security architecture can be used to enable the business. I highlight a frequently overlooked aspect of architecture, and talk about why it’s so important to miss it if you hope to be successful in your architecture efforts. And then we discuss that if you want to do security architecture right, you can’t do it without understanding the fundamental relationship between architecture and risk—even though in many organizations these are so far apart, they might be on different planets!
In Part 4, we referee the perpetual battle between qualitative vs. quantitive risk assessments. Ed shares some of the insights he’s heard from other people he’s interviewed as part of his research, and then we talk about why arguing about numbers vs. words is actually focusing on the wrong problem, and what the real secret to successful risk assessments actually is.
In Part 5, we continue our discussion of risk assessments, and, again, Ed shares some of the guidance he’s heard previously in his research about the right time to do risk assessments and the rationale for those decisions. What follows is a discussion that goes deep into understanding the role of risk assessments in the delivery of architecture and even links back to one of the fundamental frameworks of the SABSA methodology—which happens to be one of the most important, and, based on the conversations I have with fellow SABSA practitioners, one of the least frequently used in the community.
In Part 6, Ed asks me my opinion on the most common mistakes I see people make. And it’s here that we go through the alphabet soup of frameworks and standards, including TOGAF, COBIT, the NIST Cloud Security guidance, the Enterprise Architecture and Trusted Cloud guidance from the CSA and even touching on the Microsoft Cloud Reference Architecture. Based on my comments above, you might think I skewer the lot of them – which is, in fairness, partially true – however what you might not expect is what I say about them that can have a direct, measurable impact on the way you apply them in security architecture yourself.
In Part 7, Ed opens the floor and asks me to give my opinions about what new architects should know from the beginning. During this answer, I talk about my own evolution as a software, solution, security and enterprise architect and the key references and materials that had the biggest impact on the way I do architecture today. I also share what I think is the “essential reading” list and the highlights of what each one will help you do, and I also give a “behind the scenes” look at the origins of both my concept of architecture archaeology and how The Agile Security System evolved from my own SABSA practice.
In Part 8, which is very short, we close the interview and provide a few closing thoughts—including some interesting perspectives from Ed on what he’s heard me say in response to the questions he asked and how it will impact his perceptions of architecture going forward.
It's All Packed And Ready To Go Right Now
To get INSTANT access to these and a wealth of other practical insights and experience from both Ed and myself, all you need to do is click the button below.
And not only will you get full access to the interview I did for Ed, you’ll also get immediate access to extensive additional information and videos on SABSA, security architecture, security governance, risk management – and even a glossary of over 90 security terms – that can help you be a better architect starting today—including almost an hour of never-seen insights and advice on SABSA I recorded just for you.
Simply click the button below to get started.
Stay safe,
—
Andrew S. Townley
Archistry Chief Executive
P.S. The only way to access the interview – and all the other additional content I mentioned above – is using the brand new Archistry Learning app. Once your order is confirmed, you will be instantly provisioned with the interview in the app, but you must download it using only the instructions you will get following you purchase.
If you have any problems accessing your content, please direct them to apphelp@archistry.com
What People Are Saying About Andrew
A True Thought Leader
“Andrew is a highly skilled and experienced architect and consultant. He is innovative in his thinking and a true Thought Leader in his specialist domains of knowledge—in particular the management of risk. Andrew has also been a significant contributor to expanding the SABSA body of knowledge.”
John Sherwood – SABSA® Creator and Chief Architect
Makes Things Work
“Fabulous person to work with. Very engaging and insightful. Extremely good technical knowledge with ability to relate concepts together and overcome differing opinions. Makes things work.”
Kevin Howe-Patterson – Chief Architect, Nortel - Wireless Data Services
Clarity, Depth and Breadth
“Andrew was able to bring clarity and great depth of knowledge to the table. His breadth of thinking and understanding of the business and technical issues along with a clear and effective communication style were of great benefit.”
Doug Reynolds – Product Manager, MobileAware
Fabulous Consultant
“Andrew is a fabulous consultant and presenter that you simply enjoy listening to as he manages to develop highly sophisticated subjects in a very understandable way. His experience is actually surprising!”
Biljana Cerin, Director, Information Security and Compliance
Interesting, Useful and Full of Ideas
“Found the link to the July issue and read through this afternoon. Think you’ve done a really good job with it and especially around the objective of it being interesting, useful and full of ideas—which the newsletter easily met. Really looking forward to the September issue. If, in the unlikely event an August addition become available, I would happily purchase!”
Andy Smith – Security Architect
A Source of Sanity
“I have been working flat out the last 2-3 weeks on a very detailed program. The one thing that has kept me sane has been your daily emails about the Archistry training. Keep those great emails coming!”
Shane Tully – Enterprise Security Architect