May 19, 2023

Learning Application Security With Chris Romeo

TLDR;

Security Tools does not mean AppSec. There are other factors to Security as well like People, Process and Governance.
For resource constrained organizations, start with Open Source to improve Security for high impact areas before investing in Wholistic & Expensive Tools.
Instead of following all the best practices like OWASP Top 10, and others follow a Data Driven approach and pick High Value sections for CI/CD Security, Supply Chain Security and other areas.

Transcript

Host: Hi, everyone. Thanks for tuning into season two of Scale to Zero show. I'm Purusottam, co-founder and CTO of Cloudanix. Today's episode is focused on application security and threat modeling. To share his knowledge on this topic, we have Chris Romeo with us today. Chris is a leading voice and thinker in application security, threat modeling, and security champions. He's the host of a few award-winning podcast like application security podcast, the security table and the threat modeling podcast. He has over 25 years of security experience holding positions across a gamut of like application security, security engineering, incident response and various executive roles. Chris also holds the CISSP and CSSLP certifications as well. He founded security journey leading to an exit in 2022. Chief Security Advocate at Cisco, spreading security knowledge through education and championship programs. Currently, he serves as the CEO of Care Ventures, an early stage cybersecurity investment and incubation firm. Chris, it's wonderful to have you in the show. For our viewers who may not know you, do you want to briefly share about your journey?

Chris Romeo: Yeah, happy to. As you read in my bio, I've been involved in the world of security for 25 plus years. And so I've seen a lot of different things. Like security was very different when I started. We went from people saying we're not we don't need to do that. The security thing, we don't need to do that to where we are today, where people are like, OK, security, it makes sense. But I started as a sys admin and I got really I was very blessed in that. I was, I started in a company that had this idea of growing security engineers back in the 1990s. And so I became a security engineer and that led me down this, the path of being a security consultant, of being a director of incident response, of doing some things with managed security services, and then eventually finding my way to Cisco where application security became my passion and then ultimately starting my own company's security journey and selling it. And so it gives you a little bit of context about my, the journey that I've been on from. Starting as a system administrator, really knowing nothing about security to going through almost a lifetime career in this field of security.

Host: Yeah, I'm looking forward to learn some of the challenges that you have faced and how you have addressed and your knowledge around it. So the way we do the podcast is we have two sections. The first section focuses on security question and second section is mostly around security practices and rating the practices as well. So let's start with the security questions. So Throughout your career, you must have seen that applications are getting deployed in many ways, right? In-house, data centers, clouds, edge, connected devices, and there are many more, right? And with these different ways of deploying applications, there are more entry points or touch points which make applications vulnerable to security threats or breaches, right? One of the goals of application security is to focus on identifying and minimizing these vulnerabilities. So my question is,

How do various components of application security work together to identify and minimize security vulnerabilities when you have to deploy across so many ways? right.

So many ways you can deploy your applications.

Chris Romeo: Yeah, so I'm gonna take you up to the 20,000 meter, 50,000 foot view to talk about application security because one of the challenges that I see I'm gonna throw in right from the beginning is that often people think application security and they think tools. And that's the end of the conversation for them. They think AppSec is just, I take these tools, I incorporate them, I work with the results. And from my perspective, in my viewpoint, Let's step up a level and think about what application security really is. Application security is people, process, tools.

So tools are a piece of this, they're a pillar, they're a leg of this table, and governance. And so if we work through each of these and think about how they come together, so on the people side, so application security requires developers. Developers are writing code. We want developers to write more secure code. So we need people that write code, but that write secure code. And people by default don't write secure code. In our university systems, we're not teaching them how to write secure web applications that avoid SQL injection or cross-site scripting or all these different types of attacks that we have in the OWASP top 10. And so people, that's the first leg of the table here. Process, we have to have a repeatable way to ensure that everything we build goes through the same set of controls, same set of security steps to ensure we have the most secure and private product that we can put out when we get to the end of the life cycle. And so for process, we're talking about a secure development life cycle.

