Matin Mavaddat - Understanding Security as a Systemic Concern: The Role of Anti-Requirements

0:00Chris RomeoMatin Mavaddat is an experienced technology professional with over 2 decades of industry expertise. He holds advanced degrees and roles from software engineer to principal security engineer. He contributes through work, publications, and patents. As the principal security engineer at Amazon since 2021, Matin has developed innovative security solutions for healthcare driven by collaboration, continuous learning, and leveraging technology for meaningful impact. Mateen joins us to explore a definition of security that will have you pondering when you try to go to sleep tonight. He helps us understand the systemic nature of security and the role of the anti-requirement. I've been doing this podcast for 7+ years at this point, and this is one of the interviews that really left me thinking and reconsidering a lot of the things I understand about security.

0:53Robert HurlbutToday's episode is brought to you by Security Journey. Our education platform teaches valuable secure coding skills based on real-world vulnerabilities and threats, including OWASP Top 10.

1:04Matin MavaddatLearn more at securityjourney.com.

1:06Robert HurlbutHey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo. I am the CEO of DaVinci. We are the threat modeling company/platform. And as always, joined by my good friend, Robert Hurlbut. Hey, Robert.

1:32Matin MavaddatHey, Chris. Yeah, Robert Hurlbut. I'm a principal application security architect and threat modeling lead at Acquia. And as you said, glad to be here again to talk about AppSec.

1:42Robert HurlbutI think we're going to go in a slightly different direction than we've ever gone.

1:47Chris Romeobefore.

1:48Robert HurlbutAnd so I'm excited to have Mateen join us here. And Mateen, we always like to jump right in with guests' security origin stories, giving you no time to warm up. We just throw you right into the deep end of the pool. But how'd you get started in security?

2:02Matin MavaddatThanks, Chris. Thanks for having me. Well, it's a very good question. Actually, I started my both academic and professional career in computer science and software engineering initially, actually as a requirements engineer, working as a business analyst for a few years, and then became a systems architect. In 2015, I started working for a bank, and there I realized there was this huge gap in the way that we're doing actually security there. So I started actually delving deep into the concept and kind of trying to become more and more knowledgeable about security, and basically I just started my journey there. Actually, the question I've always had in my head that I was trying to find an answer was that why are we always sort of behind in security? Why are we always kind of cannot kind of achieve all the objectives that we wanted to achieve compared to other disciplines in the kind of computer science And wider discipline for life. And I was talking to different people, different experts at the time. Some people giving me like these interesting notions, for instance, like the fox runs for itself, the hogs for their owners, something like that. Or the asymmetry between defense and offense, and especially in cybersecurity, we have to fix all the problems, but hackers just need to find one and they can. There's a little bit of kind of truth, uh, in, in all of that, but never kind of satisfied really with these kind of answers. And also they're talking about the complexity of the problem, although I'm not really sure that everyone understands the kinds of complexity. But anyway, so I was hearing a lot of, uh, perspectives, but none of them was kind of giving the, giving me the answer. I, I, I, I was thinking it was something that should be more kind of foundational problem with the rarity and security. And then that was the start, start of the journey, actually.

4:17Robert HurlbutSo one, one follow-up question. I read the, the article that is the basis for some of what we're going to talk about. We'll put that in the show notes for folks to see the original source. But my question for you is, has philosophy been something that's in your past? Have you studied philosophy?

4:38Matin MavaddatUh, well, I haven't academically studied philosophy, but I've always been very interested. So I've been kind of reading books, articles, um, I've been— that was part of my doctoral research. I've been working— I've been kind of quite familiar with John Searle's kind of research because on speech act, all those kind of things, because what I was trying to do at the time was to, um, extract business processes from conversation logs or from transcribed kind of conversation logs. So it was a combination of speech act AI, which is, this is 2013. We didn't have many kind of advanced tools and techniques to read. Well, the foundations were there, but we didn't have all the huge computational power that we have today and the amount of data we have today. So just, yeah, that was my kind of interaction with philosophy. Um, and I've always been interested since I was in high school reading stuff.

5:37Robert HurlbutCool. All right, so Robert, let's jump into it.

