Help?! I Want to Be a Great Security Architect! — Part I

Those who know me well, know I fell in love with the COSAC conference first, SecArch second. Maurice Smit invited me to come and speak at COSAC in one of the non-SABSA security tracks. My first year I entered the SABSA Design Off contest, not knowing what SABSA even was. The following years my interest grew as I stayed connected with the COSAC architects. But every time I entered a talk in the SABSA track, I felt I did not know what these people we’re on about. The pivot occured in 2017 when I followed my SABSA Foundation Course with David Lynas. I decided that I wanted to specialize in Security Architecture for my work. But how does one become a Security Architect?!

This led to a COSAC submission next year for a session called “ Help?! I want to be a great SABSA Architect!” in 2018. Me and my colleague Kirsten both were searching for our path to become better architects. We found that real life and the internet offered limited resources to help us grow. In our experience, many starting (and even experienced) architects had the same questions. Our workshop thus followed this structure:

1. The concept of the Hero’s Journey, what mine had been so far and what the audience’s were.
2. Define what makes a Security Architect. Yes, here we go again, for other exciting definition discussions visit this article.
3. Determine the tasks they do in their daily work.
4. Determine the knowledge, skills and abilities they need to do those tasks.
5. Assess one’s own level of maturity on these knowledge, skills and abilities (KSAs).
6. Spot any gaps between their current KSA set and what they said was the level the job requires.
7. Compare their current level of SABSA training to the self-assessed level to spot any gaps.

Yes, I am a methodological person — this is what happens if you’re both a consultant and a Security Architect. I apologize from the bottom of my heart to all the free spirits out there. I do hope that this session’s content helps you get insight in where you are now and where you still want to grow.

Hero’s Journey

So let’s kick off with the concept of the Hero’s Journey. The Hero’s Journey is a typical way to progress the story about a hero through various stages. The typical progress follows four stages:

1. We start out in the ‘known world’, the status quo, normal-ville. Then we receive a call to adventure!
2. We cross over in the unknown world, where we have to face trials and tribulations on our adventure.
3. We succeed at our quest — slay the dragon, rescue the prince (sorry, feminist fairy tale).
4. Now we’ve saved the world, we return a changed hero to the known world — that is never quite the same as it was before.

Here’s a great animation by fellow Dutchie Iskander Krayenbosch that sums it up in <2 minutes:

What does this have to do with being a Security Architect? When I graduated from my Management Master studies, I knew I did not have to apply for ‘manager’ vacancies. Being a manager is not an entry-level position. In the same vein, being an architect is not an entry-level cybersecurity position. Most of us have had a different cybersecurity career before becoming an architect. One that shapes what we are currently like as an architect. And so everyone has a story of ‘getting into security architecture’. Knowing that story — where you came from — is a very important factor in determining where you have to go next.

My story ‘in the ordinary (read: pre-architecture) world’ starts as at Deloitte Netherlands. I was a consultant specialised in security risk & maturity assessments. Then I got my ‘call to adventure’ — Maurice invited me to come and speak at COSAC. Despite doing well in the SABSA Design Off, I ‘refused the call’ and went back to security assessments. Then, I ‘met with the mentor’, getting to know David Lynas better at later COSACs. I ‘crossed the threshold’ from the mundane to adventure via the SABSA Foundation course.

The initial part of the adventure is about ‘tests, allies and enemies’. Tests I for sure found in the SABSA Exam Papers — for more on that, see this article. Allies I found in my fellow COSAC architects. Enemies I found in those who do not believe security architecture is a thing and SABSA doesn’t work. My role as a Director at The SABSA Institute’s Board of Trustees is me ‘approaching the innermost cave’. Now I am close to the ‘supreme ordeal’ — as soon as I finish my exam paper, the SABSA Master thesis is awaiting me. The ‘Reward”? A SABSA Master title!

And then we get to ‘the road back’ from the adventure to the normal (non-architecture?) world. What will my adventures in Security Architecture bring me? As what ‘new’ person will I be ‘resurrected’ now having Security Architecture skills? A CISO? A CIO? I will ‘return’, but as changed person. I haven’t figured this last part out, but I haven’t met too many people in the returning phase of their Hero’s Journey. What’s your journey been like?

What is a Security Architect?

“If you don’t know where you’re going, every road will get you there”, the Cheshire Cat says. So, it’s important to define what we mean by Security Architect to get on the right road towards becoming one. Let’s look at three definitions from NIST standards:

NIST SP800–53 — Information Security Architect (internal)

An Information Security Architect develops an information security architecture for the information system that:

Describes the overall philosophy, requirements, and approach to be taken with regard to protecting the confidentiality, integrity, and availability of organizational information;

Describes how the information security architecture is integrated into and supports the enterprise architecture;