These are the steps. Microsoft invented this thing 20 years ago or so now of security requirements, threat modeling, security testing, code review, all of these different pieces. But the point here is that we need a standard process, a way to standardize how we secure the things that we build. And then tools, yeah, tools are a big piece of this. We need tools to make the people more efficient. Tools can help us to put the process, to enact the different pieces of the process. And in application security, we have so many different four letter acronyms for tools. You have SAS and DAS and SCA, that's only three. RASP and IAST and CWPP for the container, whatever protection. And so there's all these different types of tooling, but so they're important. but they're only one leg of the table. They're not the leg of the table. And then I would be remiss if I didn't mention governance as the final piece. And I learned this from Alyssa Miller, who I was interviewing on the Application Security Podcast, and Alyssa, she's the one who gave me this idea about governance being such an important leg of this table.

Because when you're thinking about rolling out an application security effort across an entire company, you have to have a way. Once you get to a certain maturity, you have to start measuring, are the people learning the things they need to know about security? Are they following the process? Are they using the tools and fixing the things that come out of it? That's governance. That means dashboards and metrics and traceability and tracking what's happening. And so for me, that's application security. Application security is not a static analysis tool. Static analysis tool is a piece of this bigger infrastructure of application security. And I think all too often people are focused on the tooling. Let's think about all these different legs of the table working together.

Host: I love your answer because most folks you're spot on that most folks think that hey we have a security problem let's get a tool and we are all set but they often miss out on the other three legs right so thank you for highlighting that. So now my follow-up question is let's say

we have all the four legs set up now when the organization discovers vulnerabilities what mistakes do you see people make most often?

Chris Romeo: Yes, that's a bit of a loaded question because there's a lot of different types of mistakes, but you said most often. So let me cage this answer in the perspective of most often. And so I would say that the OWASP top 10, first of all, is a great place to go to see the top 10 application security risks or what are the most likely things that have been found over the last number of years according to data. And I say the according to data parts important. So OWASP top 10 is no longer created based on a bunch of application security people getting together and saying, I think this one is important. And I feel like that one's important. It's all data driven. For the most part, it's data driven now. And so the OWASP top 10, that is our list of types of issues and things that we have to consider.

I would say other challenges that I've seen if we're going to put these into categories, one of the big challenges that people are facing right now, as we've seen in the news media and whatnot, is a lack of protection for CI CD pipelines. Your CI CD pipeline, your build process, that's part of your application security strategy. You have to protect the tools you use to build the software or you end up with attackers getting into the build systems. And if I'm in the build system as an attacker, I can do whatever I want. I can add stuff to your application. I can add libraries. I can, there are so many different ways to pollute a build. And then I would say the third thing right now is everybody's talking about the software supply chain, but I'm gonna throw it out again, cause that's one of our biggest issues, right? Is we have vulnerabilities and it's not even the vulnerabilities in the first-level dependencies. It's this idea of transitive dependencies.

And so Sonotype has this state of the software supply chain report. I don't work for Sonotype, but Sonotype's got this report. I recommend people go check it out because every year when it comes out, I grab that report because I want to know how many people are still downloading vulnerable components and including them in their packages. What are the challenges from the supply chain? And so those are some of the bigger issues that I've seen in the last, thinking about the last year or two in the realm of AppSec.

Host: So you covered a lot actually as part of your answer like over top 10, there are 10 highly vulnerable issues that is highlighted. And again, as you said, like it's data driven, it's not just few security folks just get into a room and then start dreaming and just writing it down. So it's more data driven. So it makes sense for organizations to pay attention to it and focus on it. One of the things that you highlighted as part of the security legs is the process. And when it comes to software development, most folks are familiar with the STLC model, which is the effective and time efficient process of designing and building high quality software. Now, my question is,

How soon do you think, let's say threat modeling should be included as part of the software development lifecycle?