5:42Matin MavaddatOkay, so you mentioned you were at the bank and you were noticing some things about security, but let's, let's dive into what is your definition of security? Um, okay, great. So this is actually, as I, as I mentioned, like, I was not satisfied with those kind of perspectives. So, My kind of understanding at the time was that probably we don't fully grasp the concept, don't really understand what we're dealing here. Basically, I thought that we were kind of suffering from 2 kinds of fallacies. One that we could call IRED, basically familiarity. We would confuse familiarity with understanding. of the concept. And the other was like, they were confusing manifestations of a phenomenon with itself. Let me explain what I mean. Like, whoever you ask, do you understand lies? They would tell you, of course, you know, they would tell you, of course. And they can easily tell, they can, they'll tell you they can easily tell if something is a lie or not. But usually when you delve deeper, when you just actually then tell them, okay, so can you actually define life? What is life? What is a living being? It would be very difficult for people to come up with precise definition. And they usually confuse, and they usually say they don't understand because they're familiar. They hear it everywhere. They see it everywhere. They confuse this kind of familiarity with understanding. And the other thing is they confuse manifestations of life with life itself. So for instance, if you ask someone, okay, how would you say if someone is alive? So, okay, so if they're talking, if they have a pulse, if they have like, um, temperature, they're alive. But then do you know that something can have all of those manifestations and be completely dead, right? So it's, you would never actually ask a non-experts to tell if someone who is on a kind of hospital bed is alive or not. Because you don't want someone with that kind of notion to make a decision about life, right? But even experts or so-called experts make mistakes about life. This is so— hasn't been very well kind of understood or defined. So I started kind of This is also starting in my kind of work, prior work on requirements engineering, because, you know, as a business analyst, my kind of role was to go and understand the requirements and kind of try to elicit those requirements and help the businesses build system based on those requirements. And I remember at a time, we all, like, we would divide requirements into functional requirements and non-functional requirements. I don't agree with that kind of division at the moment. I think there's a third type, which I call anti-requirements. But security was called a non-functional requirement. A non-functional requirement is basically quality. It's called the quality of the system. So, there are some things that are behavior of the system. And things that are qualities of the system. And the most important thing about a quality of the system is that it's holistic. You cannot attribute the quality to any specific part. It's kind of created from the interaction of the parts. So these are called, like, I'm sure that you've heard of it, it's like called emergent properties of the system. The qualities of the system and some of actually the behaviors as well. I don't want to describe, but most of the qualities are emergent properties. So if we think of security as a non-functional quality of the system, it means that it's holistic and it has some very, very interesting characteristics. So emergent properties have very interesting characteristics. One of them is you cannot measure them directly. So there's no way that you can measure an emergent property directly. Just like life is an emergent property of a living being. That's why we cannot actually have a measurement, but we can only understand it through its manifestation. So we can come up with metrics or things that kind of tell you if something is alive, but having those manifestations does not necessarily mean that they're alive. Correct in one way, it's not the other way. Makes them— so it makes it possible to fake that. Okay, so that's why you can easily have security theater, and that's what they were. Is this—

10:37Robert HurlbutMateen, can I give you a quick example? Let me just make sure I'm tracking with you. So if— let me give you the example of I scan a system, it doesn't have any— the scanner returns no vulnerabilities, so I say hence this is secure. But what you're saying is, in fact, that's not, that's not the case. It was the, the tool. We're not doubting the results of the tool, but it's not the, just the results of the tool that provide the overall answer. Is that, am I tracking the right, am I tracking with you? Correct.

11:09Matin MavaddatSo, so basically it means if a system is secure, it won't have any vulnerabilities.

11:16Robert HurlbutOkay.

11:16Matin MavaddatBut if a system does not have any vulnerabilities, it doesn't mean that it is secure. So it doesn't go that way. That's why it makes it— that asymmetry makes it very difficult.

11:25Robert HurlbutOkay.

11:25Matin MavaddatAnd you can have it in many different kinds of emergent properties as well. Going back to life, if you're alive, you have a temperature, you have a pulse, but the thing that has a pulse and temperature is not necessarily alive. And that asymmetry is very, very important.

11:41Robert HurlbutIs there like, what would you say? So like a plant would be an example of just trying to pull on this thread of this example. So technically a plant doesn't have a pulse, I don't think, doesn't have a heart. As far as I know, most of them don't. Maybe there's one somewhere. And so, but we, but we know that a plant is alive. So we can't say that you like breathe, but technically, I guess plants don't breathe air. They breathe CO2. So it's the, so, so basically that's, but that's what your point is here is like the plant is alive, but it doesn't meet the same criteria as the human beings.

