---
title: "Mehran Koushkebaghi  -- Security as a Systemic Concern: How to develop Anti-Requirements"
url: https://appsecpodcast.com/mehran-koushkebaghi-security-as-a-systemic-concern-how-to-develop-anti-requirements/
date: 2025-02-11
duration_seconds: 2708
season: 12
episode: 4
guests: ["Mehran Koushkebaghi"]
topics: ["Secure Development"]
audio: https://www.buzzsprout.com/1730684/episodes/16603169-mehran-koushkebaghi-security-as-a-systemic-concern-how-to-develop-anti-requirements.mp3
video: https://www.youtube.com/watch?v=_IaCjBI4oXk
transcript: true
---

# Mehran Koushkebaghi  -- Security as a Systemic Concern: How to develop Anti-Requirements

*February 11, 2025 · 45 min · Season 12, episode 4*

with [Mehran Koushkebaghi](https://appsecpodcast.com/guests/mehran-koushkebaghi/)

on [Secure Development](https://appsecpodcast.com/topics/secure-development/)

[Audio](https://www.buzzsprout.com/1730684/episodes/16603169-mehran-koushkebaghi-security-as-a-systemic-concern-how-to-develop-anti-requirements.mp3) · [Video](https://www.youtube.com/watch?v=_IaCjBI4oXk)

## Show notes

Mehran Koushkebaghi, a seasoned engineering expert, delves into the intricacies of systemic security. He draws parallels between civil engineering and IT systems, and explains the importance of holistic thinking in security design. Discover the difference between semantic and syntactic vulnerabilities and understand how anti-requirements play a critical role in system resilience. This episode offers fresh perspectives on application security. Mehran Koushkebaghi has 15 years of engineering experience across multiple industries, beginning as a structural engineer before discovering his passion for security. He sees parallels between designing resilient buildings and robust IT systems, applying a holistic engineering mindset in his work. With a master's in computer science and self-taught expertise in applied cryptography and cloud, Mehran continues shaping dependable IT solutions.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
We provide diverse training content and easy-to-digest lessons to meet individual learner needs.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Mehran Koushkebaghi:  
→ [Peter Checkland](https://en.wikipedia.org/wiki/Peter_Checkland)  
→ [RSA Conference](https://www.rsaconference.com/)

Mentioned in this episode:  
→ [Peter Checkland](https://en.wikipedia.org/wiki/Peter_Checkland)  
→ [RSA Conference](https://www.rsaconference.com/)  
→ [Black Hat](https://www.blackhat.com/)  
→ [Critical System Thinking Book](https://onlinelibrary.wiley.com/doi/book/10.1002/9781394203604)  
→ [The Fifth Discipline](https://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization/dp/0385517254)  
→ [Understanding Complexity](https://www.audible.com/pd/Understanding-Complexity-Audiobook/1629976849)  
→ [Nassim Taleb books](https://www.amazon.com/Books-Nassim-Nicholas-Taleb/s?rh=n%3A283155%2Cp_27%3ANassim%2BNicholas%2BTaleb)

Chapters:  
00:00 Meet Mehran Koushkebaghi: Security as a Systemic Concern: How to develop Anti-Requirements  
01:32 Yeah, we're going to explore a topic that we started a  
07:31 Does resiliency mean in a civil engineering context  
14:25 Because if you don't, if you don't understand that though, then  
19:55 I did have a, I did have an odd question on  
21:48 Yeah. Let me see if this— tell me if this works  
24:11 Sure. So, Marin, let's take a look at semantic versus syntactic  
40:39 Okay. Second one is, if you could display a single message  
42:37 Yeah, they're dense. They're thick books. And there's a, you have

## Transcript

*7,724 words · assemblyai*

**0:00 Chris Romeo:** Mehran Koushkebaghi has 15 years of engineering experience across multiple industries, beginning as a structural engineer before discovering his passion for security. He sees parallels between designing resilient buildings and robust IT systems, applying a holistic engineering mindset in his work. With a master's in computer science and self-taught expertise in applied cryptography and cloud, Mehran continues shaping dependable IT solutions. Mehran joins us to explain semantic versus syntactic vulnerabilities and the impact of anti-requirements. These are thought-provoking topics and really things that we haven't discussed in depth before and just new ways of thinking. So, I encourage you to take a listen.

**0:46 Mehran Koushkebaghi:** The Application Security Podcast is brought to you by Security Journey. We provide diverse training content and easy-to-digest lessons to meet individual learner needs. Learners report improving their knowledge as much as 85% on AppSec topics. Learn more at securityjourney.com.

**1:01 Chris Romeo:** Hey folks, welcome to another episode of the Application Security Podcast. My name is Chris Romeo. I'm the CEO of DaVinci, and I'm also joined by my good friend, Robert Herold. Hey, Robert.

**1:22 Robert Hurlbut:** Hey, Chris. Yeah, it's Robert, and I'm a principal application security architect, as well as threat modeling lead at Acquia, and always, as always, glad to be here to talk about application security.

**1:32 Chris Romeo:** Yeah, we're going to explore a topic that we started a few episodes ago with Mateen, and we're going to dive into it, hopefully from some different perspectives, different angles, this whole idea of the systemic nature of security, anti-requirements, all kinds of fun stuff. But before we get to all that type of fun, Mehran Koushkebaghi is our guest today. And Mehran, we want to start with your security origin story. We want to learn how'd you get into this field of security?

**2:04 Mehran Koushkebaghi:** Yeah, thanks, Chris and Robert. Thanks for having me. So yeah, my story in the security space probably is a bit conventional, unconventional perhaps, if there is any kind of conventional path in the cybersecurity space. But I start as a civil engineer, like perhaps like close to like 20 years ago. And I was a trained civil engineer. I was working kind of, I studied civil engineering at the university and I was working close to a decade in the civil engineering industry before moving to the information technology space, basically. And then when I was working there, I was mainly kind of working on, I was studying kind of different systems there in terms of the, some of the engineering system in a traditional sense, how you're designing for resilience, for performance, for different kind of concerns. And then I moved to the kind of the computer science area and basically working more like information technology systems. Yeah, I was looking at the kind of the first, and I studied a computer science degree here as well, and then moved to the kind of working on a software developer kind of role for a number of years before moving to the security. And when I was working in a kind of in the software developer, and then you're basically writing code and designing system to deliver some particular kind of value, particular kind of business problem to solve, that resilience of those system that we were building was always at the forefront of my mind. So that was the kind of main thing that was quite kind of interesting to me when we were designing those systems. And I was trying to basically transfer some of the skills and knowledge that I gained from the previous role as a single engineer in this kind of new area, new domain, which I think there are a lot of things that can be learned from the kind of the other discipline as a software industry, perhaps as quite a young industry compared to the other kind of industry. There are lots of things that can be learned from the other discipline as a interdisciplinary kind of efforts, basically. And then that kind of resiliency was always as a part of my kind of my thinking when I was writing code and developing basically application with the software team. And then I found that in order to be a little bit more like specialized in that area, you need to, I need to move to the kind of other part of the industry, which is more focused on this security rather than just just, just writing code and basically having this resiliency or security mindset there. I need to move up the more specialized role there. And in fact, I would like to talk about a very specific kind of, I would like to talk about this story about how the design at the very high level goes in a kind of a more traditional engineering space that I think can bring into life that kind of the notion of security as a systemic concern. Because most of the time when you're talking about security in information technology system or information system as a more abstract one, it's still quite abstract. So in just having some more engineering example, it might bring it to life. And if you don't mind, I'm going to talk about the particular example of the kind of design of a steel structure against those kind of natural threats for resiliency. And then we can see there are some observations that I think you can use some of those and bring those concepts forward to the kind of this systemic nature of the security and how that applies to all the things that you talked about in the previous episode and going forward. So the example that I would like to talk about here is very kind of simplified version, just to get the gist of it, to go to the kind of the main point of this conversation. So suppose that you would like to basically design a building, a steel structure in a particular area, against natural threats. So for simplicity, we are going to focus on the kind of earthquake as one kind of factor. Suppose that you're going to build a steel structure, I don't know, like 20 stories in the kind of particular like width and kind of length in a particular geographic area like in London. And what I would like to talk about is a kind of talking about designing the steel structure. I'm not talking about the kind of the architectural design. So what's going to be the layout, how many, like if it is a residential property, for example, how many bedrooms or kitchen or kind of how many units are you going to have in each kind of floors? I'm not going to talk about that. That's more like an architectural view of the system.

**6:43 Chris Romeo:** Okay.

**6:43 Mehran Koushkebaghi:** I would like to focus on the kind of the steel structure in particular, those kind of fancy perhaps tower crane that you see in the city that they're basically building those So more on the engineering.

**6:54 Chris Romeo:** So you're going to focus this more on the engineering side. The architect creates the plans, works with the person who's paying for it to figure out what the building's going to be for. There's a whole other discipline though, the way I understand it, on the engineering side where you're measuring and designing the structures to ensure they don't fall over.

**7:14 Mehran Koushkebaghi:** Exactly. That's precisely true. And then you're busy dealing with those kind of structural kind of design. One of the main concerns is resiliency. I think there are lots of kind of similarity between the concept of the design for resiliency there and design for security or resilience.

**7:30 Chris Romeo:** So what does resiliency mean in a civil engineering context? Because I honestly don't know the answer to this question.

**7:36 Mehran Koushkebaghi:** That's a great— so in there, when you're designing a steel structure, for example, the one that I was talking about, Depending on where you're building that, resiliency means that that structure can stand and can bear the loads that's being kind of exposed to that kind of a steel structure in that particular area. So in most, in some of the areas, the kind of the dominant load, for example, is wind. If you're building such a, perhaps, I don't know, in Amsterdam or somewhere that's where you have got those kind of quite a strong winds, the waves can be the more, the most dominant one. Some other building might have the most dominant one might be like snow or like, you know, the hurricane or those kind of things. Some other place it might be like Japan, it might be like earthquake because we are dealing the most dominant load there. And the resiliency in that context means that you are building it in such a way that you can basically, you can tolerate that load that comes in. You're not going to fall apart. The system is going to operate. under those kind of circumstances. So when you design it, so I'm going to just go very, very simplified just to give you some of the kind of ideas about the kind of the process, the thought process, and what are the kind of the key design principles there. So what they do, they start with the kind of the, this is the architecture that's been given to them by the architecture, by the architect basically. And they start with basically talking about the kind of the main components there. If I want to just talk about like 4 or 5 of them as the most kind of common components there, you're talking about like there we have different floors and each floor we've got like different columns. Those columns are being kind of connected by different beams. Beams are like a technical term for some kind of steel structure that connects those columns. And there are some other kind of minor beams, like they are called joists. They're basically connecting those beams together. And then these columns go all the way down to the kind of the foundation, and the foundation lies on the kind of the ground, and that's it. That's very, in this very simplistic way, that's all the kind of elements that are working there. And then when you're basically designing for those kind of resiliency, what you do, you basically model the external forces. You model how does the earthquake, for example, forces is going to interact with your system. And then you see, you basically trace the load, the kind of the physical kind of forces that is in action. In this particular case, for example, just the earthquake. You see how the loads come into the building through the system boundary and then how it basically travels through kind of different components. It goes through the floors, for example, and then goes to the joists and then through the connection goes to the beams, goes to the columns, and then goes all the way, goes to the foundation and then and then to the kind of the ground. So in order for the system to not to fail and to work properly and be a kind of a resilient system, the entire kind of the load path that I just described should, should basically all the members that are within that load path, they should be resilient. They should all be able to absorb the load that is being, that is being kind of appended. So they need to basically absorb the load and basically be able to, to have the capacity to basically be strong enough to not to fail in that particular case. So I think there are 2 or 3 kind of main observations that I would like to take from here. The first is the kind of the notion of the environment. When you're talking about the environment here, suppose that you've done a design for a building in, in the UK, for London, for example.

**11:17 Robert Hurlbut:** Yeah.

**11:19 Mehran Koushkebaghi:** And someone comes to you, they say, you have the same exact architecture, the same exact requirement, everything the same. The only thing that is different, we would like to build the same building in Japan. There is no way you can just grab this structural design and basically move it to the kind of Tokyo and basically build the same thing there.

**11:41 Chris Romeo:** Yeah.

**11:42 Mehran Koushkebaghi:** Because why? Because those kind of the environment, is significantly different. So you're really dealing with an entirely different environment from, from the earthquake perspective. For example, there are 4, there are 4 like tectonic plates, those kind of plates that basically shapes, influences how much earthquake you've got in each kind of area based on the geography that you're building. But in the, in the UK, for example, there's no such a huge concern about the earthquake. So we don't have like many concerns when you're building earthquake, those kind of things. The notion of environment here in the civil engineering is quite bold because you're dealing with a kind of geographic environment, and that's something that is being kind of understood quite well. What I see from my experience in the software industry, the notion of environment is sometimes really easy to forget because we are dealing with like abstract kind of environments. So when you're talking, sometimes when you talk to people, so they Just don't realize that when you're, if you're dealing with the same kind of a structure, the same kind of architecture, if you're dealing like a 3-tier web application in some environment, it's going to be having a completely different kind of, completely different kind of resilience and security requirement if you change that environment. If it is like in the banking industry, okay, it is completely other environment, those security requirements are going to be quite different. In some industries, it's much more mature because of the kind of some of the regulation that is in place. And you're basically getting there, you're building in maturity. But I think that concept of environment is quite, is the key. And that's one of the areas that I wanted to talk about. The second observation is around the kind of the concept of the load path that I just described. I described that basically when the load comes in, it goes through different members. It's not just about the members that I described. It's not just about the kind of the floors, the columns, the beam joists. It's also about the connections, about how those kind of elements are connected, and you're seeing the kind of how the data, how the kind of the force flows between those components until it reaches the ground. I think it is very similar, or it has significant similarities between the load path and the data flow in information system. So if you see the same kind of, you see what you're dealing with information, so it's not physical laws. It's not about the kind of those forces that comes into the system, but it's about the data. So in order to make the kind of— it's in the kind of those traditional engineering systems, if you want to make it secure or resilient, you need to understand quite well how the load— what is the load path, how the load basically traverses across the kind of different members and integration between your system.

**14:24 Chris Romeo:** Because if you don't, if you don't understand that though, then building falls, the building tilts, or if a catastrophic weather event occurs and that's part of that threat model for that particular building, then the building fails, the building tilts, maybe falls over, right? So that's the worst-case scenario for what can happen.

**14:48 Mehran Koushkebaghi:** Exactly. Indeed. That's the thing. I mean, that's quite obvious there. But what I've been seeing from my experience in the kind of the software and the way we are basically talking about the security of the software, sometimes the data flows that, if that sometimes perhaps is a kind of very generous word, most often the data flow is not quite well understood when you're talking to the people that would like to kind of secure the system. They don't know where the data comes in, how it goes out, how these basically go through different components. And then still, we would like to kind of secure it per se with kind of some magic wand or whatever that mechanism is. So that concept of data flow versus that kind of load path, I think that that's quite important. And perhaps this third one, which goes to the kind of the nature of that systemic concern, security as a systemic concern, basically is about, basically when you're designing those systems, you are relying at the kind of the symmetry and the kind of the how the load is being distributed across the entire system for resiliency.

**15:55 Robert Hurlbut:** Yeah.

**15:56 Mehran Koushkebaghi:** So if I go back to the kind of the example that I gave you about the kind of the steel structure, if for example you've got the design is iterative, so it's not something that you basically come up with a load and you model it and you see how the load basically goes through the different components and then you come up with the kind of all the elements with all the specs. You start with the kind of the first initial design and you see like, for example, 50% of the elements are okay, the other are going to fail. So you're basically Gradually, like making them more stronger or changing the spec or whatever kind of methodology you're using to make the entire system secure or resilient in that case. The important factor is that if you have a number of a few, like overly strong columns, for example, or beams in your structure, that doesn't make it secure. It makes it even less secure because if you have some overly strong components there, they just absorb more load. And what— because they have— because they change the load distribution if you change the kind of the components there. So, and then when they change the load distribution, they get more loads from the kind of the overall forces that comes in, and you need to make them bigger and bigger. So that's a kind of a circle that goes around it. So you're basically, by hugely or by overly strong— making some component strong, you're just changing the load distribution. And that change is going to be manifested in the kind of the connection that goes between those components and all the way down to the kind of entire kind of elements across the system. So I think for me, the key takeaway is that in order to make it resilient, those structures, we are not talking about local optimization. We are not focusing on a certain element to make things secure or resilient and just Just forget about the rest or all the kind of the connection, all those kind of things. So we are, we are basically the resilience in that particular example emerges from the interaction of those kind of components within that steel structure. I think the same principle can be applied to the, to the kind of the information system. Sometimes when you're talking about the systemic security, you're talking about like how the system as a whole can be secured, not just the kind of the components within the system. Because if you purely focus on the components of the system, only secure them, you don't always end up in a kind of more secure system. In fact, in most cases, you end up in a kind of worse position than you were before. I think those, those kind of 3 observations, those are the things that I took away from kind of my previous career in the more kind of engineering, traditional engineering space to the kind of information security space?

**18:41 Chris Romeo:** Yeah, I think that's, it's interesting to consider different disciplines and try to find the intersections where we can learn lessons from another engineering discipline that can apply, because I'm a firm believer that a good, doesn't matter where a good idea comes from, A good idea is a good idea. And if it's something that will bolster our ability to apply security, then it doesn't matter where it came from.

**19:14 Robert Hurlbut:** So, all right.

**19:15 Chris Romeo:** So we talked about environments, talked about data flows, were the first 2 connections to the world of technology. Remind me again, what was the third way that we can illustrate that forward into technology? With the third item.

**19:32 Mehran Koushkebaghi:** Yeah, the third item was more about the kind of the emergence of those resilience or security as a systemic kind of nature, as a systemic property. So we are talking about this third one is not, we are not getting resiliency from just a collection of resilient components. It's about the resiliency or security of the entire system working together. Yeah.

**19:54 Chris Romeo:** So I did have a, I did have an odd question on the civil engineering side. So in your example, you said that it's actually a bad thing to over-engineer one particular piece of the, or column or something that's going to carry the load. So like what, I guess what's the negative that happens if I over-engineer one piece of the structural system? and it starts— it takes more load and the other side takes less load. What's the threat? Like, what, what, what can be the bad thing that happens?

**20:32 Mehran Koushkebaghi:** Um, because when we are— so basically what happens when you're basically making one of the components or a few of those components overly strong, it gets more load. So in order to— in a response that it gets more load, you know, you make— you need to make it even more stronger to basically absorb the load. It's not just about that particular element, it basically breaks the symmetry in your entire kind of system as a whole. And the impact at some point is going to impact the other aspects of the building or structure as well. Because if you have overly strong column, it needs— the size is going to be disproportionate to the other parts of that kind of the system.

**21:08 Chris Romeo:** Yeah.

**21:09 Mehran Koushkebaghi:** It's going to affect the architecture at some point. It's going to affect the connection that it makes to the beams. Because if you've got super strong kind of super— and you have got a disproportionate amount of load in one of the components, the connections are going to be quite big as well. It goes all the way to the kind of the foundation. That's going to be— you're going to hit some problem at the kind of foundation or the ground level because at some point perhaps the soil that is underneath your— the ground that's underneath the foundation is not going to be able to absorb that load. You need some sort of an adjustment there as well. So you see that some decisions that you're making at the kind of high level is going to bite you sometime down the road.

**21:48 Chris Romeo:** Yeah. Let me see if this— tell me if this works as a way to take that principle to the world of software systems. So, if I over-engineer or I spend too much time securing one feature and I neglect the security depth of other features, I'm actually creating weak spots in my system because I didn't, I spent too much time on feature C. I spent all my time on feature C and I just buttered the top of features A and B. So now I have a weaker system, just like in the civil engineering example, the system's weaker because the soils underneath may break down and cause the building to fail. In a software world, it's actually the other way around. The weaker the weaker components, I overinvested in one, and now the weaker components are what attackers are going to go after because I didn't put as much effort into securing them. Does that work as an illustration?

**22:54 Mehran Koushkebaghi:** I think that works. I think that there is another angle there as well. So even the kind of, you're going to be worse off, you're going to be worse off in the kind of the weaker components, but even in the stronger components, Because you're making it over, you're giving it more importance. So you're creating that asymmetry there. So basically, in a case of civil structure, we are talking about the force, basically the loads. In your case, perhaps you're talking about the data flow. So you're basically shifting the flow of data in a way that the kind of consumable amount of data goes through that kind of strong component. that creates a kind of a good target for attackers as well. It's strong, but they know that if they can get there, there is lots of kind of valuable data there. So that's created a good kind of incentive for attack as well. So your system is not symmetric in the sense that all this, there's a symmetry there. That asymmetry is going to basically have 2 kind of—

**23:57 Chris Romeo:** Yeah.

**23:59 Mehran Koushkebaghi:** negative implication at the same time, both for the stronger kind of component, also for the weaker components.

**24:04 Chris Romeo:** Got it. So, Robert, why don't you set up the next part about the vulnerabilities?

**24:10 Robert Hurlbut:** Sure. So, Marin, let's take a look at semantic versus syntactic vulnerabilities. And if you could link them to the definition of security, we really want to dive into that. So, could you take us through that?

**24:26 Mehran Koushkebaghi:** Sure. Yeah. So I think before getting there, so I, when I was basically in the process of transferring, basically doing these, started basically looking at these kind of information technology systems and these kind of the concept of systems as a whole, whether in the kind of the more engineering space or in the information technology system, basically. I, I become quite interested in kind of the idea of the system thinking and how the security is one of those systemic properties of the system, basically. In fact, I was doing some kind of studies on that. I started doing a kind of degree in system thinking as well. So I would like to basically, before getting to the vulnerabilities, I would like to talk about, introduce 2 concepts that I think would help us to basically unpack that, the concept of vulnerability here. So when you're talking about the systems as a whole, as a concept basically, there are 2 kinds of schools of thought and a kind of systemic system thinking in a broader kind of discipline. There is one school of thought which is about the system as an ontological device, and the second was the systems as an epistemological device. So it's based at the around If we see system as an ontological device, we are basically using systems, the idea of the system, to basically identify the components of the system, understand the relationship between those components, and define the system boundary, basically. And then when we are talking, and then basically one or the other is basically the distinction that you're making in this particular context, the distinction that we have to make between kind of the semantic and syntactic vulnerabilities. I will get to that in a second in terms of what is that distinction and why that distinction matters, basically. But the other kind of school of thought is more about epistemology. So why, in terms of the kind of system thinking, how we know what we know about the system, how does that help us here? And I think that is the thing that is The episode that we had about the anti-requirement, kind of that definition of security as absence of vulnerability, that falls into kind of that second category. But yeah, going to the kind of the things like systems as a kind of ontological device, basically. So the concept of, before getting to the vulnerability, there's one more concept that I need to talk about, and that's the kind of the concept of the kind this system boundary. So remember, then you're talking about that kind of the example in the civil engineering space, that kind of steel structure space. The boundary is quite visible there. So you know that where the system starts and where does it end. So the edge of the boundary is quite visible. But then you're talking about the information systems or information technology system, that boundary is a bit like more abstract. So understanding exactly where the system starts and where does it end, it's quite like— sometimes it's quite depending on how you define it, you might get different answers, like what— where does the system start, where does the system end, basically. Um, Peter Checkland, who is a British system theorist, he did— he made a distinction between 2 types of kind of behavior. or 2 types of systems perhaps, and that is quite helpful, I think, here. He talks about the purposeful system and also purposive system. Purposeful system or purposeful behaviors are behaviors that are like something that you can— it's some sort of voluntary action or willed action that you can attribute to any social component. So that the user, the social components of the system, they are purposeful. But the purposive, on the other hand, are the things, are the purpose of the system or object that we are basically assigning those purpose to them. So they are not aware of that purpose. We are basically assigning those purpose. And that's the case for most of the kind of the engineering or biological systems. You're basically, they do some function, they have some function, those biological systems, but Most of the case, they, they are not aware of their own kind of purpose. We are assigning the purpose to those objects, basically. So why I'm talking about these, because in the context of the kind of the technology system, we are dealing with socio-technical system. And when you're saying socio-technical, it means that they— we've got— we are dealing basically with 2 sub kind of system there. So we are dealing with some sort of social elements of the socio-technical system. And there's the technical elements of that socio-technical system, basically. I think depending on where you define that system boundary, that's going to become a little bit interesting if you look at the kind of the system from a different perspective. So if you define the system boundary just around, just you say, if the technical elements are part of the system, but the social elements, which are the users, the developers, the operator, or whoever, like those people who are engaged with the system in any shape or form. If you leave them outside the system, this is going to be a purposive system. So you're basically designing a technical system, you're assigning some purpose to the system, and then you're expecting it to basically deliver that particular purpose.

**29:56 Chris Romeo:** Mhm.

**29:57 Mehran Koushkebaghi:** But then you're dealing with— if you define the boundary in a sense that you define it, we include the, the agents, the social elements within the system, that becomes a socio-technical system. And in that case, if it becomes a socio-technical system, it has become a purposeful system.

**30:16 Chris Romeo:** I think— So just to make sure I understand this. So if I could sum this up to say, if the system designer defines what I'm going to do in the system, it's one thing. But if I can explore and find value socially, in the system, it's the other one.

**30:36 Mehran Koushkebaghi:** That's true. Yeah.

**30:38 Robert Hurlbut:** Okay.

**30:39 Mehran Koushkebaghi:** Gotcha. All right.

**30:39 Chris Romeo:** I'm tracking.

**30:40 Mehran Koushkebaghi:** Yeah, exactly. So when you're— when we— if we have the kind of the assumption that it is just a technical system, at least a purpose system, basically, we have the assumption that somebody who designed the system basically assigned some kind of purpose to that particular system. We are assuming that nobody is going to use that outside that kind of, that particular purpose. I think it has got at least 2 significant security considerations depending on which world view or which perspective do you choose. So if you choose the kind of the view of the system as a purposive system, the thing that you just assign some kind of purpose to that and assume that everybody's basically going to look at the system from that particular kind of perspective and use that system in a particular way that it's designed for, there is an assumption that you are basically, you're neglecting some of the threats that come outside your threat model. You're basically, some of the things that you are, you think that this system is not designed for this particular case, but people ultimately find a way to use it in that particular, if they found it useful. So the assumption that user will adapt to use the system in a way that it is designed for, is often not true. You often, in reality, what happens that people find a way to use the system in a way that works for them, in a way that they, it does the job.

**32:05 Robert Hurlbut:** Yep.

**32:06 Mehran Koushkebaghi:** So that's, that's a notion that basically proves that most of the systems that you're dealing with are socio-technical. They're not just purely technical systems. And they are, that's not something, if, if we look into that just from the kind of technology perspective and we try to basically just assign some purpose to them and basically expect the users to use that in a certain way, we are just going to lose or neglect some of the kind of threats that are in the system basically as a whole. So yeah, that was the kind of the thing about— so that was the kind of the— what I wanted to talk about, the kind of the system boundary, the distinction between socio-technical and technical system and purposeful versus purposeful system. Now, if you want to just talk about the kind of the concept of the vulnerability in that context that you just mentioned, I think that there is a distinction there that from the kind of the ontological point of view, it is important to talk about that distinction between syntactic and semantic vulnerabilities. So when we're dealing with syntactic vulnerabilities, we are, we are talking about the vulnerabilities that are, uh, we are expecting the implementation to follow a particular rule or a particular pattern, and we are then, we are not seeing that particular pattern. That leads to the kind of a syntactic vulnerability. So there is a, there is an assumption that there is a particular format or a structure that an implementation should have. And if it doesn't follow that particular structure, basically, we are dealing with those kind of syntactic vulnerabilities. So an example would be, so I think if you talk about like input validation or SQL injection kind of attacks, suppose that you have a code, a piece of code, that basically does the input validation for you. And basically, you are— what it does, it basically gets the data from the user and in a kind of those kind of typical SQL injection vulnerabilities that we've seen, it just put together kind of the strings with a string that it gets from the user and passes to the database, which causes the kind of that input validation flaw that can cause the kind of the SQL injection attacks. That is, that is a typical, like, syntactic vulnerabilities in the, in the input validation, because we are basically getting the data and we are basically just forming a SQL query and sending it to the database to, and that's not the form or kind of the structure that we are expecting to see there. And that's something that is, because it's syntactic, it's just about the formal structure. You are supposed to be using, for example, the prepared statement in the kind of the particular language that you're using, in Java language, for example. And if you're not using it, you're just putting together, crafting a SQL statement, you are basically exposing your application, your system to the syntactic flaws there. But I think there's another kind of Another kind of, okay, so before getting there, so these sort of vulnerabilities, just syntactic, most of the time they're easy to find out. So it's easy to find out these sort of vulnerabilities because, as I said, there was basically just some deviation from the form, deviation from some sort of a structure that you expect to see. And there's lots of kind of automated tools nowadays that they can spot those, identify those sort of vulnerabilities. But when it comes to the semantics, suppose that you've got the same application, you're getting some data and you've got, you haven't implemented any kind of input validation at all. So you're getting the data and the lack of basically absence of any sort of input validation in your application. I think I would clarify, I would classify that as a kind of a semantic vulnerabilities. If you have the input validation, but you're not doing the validation in a way that you should be doing that.

**36:28 Chris Romeo:** Yeah.

**36:29 Mehran Koushkebaghi:** That's the— it's kind of, it's not context dependent because input validation should be done in a certain way. And if you're not doing it in a certain way, you're not doing it right. So it's syntactically wrong. But if you don't do this input validation, you never know. So it's the other question that's very, when you should be doing the input validation is quite context dependent. So whether you need the input validation Depends on the kind of the nature of application that you're building, how you define the trust boundaries, where the data is coming from. Do you trust the data on the other side of the thing? This is the kind of the, the vulnerabilities that I call semantic vulnerabilities. So I think they are harder to identify. So most of the automated tools that we've got today, it's quite harder, if not impossible, for them to understand like what are those semantic vulnerabilities and identify them in the system.

**37:24 Chris Romeo:** Makes sense.

**37:29 Mehran Koushkebaghi:** Does that make sense?

**37:31 Robert Hurlbut:** Yeah.

**37:32 Chris Romeo:** Yeah. And I think it's helpful to the way we explored kind of the civil engineering tie-in. That example really helped me to crystallize my systemic thinking when it comes to security of IT systems and And software and whatnot. Like, that was very helpful to go down that path and see the connections between those things. And then also, you know, continuing the systemic conversation of security and then getting into the vulnerabilities here. I think we've covered enough ground for today as far as the depth of conversation, just like the conversation that we had with Mateen. And now I have to go and think about this for a while because it's just a different way. System thinking is a different way that we don't normally approach in the world of security design, in the world of software design. We don't use these. It's a relatively new discipline to most people and applying these principles. So we'll definitely continue to think about it and we'll have, maybe we'll have another episode with you and Mateen together where we can really dive in even deeper. We can do a 201 version of this. This is kind of the 101 version. I feel like I'm starting to The pieces are starting to fit together for me. But before you go, we do have to take you through Robert's AppSec Podcast lightning round, which are just 3 questions that are designed to be answered fast.

**38:59 Mehran Koushkebaghi:** Cool.

**39:03 Chris Romeo:** Oh, and Robert is now officially muted.

**39:05 Mehran Koushkebaghi:** So, oops.

**39:06 Robert Hurlbut:** Yeah. So we have 3 questions. Uh, so we'll just dive in. Uh, first one is, uh, what's your most controversial opinion on application security and why do you hold this view?

**39:20 Mehran Koushkebaghi:** Yeah, interesting question. I think this notion, as you said, Chris, I think it's still this, the notion of the kind of security as a systemic concern is quite kind of new. And some of those things, when often I, when I talk about it in a kind of different setups in the workplace and other places in the wider society, wider community, I still find that some It's, I find it is one of those conversations we need to basically get better at the kind of, uh, talking each other in a kind of the system language. So it's still one of those things that still needs to be kind of developed further and further in the, in the, um, in the wider community there. Uh, I think this kind of security systemic concern is one of the things that's really, I find it really fascinating. I think it's sometimes I find it really controversial to talk about people about these sorts of concepts and think about and talk about the kind of, not just about it, because it's not just about the kind of seeing it as a systemic or versus non-systemic. It has got huge implication the way that we are designing and testing and building our system basically, and adopting that kind of systemic view, something that can help us to build, uh, more resilient systems for the future.

**40:38 Robert Hurlbut:** Okay. Second one is, if you could display a single message on a billboard at the RSA or Black Hat conference, what would it say?

**40:45 Mehran Koushkebaghi:** So it would be, secure the whole, not the parts.

**40:54 Chris Romeo:** Okay. You had a t-shirt, it would be a good t-shirt idea right there.

**40:59 Robert Hurlbut:** Yeah, definitely. Definitely. And the last one is, what's your top book recommendation and why do you find it valuable? It doesn't have to be a security book in particular or technical book.

**41:10 Mehran Koushkebaghi:** Cool. I think I'm quite interested in a kind of system thinking as a practice and how it can help us basically building that mindset of this security as a systemic concern. There are a number of, there are a lot of good books there, so I can name a couple of them. Perhaps the Critical Systems Thinking book by Mike Jackson is a really good one. He's got like kind of a new version of it, is a newer version, which is more about the kind of the practitioner guide. Peter Senge has got a really good book about the kind of, which is called The Fifth Discipline, which is about the kind of the the kind of system thinking, how we can apply it in the enterprise and social kind of setups in order for— it's not about just building software, it's a broader thing. But I think there are lots of things that can be learned from those topics. There's another book, it's an Audible book that I read about the Scott E. Page has got something about the complexity, understanding complexity in Audible, which is amazing as well. It's about the kind of what are the features of the complexity that they need to deal with in a in the complex system, how to build a system to be resilient against all those things. And as always, I think Nassim Taleb is one of my favorite authors as well. I'm sure that you all heard about or read his books.

**42:36 Chris Romeo:** Yeah, they're dense. They're thick books. And there's a, you have to like read a page and then you have to stop and go, hmm, let me think about this for a few minutes. Okay, next page. Like you can't, it's not a, it's not something you just read quickly. I find I have to think about it a lot. So, so Mehran, what's a key takeaway that you want to leave with our audience based on our conversation?

**43:00 Mehran Koushkebaghi:** I think that kind of thinking about the kind of systems, thinking about the security as a kind of a systemic property of the system, thinking about the kind of those kind of the construct that we talked about here, like system boundaries and thinking about this kind of different type of vulnerabilities, they're like semantic and syntactic. Those are things that I think getting to know and having a wider kind of collaboration between the, in the industry around those topics and building a shared kind of language around those can help us to basically adopt those kind of concepts and talk about it in a more collaborative way. So my, my, my kind of takeaway from here is that if we can basically build a more collaborative or probably community around these sorts of things and try to think about, if I'm sure that there are different people in the software industry that come from different kind of backgrounds and different industries, having those kind of diversity set of kind of skills and also kind of diverse perspective in the Uh, in this industry can be really helpful. I mean, I kind of, I came from a kind of a civil engineering, so I'm sure that lots of other people are a different perspective. They can bring in their own value and try to think how we can, how we can use these kind of systemic constructs or mental models to basically build more, uh, secure systems. I think that's probably something that's gonna be quite helpful. And we, we don't probably, we, we don't have the kind of all the methodologies and methods yet. to build that, but it's just one step in the right direction and we can, we can build on top of that, uh, with the help of each other. Cool.

**44:49 Chris Romeo:** Well, Mehran, thanks for, uh, for coming on the show. Thanks for walking us through some of these concepts, which I think we're starting to crystallize, like I said. So, uh, we look forward to continuing the conversation in the future. So thank you very much for being a guest.

**45:03 Mehran Koushkebaghi:** Cheers. Likewise. Thanks for having me.

---

Source: https://appsecpodcast.com/mehran-koushkebaghi-security-as-a-systemic-concern-how-to-develop-anti-requirements/