Chris Romeo: There's two answers to this question. There's kind of the, what I would say is what I wish happened and what really happens in the real world. So I'm a realist. I believe that we can set standards for what we hope is gonna happen, but also when we get into working in development organizations, it's not gonna happen that cleanly as we hope. So the threat modeling purist in me is gonna say,
I want threat modeling to be occurring at when somebody has an idea for building a new feature, they grab a developer grabs a user story, for example, let's say in an agile or DevOps world, they grab a user story from their, whatever tool they use to keep it and they're starting to think about the design. That's where I want them to do threat modeling before they've ever written any code, written any lines of code. I want them to be considering.

Host: So even in design phase in a way.

Chris Romeo: Definitely. I mean, and you think about it though, like in an agile world, in a DevOps world, design phase has been crunched down to be a short period of time from the time the developer grabs that user story, either the, you know, if you're, if in the old days they would have them as sticky notes on the, on the wall and you'd grab a sticky note and go work on it, right? We do it all virtually now, but the design phase really happens from the time they grab that user story until they start coding. That's the design phase. So there are multiple mini design phases occurring in an agile sprint, for example. So the purist in me says, I really want threat modeling to happen there. That's my goal. Now, let's look at the other side of the coin. The realist in me knows that when an organization is starting to do threat modeling, they have lots of code already deployed. They can't just delete all their code and say, let's just start from scratch. We're gonna delete the entire application. And we're going to start from scratch to ensure we threat model. And so you're going to have to figure out how to integrate threat modeling into.

Wherever, you know, the, the, the various code that's already been built. It's going to have to be retrofitted. It's going to have to be, have threat models performed against features that are already deployed in production. And so you really have that balance between the purest view of let's threat model new stuff to ensure we don't get further behind, but then also the realist saying. Hey, there's a bunch of stuff in production. We have to go back and perform threat modeling upon. And so it's really, it's both sides of the coin is really, it's early and it's catching up with everything that we've already built.

Host: So I like how you differentiated being the purest and the realest. So where is the gap? Why are organizations not able to get close to what you said should be the best case? That maybe we start very early and we do it in every phase. So where do you see the gap and how can that be mitigated in a way?

Chris Romeo: Well, the gap is just a result of they didn't start threat modeling when they started the company. And so the gap exists because they're bolting on security concepts or process-related pieces after they've already started building something. So it's not their fault. They didn't know any better. They didn't know 10 years ago when they started the company that they should start threat modeling. And so that's why the gap exists. And I think the way that we close the gap on anything related to application security is to integrate the different pieces that I talked about, people, process, tools, governance, into existing applications, knowing that there's gonna be, we're not gonna be able to fix this in a week. You can't just turn this thing on and say, okay, we're doing application security now.

If you turn on a SaaS tool for a product that's never been scanned before, you're gonna get hundreds or thousands of results. You're gonna bury developers in just noise and false positives. And so you really have to approach those things that are already in production. You have to really come into those and use a more careful and slower approach to bringing the AppSec pieces into it. Because the worst thing you can do is turn on a tool, generate a thousand results, generate a thousand tickets in Jira, and they all get assigned to a developer. What does that developer think about security at that moment? They think... These people are morons. They just generated a thousand tickets that I can't, there's no way I could fix these, these thousand tickets would take me half a year to resolve as a developer. And so by carefully leading how we bring application security into existing products, and existing applications, we can ensure that the developer gets value. And if the developer gets value from the first tool that provides output to them, You know how the developer will then answer, eh, it wasn't so bad. The security people added this stuff, it wasn't so bad. That's a compliment from a developer. It's not so bad, that's them saying, this is awesome, we love it. This is the equivalent of a salesperson saying, this is the best thing that's ever been created on Earth. Translating from engineer to salesperson. So you just gotta be careful. You gotta be careful that you're going to properly introduce application security so you don't create something that's going to be tough for people to really grab a hold of and be a part of. You want them on board. You want all the developers to be excited about security, not figuring out how they're going to get around it or figuring out how they're going to fight you.

Host: I see how you connected this to your earlier response. You cannot just switch on a tool and you're like, yeah, we have security in place and you sort of bombard your developers with tons of issues that they need to address rather than rather put all the pieces together process and your governance, everything together and then use the tool as a way to improve your security posture in a way. That makes a lot of sense. So I want to dig a little deeper on the threat modeling. So when it comes to, let's say, threat modeling, there are many models, like Stride, there is MITRE ATT&CK, OWASP-PROP, and you already spoke about that. And with each of them, there are different pros and cons as well.