12:16Matin MavaddatDefinitely a little bit different, actually. So it depends on how you define, uh, life. So you can perfectly define life differently, but this is a little bit different. This is like, if you come up with the metrics to measure life, I can go and fake them in a way that you can think something is alive, although they're not. That's, that's what I'm trying to say. So you can say, this is how I measure life, with pulse, with temperature, whatever. But I can go and build a robot, for instance, that you know it's not alive, doesn't have anything. When it has a temperature, impulse and everything, but still not a lot. That is similar. So that's the security theater that we talk about. So if your system is secure, it will show all those manifestations, but I can have it, I can fake all those kind of metrics in a way that a completely insecure system shows all those manifestations, but is actually not secure. That's what I'm trying to say. That's why we have security theater. And the third kind of characteristic of emergent properties is also even more important is that improving the parts from those characteristics perspective does not improve the whole. And usually it makes it even worse. So if you go and improve, this is like in security, it means if you don't improve your components from security perspective, whatever your understanding of security is, even if your understanding is correct, it doesn't mean that your whole system is now secured. And you can see that, and because security is coming from interactions of the parts rather than the parts themselves. And you can see that in many different kind of, an example to prove that, for instance, is that let's assume that we are building a car. I can go and find the best, most kind of performant pieces of the car from different manufacturers.

14:07Chris RomeoMm-hmm.

14:08Matin MavaddatPutting them together, you don't have a car. Because the most important thing about a car is how those parts work together rather than how great each of those parts are. I'm guessing—

14:20Robert HurlbutI like that example. I'm just imagining a pile of parts on the ground. Like, hey, look at my cool sports car. And people are like, what?

14:30Matin MavaddatExactly. And you see that in like, Other examples like football teams, the myriad of stars, and they usually lose to local teams because they're great players in isolation, but together they cannot actually collaborate and work well. So that's another example you can take. And this applies to this concept of security as well. So having these two, these kind of things, It seemed like security as an emergent property, because of its properties, it has caused us a lot of problems. And our approaches, even now, doesn't seem to be fully correct. So we've been focusing on securing the parts. Wherever we kind of discuss things, people are talking about, oh, we need to encrypt things here. We need to— Yeah. I don't know, just everything's focused on the part instead of the holistic picture, understanding what the system is trying to do and kind of enabling it to have to prevent undesirable states. When I was— and so I started kind of— this is like 5, 6 years ago that I've achieved this kind of systemic perspective from security, and they're actually talking about it. And I've had some pushbacks, which, which some of them are kind of interesting and actually have value and meaning. So some people are telling me, oh, so you're saying that fixing the XSS is not important? Are you telling me that, you know, using a PLF that is not vulnerable is not important? Are you telling me that I need— I don't need to scan for parts that have certain known vulnerabilities. And that's absolutely, you know, so they should, we definitely should do that, but that's not what I'm talking about. So I started actually creating 2 different concepts to answer both questions. So I started talking about syntactic security and semantic security. And please don't confuse semantic security with the concept semantic security in cryptography. This is a different, different kind of problem. So, syntactic security is the things that are always correct. So, this is like the box, like, I'm sure that if you've been an engineer, you fully understand what I'm trying to say. So, it's like syntactic flaws versus semantic flaws, right? So, syntactic flaws are the things that are incorrect. So, your compiler really will compile if you have syntactic flaws. Your semantic flaws are things that They're not incorrect necessarily, but they're incorrect in the context. So, so you, you need to understand fully what the context is, what the objectives of your system is, and then, then you can decide if it's a kind of semantics flaw or, or not, if, if it's irrelevant.

17:32Chris RomeoOkay.

