Open Comments, hosted by The Open Group

Open Comments: S2 Ep. 5 - Modeling Security Architecture - The SABSA Security Overlay for ArchiMate® with Steven Bradley and Bonnie Demeyer

• The Open Group • Season 2 • Episode 5

Share episode

This episode is dedicated to John Sherwood (1947-2025) who founded the SABSA Institute with David Lynas, where he was the Chief Architect of the SABSA methodology. A pioneer in his own right, John’s legacy will continue through the future efforts of the SABSA Institute. 

The path from code to comprehensive security architecture rarely follows a straight line. In this enlightening conversation, security architects Steven Bradley and Bonnie Demeyer reveal how their diverse backgrounds—Steven as an electronics engineer turned software developer, and Bonnie from sales to project management—converged to create innovative approaches to Enterprise Security.

When traditional security functions operated like "police raids" on projects, Steven and Bonnie pioneered a collaborative approach that engaged teams during design phases rather than punishing them after implementation. This fundamental shift transformed security from an obstacle to a valuable service, seamlessly integrated into development processes.

Their breakthrough came through visualization. "Human comprehensibility works very well with visual media," Steven explains, highlighting how diagram-based approaches dramatically outperform text-heavy documentation. By combining The Open Group ArchiMate® modeling language with SABSA (Sherwood Applied Business Security Architecture) methodology, they created a powerful framework that bridges technical and business perspectives.

This integration yields remarkable benefits for compliance challenges. Rather than wrestling with disconnected regulatory frameworks, their model-based approach normalizes requirements into a unified data structure, enabling organizations to identify gaps through automated queries rather than manual cross-referencing. The result? Consistent, traceable security implementations that support real business objectives.

For aspiring security architects, their advice emphasizes structured thinking, collaborative problem-solving, and confidence that persistence leads to solutions—even when the path isn't immediately clear. The most effective security professionals combine technical expertise with business acumen, communicating complex concepts clearly while demonstrating tangible value.

Want to explore these concepts further? Check out "Modeling Security with ArchiMate®" in The Open Group Library, or visit the SABSA Institute website to learn how visualization can transform your security practice.

Send us a text

Copyright © The Open Group 2023-2025. All rights reserved.

Speaker 1:

Welcome back to Open Comments with me, Ash. Today we have Stephen Bradley and Bonnie DeMeyer, both security architects, who will be talking about their journey with security architecture and what it's been like for them so far at the Open Group Amsterdam Summit. Thank you so much both for joining us today. You're welcome. Before we dive in, please can you tell us respectfully about your careers so far?

Speaker 2:

Shall I start with mine because it probably starts earlier. Originally I was an electronics engineer, converted to software developer in the early part of my career, but things took a turn in the run-up to what some listeners might remember as the millennium Bug, where I ended up scanning writing scripts, basically to scan source code, looking for any routines that were handling dates and might be tripped up by the changeover to the year 2000. So that's really where scanning code for date defects started turning into scanning applications for vulnerabilities and just put that slant on trying to write software to make it work, to try to make software break, yeah.

Speaker 3:

So okay and uh yeah, my career, um yeah, I started actually as a salesperson. So I'm not really that technical like Steve is, but I started as a sales and you know, from that perspective, I think what interests most for me was like really adding value towards the customer. I start moving towards project management, portfolio management and then started growing further into the security architecture business, and all typically based because it's important for a company to assess their risk, and that's actually the reason why I constantly moved up towards a security architect.

Speaker 2:

Yes, it's helping clients protect what they care about. If you feel really that you're doing something that adds value.

Speaker 3:

And the benefit is that I see it not from a very technical perspective, but very much on a business level, and that is really the interesting part, but very much on a business level, and that is really the interesting part.

Speaker 1:

So, yeah, would you say as well for both of you that it helps you stay passionate about what you do because you're seeing people's, you know engagement and interaction in real time, but then you're also learning yourselves along the way. So I feel like you're learning everything a little bit every day. So you're not necessarily like new every day, but there's always something different you could say, correct what you do.

Speaker 2:

Yeah, I think we're really lucky to have a career like that. I mean, I always have thought that um, I mean, you can train really hard and be a very good dentist, but you'll be drilling teeth for most days of your career. Okay, with us, you rarely get two days the same indeed, you know every project is different. Every client works in a different context, got different risks that they worry about.

Speaker 3:

And that's where we also meet up each other, isn't it? At a client in Belgium, a telephone company, proximus, and we actually were working on projects that we had to find out the security requirements for them and that is actually the reason why we started our company as a startup cyber enterprise modeling. We really thought about, okay, we have to present kind of security architecture visualizing models and try to explain from that visualized model how the security requirements are made up by the model. And that is what's really novel about it and people loved it. All project managers really loved it from a security point of view because you had the ability to engage everyone and it was not like an abstract thinking. You can really show that, okay, from that model visualizing, okay, your security requirement from that is because of it relates to that and that you know and it helped focusing and it helped also understanding the projects and you know know you could collaborate closely.

Speaker 2:

In those days, security architecture was a relatively new discipline and there were lots of well, the way of doing it hadn't been fully formed and established, so people were trying it different ways, and some organizations we would work. The security team would act a bit like the police. We would work. The security team would act a bit like the police. They would turn up and raid your project and then beat you up for having failed your pen test, whereas our approach was to try and engage with the projects while they were still in the design and development stage and understand their concerns and their objectives and their scope and work with them to produce something that where the security was built in from the, from the ground, up, Did that involve as well getting real time feedback, which was also beneficial as well, so you could see how people are.

Speaker 1:

You know, learning about this, but also where maybe the problem lies and finding solutions as opposed to maybe not. I don't want to say generalizing, but saying oh, it's's like this, but without actually experiencing it or seeing it from a to z, instead going oh, I've heard that it's like this, I'm going to assume it's this indeed, but you, you could, uh, yeah, you could review it and you could yeah yeah, if you present yourself as a supportive service rather than a police department police

Speaker 2:

department. People will approach you when they're considering their options and they'll seek your advice, which is a far better approach than having to uncover errors after they've happened. Okay, and they also have a better understanding of why you are asking for certain safeguards and controls, because you explain how it helps either them or other parts of the company to achieve compliance. Because it's important for your operating license that these records have to be maintained in a certain way, or it's because a certain attack vector is becoming prevalent. And I think, having that ability to engage with people early, they understand what you're coming from and you're helping them and they're helping you and you're working towards a better solution, would you say it?

Speaker 1:

also works as, say, um, the whole process sort of like a case study right, something you can refer back to saying it was like this before, this was the process, this is what we uncovered, and then your clients can see that and go, look, these were your um, you know insights from that. How can we carry that over? So do you think that also helps, not only for from an experience point of view, but also going forward kind of key takeaways you can take from this project and what you maybe learn from it and how you can improve along the way?

Speaker 2:

yeah, what? In a sense, we, yeah, we, we took that experience and thought, hey, this is a nice way of working, this was the idea for starting a company that says I run to price modeling.

Speaker 3:

It's a whole philosophy behind it. It's like by first visualizing everything, it's like you have a very good yeah, you have feedback from the stakeholder, they, they really follow you into the concept of thinking and you, yeah, it's bringing added value by just showing the visualization of it, you can approve it, you can make it consistent all the way up downwards and yeah.

Speaker 2:

In fact, this is a good point to bring in our first contact with Open Group. Yes, indeed, this is a time period 2014-16, so roughly 10 years ago. Yeah, and this project was a digitalization project so Greenfield site, essentially which meant there was no legacy documentation. Which meant there was no legacy documentation. So what we found because this is where we started first working with Archimate is if we could use an Archimate diagram to draw the solution they thought they were trying to build.