Let's say you do not have a lot of budget to have a security expert in your team.

It's hard to understand what's the right model, what's the right way to implement.

How should teams tackle this?

Chris Romeo: I'm a big fan of the methodology that's referred to as stride. And so I'll tell you a little story about my history with stride. Just so folks, in case folks don't know they're listening, stride is spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. It's a simple, simple to me, I shouldn't say it's a simple, it's a mnemonic that helps us to think about some categories of threats when we're first getting started with threat. And so I'll tell you that when I first got into threat modeling, I had learned about stride. I said, oh, this is a really interesting way to teach people. It's helpful. It simplifies it. And then I got too cocky. OK, I said, ah, this is this is just not a good this is just not a good kind of way of, you know, approaching it.

Like this is people aren't going to get they're not getting this. It's too easy. It's too easy for people to understand. Right. And then what I ended up figuring out is I started trying to do something more complicated and I couldn't people were struggling to learn it they they weren't Understanding like I was I was making it they couldn't they didn't know where to start they didn't know what they were supposed to be doing and so What we ended up what it would end up doing is coming back around to stride and saying I came back I was I jokingly say I had a love-hate love relationship with stride as a methodology I came back around to it because I saw there is beauty in simplifying how you teach threat modeling to people and then once they understand the basics of it, then I can, then we can take them on like they should outgrow stride as a methodology and that's okay. But it provides that foundational layer that helps them understand how to go to those next levels and how to do the basics.

And so that's, so I would say stride is, and then like you mentioned another, a number of other methodologies, you know, there's, there's an attack from MITRE, there's defend from MITRE. So attack is like how to break stuff. Defend is how to, how to mitigate stuff. There's Linden that's used as a methodology from the privacy world. There's, you know, implementing attack trees. There's a lot of other ways that you can approach this, but I still come back to starting people off with stride and then letting them, letting stride kind of be the way, the guiding light that helps them build the foundation. And then once they do that, then we can move on to more complicated things.

Host: Okay, that that makes sense that sort of gives an idea where to start from. And then as you face challenges, maybe look at other options. So another question on threat modeling is often teams or organizations might think that it's a one time activity that hey, we did it for our product X, and then we are all sorted. But ideally, it should be a continuous process, right? Like as you add more and more capabilities, you should continue to do it.

How should that mindset be instilled in organizations?

Chris Romeo: Yeah, so I think you're first of all, off your right on. Threat modeling is not something that's a one-time activity. There is the need for what we think of as continuous threat modeling. We have continuous deployment, continuous delivery, continuous threat modeling. We need that as well because systems change, features change, new attacks, new threats come on the scene. You think about a couple of, five years ago, we weren't thinking about the software supply chain. It wasn't a threat. Look where it is today. It's on everybody's mind. People are building companies to build solutions to solve your software supply chain things. And so I think that, you know, we really do need to build that mindset into people. We need people to understand kind of how important this whole idea of threat modeling is and being able to apply that to whatever it is that they're building.

Host: Exactly. Okay, makes sense. I just want to pivot slightly on the threat modeling itself. So it's often like for the development team, it's often poorly understood, right? Because we let's say you don't have a security team member or security expert. It's even more challenging for security, senior leaders, let's say. And when it comes to budget, security is often. Security often is the last priority and threat modeling is considered even lower priority and receives only a fraction of budget. So

How should organizations deal with these challenges of like budget constraints when it comes to threat modeling, threat hunting, different security practices?

Chris Romeo: Yeah, I would say that we certainly don't have the budgetary constraints that I saw early in my career, where we were literally fighting for budget to be able to do things for security. I think if you go all the way up to the board of directors, so let's split into a couple different sector, or let's break the world of companies into some different categories and buckets here. If we think about...you know, large enterprises that have boards of directors, they all have somebody on their board who's super serious about security. That's they're doing briefings about cybersecurity. Like in those world and those type of companies, there is no stress about a cybersecurity budget. Like you're getting if you need something for security, they realize the risk profile. You know, you think think about large financials, large banks, large insurance companies.