17:33Matin MavaddatThe important thing about that is that it's the semantic versus syntactic in security is a little bit different, but generally follows the same kind of pattern. So syntactic security are all the things that are always incorrect. So you never want to have XSS. So you'd never want to have a vulnerable kind of component. And these are the things that we can automate. And these are the things that you don't need really much context to be able to identify. But the semantics security are the things that are very difficult to automate, and there are emergent properties. And that's the kind of systemic security that I am talking about, really. But then there's another kind of part to this as well. So now we have like syntactic security and semantic security. I started thinking about whenever we talk about security, do we actually understand what security, even semantic security is? And I started looking at different people's definitions of security. And the most generic one that I found was to, security was kind of the degree to which it could prevent undesirable states. And there is, this is the commonality between resilience and security is that In security, there should be a malicious intent. So you prevent all undesirable, if you can prevent all undesirable kind of states of system moving to undesirable states, you have resilience. But so it seems like security is a subset of resilience when there is malicious intent. So when there's someone maliciously trying to move your system into the, the, the, the, states that are undesirable. And at the time, I started thinking about, okay, so it seems that security is really not a thing. It does not exist. Because whenever we're talking about security, we're talking about an absence of something else. So, and that's kind of the start. That's when I started thinking about this absent existence phenomenon. or phenomena that is like in philosophy, there are kind of things that they do not have ontological, independent ontological existence. So they don't really exist in reality. So for instance, the example is like darkness. So darkness does not really exist independently. It's the absence of light. Right? So the more light you have, the less darkness you have, and vice versa. So you cannot go and create darkness, you remove light. And there are many other examples that they have absent existence, but it's very important not to confuse a lot of other kind of concepts as absent existence. For instance, some people, they think war and peace are absent. And that's absolutely incorrect. War is not the absence of peace. War, they're completely different. They have independent existence.

20:58Robert HurlbutWell, there's independent choices that drive it, right? Like darkness and light, there is no, there's no independent choice that drives it. It's, it's just, it is. And I'm with you on that. Like darkness is the absence of light, but war is not the absence of peace. War is a choice by Many different, I mean, many different variables play into there.

21:19Matin MavaddatBeautiful. Exactly. Just like, like hatred and love. Love is not the absence, but the important thing about the things that are not absent existence is that you need to put energy, as you mentioned, and decisions to make one possible, even if you remove the other one. But the good thing is security is that it's, it's not actually doesn't seem to be the case. It's like if you focus on removing those undesirable states or preventing your system to move to those undesirable states, you basically, basically security emerges. That's the kind of emergence. So it's like, it doesn't have an independent, so you don't have to go and put energy into creating security. As long as you go and put energy to understand what those undesirable states are and then build mechanisms or design your systems in a way that does not even have those undesirable kind of states, or there are controls that prevent the system to go into those kind of undesired states. And that's what I call an anti-requiem. So that's what those That's why I think the focus on anti-requirements are important, because they're not really the opposite of the requirements. And the interesting bit about anti-requirements and requirements is that unlike the security, they're not— anti-requirements are not absent existence. It doesn't mean that if you work on requirements, you automatically won't have any response. And I give you an example, like this, uh, genie in a bottle that we've heard a lot about in stories is like, you go and tell it what you want, but you don't tell it what you don't want. You just say, I want to be rich. And then what it does is that it goes and fills your house with pennies and with jewelry because you wanted to be rich. You didn't tell it that you not you know, make me rich by, you know, killing me or even, you know, stealing, whatever. These are the agile requirements. So, the requirements, focusing on requirements does not prevent agile requirements. We need to think in both terms from the outset. And this is kind of my way of kind of understanding shift left as well. So, it's like, if you want to really shift left, it means that at the beginning, when you're working on your BRD, start thinking about what your system needs to do, as well as what your system should not absolutely do.

24:01Robert HurlbutAnd so that— Is that the definition of anti-requirement then? What your system should not do. So defining what it should not do.

24:08Matin MavaddatExactly. Absolutely. And the, the, so just like requirements in complex socio-technical systems, we have indefinite number of requirements. So we prioritize.

24:22Robert HurlbutRight?

24:23Matin MavaddatThe things that we want to build. The standard anti-requirements, we need to identify them and prioritize. I know that. And that's why absolute security is impossible, because absolute security means knowing the absolute number of the anti-requirements. Anti-requirements are by nature, in complex systems, indefinite, because you don't know all the states that you don't want, or all the bad, undesirable behaviors of your system. As you don't know what the desirable behaviors are. And because it's so subjective and so context-sensitive, that with small changes in the context, some of the anti-requirements become requirements. And that's the kind of, you've heard about, like, bug as a feature, right? So, this is some sort of same concept. So, things that are anti-requirements in one system are absolutely requirements in another. Even depending on how your context is changing, again, the same thing can happen. So even absolute security does not even— is axiomatically incorrect. So it doesn't even make sense because it's subjectively relevant. Okay.

25:33Robert HurlbutSo I'm going to ask you what I think of as the million-dollar question now, which is, how do we make this, everything you've just described, a reality? in the average technology company out there? How do we take the things that you've unplugged and unpacked here and make them work in a resource-constrained environment where they're not going to agree that security is the absence of vulnerabilities?