Describes any information security assumptions about, and dependencies on, external services;

Reviews and updates the information security architecture to reflect updates in the enterprise architecture;

Ensures that planned information security architecture changes are reflected in the security plan, the security Concept of Operations (CONOPS), and organizational procurements/acquisitions.

NIST SP800–53 — Developer Security Architecture & Design (external)

The organization requires the developer of the information system, system component, or information system service to produce a design specification and security architecture that:

Is consistent with and supportive of the organization’s security architecture which is established within and is an integrated part of the organization’s enterprise architecture;

Accurately and completely describes the required security functionality, and the allocation of security controls among physical and logical components;

Expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection.

NIST SP800–181 — Security Architect

[A security architect…] ensures that the stakeholder security requirements necessary to protect the organization’s mission and business processes are adequately addressed in all aspects of enterprise architecture including reference models, segment and solution architectures, and the resulting systems supporting those missions and business processes.

I do not think any of these definitions are better then the other ones. We are going to use the information in NIST SP800–181 for the rest of this article. The NIST SP800–181 describes cybersecurity work, knowledge, skills and abilities (KSAs). As such it is best positioned to use as a reference to the Security Architect’s role and its contents. One final note on NIST SP800–181 is that it does have a strong focus on the US government. As such, some framework or public services tasks might not be relevant for you. You can also define what a Security Architect is for yourself via these questions:

What should a Security Architect do?

Below you can find the tasks that NIST SP800–181 (2017 edition) lists for a Security Architect. We asked the audience to rate what they found to be core, supplemental and irrelevant tasks. Core tasks are those that are either of great importance to the role or you do on very frequent basis. Supplemental tasks you also do, but somebody else could also do them and/or you only do them once in a while. Irrelevant tasks are tasks which you may or may not do, but you wouldn’t list them if I asked you what you did for your work. Easy peasy, right? Why don’t you try that out for yourself?

What should a Security Architect know about?

The next question to ask is what knowledge, skills and abilities (KSA) you should have to be able to do those tasks. Below you can find the knowledge, skills and abilities listed for Security Architect. We again asked the audience to rate them as core, supplemental or irrelevant. I have included the files here so you can repeat the process for yourself.

How do you score on these KSAs?

So the next thing we did was a self-assessment against the KSAs. We used Bloom’s Taxonomy, the framework that The SABSA Institute uses for certification. The audience rated themselves on each of the 95 KSAs on level 1 through 6 — see definitions below.

What you soon notice is that the list of ‘knowledge’ items is very long. When I assessed myself before the workshop, it was quite a self-deprecating experience. Of course, as a starting Security Architect there were many things I wasn’t yet great at. One of the core insights we arrived at in the COSAC session was that almost no one possesses all these KSAs. Many architects work in teams with others that have complementary KSAs to be able to deliver. That was a great relief for me. It does mean one of two things if you’re the only Security Architect in your organization. Either you are very experienced and bad-ass. Or you are in a lot of trouble because they expect you to be able to execute on 95 KSAs. Give me a call if it’s the latter.

Where are the gaps?

Now the answer to finding out where we need to grow is quite close! We asked the audience to perform a gap analysis. They listed the KSAs with the biggest gaps between their current level and what they said the job needs. It’s time to do the same for yourself — compare the answer from the two previous steps! Please note the NIST SP800–181 is not perfect, but it’s the best we’ve got. 2017 was its first release an improved release is coming up this year.

What are the gaps in SABSA education?

Now this last step may or may not be interesting for you depending on whether you’re into SABSA. As said in my article on acing SABSA exams, each SABSA level represents two levels of Bloom’s Taxonomy. SABSA foundation is about establishing knowledge and comprehension of SABSA. SABSA practitioner about its application and analysis. SABSA Masters need to be able to synthesize and evaluate based on SABSA. So the final step in our analysis was a cross-check. If someone has the practitioner title, do they score a 3 or 4 on all core Security Architect KSAs? We looked at this to find out what more training next to SABSA courses one needs to be a great Security Architect. If you feel like doing that as well, here you go:

Conclusions & Part II

Although we had many different personal results that day, there were a big picture. SABSA courses are not all that you need to become a great Security Architect. They focus on applying security at enterprise-level whilst taking into account business needs. They do not teach one the basics of cybersecurity. They do not go into the technical details either, e.g. how to design secure networks. Neither do they tell you how to integrate with enterprise (and other) architecture. So, Part II in this series will be a compilation of cybersecurity, technology, security- and enterprise architecture resources I have found useful during my Hero’s Journey — and will hopefully help you to become a great Security Architect!

Are there any tasks, knowledge, skills or abilities you missed here? What kind of training do we architects really need more of? And how about knowledge of organizational design, business process modelling and psychology?

Originally published at https://www.linkedin.com.