They know the value of their data and they will invest almost anything required to protect that data. And so I don't see, I don't see the budgetary constraints from that side. Now we are in the, in the midst of a bit of an economic recession is what people tell me. I'm not an economist, so don't buy or sell stocks based on anything I say. But so for companies that are, we are seeing companies that are pulling back a little bit right now from a spending perspective, even in the security realm and so, if you're on the other side, if you're somebody that's in one of those companies, you have to do more with less at this particular point of the world, or where the economy sits, whatever. And so, when I think about people in that situation, they're not in those large enterprises that have kind of protected budgets to be able to do things. My advice to them would be, look at things that exist inside of the OWASP world, for example. And I'll give you a couple of examples. So, software composition analysis Okay, it's a big category.

It's a tool you should be running in your pipeline to determine if you have any vulnerabilities in the packages or transitive dependencies, stuff like that. There's lots of commercial tools, but there's also a tool, an OWASP project called dependency check. So there is a software composition analysis tool and that OWASP puts out that you can include in your pipeline. There are other, there's other software composition analysis things you can do like using NPM, node package manager has an audit commit flag that you can run. That's not, that costs zero. It doesn't cost you anything to add that and to use that as your way to check your packages and stuff for node vulnerabilities. I think about Ruby has a, there's a bundler, you know, there's some things you can do in Ruby to get the same bundler audit is a tool in Ruby that will look to see if there's a node vulnerabilities. So I would say if you're in a situation budgetarily where you need to do more with less, look to some of these open source tools. These things are battle tested. It's not like this is just a tool somebody released last week and we're like, I don't know if we really wanna put it in our enterprise or inside of our build pipelines.

Find these tools that are very well established and that a lot of people have been using for years and incorporate them. Then all it takes is time. So for those smaller companies that maybe are facing budget pressure, look to the open source world maybe you're able to get some commercial tools in a few years. Use those open source tools to protect your pipelines today because they'll get you a lot further than nothing will. If you install nothing, you're going to have a series of packages that are loaded with vulnerabilities. If you install something and that open source tool for software composition analysis, it may not find everything. It's going to take you, it's going to get you 90% of the way there. Maybe it'll get you a hundred percent of the way there. I'm not going to say it won't. But it'll at least get you 90% of the way there while you wait for budgets to open up further down.

Host: Make sense. So, one follow up question to that is like as you highlighted right there the current economicals economy is a little shaky. So,

let us say if you are pitching threat modeling to your leadership, what are some of the advantages you would show so that you can get some budget?

Chris Romeo: The easiest way to explain threat modeling is in what is the value? What's the return on investment? If I find security issues during design and we adjust and mitigate them versus if that same feature gets designed with security challenges built in and goes all the way to production, I still have to fix it. I can't just leave it in production in an insecure manner. And so the value proposition of threat modeling is, it. Prevents or eliminates or limits. I guess I shouldn't say eliminates but it limits rework Which is a big challenge rework is a is a developer cost where Developer builds a feature they push it to production somebody finds a security issue That feature gets routed back to them that developer not only do they have to stop what they were doing They have to empty their brain of all the context of what they're working on and they have to Reload their brain with things that they did three weeks ago or whatever it was.

And then they need to try to fix the problem and then move on. And so threat modeling can help you to find more of those issues upfront. So it saves us in development time. It saves us in security, the time it takes to fix a security vulnerability, the time it takes to communicate a security vulnerability. Cause we have to communicate. If we have a nasty security vulnerability, we have to communicate it to our customers. We may have to perform incident response if we get a compromise. Like there's all of these things that we can, it's that we can help to, to, to make them less of a, of a, of a charge or less of a problem for the business by doing that threat modeling early on. And so that's how I sell it. Whenever I go in and say, when someone's like, Oh, how am I, you know, what, what's the benefit of this? Well, the benefit is you're going to have less security problems, get to production. That's it. Like, do you want less security issues in production? Do you want to fix things? Do you want to prevent rework or limit rework? If the answer is yes, then threat modeling will provide that. It'll have a higher cost upfront to teach people how to do it, but it'll return for years into the future because in less security issues.