Speaker 2:

That model was a really good basis to start our security risk analysis. Indeed, because everyone's working around a common understanding of what it is you're building, and and it's a diagram where the symbols have a meaning. They're just not arbitrary circles, squares, lines in different colors. In archimate, it's a semi-formal visual notation, so when you draw a symbol, it means a specific thing and you can agree on, you can look at the picture and all have a very good shared understanding of what that model represents.

Speaker 2:

Indeed, and then, from a security point of view, of course, having done the risk analysis on the target architecture, we wanted to try and add our security perspective back into the model. Okay, and of course, that that even now, to a certain extent, the security uh perspective in Archimedes is kind of like overdeveloped, it's a little bit out of its scope. So, working with other architects through the Sabsa Institute, we devised what we call a security overlay for Archimate. So as security practitioners we can now draw the security view of the system in using the same tools that enterprise architects use to document their functional architecture. And that's kind of how, over the last 10 years, we've come to be speaking at this, this event this week. We were presenting yesterday on the security overlay for Alcumate on behalf of the Saps Institute.

Speaker 1:

Nice and can you tell us a few takeaways? Perfect, segue a few takeaways from your presentation yesterday, please.

Speaker 2:

Well, I don't know takeaways as presenters. I mean, certainly there were a couple of people at the end that came up and said that they enjoyed it, but of course you don't know who the audience are at a large conference like this, or what they're really thinking or what they thought they were letting themselves in for, so maybe we surprised a few people, maybe which we did actually because they came to us and say hey, this look wonderful, we would like you to present that to our bank, you know.

Speaker 3:

So we really get some good leads about it and they really found it very interesting. They want to learn more from it.

Speaker 2:

And it's kind of a different audience for us, as normally we're in front of security guards.

Speaker 3:

It's the first time that we went presenting something like that within the open group Indeed quite interesting.

Speaker 1:

And continuing the theme on presenting, do you have like a particular mantra that you follow or how do you prepare yourselves in terms of, like, speaking on audience, for example, as obviously there's different types of attendees at these events? So how do you go into when you put together your slide deck, for example, of what you want to talk about? How do you do it in a way for those that may not know much about it can still learn about it for, but those who know more, it's still relevant to them, type of thing like getting that balance.

Speaker 1:

yeah it's not easy it's really not easy, because it's a very conceptual topic as well, but um?

Speaker 3:

for us. For us it's also, you know, you have the saps institute okay it's like the sherwood appliedlied Business Security Architecture what it stands for, so that's something that you need to introduce to an audience.

Speaker 1:

Are they familiar with that? They need contact.

Speaker 3:

So you have to start explaining what SAPSA is all about.

Speaker 3:

Okay, you know and just for the record, it's like you use it as a business security, enterprise security architecture, enterprise security architecture you use it as attributes. That follows down from a business level towards all the layers, down towards a component level where you use a business attribute. So that is the first concept that we need to explain to our audience and once that's explained, we move down towards the Archimate the diagram things, where we use the SAPSA and the Archimate the diagram things where we use the Sapsa and the Archimate to mingle it together and come up with a diagram.

Speaker 2:

Yeah. So you can show your architecture. You can show where the assets are, where the threats are coming from, where your crown jewels are located, the possible path that an attacker might use from their point of entry to reach the assets. You can place controls along the way. You can check you've got no gaps. You can check you've got no single points of failure. You can speculate about what a control failure might look like and would it lead to a small incident or a major one, and trace it up through the layers as to which value chains would be impacted, which stakeholders would be affected. So you get this very holistic view of the security of your whole system, in which everything is connected.

Speaker 3:

But even that that's really technical, but if you, you know, for nowadays it's like being compliant is one of the biggest things nowadays, okay, especially with nistu uh compliancy.

Speaker 3:

So we also presented in this uh, in this event, uh, how you can get this compliant with just not only the nist regulation frameworks, but start from a controls integration platform where you have several frameworks, legislation frameworks, add up in one data model and where you can query okay, what is the control objectives which are applicable for my domain where you're working for it's like within the NIST, it's like the statement of applicability.

Speaker 3:

You have your scope requirements and then you have to check. You know that's on the left part of it. Then you have your control integration platform, you form and on the right angle you then start with building reference architecture and because the reference architecture is included, is built up on top of the integration platform. If you then list that towards a target architecture, you easily can find the gaps, to find the gap analysis and the beauty of it, because now I sound very technically and very difficult, but you know what the beauty is. It's very simple. We have the integration platform ready, so all the legislations are already lined up, they're normalized and the only thing that needs to be done is like okay, what is my target architecture.

Speaker 2:

Just design it.

Speaker 3:

And you can query immediately where your gaps are. You have at the end a heat map where you say, okay, I'm so many percentage ready and voila, and that's the most robust compliance check or method.

Speaker 2:

It's a complicated thing and lots of organizations struggle with it, but actually if you take an architectural solution, it doesn't doesn't have to be complicated, yeah really it's.

Speaker 1:

It's really a set of logical steps on that note as well, do you think it's? When people see your presentations? So say, for example, future security architects, what advice would you maybe give them if they're starting out in their careers or they're wondering how to get more involved in security architecture on the whole, because in today's world it's quite overwhelming with how much information is out there, right, correct. So how do they kind of sieve out the noise?

Speaker 2:

I think what we've done by bringing together Open Groups, archimate and SAPSA and the security architecture practice, it's a win-win-win right. Yeah, for Open Group and Archimate there's now an overlay that proposes a very good way of integrating security into your models.

Speaker 1:

Okay.

Speaker 2:

For the Sapsa people that do the security architecture. They now have access to what we call model-based systems engineering tools. In other words, the tools that support Archimate now support SABSA.

Speaker 3:

Where SABSA didn't have any tools Before.

Speaker 2:

Now it's all in one tool, so it enhances it.

Speaker 1:

Yeah.

Speaker 2:

You see the security view and the functional view in the same model. But the third part is like yourself, like the architects. What do the architects get out of this? Now, I don't know if you have ever had this experience of If you really want to test whether you understand something, write it down, yes, or teach it, or try and code it, try and model it.

Speaker 2:

Okay, try and model it. Okay, because that way of having to train your thinking into a structured approach Breaks it down. Breaks it down and makes you aware of oh, I've got this information, where does it come from? Where does it go to? To, I'm peeling the layers so it's very easy to write fluffy diagrams and join them up with lines which look pretty but everybody has a slightly different interpretation and what do they actually mean?

Speaker 2:

say, if you have to write it down in a semi-formal, structured way, okay, you have to think about it a little bit more carefully, just like when you write it down, when you teach it, it makes you understand it better.

Speaker 1:

So I I am convinced that working with modeling has made us better architects, and that's after 10 years of working in this domain, right, so it's a win-win-win and do you think that also um brings in problem solving in the sense of you know, when you said how you break down things and the coding as well, when you can see sort of going past diagrams. So if you write something down you can see, you can visualize the steps, but then you can see the steps in between and then you can almost think if someone were you know, if they're new to this what would their viewpoint be right, what questions would they be asking?

Speaker 2:

and then so again, you could write that down in a document of 80 pages, okay, or you could show it in a couple of diagrams, okay. And human, uh, comprehensibility works very well with visual. Yes, individual media text is nowhere near as efficient as a way of absorbing information. Human comprehensibility works very well with visual. Yes, in visual media, text is nowhere near as efficient as a way of absorbing information. Yeah, that's true, but looking at a diagram. If you've done the basic learning of the notation, you can look at a diagram and you go. This is the bit.

Speaker 1:

I don't recognise that. Looks odd to me.

Speaker 2:

Yes, right, and people will look at a diagram I don't know every three months if it needs updating. They won't read an 80-page document every year when it needs to be reviewed, but they'll review your diagrams.

Speaker 1:

And it's quicker to update a diagram because all that stuff You'd probably have to go through reviews again. Yes, references If you change it, it again references. It could be changed. It could be changed in other documents. Yeah, so the whole thing Domino effect.

Speaker 3:

You can imagine that you have a company where nowadays they have to do it like that. You have a bunch of legislation.

Speaker 1:

Yes.

Speaker 3:

And all those legislation needs updating. Where do you start? So, in that perspective, it's like because all the legislation frameworks are also linked to each other. You know some control objectives are also representing with another legislation framework. Yeah, but those are all mapped. You know, we have um the metadata linked to it, so once you change that, it immediately updates updates. Uh, you know from other legislation frameworks. So it's kind of very easy to do it. But if you have to do it manually it's a very, very it doesn't have to be complicated.

Speaker 2:

It doesn't have to be complicated, simple does it.

Speaker 1:

There we go, but it's simple does it yes it's true.

Speaker 3:

It's like nowadays you have to, you have to, you have to be able to tell that you're consistent. So for a model it needs to be very consistent. But we can present that and it's more consistent than you put one diagram and you don't link them up whatever. But if you are linking them up, you stay consistent and the fact is that you don't make a lot of mistakes because you just add, but the model stays consistent again. But if you have to do that manually, it's like yeah, it's, it's, you make mistakes, so the consistency is gone.

Speaker 2:

You don't have a good process yeah, indeed again. So if it's secure by design, it doesn't have to be complicated. Retrofitting it is hard, yeah, but doing it by in the design it's fun. Actually, it's not just. You enjoy your work because you you get a tangible sense of how you're adding quality to the, the final deliverables.

Speaker 3:

You have real trust in, in what we produce but it's also a very good benefit of modeling it. It's because, once you've modeled it, you have a data model actually, and that data model you can query whatever you want, so you can perform actually a kind of predictive analysis upon that to understand, okay, if I change that, or I would have a project consisting of that, what could be the impact on my model, you know, so that's also. Yeah, that's right.

Speaker 2:

Because you might create this model from an architectural process, but the use of the model goes way beyond architecture. Yeah, because it's like. It's like querying a database that knows everything. It knows how everything is connected. It's large, irregular, complex, but it's it. It's been built in a predictable way where you can write scripts that know what information you need and where you can find it. Okay, right, so it supports you along the way, kind of thing. Yeah so, yeah, it's so. It's a data resource that you can query in a very flexible way to answer all sorts of problems, all sorts of questions nice and speaking about, well, problem solving, you could say do you have a particular outlook on problem solving?

Speaker 1:

so, for example, when you come across a problem in your both your respective minds, do you have particular process of how you break down problems? Or or is it more that the problem might be tested with a group of people we collaborate with others and how you can break down the problem? Or maybe advice you got from your mentors and how they solve problems, and it's quite a vast question. That's a lifelong experience, a lifelong. We do cover that on the podcast. That's great that you mentioned that. Thank you.

Speaker 2:

Yeah, experience lifelong. We do cover that on the podcast. That's great that you mentioned that. Thank you. Yeah, all those elements exist, yes, I think. Um, when you have a lot of experience, it's sometimes hard to hold that experience back and let your client talk and express the problem. Okay, how they see it, without rushing to the conclusion you've already got in your mind okay, okay.

Speaker 1:

So in some ways.

Speaker 2:

Being fresh is an advantage, as being experienced okay.

Speaker 1:

Do you think you sometimes so say if they come in with something and you kind of know you don't want to preempt too much, but you want them to. That's the danger yes.

Speaker 2:

Then the second thing is do you have a kind of toolkit of techniques for breaking down a problem? Uh, disassembling it, okay. Examining the pieces, yeah. Juicing them for wisdom and knowledge, cleaning them up and putting them back together again in a smoother working order? Yes, and then the third part, I think, is probably personality and temperament. It's like are you someone that can engage? Engage in a problem regardless of how confident you are of whether you can solve it or not? You have to be confident in yourself that by just trying and persisting and teasing out information, you will eventually get there, even though the end result might not be apparent to you at the beginning. You kind of have to have that inner confidence that if you keep trying, you will, you will crack it.

Speaker 1:

So the puzzle pieces will eventually fit, but not forcing them as well, not forcing them don't think of it as a rubik's cube.

Speaker 2:

You might think. To solve this I'm gonna need a lot of patience. I'm gonna try a lot of things. Okay, I don't want to force it.

Speaker 1:

Yeah, you know what happens if you do you can solve it that way, but it's not.

Speaker 2:

It's cheating. I don't want to force it. You know what happens if you do.

Speaker 3:

You can solve it that way, but it's cheating.

Speaker 2:

But honestly, in my point of view, that's what Sapsa. It's very much like it's a mental root, isn't it?

Speaker 3:

Sapsa is really used to try to understand what a specific problem is for the customer. And you can apply it for any problem you can have.

Speaker 3:

And that's the interesting part you can really abstract from it and use the business attributes in a very understanding way. What is important to you? It's like it needs to be available, needs to be trusted. Those are certain attributes that can you know where you need to contribute that towards a component level, on an operational, logical, you know, application level you downwards, you put that downwards, uh, on the chain, isn't it?

Speaker 2:

everywhere in your architecture stack. Everything should support the things that the business cares about. But, the technique is just as applicable to things that a business cares about to what a person cares about in life? Yeah, indeed, it can be everything. It's just properties, qualities, things that make life valuable to you, the things that you want to protect and enhance, and it's a problem solving network, a methodology that enables everyone to understand that we're supporting these qualities.

Speaker 3:

Yeah, the value chain. It's based upon that and it's traceability, back downwards, but also upwards again.

Speaker 2:

So you can show you're working, you can show why you arrived at a certain conclusion, which I think that helps people understand you're working.

Speaker 3:

And if you've got something wrong? Along the way you can tweak it and the beauty is that from that attribute you can create metrics to it, you line it up, you can create thresholds to it where you can see okay, if it's beyond that threshold, it needs to create an alert coming back so you're closing the loop exactly.

Speaker 3:

It's also the same with a model. It's good for the feedback loop. It's also how the for the feedback loop. It's also how we use the gap analysis for the control compliancy. It's like every if there is no link from the target architecture, if from a certain control requirement objective there is no link towards a realization services or a component or whatever, it means it's lacking. And that's that's actually the way how we can um see if it's a gap or not.

Speaker 2:

You know, yeah yeah, you can't have unterminated requirements. It's just a way until you anchor it to a control that exists in your core real world architecture. Gotcha right, yeah, yeah, but your model can check those paths. Indeed, it can monitor. Yeah, it can monitor its performance.

Speaker 1:

Yeah, nice. Now, before we end, is there any other nuggets of information, any more information that you'd like to share with our listeners, or even something that you'd like to leave?

Speaker 2:

our listeners with Okay. So I'd say, if this sounds interesting to you, the Modelling Security with Archimate is now a paper in the Open Group Library, so check that out as one of the security guides. If that looks interesting and you'd like to follow it up with courses on how to do it in real life, have a look us up at the Sampson Institute website.

Speaker 1:

That's great. Thank you so much. Thank you, stephen and Bonnie, for coming on to the Open Comments podcast. It's been really great learning not only more about security architecture but also your career journey so far, and we hope our listeners have really taken to this episode as much as I. Have been very interesting and lots of insightful information and we wish you all the best and thank you so much again for coming on the podcast.

Speaker 3:

You're welcome, thank you very much.

People on this episode

Head Shot

Ash

Host