26:02Matin MavaddatI think it's not actually that difficult in my opinion, because We are, we've learned how to focus on requirements. The message that I have is that if from the outset, as we are building this, as we are designing this, as we are thinking about the system that we're trying to build, and this is not just software, it's a system, the whole thing, including your operations, your people, everything is a socio-technical system that you're trying to build to realize some business objective, start about the things that you definitely want the system to prevent. Because without that thinking, it won't prevent them. The interesting thing about systems are that they do what you've designed them for. And if you don't take into consideration the things that you don't want them to do, they will definitely do them. Or in most cases, they will do them. So it's not really a very technical concept. It's not really, doesn't need a lot of expertise. As you just get together in a room discussing your requirements, again, I've been a business analyst for a few years. I know this is like, it's not a very difficult thing. You just bring people together and discuss it. I think, start thinking about, okay, so I want this system to have this behavior. What are the things that I definitely don't want it To realize what are the things that I, if they happen, they will break my business. They can be even business and then design their system in a way that if you can, does not even have those states. And I can give you an example, very kind of, probably, I apologize, it was probably trivial, but just, I think it might kind of make it work. So initially when people were like, creating meat, automated meat grinders, they didn't think that they don't want the meat grinder to grind hands. So what they did was that they created this thing that would grind meat for you, but then it would happily grind your hand as well because they hadn't, you know, had that in, but they hadn't think about it, thought about it when they were designing the system. Then what they did for a few years, I remember this actually, they added controls, which are like your sensors at the entrance. So what they would do was that, okay, so it would sense if something, blah, blah, blah, that looked like a hand, temperature, whatever, they had all this kind of interesting stuff to detect the hand and stop the system from grinding. And the problem, we all know what, you know, it's like, The sensors are faulty, they eventually fail, whatever. And so they kept grinding. So what they did was that they got together and thought, okay, so what did we do? We should just like rethink the whole thing. They made a small change, which was, okay, do we really need this wide entrance to the meat grinder? Can't we just like— it's a meat grinder, it's not a meat cutter. So we can ask people to just cut things in smaller pieces and put them so that they The hand wouldn't even fit. With that small design, having requirement and the energy requirements, like, okay, I want meat grinder, I don't want it to grind hand, they'd build something simple. It doesn't have all those kind of complex technology sensors, but it would definitely meet the objectives and both requirements and energy. This is, this is the kind of a mindset change. It's not, it's not a very kind of, it's not expensive, it's not time-consuming, it's just the way that you look at the problem.

29:47Robert HurlbutI see the challenge here, Mateen, is people that aren't going to have a catalog of anti-requirements. And so I think about, like, I know, and I want to get into threat modeling next, because I think there's, I think you've written on threat modeling, so there's got to be a connection to threat modeling in this, in this journey we've been on here. But let's talk about the challenges of teaching people to unlock anti-requirements, because we have the same problem in threat modeling. We use things like STRIDE, for example, the best possible way to get people started in threat modeling, because people don't, you can't, you can't expect a developer to go, to look at a diagram and go, yes, there's this problem and this threat and this threat and this threat. We have to give them a mnemonic and let them learn using a simple approach. And then we have some, we can give them some more detailed approaches to do it. And then over time, they get to the point where they think like we do as security people, where they're just like, ooh, they just look at something and they see the threats, but we don't get that by default. So how do you get people to, how do you, how do you get people to see the anti-requirements in the very early times using this new approach?

30:54Matin MavaddatYeah, absolutely. So there, I think there are 2 things we are doing, uh, and I've started actually working in One is in every kind of sector, you can actually have a preset of things that people can think, can ask themselves from the outset. So when they're, just like the requirement stuff, if you're building something in healthcare or in payments or whatever, there are certain things you need to take into consideration. But the problem is that security is very context, again, sensitive. So you can never have a complete set, but you can have a set of things that makes people start thinking in those terms. And usually people who are familiar, more familiar with their own business or things they want to achieve, their own sector, they actually, this is based on my experience working with a few kind of product directors that when you give them some of the kind of entry points of these are kind of things I'd like to think about, they actually start coming up with more and more and more. And that's actually, this approach has been successful. Because I've seen it. It's just, they just need that kind of initial push, and then they start thinking those terms. And then they, just like the requirements, they come up with these kind of Android requirements from the outset. And again, because it's an iterative, just like anything else, it's an iterative process. So you might need to just start with those kind of most important things that come into your head at the beginning, and the next kind of phase, you come up with more, and then you try to Sometimes you can actually build a system with those entry requirements, and sometimes you need to add controls. And there's, you know, if you can re-engineer, you can go just like the referring, something you might need to go re-engineer the whole thing so that because you just thought about a new entry requirement. But I think it's really not as kind of difficult as it seems. That's one thing. The other thing is, even if it is, we are spending a lot of money and kind of effort and kind of on security. I think we should shift that towards this. And the reason is that this will be the part that if you kind of spend more time and energy on, it will probably, this is my perspective based on all the kind of years of thinking about it and research and whatever, this is the part that can actually achieve some, help us achieve semantic security. as an emergent property. Anything else will be syntactic security. We can solve these kind of small vulnerabilities problems here and there, but it cannot give us that holistic kind of security that we are after, or we've been after for many, many years.

