Two conversations I’ve had in the last 5 days have prompted me to put more than a little thought into what my definition of a “security architect” actually is—especially given the nature of what Archistry does through our coaching, mentoring and training programs. The proliferation of definitions of “security architect” I talked about in the free download issue of the Security Sanity™ print newsletter certainly doesn’t help matters. In fact, it makes it much harder than it should be for everyone, regardless if you think of yourself as a security architect or not.
If we look at the classic, “Blue Book” definition, remembering the publisher wanted a suitably marketable “security book” at the time of writing, we get the following:
“A person qualified to design and supervise the construction of secure business systems, usually secure business information systems.”
And we also get some guidance as to what that actually looks like in practice starting on page 28:
“Being a successful security architect means thinking in business terms at all times, even when you get down to the real detail and the nuts and bolts of the construction. You always need to have in mind the questions: Why are we doing this? What are we trying to achieve in business terms here?”
And it says we must be vigilant in the “battle against the numerous other people around you who do not understand strategic architecture and who think it is all to do with technology…
“You have to realize that being a successful architect is also about being a successful communicator who can sell the ideas and the benefits to others in the enterprise who need to be educated about these issues.”
In fairness, I’d actually not looked at this part of the Blue Book for quite a while, and in doing so, I noticed that there’s a lot of alignment between all of this, the included reference to Geoff Rob’s Ten Rules for the Successful Solution Architect and the principles and practices of The Agile Security System™.
In thinking about my definition of a “security architect,” it in fact goes even wider than “the design and supervision of secure business systems.” And it goes wider because of my pretty liberal definitions of “system” and “security” you may have heard me talk about before.
To me, it’s actually about the design, implementation of *secure business* in a way that enables the ongoing secure operation and governance of the activities and processes that work to deliver what’s important to the business.
Thinking about it now, that’s actually where Archistry’s definition of the mission and purpose of a successful security program actually comes from. In case you don’t remember, my definition of the mission and purpose of security is:
“To enable our organization to achieve its mission – the long-term aim of the organization itself – as quickly and safely as possible.”
Now that’s a pretty big order, and, if you’re going to do it individually, it requires that you have a pretty broad set of knowledge and skills or a well-qualified and diverse team supporting you to ensure you can cover all those boxes—whether they’re inside or outside security.
Unfortunately…that’s not what most people think we should be doing—and sometimes, it’s not even what we ourselves think we should be doing.
Take for example a recent description from a CISO Career Tracker article: “What it takes to be a security architect”, quoting from the InfoSec Institute:
“Security architects are the people responsible for maintaining the security of their organization’s computer systems, and as such the must be able to think as hackers do in order to anticipate the tactics attackers can use to gain unauthorized access to those systems”
Now, this isn’t false—but it implies a much more limited scope, and it gives the impression that you only need to think about technology, because nowhere does it mention any kind of business knowledge or awareness.
Or this one, from a company selling training in common cybersecurity career paths:
“A security architect is tasked with designing, building and implementing network and computer security for an organization. Security architects are responsible for creating complex security structures and ensuring they function properly. They design security systems to combat malware, hacker intrusions and DDoS attacks.”
Again, all true…and all technical. but it gets worse in their “as a security architect, you’ll be required to do” list that includes:
- Plan, research and design durable security architectures for various IT projects
- Develop requirements for networks, firewalls, routers and related network devices
- Perform vulnerability testing, security assessments and risk analysis
- Research and implement the latest security standards, systems and best practices
A veritable hodge-podge of, “nobody’s doing it, so…let’s get Mikey to do it. He’ll do anything” type of thinking.
Now, I don’t know what kind of security architect you are – or even if you are a security architect at all – given the nature of what it requires to get on this list. But I would hope that if you’re reading this email, that you have some kind of notional interest in security architecture and a hopefully growing – or already vivid – understanding of its essential and critical role in enabling a successful security program.
However, if you’re looking for technical architecture, network security architecture, infrastructure security architecture or anything that doesn’t align with growing your business knowledge and understanding so you can increase the value you provide to the organization…
…you’re probably not my kind of “security architect”, and you’re probably on the wrong list.
And I’m pretty certain that if you were to join the next cohort of the Building Effective Security Architectures program where we spend no less than 2 weeks just talking about how to better understand, map and document “the business”…you’re in for a big disappointment—and you’re probably going to be up in arms that what I’m talking about has absolutely nothing to do with “real” security architecture at all.
In my world, I guess that depends very much on your point of view, how you see your role in security, and what you aspire to be in your career.
What I know from being around technology and security for over 25 years now is that there aren’t many people who can fill the shoes defined above in The Blue Book, let alone the broader scope I use for my own definition of “security architect.”
That makes them hard to find…and that makes them valuable.
Sooooo….if you want to become one, or even if – in my totally biased opinion – you want to become a better one than you already are, then here’s the best next step you can take. You can join the February 24th cohort of the program using this link:
Or you can feel free to enlighten me on how I have it all wrong and what I’m talking about isn’t a “security architect” at all. Or you can even do nothing.
It’s all up to you.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
