The security universe is, for sure, an interesting place. It’s never on pause. Never sleeping. It’s in constant change. The complexity is increasing through regulatory pressure, more advanced attacks, emerging threats, and technologies. These are just a couple of aspects shaping the industry and the future. Personally, I think this is what makes it so interesting. And I greatly respect those who think otherwise and feel stressed about it.
This is something I heard many times during my career, security people saying something similar to “The security industry goes so fast, it’s a very stressful place to be!”. This is true, and there is nothing wrong with people feeling this way. This is also something many who are new to the industry feel. This is also something many security leaders struggle with. For example, how can those security investments and initiatives be ensured that they are aligned with the ongoing industry changes and the organization’s business strategy?
So what does SABSA (Sherwood Applied Business Security Architecture) have to do with this? How can it help a security leader? SABSA is an Enterprise Security Architecture (ESA) framework focused on “business security”. I think that SABSA provides security leaders with a very good tool that can be compared with a “compass” <cliffhanger>. A I will get back to what this means later on in this article.
I also firmly believe, and have said it many times through my articles found here at my website, that a security leader should possess a diverse set of skills and tools, encompassing a broad perspective across multiple security domains. If you’re aiming to become and/or increase your skills as a security leader, the knowledge provided through SABSA, I truly believe, can sharpen your skillset. This is what I will explore in this article.
TERMS & DEFINITIONS
Below are terms and definitions that will be used several times in this article:
- SABSA – Sherwood Applied Business Security Architecture (SABSA) is a framework and methodology for developing risk-driven enterprise information security architectures and service management practices.
- SCF – SABSA Chartered Foundation (SABSA SCF) focuses on foundational concepts and principles related to the SABSA framework.
INFORMATION
This article isn’t a “how-to” guide for passing the SABSA SCF certification. Nor does it provide an exhaustive review of the SABSA framework.
Instead, I’ll share my perspectives and reflections on the knowledge that can be gained from SABSA and its application to security leadership. I had the opportunity to attend the SABSA SCF training in 2024 and also managed to pass the examination, meaning I’m a holder of the SABSA SCF certification (together with approximately ~5200 others worldwide. These figures are from 2023 and have increased since then).
If you’re interested in understanding how SABSA can contribute to your development as a security leader and add further tools to your toolbox, read on.
PRACTICAL APPLICATIONS FOR SECURITY LEADERS
As a security leader, understanding and applying SABSA principles can enhance your skills in areas such as:
- Strategic Alignment: Ensure that security strategies are in harmony with business goals, facilitating executive support and resource allocation.
- Risk-Based Decision Making: Utilize SABSA’s risk assessment methodologies to prioritize security initiatives based on potential business impact.
- Communication: Bridge the gap between technical teams and business stakeholders by articulating security concepts in business terms.
- Compliance and Governance: Implement structured frameworks that not only address compliance requirements but also contribute to overall governance and risk management strategies.
I really want to emphasize the first bullet point, Strategic Alignment. This is the core essence of SABSA. It is a security framework focusing on “business security”, i.e. (SA)Business Security Architecture(BSA). What this comes down to is that, with the help of SABSA, is to provides a methodology and framework for how to ensure integration, transparency, and traceability of how security initiatives and investments are aligned with business objectives. This shouldn’t be something new to security leaders, but many out there lack the tools for how to do this kind of work.
To explain this in less fluffy terms, the SABSA framework provides you as a security leader with an easy-to-use and highly practical method for how to ensure that security is business-aligned. Security starts with the business, and it starts with understanding “What does the business need to achieve?”. This means, what opportunities is it that the business want to achieve and what uncertainties does it want to reduce. Yes, you got it right. SABSA is a risk-driven business security architecture framework (see bullet number 2). Opportunities = Positive risk. Uncertainty = Negative risk. Risk comes in two different flavors. Nothing new under the sun here.
This is also something interesting about SABSA. It is a framework that is built around many tested things out there. SABSA has “borrowed” and taken inspiration from, for example, ITIL around service management. Some stuff in SABSA is, of course, “SABSA specific” but if you have been around the block for a while, you will be familiar with many concepts in the framework.
As mentioned earlier, one of the “core concepts” of the SABSA framework to ensure security is business-driven. In SABSA this is managed with the help of something called “business attributes” and “business drivers for security”. I will not rabbit hole on these concepts, but what I want to emphasize is that they are very simple to apply and very powerful. Simple, in this case, doesn’t mean something negative; it is the opposite. Simple in this context means they are easy to use and understand, which also leads to them being easy to implement.
“Business attributes” and “Business drivers for security” are not a moon landing project or comparable to trying to figure out how to develop a rocket. Anyone can learn how to apply these concepts, and I think that all security leaders would benefit from the concepts in terms of understanding “What” and “Why” they are so powerful.
“Business attributes” and “Business drivers for security”, in short, will help a security leader to translate and articulate “What security means for the business”. The power of these concepts is that they can enable clarity and a common understanding between the security and business organization, “What security means for the business”. Security is expressed in the language of the business and applicable to the context of the business.
Of course, there are other ways to arrive at this point and understanding (= aligning security with business objectives), but I think SABSA provides a very good, helpful, and powerful method for security leaders to translate business requirements into the context of security. This is, as I mentioned before, also something that I have seen and still see many security leaders struggling with. SABSA is one way to go, but not he only one. For myself, the method used in SABSA was new to me, but not the concept. I have been using the same concept and principles for years when developing security improvement plans, road-maps, and strategies. To my knowledge, I think that SABSA is one of the few frameworks out there that provides a clear and simple method & concept for how to establish a structured approach for aligning security with business needs.
WHAT TO LEARN FROM SABSA?
SABSA is an Enterprise Security Architecture framework with a focus on “the business”. So what does “the business” mean, you might ask? “The business” = “The organization” = The purpose of the organization. And the foundational purpose of an organization can be summarized as –> creating value. This is more or less why organizations exist. “Creating value” doesn’t always mean monetary things. Think of non-profit organization’s for example.
What SABSA does very well is provide a framework for how to ensure security is aligned with business requirements. SABSA starts with the business/organization in focus and not from a technology point of view. SABSA is not about technology. It is a part of the model, but it is not a security technology architecture. It doesn’t dictate or prescribe that an organization should implement x, y, and z technologies, use products from a certain vendor, or recommend certain solutions. These things come into play in the “SABSA matrix” though. Easily explained, solutions/technologies/products that are chosen to be implemented are and shall be a result of the business requirements and not the other way around.
Yes, I got it. Many organizations have a preferred vendor strategy or have chosen a certain tech stack. There is nothing wrong with doing so, or me saying that this should not be the case. The point I’m making here is that I personally believe that whatever comes out in the other end in terms of an implemented solution and what name it is on that blinking box, security console, appliance, software, <insert whatever>, the decision needs to be possible to be rationalized. A rationalization needs to be traceable. This means that there needs to be a traceability of “why” that technology was chosen. Decisions, security-related or not, in an organization, become so much easier for everyone to understand if there is a “business justification” behind them.
Just think about it: what happens that day if the majority of the people in the security and business organization have been rotated? There are no people left in the organization who know why the security things x, y, and z were implemented. X, y, and z also come with huge risks as they are implemented end-to-end in the organization. At some point in time, though, it made perfect sense to invest billions of resources in terms of dollz, skills, manpower, etc. etc., in x, y, and z. But now, as times has changed, and there is a new world out there due to all these cool emerging technologies and threats, the organization has realized that x, y, and z doesn’t fit the purpose anymore…or they at least thing so due to that x, y and z also comes with a huge cost, risks due to leagay technology creating technical debt, there are no longer people in-house in the organization who can mange x, y, and z. And the list goes on. This is a very, very, very common scenario I’ve seen played out so many times. Or what happens that day when one of those core components in the technology stack becomes obsolete or deprecated, i.e. the vendor announces that the component will, in a couple of years, reach end of life. This happens many times, and I’ve seen it happen many times.
Henrik: “Do you have an enterprise security architecture blueprint for your organization?”
Someone: “No, we don’t need that. We follow <Insert vendor name> and have used their <insert vendor name security architecture blueprint only covering the vendors product and tech stack>.”
Henrik: “I get it, but I think it would be beneficial for you to have your own enterprise security blueprint, which is built for your organization based on your business requirements.”
Someone: “That seems like a waste of time; we have a technology strategy to harmonize on vendors 1, 2, and 3.”
[ Fast forward ~18 months later ]
Someone: “*Panic mode* <insert vendor name> has announced that <insert product name> is going end of life! We have built our whole perimeter and remote access ecosystem on this product! We need to do something NOW!!! *Panic mode*“
In real life story from the security trenches
Ok, just because a security leader knows about SABSA, has done the training, taken the SABSA SCF certification, done some magic with the SABSA matrix, and all that jazz doesn’t mean the problem statement I described will go away. But, applying SABSA and doing so in a prescribed way in accordance with the SABSA framework will help your organization to get a more business-driven security architecture with top-to-bottom traceability. Enterprise security architecture is about the business and organization. Enterprise security architecture starts from the top and goes to the bottom.
FRAMEWORK & TOOLS
As with many other security frameworks, SABSA provides you with a set of tools and concepts. What is unique about SABSA and the framework is the principles around each tool and concept. As I said before, you will find tools and concepts in SABSA that you, as a security leader, most likely have seen before. Things as service management, risk management, risk appetite, KRI, KPI, and strategy development. The list can be made longer; these are just a couple of examples.
The uniqueness SABSA provides is, according to my personal viewpoint, the principles for each tool and concept in the framework. How each part of the framework integrates with another to provide a full “system” for how to develop and manage enterprise security architecture from a business-oriented perspective that ensures transparency, traceability, business alignment, and risk-informed decision making.
Some of the principles within SABSA I found very interesting to contemplate as they challenge “traditional” security principles and thinking. This is also something that I think is a very good “tool” that the SABSA training provides the students with. If you let yourself take on the information, knowledge, and wisdom in the framework, this will for sure add to your toolbox as a security leader. I think that if you take the SABSA SCF training, you should go into it with an open mindset. Be open to that things in SABSA might be done in a different way compared to what you are used to.
Personally, what I take with me from SABSA SCF as the best tool is that it is a framework that is adaptable, and primarily –> it will tell and learn you “how to think“. You will learn how to think as an enterprise security architect/security leader to better ensure that security within your organization is aligned with your business requirements. This sounds like some random fluff, I know. But the thing here is that this is also what I think makes SABSA SCF unique. There are very few security courses out there that learn security people to think about security in a certain way. But, as I said before, this is what you can learn from SABSA SCF if you go in there with that form of a mindset. SABSA SCF, like all other frameworks, has its own touch on things. Some unique acronyms, concepts, principles, and yada yada.
My recommendation to you, if you are about to take the training, is to focus on the “why” certain things in SABSA SCF are constructed in the way in the framework and done in a certain way. These are the questions you, as a student, should ask, as I see it, to really understand what is behind the framework, concepts, and principles within it. The SABSA framework is very well thought through. Sounds a bit philosophical, but the SABSA framework is “deep”. With this, I mean, as I said, it is very well thought through. The better questions you, as a student, can ask your instructor, the better answers you will get.
EPILOGUE
Incorporating SABSA into your skill set can empower you to build and lead security programs that are both effective and business-centric. When I say “can empower”, this comes down to you as a security leader. A framework, standard, or <insert something> will not do the work for you. It is up to you as a security leader to do the actual work.
If you’re considering pursuing the SABSA SCF certification or simply wish to deepen your understanding of security architecture, I encourage you to explore the resources available through The SABSA Institute.
The study material for the SABSA SCF is only available by taking the training. I think this is something positive and negative. Positive is that if the knowledge is provided through the training, it ensures the integrity and quality of concepts. The negative aspect is that it limits the spread of knowledge and concepts within SABSA SCF. But, as I mentioned before, the “knowledge” within SABSA SCF is deep, and I think that to learn it in the best way is through an instructor-led training.
When doing the training, you are also provided with one certificate attempt for SABSA SCF. The SABSA SCF certificate doesn’t come with CPE (Continuing Professional Education) reporting or a yearly fee. Once you have obtained it, you are a holder of it and are expected to do your own continuous education.
Remember, frameworks like SABSA provide the foundation, but it’s your insight and adaptability that will truly make the difference in your security leadership journey. If you ask me if I recommend the SABSA training and SABSA SCF certificate to you as a security leader, the answer is: Yes. You will, if you approach it in such a way, very powerful concepts. You will get another tool for your toolbox, which is a “compass”.
Henrik Parkkinen
Henrik Parkkinen 