---
title: "Joern Freydank -- Security Design Anti Patterns Limit Security Debt"
url: https://appsecpodcast.com/joern-freydank-security-design-anti-patterns-limit-security-debt/
date: 2022-01-25
duration_seconds: 2207
season: 9
episode: 14
guests: ["Joern Freydank"]
topics: ["Threat Modeling"]
audio: https://www.buzzsprout.com/1730684/episodes/9942992-joern-freydank-security-design-anti-patterns-limit-security-debt.mp3
video: https://www.youtube.com/watch?v=7LtZSZgDIuI
transcript: true
---

# Joern Freydank -- Security Design Anti Patterns Limit Security Debt

*January 25, 2022 · 37 min · Season 9, episode 14*

with [Joern Freydank](https://appsecpodcast.com/guests/joern-freydank/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/)

[Audio](https://www.buzzsprout.com/1730684/episodes/9942992-joern-freydank-security-design-anti-patterns-limit-security-debt.mp3) · [Video](https://www.youtube.com/watch?v=7LtZSZgDIuI)

## Show notes

Joern Freydank is a Lead Cyber Security Engineer with more than 20 years of experience. He is currently establishing the Threat Modeling Program at a major insurance company. Joern joins us to talk about security design anti-patterns. He defines the term, explains security debt, reviews the categories of anti-patterns, and walks us through the example of a common role misconception. We hope you enjoy this conversation with... Joern Freydank is a lead cybersecurity engineer with more than 20 years of experience. He's currently establishing the threat modeling program at a major insurance company. You're about to listen to AppSec Podcast. When you're done with this, be sure to check out our other show, High Five.

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

About Security Journey  
Joern Freydank is a lead cybersecurity engineer with more than 20 years of experience.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Joern Freydank:  
→ [Security Design Anti-Patterns -- Creating Awareness to Limit Security Debt (YouTube talk)](https://youtu.be/o_Wq7Ga4M-0)  
→ [Stack Overflow](https://stackoverflow.com)

Mentioned in this episode:  
→ [Security Design Anti-Patterns -- Creating Awareness to Limit Security Debt (YouTube talk)](https://youtu.be/o_Wq7Ga4M-0)  
→ [Stack Overflow](https://stackoverflow.com)

Chapters:  
00:00 Meet Joern Freydank: Security Design Anti Patterns Limit Security Debt  
03:04 You came to security from more of the breaking perspective  
04:37 One of our topics that we're going to be talking about  
07:19 It's missing pieces versus bad architectural decisions that are being laid  
10:53 That's one of the things that, you know, I think about  
13:11 Yeah. And I was thinking a similar, the trade-off with also  
17:58 Talking about roles, we mentioned roles. There's a malicious insider admin  
20:15 Yeah. And you think about the couple of examples you shared  
21:49 Yeah, occasionally. Certainly. I mean, like you said, mostly from the  
25:04 What's the corresponding pattern, essentially  
27:13 As we start to kind of bring this conversation towards a  
31:04 There's an awareness— I mean, there's an awareness play in that

## Transcript

*5,754 words · assemblyai*

**0:00 Chris Romeo:** Joern Freydank is a lead cybersecurity engineer with more than 20 years of experience. He's currently establishing the threat modeling program at a major insurance company. Joern joins us to talk about security design anti-patterns. He defines the term, explains security debt, reviews the categories of anti-patterns, and walks us through an example of common role misconception. We hope you enjoy this conversation with—

**0:26 Joern Freydank:** Joern Freydank.

**0:30 Chris Romeo:** You're about to listen to AppSec Podcast. When you're done with this, be sure to check out our other show, High Five. Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I'm the CEO of Security Journey and co-host of podcast as well as application security lover. Robert Hurlbut joins me today as well as my co-host. Hey, Robert.

**0:56 Robert Hurlbut:** Hey, Chris. Yeah, it's Robert. a threat modeling architect, and also a lover of application security.

**1:01 Chris Romeo:** Another t-shirt we should have. We need a t-shirt archive. Like, I don't know, there's so many things we say on this podcast that feels like they belong on t-shirts. I fear that nobody would actually buy one though, but maybe other than family members would buy one.

**1:17 Robert Hurlbut:** Small market, but hey, great ideas.

**1:20 Chris Romeo:** We're joined today by by Joern Freydank. And Joern is a person that I got connected to through OWASP's global conference. And I was going through and looking at some of the different talks that were happening, and I read his title, I looked at the slides, and I said, this is somebody that the application security audience wants to hear from. But Joern, before we get to our topic at hand, we have to always start with our guest's origin story. So, how did you get into this crazy, wild world of application security?

**1:57 Joern Freydank:** Yeah. Well, thank you, Chris and Robert, for having me on the podcast. So, I started out end of the '90s as a software cracker. Of course, you can't really put that in the resume, but that's how I started out, by removing basic dongles from software and trained myself on the most expensive software then, And one of the software programs, I showed this to my colleague, well, my college colleague, and he became a manager on a security project that developed this FIPS 140 certified hardware module that contained money for franking machines, for stamps. So that was at that point they developed a module that contained up to $1 million and that was US certified by the Postal Service. And that got me in the door of the, the security space because that was different than everybody was expecting at that point. I was like all open, not all secure, like no secret. And I got my head and my start in the security world based on that project.

**3:04 Chris Romeo:** So you came to security from more of the breaking perspective?

**3:09 Joern Freydank:** I did. I did. Yep. Reversing assembly language, reversing code, looking at What is there? Knopping out go/no-go points, things like that. And then I shifted into—

**3:24 Chris Romeo:** Now, can you write assembly today still?

**3:27 Joern Freydank:** I don't know. That ability depreciates over time, but I was able to read a lot in a very fast way. That is more like that. Not sure if I can still do it. I didn't try.

**3:40 Chris Romeo:** Yeah, I've never been able to write assembly, so probably not even read it either. But so how'd you go from hardware to AppSec then? How'd you make the transition to software?

**3:51 Joern Freydank:** Well, this was a C/C++ project, so it was software and hardware both. And then it was early 2000s, I switched to the bank in Germany. That's where I'm originally from. Worked at a finance portal and then backend system for ATM manufacturers. And then actually moved to the States and there was this, what I consider the Silicon, the Death Valley of security, nothing really going on until mid-2014. In between, there were little on and off projects. And then I got working for a company that did data analytics and that morphed into a cybersecurity platform. And since I had security in my resume, a lot of companies and projects picked that up from there. So that's how I made the transition into that space. And with a developer background, that's, you know, was prone to do AppSec.

**4:37 Robert Hurlbut:** So one of our topics that we're going to be talking about today is anti-patterns or security anti-patterns, design anti-patterns. Could you help us understand, our listeners understand, what is that? What is a security design anti-pattern?

**4:51 Joern Freydank:** Yeah. So, similar to when developers go out and fetch some code off Stack Overflow, for instance, with all the vulnerabilities in that, like how to make something run, there's another level to that. And that is that they also copy-paste setups or patterns on a higher level, architectural patterns. Between teams or projects, or somebody names something on the internet, how certain things are done. And with that, they also copy-paste the potential flaws and the things that need to be fixed in those projects. So that's a higher level. Patterns, same thing, copy-paste or copying how certain things are done. And then the problem that we are facing is with the open source that they usually stop at very, you know, once they run, like on the very minimal level, and like authentication, for instance, and they don't go deeper because that's not what they're intended to address. And that's usually the level of setup that you would typically see when developers use certain setups of components that they're hooking together.

**6:02 Chris Romeo:** So when I think Stack Overflow, and because you mentioned it, I'm gonna use, kind of draw out that example a little bit more. I think one of the big challenges with Stack Overflow is that the code that gets copied and dropped into production applications at the end of the day has been known to have various flaws and vulnerabilities in the code that's put on Stack Overflow. There's a few academic studies even that have gone out and looked at this and said, you know, just because something's the highest voted doesn't necessarily mean it's secure.

**6:32 Joern Freydank:** Correct.

**6:34 Chris Romeo:** And they've got lots of data to back that up. So, you're saying from a security design anti-pattern is the same thing. So, developers are going out and finding architectural blueprints, for example. But so, what you're saying though is that those are flawed blueprints that they're finding and then they're building on top of.

**6:54 Joern Freydank:** 2 areas. They might be flawed a little bit, but they're mostly lacking certain things, right? They're not fully considering all the security variations that we would have to consider because when they look at the blueprints, The biggest documented area is how to get this running, right? So, the system that they're looking at in the blueprint, not how to get this running in a secure way with all the variations.

**7:18 Chris Romeo:** So, it's missing pieces versus bad architectural decisions that are being laid out on the page. It's just that the architects who are the source for these aren't even considering security, and then developers are grabbing those and running with them. And so, they're ending up with something— it's the age-old problem of, like, you know, where do security requirements come from and how do they fit in? They don't get considered early in the process. Something gets built. It doesn't take into consideration the basic security functionality that we need.

**7:50 Joern Freydank:** Yep. That's the missing part. And then, it becomes painful later on, you know, when they have to fix it, right? That's, you know, the missing features, basically, right?

**8:01 Robert Hurlbut:** You know, when I think of that, one example I think of for a design pattern, a security pattern, and then anti-pattern. Pattern is you always authorize after you authenticate, so you don't just assume that authentication is enough. And the anti-pattern is you do. That's enough. I've authenticated. That's basically the same as authorization. Let's go on. And so, you can get yourself in trouble by simply missing, as I understand how you're defining, missing some key aspects. And so, what you think may be enough for a secure design is not simply because it's not correctly implemented or thought through and followed through on all the missing pieces that need to be in there.

**8:48 Joern Freydank:** Yep, exactly that. Yep, agree.

**8:52 Chris Romeo:** So, you also talk about security debt. And so, this is one of those terms, it's one of those loaded terms, right? Because it's technical debt, security debt, people throw it around all the time. And one of my concerns with these types of terms is I don't think people are always talking about the same thing. And so, when you think security debt, what's your definition of that? And then where does security debt come from? What are the sources?

**9:18 Joern Freydank:** Yeah, so I— when I talk about security debt, I, I'm considering features, the security features for the system. So I'm looking at a system, and I'm— my frame of reference that the business— businesses implement, or business systems implement business functions, and the security then prevents threats to those business functions. And the implementation of those controls which is control is like a feature, right? The mitigation of those threats is a control implementation. When you delay this implementation though over time, you're owing a workload item to the system to be implemented to make it function properly. Now in the beginning, this might not make much of a difference, but then if the whole business unit grows or the system grows, that might have a big impact up to the point where you have to throw the whole thing away and redo design the whole system because you can't retrofit it anymore. So the retrofitting piece is actually the key point that, you know, if you have debt, you may not be able to retrofit it. Or worst case is like the bankruptcy case or the equivalent is that management goes and asks, how long does it take to fix something? And developers say, well, it takes too long. Well, it takes long. And then they come up with their own conclusions and say, well, this tech stack is something we can't fix, maintain anymore. And they throw it out, spinning up like a parallel project with the next promising tech stack and switching the whole team out.

**10:52 Chris Romeo:** That's one of the things that, you know, I think about, and you just got me thinking about this in more depth. I'd never really thought about the fact that security debt is something, or technical debt even, is something that could eventually like die on the vine almost. I guess I'm an eternal optimist. And so I'm thinking like, if it's security debt now, we'll eventually, we'll eventually take care of it over a certain period of time. And maybe that's an infinite period of time. Maybe that's the problem with me as an eternal optimist. The line is infinite to when we actually can close all that debt. But you're making me think about this a little differently in that there could be a time where we just declare security debt bankruptcy, or security bankruptcy, and we throw everything out. But it almost seems like, are we any better with the next tech stack, though, in your mind?

**11:38 Joern Freydank:** Sometimes. Sometimes you are, because some of those issues can be addressed as a blanket pattern in newer tech stacks. Think cross-site scripting, for instance, in Java, or JSPs. It's a custom implementation. In other languages, that's built in. So, yeah, there are certain things, of course, that can be used in a newer tech stack. But then there are other things like Go, for instance, that doesn't have a versioning system. in terms of vulnerabilities. Well, now they do, but that could also mean they're revisiting older issues that have been addressed in other languages or tech stacks before.

**12:17 Chris Romeo:** Yeah. So, you almost end up with some trade-offs there between new tech stacks that are gonna be able to eliminate some of your old tech debt, but you also have a scalability problem. Because if we're talking a team, you know, engineering team size of 10, we can do anything. We can throw the tech stack out and we can rewrite this whole thing in Go by the end of the week. If you're talking about a 25,000-person engineering team, it's gonna take us 10 years to migrate to some other new upstanding language that has better solutions and things. So there's definitely trade-off there between scalability and Being able to just declare security debt bankruptcy.

**13:03 Joern Freydank:** Correct. Yeah. And that has to be baked in upfront, right? That's why this whole threat modeling thing, think through it at the beginning is so important.

**13:11 Robert Hurlbut:** Yeah. And I was thinking a similar, the trade-off with also risk. What's your acceptance of risk as you go along and you know that you can't fix that security debt or you're not fixing it, then you are potentially increasing your risk. as you go along, or accepting risk as you go along, more risk as you go along. A recent talk that you did, you listed some categories for these anti-patterns. Could you help us understand some of the ones that you've identified?

**13:44 Joern Freydank:** So, in that OWASP speech, I was talking about, I grouped the patterns according to certain themes. And one is the Common role misconception is one that I started out with because it covers a lot of other patterns, technical patterns. Then authorization anti-patterns, and something has to do with time, timing, or time-related anti-patterns. And then systems that don't mix well and scalability anti-patterns. So that's, um, that's— those are the areas. I'm sure there are more, and I know some more. I would— but that was kind of the scope of what I was talking about.

**14:17 Chris Romeo:** So, to ensure our audience has a perspective on kind of what these things are, give us, like, a 1 or 2 sentence definition of each one of these, starting with common role misconception, and then just to kind of lay this, set the stage so that people may be able to connect it with other things they've already heard of.

**14:36 Joern Freydank:** So, the role misconception is, I started out with that. I didn't know if it was actually an anti-pattern until I started describing that more. It's a conceptual anti-pattern. Of how the roles in the business are laid out. That has to do with the superuser role and the business role. The authorization anti-patterns is— it comes from the shift in the design from monolithic systems to web app, web servers deployed on multiple cluster kind of systems. So there are a lot of opportunities to drop authorization in different stages in that pattern switch. That's what I addressed in that. Time or timing-based anti-patterns. Now, this, I thought it was time, and I used that term as a red flag term for communication. And it has to do with time and execution, deferred execution. So, and it's actually one pattern that covers a whole group of patterns. While I was describing that, I discovered that it's actually the same pattern in different variations that surfaces in different areas. It has to do with somebody puts instruction into some form of code somewhere, and then another system picks it up and there's a switch. Okay? That's what I call this time or execution-based anti-pattern. Systems that don't mix well. That's something that in the design phase, we talk to teams about that. There are certain systems that are hard to mix. That's just from features perspective. And then of course there's the scalability, interop. Those are systems that work currently, but then once you scale up, do a lot more of it, it becomes an issue. And that's why I put on under that. I'm sure there are more categories, but that's kind of like the natural flow of how I group them together.

**16:35 Chris Romeo:** So how did you derive this list then? I'm envisioning, did you have a dream one night? You just woke up, you're like, give me a pen and paper, got to write these things down. This is the anti-pattern dream, or how'd you get to this list?

**16:51 Joern Freydank:** Good question. So it wasn't a pen and paper. So I was asked the question, why do you want to do threat modeling? And I And why don't we just do an assessment later on? I was like, well, if you do ABCD or if you miss ABCD, you'll experience pain later on. So I started making a list in my phone, actually not on paper, in my phone, thinking, okay, well, next time somebody asks me, I'm gonna bring up one of those things to just ask them if they're using that tech stack or that pattern. And it was not until I wrote up the proposal for the speech until I grouped them together and it's like, oh, wait a minute, there's grouping here. I can actually, Group that and look. So that came out of from a practical sense, just collecting them and and put them into that scale and the scale or the groupings. They're according to the pain points what the developers would experience. You know, grouping kind of like missing authentication is not really direct pain, but feature pain, I guess. And and the the other ones in systems that don't mix well and scalability—that's like current pain. Can't do it, right? And to fraud pain later in the future. So that's how I group them together.

**17:58 Robert Hurlbut:** So talking about roles, we mentioned roles. There's a malicious insider admin role that I think sometimes can be overlooked. How does that play into some of these, and what are your thoughts on that in terms of the different use cases and anti-patterns?

**18:17 Joern Freydank:** Yeah. So this is When you do a threat model, then usually it's there that the threat model goes through different stages. And at some point, you end up with, I would call it, like an 80% inventory threat model of everything that's there. Then you're at the stage where it's like an 80/20 rule where you would add the threats to the system in threat use cases. And usually, that's starting with external malicious actor. And then, there are also, though, internal malicious actors. And that, That became more and more significant over the last years now. There are 2 trends that contributed to that being very, um, relevant. One is the offshoring trend, right? So you have, um, the classic offshore that started like in mid-2000s where they put the development teams in other countries, and the value of data versus the salary is very high. So, and that's one trend. So you have a lot of people that potentially have access to data where that salary is high. Now, in the Western world, where the salary is high and the data value is low, that trade-off is not that relevant. And then together with the second trend is this CI/CD automation and the DevOps trend, where you have a lot more people on top of developers that have those internal roles, those internal admin roles, for instance, that have access to those systems indirectly through automation scripts or some other systems. And then, with that, it's not we are saying that the user per se is a bad person. We don't assume that. But statistically, you have to assume that one of their roles flips over or the system gets captured. Like, think Log4j tunnel, right? Like, going into the first hop, and then what is actually the— Yeah. the blast radius or the access at that point. So that's why that malicious insider becomes more and more relevant.

**20:14 Chris Romeo:** Yeah. And you think about the couple of examples you shared, like the site reliability engineers that are responsible for the DevOps build pipeline, for example. Like, a lot of— like, we still don't focus enough on the trusted insider role, in this case, the malicious insider role, you know, I know that I, when I'm thinking threat modeling, I'm often thinking outside in as my primary motivation. And I think that's a good reminder here, Joern, that you're sharing about, you know, we have to consider the inside out as well and start looking at, you know, what type of controls do we have between the different functional people who are supporting a DevOps pipeline, for example. You know, 'cause there's a lot of organizations, and I'll dare say most organizations, where a malicious admin insider could do almost whatever they want at this stage without anybody really detecting it. You know, it's not like they're doing code reviews of configuration changes. And maybe somebody's doing that out there. And listen, if you're out there and you're like, no, wait, my organization, we do code reviews of every configuration change that has anything to do with our DevOps pipeline, Send us a message. I'd love to interview you and understand how that works because it seems like that would be very slow going in a DevOps world. So I think that's— that the malicious insider is something that we need to pay more attention to from a threat modeling perspective. I mean, Robert, from your threat modeling experience, is that somebody that you're looking at, the malicious insider, often, or how does that fit into your world?

**21:48 Robert Hurlbut:** Yeah, occasionally. Certainly. I mean, like you said, mostly from the outside in, but But certainly, in terms of processes, in terms of business processes that are really critical, absolutely, you're looking at inside. Because the thing sometimes we forget is that typically the outsider is— one of their tasks or one of their objectives is to try to look like an insider that you will completely ignore. And so, if you look at the insider, you may think, well, we trust everybody here. But how do you know it's not an outsider that it's now posing as an insider? And so you do need to look at it. And certainly critical operations are important in terms of those insider access and so forth.

**22:34 Chris Romeo:** Okay. So let's, Joern, dive into the common role misconception as an example here. And so I want you to run through this one in a lot more depth and explain it to us closely. We're not going to do this for all of them, we are going to provide a link to Jörgen's Global OWASP talk so you can go listen to the full entire talk and hear the deeper explanation about each of these. But I did want to explore one of them just so folks have an idea what are they going to get when they go listen to the full talk.

**23:03 Joern Freydank:** Yeah, thank you. So, this common role misconception, as I mentioned before, is like a conceptual— leads to the conceptual anti-pattern. And that comes from the question, often, from a attacker's point of view, which role is the most valuable from the attacker point of view? And if you ask that question to the developer, they usually say, well, yeah, the name of the game is become root. You know, every capture-the-flag event is aimed at that. Now, if you think about value, though, is the sysadmin root certainly has ability to access computing power that leads to value, like for, you know, hijacking or, you know, crypto mining or something like that.

**23:43 Robert Hurlbut:** Yeah.

**23:44 Joern Freydank:** and also some data. But then, since we are securing a business function, there's usually a business function that's higher. And that, in real-world terms, that would be if you go and call into a company and want a refund for your credit card transaction, there's this power user you talk to, the customer service representative. And I call it the power user or business fairy, the person that can make it rain, right? That has direct access to money. And also direct access to a lot of data because they can, for instance, rename you in the system if you get married or something. They have access to a lot of broad data and direct, potentially kick off direct transactions. And in that sense, that role, to capture that role is actually the more realistic role where an attacker would go and try to get access to one of those roles. either by social engineering or by flipping a system that runs that role. So that the failure then to plan for this higher-level role, that's an anti-pattern that I identified, which has an impact then on certain other areas for implementation, for instance, when you have to consider this. So you have to plan for a role that's higher than a sysadmin and consider the sysadmin role as a helper role in the middle, not the highest top-level business function role.

**25:04 Robert Hurlbut:** What's the corresponding pattern, essentially? So, there's an anti-pattern. So, what's the corresponding pattern?

**25:11 Joern Freydank:** So, the pattern where this surfaces is this, first off, the zero-trust architecture pattern, right? To double-check and double-check that somebody is running in a certain role. Then, this whole anti-pattern deals with scoping or the wrong— well, not the blast radius, if somebody gets access to a system, can they actually run in the highest level role? So for instance, think about refund system. Then you would, if you consider the root the highest level, the root role would have access to keys of the mounted systems, but they don't have to have that access to those keys, to all of them. For instance, you would definitely separate signing keys for transactions from the key storage that deals within their systems to interact with each other internally. And then you would, and the outcome of that would be that you have maybe dual responsibility for that vault that holds the transaction signing key and require like a business user or business manager together with the admin to go in and change something around so that not a single person can do that by themselves. So, you have to think about that, what that means if you give an admin then access to those systems that run those business functions. In the ideal case, the business systems, they just run and don't have visibility in anything that's critical. But of course, it's not the case because secrets are mounted to systems, but then not all secrets should be mounted equally across the whole backplane. Then maybe you have to separate that out. So in the key space, for instance, separating the key spaces out, that's one of those patterns you would have to think about by the business units or by those critical business roles. The other thing is that breaking glass, whenever somebody logs into those applications that deals with production data or transactions, that somebody gets notified that it's relevant from the business unit. That's another pattern that you can use for this.

**27:12 Chris Romeo:** So as we start to kind of bring this conversation towards a closing part, I wanted to explore a little bit about what can we do to limit security debt. So, you've talked about this catalog of anti-patterns. How do we put this into action now for somebody who's listening to this saying, hey, I've got, you know, 250 developers in my organization, I've got 10 architects that drive this, trying to get us to a better security posture, what do they do with these things that you've built here to help limit security debt?

**27:49 Joern Freydank:** Yeah. So, the first big— the biggest action is awareness, right? You have to know about it, that those things exist. And that means that you create a place for it where that is documented in Confluence. Patterns that deal with smaller scoped systems, like a queue, for instance, those things, those patterns, those descriptions can go into the thread library if you do thread modeling, for instance. The rest can go into like a wiki or Confluence page, or you can create some starter thread models that have those patterns in them. Now, the one thing though that's relatively important is that when those things are documented, those patterns, that is that you have to create an easy entry for the developers that don't have that abstraction-level knowledge. So, like a jump page with red flag terms like queue, timing, something that they get reminded of to look at and read and see and check out the pattern if it's actually relevant to them. That helps create, yeah, that they can actually identify it. Then the next thing is that's on us as a security personnel. We need to get feedback from the developers on what is hard to implement. So the, I would say, the complexity is not the same. So we have to track it and somehow ask them, hey, do your libraries now support ABCD, for instance? End-to-end payload encryption. It's definitely harder because it involves 2 pods with mounted keys and all kind of things in the middle that you don't lose visibility then. And if that, for whatever reason, would come up early on and we have to ask that, do you ever— whatever would require endpoint encryption, then please put that in right away. That's one of those things, just knowing from the complexity, they have to do that early on, just put a placeholder in their code or something like this that's already there. On the operational side though, we have a trend to doing infrastructure as a service with modules, for instance. We can have services that are fully configured. Think about if you download like a SQL database appliance, they usually have already scripts in there that that separate the regular user from the power user— sorry, the admin. And you can build your own platform services accordingly now too, with fully required, fully configured services. That's one of those more practical things you can do. Or use like pre-configured infrastructure as a service modules that work across multiple different modules when they work together. That's another more practical approach. Like have a preconfigured queue, for instance, that turns certain things off. Or when you're dealing with interaction with other systems, that once they include other modules, then you already have a set of preconfigured variables that have to be filled in order to function properly. So that's—

**31:03 Chris Romeo:** So there's an awareness— I mean, there's an awareness play in that we need developers and architects to understand, you know, what are all these different categories of things to consider. I heard about— I heard you talk about there's inputs to other processes like threat modeling, having these be things that people can use, whether that's with template threat models. And then there's also just reference kind of service approaches where, you know, you've got a series of best practices that are being applied maybe in a standard way with a template. or something so that, you know, you're providing a pattern, you know, countering an anti-pattern with a pattern that provides me with all the things I need to be successful. You know, it's that default security approach, which, you know, throughout my career, I've watched as we get closer and closer to that, you know, taking away the options for people to make insecure choices, for example, when rolling out a new service. I've seen a lot of progress in 25 years, but we're Funny thing is, we're still not there. And I don't know that we'll ever get to the point where it's like, there is no insecure option, but we can certainly dream. So, what, Joern, do you see as a call to action or a key takeaway to our audience here? Like, what do you want them to do as a result of learning about security design anti-patterns and security debt? I'm hoping it's not declare security debt bankruptcy. I'm hoping that is not your key takeaway.

**32:33 Joern Freydank:** No, because we already talked about it, so that's a good start, right? We need to Spread the message. That's the key takeaway. It's, hey, there's a different level, right, that we need to address. It's not the little bitty threats that everybody's kind of throwing around already. There's a bigger scope, and we need to address it in a more organized fashion, for instance. But we need the feedback from the developers for this. We can't do that as security developers, security personnel, because we don't know what's all out there, right? So we need that feedback loop for them to point and say, hey, what about this? Where does this fall into play? You know, is this a pattern? So we need to raise that awareness and probably document it somewhere, maybe OWASP project, I don't know. Think about that. The categorization is a bigger challenge because that is, you need to have the data like in multiple variations first before you categorize it. And my scope's also limited to my career so that we need the community to feed into that too. Hey, what would be a good categorization and topology for this in order to address, then point to the right correct patterns, right? That's kind of the goal there. You name the anti-patterns and then you point to the ones that would fix certain things. So, I would say, Documentation and awareness is a good start. And asking for that, asking for feedback, that we need that feedback from the community for this.

**34:06 Chris Romeo:** Well, very good. Joern, thank you for taking the time to share the security design anti-patterns approach and security debt and, you know, all the experiences and things that you've shared with us here. Thank you for providing that for our audience. And their call to action is to go dive deeper into this topic. And so once again, thank you for the time today. Thank you for the education and keep chasing down these security design anti-patterns.

**34:33 Joern Freydank:** I will do. Thank you. And thank you for having me on the show. Thank you.

**34:37 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast and on the web at www.securityjourney.com/resources/podcast. podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, with application security, there are many paths but only one destination.

---

Source: https://appsecpodcast.com/joern-freydank-security-design-anti-patterns-limit-security-debt/