Host: Makes sense. So early detection and then less interrupts for your developers or the engineering team as well. So yeah, that makes a lot of sense. So now if we want to think about different phases of organizations, right? Let's say for an early stage startup, when they are focusing on product security, there are many areas like vulnerability,

Chris Romeo: Definitely. That's the value.

Host: So what are some of the key areas to focus on, given startups have limited time, people, and budget?

Chris Romeo: Yeah, so I kind of maybe even I answered this a little bit earlier, but I'll kind of re-reset that answer a little bit because, you know, I've started a started a company from scratch. I've built that startup up into a big company. So I understand where a lot of startup founders are sitting. Now, I had an unfair advantage because I love application security. It's part of what I am and who I, you know, it's who I am. It's what I do. But here's what I did in the, you know, from a inexpensive approach to product security. First of all, I, I perform threat modeling myself of a lot of our early designs. I threat modeled our architecture. Uh, but I also taught our developers how to do threat modeling and it's a work in progress, but they, they were learning how to do threat modeling, how to consider what the threats are in what they're building and how to mitigate them. The other thing I did was I looked for open source static analysis, you know, SAS, static analysis, static application security testing. I found open source versions of that that I could include in our pipeline so that every time code got checked in, our DevOps pipeline would grab that commit and build it. Everything got built when somebody committed code. And so the static application security testing tool, the open source one got executed on every commit. And if it threw an error, that code, we would know that that code needed to be fixed before it could be merged. And so the developers got in the habit of going back now. I didn't pay anything for that tool. It was an open source tool, but it provided a checkpoint. I did the same thing with SCA with software composition analysis. I used all the things I mentioned in that previous answer. I used NPM audit. I use bundler audit cause it's a, it was Ruby on reals application. Um, and those two things could also break that build on that commit causing the developer to have to go back and upgrade the packages to get everything to pass for that commit coming in. And so there's three examples, you know, from threat modeling, from open source SaaS, open source SCA that any company can do that. It doesn't cost any money to integrate those things. And those tools, integrating the SaaS tool, integrating the SCA tool, it didn't take much effort. They're pretty out of the box as far as that you don't have to go tweak them and do a lot of configuration. They're pretty much out of the box. You may get some false positives, you wanna adjust policies or something, but the return on investment from doing those type of practices, one, it sets the stage early that we care about security. So when your customer says, Peru, what do you do about security with your startup? Oh, well, we threat model the stuff that we build, we run static application security testing, and we run software composition analysis. And only five people work here, and this is what we do. It shows that you're thinking about security in a way that those customers, and especially larger enterprise customers, want to know you care about security. And so that's really the big pieces of this coming together are being able to find the, doing threat modeling, adding these open source SaaS, open source SCA, building that foundation of application security in your pipeline, but ultimately for your entire company.

Host: So there are two takeaways, at least for me.

Use open source, since you have budget constraints or people constraints, try to use as much open source as you can.
The most more important one, is around teaching your development team to do the threat modeling. That sort of defines the culture of the organization as well. As you grow, all the developers will start doing that as part of their design phase which helps you in future less interrupts or less vulnerability is exposed and stuff like that. So I love the second part of your answer. This is one question that we have to ask you. So there is a new shiny technology called ChatGPT, and everyone is talking about it. In fact, Google also launched BARD to compete with ChatGPT. So now.

I can generate security policies using the tool and use that in my organization. So is that the magic trick to solve all of my applications and security problems?