33:28Robert HurlbutSo what happens, here's another million-dollar question. I often think about, in the context of threat modeling, when I go in and I start working with a company, And I'm like, would've been great if I'd have been here 15 years ago when you started this company. Because then we go through a process of saying, how are we going to retroactively try to threat model the most important assets inside of the application portfolio, knowing full well that we're never going to get to 100% coverage? Whereas if we had started from day one and said, threat modeling is a foundational principle of how we build software here, and hardware, and we do threat modeling for everything, there would be a lot smaller delta if I walked in 15 years in the future, right? From when that decision happened. All of that to say, how does this strategy, philosophy, approach that you're describing work in the real world where people have already, you know, many ships, application and product ships have already sailed and they're, you know, maybe towards the end of their journey? Like, how can you apply this philosophy retroactively to existing software?

34:42Matin MavaddatYeah, so legacy complex software is always a problem. And the problem, yeah, I totally acknowledge that. And the problem with our kind of discipline is that today's novel ideas are tomorrow's legacy, right? So, and the pace is so fast that you can always— so that's why I'm not actually discounting the kind of idea of syntactic security. So one thing that we are trying, so my focus, I've got other articles talking about what can be kind of automated in DevSecOps. And I think this is, the more we can automate the syntactic security, the more we can spend on semantics. And this is what I'm trying to say.

35:27Robert HurlbutYeah.

35:29Matin MavaddatMost of our efforts as kind of external, as consultant, a security expert, whatever, that when we join a team, is spent still on syntactic security to identify the vulnerabilities, the problems that they should really be, you know, should be written. We should have tooling for them so that we could just easily find them and fix them. So there shouldn't be any, any real, real kind of mental energy spent on those kinds of things. So it's in reality, I think we need to spend some as a discipline, make sure that we have all of that part fully automated so that when we kind of join this, this kind of new initiative that already got something, they were already at the end, basically, as you mentioned, the end of the journey. We apply those tools, identify all the syntactic security matters, make sure that there's nothing syntactic flaws in their systems, and then start talking to them in the meanwhile. Because one thing that I've learned is that unless you understand the business well and the kind of system they're trying to build well, you cannot actually provide them with good solutions from a semantic security perspective. And that's, that's why I think we need to schedule this kind of sessions, workshops with them to work on entry, just like what we did with 3Commas when we want to kind of build the system, to understand the entry costs, what is absolutely important for them to, to, to prevent. As I've said before, most of the time, my, again, experience has been it's possible to find simple tweaks in the system in a way that it automatically prevents those kind of bad, undesirable behavior. Let me give you a very quick example. Most of the problems we have, not most, some of the problems we have is in the authorization mechanism. So, so it's like—

37:33Robert HurlbutRight.

37:33Matin MavaddatThey do have an authorization system. It's not about the technical capability. So if we fix the syntactic issues, for instance, if you know that you've implemented your OAuth 2 correctly, your OpenID Connect, I'm sorry, correctly, if you have, if you use your crypto libraries that are secure, if you scan your containers, you don't have, you know that they're not, they have no vulnerabilities or anything. So the technical foundation is there. The problem is they don't know who should have access to what. And that really depends on the context of the business. And this is something that even if a system is already there, a little bit of kind of understanding and consultancy, understanding the enterprise requirements, what they want to achieve, what they don't want to achieve, can help configuring their systems in a way that would definitely achieve what they want to achieve. So it's not really, so that, if that, you know, the authorization mechanism is syntactic, The authorization policies and rules, in my opinion, are semantics. And these are the kind of things that you need to focus on. That doesn't matter if they're at the end or beginning, whatever. When I started project here, where we start with kind of that early on, we start from, okay, what are the policies that I need to implement? Because it has an impact on the kind of authorization mechanisms that we want to use as well. So sometimes you don't need this kind of full-fledged attribute-based access control ever, because you can make, you can have a much cheaper kind of solution that solves that problem. But if it's already happened, there are ways to configure it to your advantage.