Chris Romeo: Hold on one second, I'm gonna ask chat GPT. See what chat GPT gives us as an answer here. No, I'll give you my thoughts on this. So I see different people are approaching or looking at chat GPT kind of from different perspectives. Some people are looking at it saying, it's gonna replace all of our people, it's gonna do all these things. I'm not in that camp. I don't see generative AI replacing any anything other than the most menial of jobs. Where I see the advantage from an application security perspective is when I think about a generative AI that can provide guidance into a developer, if we can train this generative AI to have secure coding knowledge, so that when a developer's coding something, there can be, I see more of like the road where AI helps all developers to be 10x developers. We always talk about 10x developers. You have to have a 10x developer or two in your startup because there's someone who generates code at 10 times the rate of everybody else and they're just incredible. I think AI can really make lots of regular developers, 10x developers, because it can help them and it can make the 10x developers go faster. The most senior developers can rely on the different, kind of the different scaffolding, for example, like a senior developer, if the if the AI can create the scaffolding for something they're trying to do, and then they just go, instead of creating the 20 lines, they create the three lines to the real special sauce or whatever that they needed to do to make that function really do it, what it was intended for. So I see kind of AI playing in on helping to advise developers, but I think there's a security angle to getting an AI that note that has more training on secure coding principles and approaches and is able to advise and scaffold more of secure strategies and secure blocks of code for the developer. And so it's the developer working with the AI to really empower them to go further. Then I don't see the AI writing code at this stage that's usable. And then I think about like on the SOC use case. If you haven't seen yet, Microsoft has released something called Copilot. It's an AI that's designed for their for their, for sock analysts. And what it does is it does a lot of the leg work that a sock analyst would do in trying to, to bring disparate pieces of information together, putting them in a way where you can look at various feeds and things coming from different devices and then tie them all together and then, and then try to, try to figure out what's going on the, in the case of Microsoft co-pilot, it can save the sock analyst, all that legwork it can bring everything together into a single view. And then as a sock analyst, I can say, okay, this, I see this, I see this, boom, I know what it is. I know what we need to do. And you know how we need to react versus the sock analysts going and spending five minutes looking at this one piece of information. Use it 10 minutes to find this up, like the AI can do all that legwork for them behind the scenes so that it can 10X a sock analyst as well. And so I think AI is gonna, it's definitely gonna change the landscape. It's not gonna do AppSec for you. You still got to have people that are smart people that are driving, coming back. I'm coming back all the way around to the beginning. People, process, tools, and governance. The AI can't replace the people. It can help the people to be better. It can help the people to be more to 10 X their abilities. Um, from the process, the AI is not going to create the process for you. You, you got to build the process and adapt the process over time. The AI can help maybe with some of the tools. Like I think the tools are going to get smarter in AppSac and then maybe from a governance perspective, maybe AI can help on the dashboarding and tracking that data and at least pointing out people, certain situations where people are not meeting a governance level. And so I see AI really improving all of these different areas, but it's not replacing. It's not replacing any of the things that we do.

Host: So I can see like in future architecture diagrams, there is AI as one of the layers in between all of these components, right? The governance, your tools, the processes, people like everywhere, AI helping you get better rather than sort of we fearing that AI might take our jobs or like getting into that kind of even discussion. So yeah, so that's a great way to end the security section. Thank you so much for sharing your insights and knowledge around the area. So let's go to the next section, which is around rating security practices.

Rating Security Practices

Host: So the way it works is I'll share a practice and you sort of rated one to five and maybe you add some context why you are rating it as a one or two or three or four or five during the onboarding only so that they can identify and respond to potential security threats because there is no need to do it on a continuous manner or doing any tabletop exercises let's say every six months or a year. What's your rating for that?

Chris Romeo: So I'll give that one, which is the worst practice. And it's a worst practice because education needs to be continuous. Taking, let's use developers, because that's where I spend, I spend most of my time working with developers. If I teach developers for one week, and then I turn them loose for the rest of their career inside the company and say, go make secure products and applications, there's no reinforcement of the learning that's happening there. And so education, learning, Transferring knowledge this has to happen over a period of time You can't do this in a single because if you go into a 40 hour class You will forget by the six months after that you will forgot forgotten almost everything that you learned there But if you approach education and learning through things like tabletop exercises You will have the ability to reinforce the concepts you teach the concepts and then you reinforce the concepts so that Developers should have a security training experience every month Oh, I remember we did this thing and then we did this little challenge where there was a cross site scripting. Oh look I just made a cross site scripting crud. I got to fix this. I just did I did what I did in that exercise It's reinforcement that makes that it's not it's not a single point time. So that's why I say that one's a worse practice

Host: I would have been surprised if you had given anything higher than one honestly. So the next one is developing and regularly testing an incident response plan to help quickly detect respond to and recover from security incidents.

Chris Romeo: I didn't know I could go lower. Can I use negative numbers? Okay, for me, that's a five. And I'll tell you why. In a period of my career, I was a director of incident response for a large web hosting company that our focus was working with customers who had compromises inside of their web hosted environments. And when somebody doesn't have a plan, it's just chaos. So we're gonna make a plan while we're in the midst in the fire, while things are falling apart and we're trying to deal with the media and try to deal with... customer base and trying to deal with the executive team. We're building a plan, but we're doing it. It's costing you a lot more for us to build that plan on the fly while we go. And there's a lot more chances we can make mistakes or go in different directions. So I say that's a best practice as I'm going to give that a five because I've been on the other side when we didn't have it. I felt the pain of not having something that was fleshed out in advance that who we communicate with, what are the steps we go through, Not having that is a very painful experience. So having it is a fight.

Host: Makes sense. So the third one or the last one is security is challenging and it delays our business growth. So grant developers or security teams unrestricted access to your database or your cloud systems or applications so that business growth is not affected at all.

Chris Romeo: I'm gonna go back with a worst practice. I'm not, for me it's either, there is no gray areas in the middle here with me. So here's why though, here's why. You can live in the world that, what you just described there of having all developers have all access to everything, that works until you hit a certain size. If you have 5,000 developers and everyone has access to everything. You have to build such a robust system of traceability and tracking everything that everybody does because somebody could go in and drop all the tables in the database. If everybody has access, everybody has admin, there's no least privilege. How do we know who did it? How do we, how do we, who do we know? If someone did it on purpose, they should be fired. How do we know who did it? How do we, how do we prove they did? And so I, I think it's important to build those controls from the very beginning in a startup. Like just get people in the habit. That's why we have containerization, right? Docker containers were created to serve, to solve one central problem. Everybody forgets what it was. Developers used to build software on their local computer and then they would upload that to the server and it wouldn't work because they had libraries installed on their computer. They had other components that the application needed to run and they didn't replicate it. They didn't even know to replicate those to the server environment. So somebody, we invented, I didn't invent containers, somebody invented containers because they said, well, what if we create this thing called a container and the developer creates the container on their local computer, and then they copy the container up to the server, and then it's the same thing running in both places. And so if it doesn't run on the, if it runs on the developer's workstation, it will run on the server because they had to put all the libraries in the container and define them. So that's an example of how we. how something that came out of the necessity, being able to solve this type of a problem there. And so that I think is, it just helps to kind of frame the issue.

Host: Yeah, makes a lot of sense. So that's a great way to end the episode. Thank you so much, Chris, for joining with us and sharing your insights. It was lovely to speak with you.

Chris Romeo: Same, same with you as well. Thank you for the opportunity to be here and to share a tiny bit of wisdom that I may have learned along my own journey.

Host: Yeah, I have learned quite a bit and I'm hoping that our viewers will learn something new as part of it as well. To our viewers, if you have any questions around security, share those at scaletozero.com and we'll get those answered by an expert in the security space. Thank you so much. Thanks again, Chris, for joining. Thank you, bye.

FAQs

Importance of Governance on Software development life cycle

Alyssa Miller, shared this idea about governance being such an important leg of SDLC. Because when you're thinking about rolling out an application security effort across an entire company and Once you get to a certain maturity, you have to start measuring, are the people learning the things they need to know about security? Are they following the process? Are they using the tools and fixing the things that come out of it? That's governance.

How to close the gap of businesses focusing on Application Security or AppSec in a way?

The way to close the gap on anything related to application security is to integrate the different pieces that we have shared above about, people, process, tools, governance, into existing applications, knowing that there's not gonna be any fix in coming weeks as well.