39:17Robert HurlbutSo paved roads, the concept of paved roads—

39:20Matin MavaddatThat's what I keep thinking of as well.

39:21Robert HurlbutPlay into your approach here, like with authorization.

39:26Matin MavaddatYep.

39:27Robert Hurlbutto, if security is the absence of vulnerabilities and we're focused on raising this stack and getting out of the syntactic type of things into the semantic things, paved roads, uh, like providing an authorization system and library and everything locks right in step with what you're describing here.

39:47Matin MavaddatAbsolutely. I think, I think we're getting better from that perspective. So we now have like these libraries that are available for people to use. We have like, no one, no one, you kind of cook up their crypto any longer. So we have like secure crypto libraries that people can use. Containers, we have pre-configured, pretty secure. For syntactic security, I think we are doing a good job generally in security. But the problem is, and that, but because the focus of security industry discipline has been on the syntactic security. But the reason we haven't been able to achieve what we wanted to achieve holistically has been neglecting semantics. That's what I'm trying to say. Absolutely. You're absolutely right. So paid paths, paid frameworks, whatever we call them, they're called in different kind of parts of the industry, secure, We need, you know, CDKs, whatever, you know, the things that AWS provides, secure architectural kind of frameworks, all those kind of things are great. We should definitely take advantage of them. They give us syntactic security. Then we need to focus on semantic security. Okay, so now I join your initiative, I need to understand what you're trying to achieve as a business and try to help you to understand your requirements and anti-requirements, and then try to configure these PaaS paid frameworks in a way that, you know, achieve what you want to achieve.

41:26Robert HurlbutAll right. Well, I think we gotta, we gotta move on to our lightning round, but I gotta say, Mateen, this has been a fascinating conversation. Uh, my brain is churning away here and processing these concepts and ideas, and I'm still stuck on, is security the absence of vulnerabilities? And like any good philosopher, I don't need to have an answer yet. I'm going to need to ponder it for another 20 years, and then I'll get back to you. Um, not really, but I'm going to think about that one some more because I'm not fully bought in on it yet. I'm not, I'm not saying I'm, I'm, that you're wrong. I'm just, I'm not, I've been defining security so differently for so long that I really have to spend some time pondering it, thinking about it, and seeing if, if I— seeing if it lands for me after a day and a week and some time in the future. But, uh, but excellent conversation, excellent, uh, it's been an excellent topic. But Robert, we're not done yet. We got to take Mateen into the lightning round, so take it away.

42:23Matin MavaddatAll right, Mateen, we have 3 questions that we usually ask. So the first one is, uh, what's your most controversial opinion on application security, and why do you hold this view? Oh, okay. So I think that's a very interesting question. I think the whole, you know, as Chris mentioned, I think just anti-ballroom kind of concept has been quite controversial. And even the systemic security has been controversial. As I mentioned, there's been a lot of objections to the nature of security as I defined it. and I've been talking about it because, you know, again, people talking about syntactic security not being necessarily an emergent property because you can identify things in the components and fix them. And again, as an answer to your requirements, there've been 2, they've been controversial from 2 perspectives. First of all, it's a new term, and I've specifically used that, a new term, to make people stop and think. Because then, again, to break that thing that I mentioned in the beginning, like familiarity, confusing familiarity with understanding. Because when you use terms that people have heard a lot, they think they understand it, so they don't think about it. So when you talk about threat modeling, resilience, security, just people go, okay, it's like, yeah, of course we know what resilience is. Ask any engineer, and that's not a dirty understanding, of course, Where's a part of it is bread, bread or butter, you know. But then you met— when you talk about anti-response, everyone said, what? And they start actually thinking and arguing, and which is great. I don't mind this. I love that, you know, the conversation. Just like I love to hear from Chris that he finds out that, you know, this is not very correct. And that's always been, you know, I've been trying to kind of solve this problem all the time. So initially I thought that security is just a kind of emergent property, but then I realized actually security probably is not even a property itself. So it exists in the absence of something else. So these are kind of things that, as Chris also mentioned, like this constant thing and try to correct yourself or find new ideas that could complement or kind of contradict. And that's the whole thing about science. And there is no religion, right? You don't, you don't. I'm more than happy to contradict myself next time we talk. I was completely wrong. So these are this. This is not— this is, this is the whole, the beauty of kind of thinking and being able to correct yourself and build new stuff.

44:55Robert HurlbutYeah.

44:55Matin MavaddatAll right. Next question is, if you could display a single message on a billboard at the RSA or Black Hat conference, what would it say?

45:04Robert HurlbutI already know what he's gonna say, but I'll, I'll tell you if I— I think I know what's gonna go on that billboard.

45:12Matin MavaddatI would say security does not exist. Long live anti-recallment. Okay. That's not what I thought.

45:18Robert HurlbutI was expecting you to put security is the absence of vulnerabilities, but security does not exist. That feels like we're in The Matrix all of a sudden. Like, right.

45:27Matin MavaddatYeah. Because again, as I was talking about security, there's, it might at the moment at least, but my understanding is that security does not exist as an independent kind of phenomenon. So it's an absent existence. That's why I say security does not exist, and then independently. Okay. All right. And the last one is, what's your top book recommendation and why do you find it valuable? Well, I generally like, this is not really a security book, but I've learned a lot about it. So generally, there are 2 kinds of Any book that is about systems thinking, I really think people grab and read. There are many of them at the moment. I don't really want to kind of recommend one. So if you just look on Amazon and search for systems thinking, you can find A lot, a lot. And the books that they've written by Russell, you know, Ackoff, I really like. And his— these are all in systems thinking. And his kind of student, Mehdi Kirochadobi, again, it's a little difficult to— so his name is Persian, so it's difficult to search. But, you know, you can You can definitely find them if you just search for Russell Ackoff's student book, something like that. You can find that. And I generally like Nassim Taleb's kind of books like Black Swan and Skin in the Game, Randomness. What was the name exactly? I don't remember the exact name of the— All his books are, I think, really, really interesting. I really enjoy— I read most of them a couple of times actually. And each time I read them, oh, Antifragile was also very, very interesting. So, um, so I've been, I've read it a couple of times. It's just, you can learn a lot from them. And they're, they're not directly about security, but I think they're very, very relevant.

47:41Robert HurlbutYeah. Yeah, I agree. I, I've read some of, uh, Taleb's books and they're just so dense like that it's, you have to stop and think about, like, you can't read them Quickly. You kind of have to read some, then you have to like spend some time processing it away from the book. It's so strange. Like, I don't— very seldom do I have that experience with an author where normally I read pretty quickly and I just kind of blow through things. But with him, I'm like, wait, what? Sometimes I got to go back like and read the paragraph 2 more times to be like, what?

48:13Matin MavaddatWhat are we talking about?

48:14Robert HurlbutYeah. Okay. Got to ponder that for a while. All right, Mateen, what, uh, what would be your key takeaway? For our audience here?

48:22Matin MavaddatWell, I think the most, I think, important message I'd like to share with everyone is that start thinking about the anti-requirements from the outset, the things that you don't want your system to realize when you're thinking about the requirements. Do not ignore them. Do not leave them to later, because it'll get more and more expensive as you kind of, as time goes by, and to fix the problems that are caused by engineering problems. So whatever you want to call them, undesirable behaviors, security requirements, whatever they are, start thinking about them from the outset. And that's the message I'd like to share.

49:11Robert HurlbutExcellent. Mateen, thank you for sharing these concepts, this knowledge, this wisdom with us. Like I said, you've given me plenty to ponder. So I'll, I'll be doing that over the coming weeks, thinking about all of these things. Sounds like you need to write a book.

49:26Matin MavaddatYes.

49:26Robert HurlbutPut all this stuff down into a book so that people can digest it. Try to make it like a Taleb book where it's so dense that people have to read a page and then go sit in the woods for a while and stare up into the sky and ponder the content. But no, for real, this would be, you should write this down. You should put it in a book and systematize this whole thing in such a way that people could understand it. Because there's a lot of new stuff here. There's a lot of, you're challenging our thinking on something as core as what is security, which people are going to need to digest that and to kind of come around to it. So. But yeah, thanks for taking the time to be with us. It was an excellent, excellent time. I look forward to a future chat where we can talk about something else philosophical about—

50:13Matin MavaddatThank you very much, Romain. We enjoyed our conversation.

50:16Chris RomeoThank you.

50:18Matin MavaddatGood time. Thank you.