The Security Table
The Security Table is four cybersecurity industry veterans from diverse backgrounds discussing how to build secure software and all the issues that arise!
The Security Table
SQLi All Over Again?
Chris, Matt, and Izar discuss a recent Secure by Design Alert from CISA on eliminating SQL injection (SQLi) vulnerabilities. The trio critiques the alert's lack of actionable guidance for software manufacturers, and they discuss various strategies that could effectively mitigate such vulnerabilities, including ORMs, communicating the why, and the importance of threat modeling. They also explore potential ways to improve the dissemination and impact of such alerts through partnerships with organizations like OWASP, the various PSIRTs, and ISACs, and leveraging threat intelligence effectively within AppSec programs. Ultimately, the trio wants to help CISA maximize its effectiveness in the software security industry.
Link to CISA SQLi Alert:
Secure by Design Alert: Eliminating SQL Injection Vulnerabilities in Software -- https://www.cisa.gov/sites/default/files/2024-03/SbD%20Alert%20-%20Eliminating%20SQL%20Injection%20Vulnerabilities%20in%20Software_508c.pdf
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
Well, that just about sums up the security table. We're totally unprepared anyway. No, just kidding folks. This is Chris Romeo and, uh, joined by my good friends, Matt Coles and Izar Tarandach, you have entered the security table. And on the security table, we discuss, debate, argue. Once in a while we get excited, uh, as we discuss various topics that surround primarily product and application security, but we sometimes branch out into other deeper subjects. Today, we got an alert. And so I think we all should be, have red lights like, ah, yes, Izar has received the alert. He's heading to the bunker because there is an alert. It is a secure by design alert. And it's called Eliminating SQL Injection Vulnerabilities in Software. Shall I give you my initial take on that? My initial take, and my initial official, this is an official response, just from me, at the security table, and that official response is, Uh, duh. That's it. That's my response. That's my official response. Like, did we, did, did, did SQL Injection just sneak onto the scene? No, I don't think so. neither does Matt Stogg think so. Matt Stogg said, it's just saying, let me translate, that SQL Injection's been around since the early 2000s. And we've known a lot about it, and people have publicized a lot about it, and how many conference talks have we had on it? Probably over a thousand, when you talk about, talks about individual vulnerabilities in general. So, that is my official response. I'm curious to see if you have perhaps more eloquent responses, but my response is, uh, duh.
Izar Tarandach:I'll give you mine in the form of, uh, Interpretative dance.
Chris Romeo:nice. A bit of stretch.
Izar Tarandach:What?
Matt Coles:I'll be a little bit more, I'll be a little bit more diplomatic. Thank CISA, for, thank you, CISA, for highlighting what we should have already known.
Izar Tarandach:No, okay, so let me put that, this in there. In the beginning, my first reaction was really, duh. But my second reaction was, perhaps now that the FBI is talking about it, somebody's actually going to listen.
Matt Coles:My first thought was the only reason the FBI is there is so that people don't ignore it as spam.
Chris Romeo:To legitimize the delivery. Yeah.
Izar Tarandach:point. That's a good point.
Chris Romeo:here, here's the struggle here. Here's the mighty struggle that I have with this document. I certainly agree with everything that they're saying. Well, for the most part, right, SQL injection is a big problem. It's needs to be fixed. Software manufacturers should not be leaving SQL injection vulnerabilities in their code. I mean, none of this is things we're going to argue with. The problem I have is what in the heck am I supposed to do with this? This doesn't tell anybody how to, yes, they say, well, here's a few mitigations you should use. We already know this. This has already been publicized across our industry for decades at this point. Um, Jim Manico has done so many talks about this particular topic, right? Like, the challenge here is there's no guidance on what to do with this if you're a software manufacturer. And it doesn't, and what I'm not talking about, use prepared statements, or use ORMs. Those are technical mitigations. People, that is head knowledge. People just don't know how you could, there's no guidance here on how could you actually roll out something inside your company to make these things go away.
Matt Coles:I think the benefit, the benefit of the, oh go ahead Izar,
Izar Tarandach:no, no, no, you go.
Matt Coles:I just, I think the benefit, the benefit and actually the real value of these alerts, uh, cause it's a series of alerts, this is not the first one, but this is the first one for a technical, for a weakness that we all know about. Um, is to give it some context, right? So, so it, it, I think, attempted to, I don't know if, if it succeeded, but at least it attempted to, um, if your developers are ever asking why. Do I need to fix SQL injection? It is a weakness. It is potentially severe. There are lots of ways it can be exploited for a lot of different purposes. And so the alert, um, sort of brings it to the fore. Why, why has it been a CWE top 25 for the past decade, right? Uh, why is it potentially pertinent now to be a priority? Um, so if anything, I think it adds context and maybe that's its value. I don't know if it's an alert because that's its value. Like alert implies an imminent danger.
Chris Romeo:Unless it was an alert. that was sent in 2002 and somehow went through a time vortex and only now dropped in 2024 and came out of the wormhole, boom, there's an alert.
Matt Coles:was a, it was a, it was a storage SQL injection. It was a storage SQL injection with a timer. And so,
Izar Tarandach:it was like sleep a lot, but no, really, like, let's, let's for a second look at the motivation and, sorry, at the state of the motivation, and then let's look at the action that's being proposed, right? So, okay, we agree the alert is not really an alert. The alert is more like, uh, hey, we are just joining the chorus right now, so please add our voices to the But the motivation for it, in their words, is move it. I like to move it, move it.
Matt Coles:so context wise, right? It's saying context.
Izar Tarandach:yeah,
Matt Coles:injection being used today?
Izar Tarandach:no, but that's the thing. For them, the fact that there were 2000, I don't know, whatever the numbers are for move it. For them, it was a big enough motivator to fire an alert, right? Now, we look at the action that they are proposing. The last thing that I have here. Action item for software manufacturers. So yay! After two pages we get to, okay, what should I do about the alert, right? Everybody's in DEFCON 5 here. DEFCON 1, sorry. What, what is it that we do? What, what now? Well, the action is, although the secured by design alert focuses on approaches to mitigate SQL rejections as a class of defect, That's just one part of a more comprehensive set of Secure by Design practices. Blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah. Manufacturers should fully implement the principles and practices touched upon in this alert by reviewing, shifting the balance of security risk principles and approaches for Secure by Design software. So basically what they're saying is, we are giving you this alert for you to go back and remember the thing that we talked about a couple of times, threat modeling, just do it. Right?
Chris Romeo:I wish that's what it said,
Izar Tarandach:if you interpret what came out of the, uh, of the Shifting Bar Balance document and what everybody was talking about, yeah, this is great, but you know, how do you really operationalize this? You go and do threat modeling. And I love the fact that now I have an alert that points back to something that leads to threat modeling. That's like super useful. To me, as a practitioner, as an
Chris Romeo:got to take a leap though, to get that, like you made the connection because you understand all the moving pieces between A and B, the, the, the, the, the, the points along the line, the average developer is not going to follow your path and
Izar Tarandach:So, yeah, yeah, but,
Chris Romeo:go, I need the threat model.
Matt Coles:well, and
Izar Tarandach:no, but
Matt Coles:is not the only solution here. Threat modeling is, is only part of the problem, right, so.
Izar Tarandach:But, but that's, that's the point. Uh, uh, uh. One of the new developers is going to read this, going to read the action item for software manufacturers. And go,
Matt Coles:What Izar is really saying is,
Izar Tarandach:then the next thing is they're going to, they're going to go and talk to someone who is going to explain to them. And hopefully we'll be able to make those connections that, Hey, the actionable part here leads somewhere else
Chris Romeo:Okay, let me, let me, uh, call Izar and Matt as witnesses in this case, and let me take this in a different direction, Your Honor. Um, if you were to think about the, think about the people you've, the developers you've interacted with the last five, you know, from now until, you know, five, seven years ago. And how many of them would not know what SQL injection is? At this point, if you said develop, if you, if you had a chance to sit down across from them, not if you ask a group, raise your hand, if you know, SQL injection, no, if you had a chance to talk to each one, let's pick 10 developers you've interacted with in the last couple, last five years. How many of those people would say, I have no idea what SQL injection is. I've never heard of this thing. What is it? Tell me.
Izar Tarandach:at first interaction, or after some time that I've been interacting with them.
Chris Romeo:No, no. First interaction. Like, I mean, if you've influenced them in the past, then that's great. But like, I'm trying to, what I'm trying to understand is like, is in your experience, are you seeing people not knowing what SQL injection is? Like, is this somehow opening somebody's eyes? Or like, I never even heard of this before. I don't think it is,
Matt Coles:I don't think it is. I mean, if we, if you talk about, if you talk about CWE at all, top 25, if you talk about OWASP at all, it comes up.
Chris Romeo:Yep.
Izar Tarandach:Right. And, and, but, but what I do think that there's perhaps some value in here is that the CWE At MITRE, at the site, like the source of CW, is still a bit obscure for a lot of developers,
Matt Coles:It's academic. Yeah, there's some
Izar Tarandach:But, but this thing is pointing directly there. It's trying to give some very quick context. It has a nice set of pointers here on the first page. Things that might even be, well, that are actionable. We have the OWASP, vascular injection, prevention cheat sheet here. Right? Which is pretty well looked after and has some good stuff in there. And, uh, so, I don't know, I keep going back to the alert equals action, and this is not it. So, okay, we agree that calling this an alert was perhaps a bad choice of wording, or worries me now is that, can we expect next week one for XSS? And the week after we're going to expect one for, I don't know what, so last week it was the government, yeah, the government telling us all about, uh, uh, memory, uh, safety. This week it's an alert on SQLI.
Matt Coles:Well, so there are, there have been multiples of these already, right? So this is the first one that's for technical issues, like for a weakness, but they already have secure design alerts for, um, Oh, actually this is not the first one. Sorry. They have a secure design alert for limiting default passwords. So this is not the first time that they've issued a design alert for
Izar Tarandach:but, but that's pretty operational, right? You could, you could argue that, Hey, you know what, not exactly a design thing. Just by now we learned that we shouldn't be doing that thing. And, uh, that kind of thing.
Matt Coles:well, so there are, okay. So if we're going to take that approach, then the prior one that they issued in January 31st of this year. Secure by design alert for security design improvements for SOHO device manufacturers. So that's not taking a look at a specific weakness, but a, but a device class,
Chris Romeo:But who's this getting sent to? Like, who's actually reading this? My, my, my fear is it's just people like us, which we already know. And that's, and that's why we're reacting to this the way we are, because we're like, you're telling us something that we've been teaching people for 20 years at this point.
Izar Tarandach:For
Chris Romeo:think that's part of the challenge here is like, they, they haven't found, they haven't figured out how to target an audience that doesn't know about this. Cause it certainly would be valuable if, if there were, if there are, I'm sure there are developers out there who don't know about SQL injection somewhere. It would be great if this was targeted to them, but that's my fear is that that's not what's happening though. They're just putting this out and people are just getting excited for the purposes of getting excited.
Matt Coles:Well, let's see. So this one, so the, the one around SQL injection was released because of, um, of MUVIT. The one related to SOHO device manufacturers was because of, um, Vault Typhoon. Vault Typhoon as an, as an attack, as an attacker group. Cyber actor group. So I think they're trying to tie these two specific events and use the event, uh, or the, um, you know, the attack scenario as a, um, a reminder, I I, maybe this is where the alert part comes in. Hey, we've identified this particular scenario where this, this actor or this vulnerability or this malware, um, or whatever is, um, is impacting because. of this flaw, of this design flaw, take a look at it. But it's, but we're the primary, I mean, I think, I don't know anyone else who has talked about this. The only reason I know that other people know about it is because I've posted about it, uh, at, at my work just because, you know, hey, CISA came out with this alert. Let's take a look at it and revisit this issue and see if it's See what you can do about it. General guidance at the very least and some action hit list, but not, uh, I don't know anyone else's like we may be it and people may be like, oh, CISA has alerts, really? We should go take a look at those.
Izar Tarandach:So wait, what, what's, what's the next step here? I go to the post office and I see the poster on the wall with the FBI top 10 wanted, am I going to start seeing now in every kitchen, in every kitchen, in every organization out there, top 10 FBI wanted flaws.
Matt Coles:Hey, you know what?
Izar Tarandach:That could actually be a good one.
Matt Coles:That would work, except for who, who from security goes physically to the post office.
Izar Tarandach:No, no, no, no. I mean in every kitchen, in every organization out there, you know how you have the OSHA, how you have the OSHA posters in every kitchen? You would have like the FBI one of the top 10 flaws.
Matt Coles:That would be an interesting marketing. That'd be an interesting marketing idea. Some, some champion programs should implement that.
Chris Romeo:Yeah.
Izar Tarandach:or some threat modeling company or something, I don't
Chris Romeo:well, you know, then just start going to post offices and sticking it on the wall and see if anybody notices. So yeah, I mean, I found on the Secure by Design alerts page, it does acknowledge, Matt, what you were saying about what these are for. Alerts are released in response to threat actor activity that further demonstrate how Secure by Design software development can help reasonably protect against malicious cyber actors successfully exploiting predictable and well known vulnerabilities. So,
Matt Coles:So if anything, it's, it's CISA making a real world connection. Adding, adding opportunity for those of us who are, who do cyber security defense, right, application security or otherwise, to, uh, you know, sort of get this back in front of people with a top of mind and very pertinent and current. Reason for fixing.
Chris Romeo:but the, I mean, the challenge is this is a, this is a communications challenge. Nobody's, no developers coming to the Secure Digital Design Alerts page at CISA to, to find the latest things to talk about over lunch.
Izar Tarandach:here's my question to you guys. If the clock turned back, I'm guessing that this took months on the making. But let's see that you are responsible for doing this. You work now at CISA or the FBI and somebody comes and says, Hey, this is the next thing that we have to do. What would you have done differently? How would you have expressed the same message out in a way that you would be happy that people would consume it and consume it right? Brilliant.
Chris Romeo:I would have reached out to OWASP and said, can we do a joint communication release with this, which is something that OWASP wants to do. They're, they haven't been very good at it, but they've got the biggest audience of people that care about this stuff. And then even that joint release, uh, get, try to get some press from it, but then also ask the OWASP membership. to share something, see if we can magnify this to the millions and millions of impressions across various social things. Because now we're talking about something that's actually going to have, it's going to move the needle a little bit. It's not going to move the needle. We're not going from, from 10 to 90. There's no way, but maybe we're going from 10 to 11. And that's probably enough for one simple release. If you could move the needle 1 percent across our industry, that's actually probably a really big, that, that 1 percent is probably gigantic. Even if 0. 1%, if you move the needle 0. 1%, you're still, it's still worth the time you put into a single release like this and a joint partnership to get it out to the world.
Matt Coles:Yeah. I would have done, would have taken the same, taken the same approach, just probably with a different group. I'm, I would probably reach out to the, the, the, um, maybe the P certs, you know, work through first or the, or the ISAC organizations. Um, you know, the, cause those folks are, the ISACs are tend to be, I think, leaders and others who would be able to drive the message down into their organizations. Um, where information sharing like that is, you know, I mean, it could be more broadly than that, but, but you need the, you need a partner, you can't rely on direct mail. They, they, or they cannot, should not be relying on direct mail. They should be relying on. Um, uh, collaboratives who have information sharing, uh, in place already
Chris Romeo:your idea about the P certs is brilliant. If you could get, imagine if every company released a P cert. That just pointed back to this and said, Hey, we just wanted to let, you know, this thing from CISA came out and we're, we, we support this and we're trying to implement this. We we've been working towards, we always work towards implementing this in the products that you get from us.
Matt Coles:And P certs, P certs may not be, I mean, for most organizations, P certs probably are not the right place to put that, but it, there's no, there's no good, um, not that I'm aware of, any good, um, You know, folks who do, who do pre, pre, you know, pre release work, defense application security work. There's no equivalent organization that I can think of that would be as broadly covered.
Chris Romeo:Yeah. So these are, how would you solve it now? You've heard Matt and my solution.
Izar Tarandach:I don't think that I have a different solution. You guys have great, uh, great points to, to, to put in there, but now I'm thinking about the matter of urgency. I'm going back to calling this an alert and thinking about what Matt put out there. PSIRTs, they, they live in state of alerts. You want to know who works on a PSIRT, look for the people running around with their heads on fire. But now I'm asking myself if an alert like this plus the internal authority of Apicil, plus some measure of threat intelligence. Does that build a perfect storm that AppSec can come up to the internal developers and say, Hmm, perhaps it's time for you guys to actually listen to us on this?
Matt Coles:Is, is AppSec, so in your, in your experience, is AppSec tied into the threat intelligence teams in that
Izar Tarandach:No, and that's where I'm thinking to myself that perhaps that's a tie that should happen in a different way. Because we're already tying on the prioritization side, right? We are doing KF and PSS and all that good stuff, and it's a very rudimentary way of looking at threat intelligence, but it is one, right or wrong. So, AppSec is already looking that way for the much needed prioritization. But now I'm thinking, I'm thinking about this more in terms of, there's a difference between telling someone that they have to eat vegetables and actually selling them a piece of broccoli. And this to me,
Chris Romeo:That's a brilliant, that is a brilliant illustration of this point. Say that again. Say it one more time.
Izar Tarandach:I can already see it on LinkedIn with two heads. Just don't use the emoji. So what we've been doing for all this year is telling people that you have to eat your vegetables. What we have here, it's two very separately and now jointly well opinionated and well regarded organizations trying to actually sell you broccoli. Right? So not only you have to eat your veggies, you have to eat this piece here, this specific here, that's going to give you all that you need. So,
Matt Coles:They're magic beans. Is that what you're, is that what you're selling is magic beans?
Izar Tarandach:Oh, that's the thing, we
Matt Coles:We know how this ends, right?
Izar Tarandach:no, think about this, think about this, we have been sealing, we have been selling magic beans so far, right? And some people, we even managed to get those beans into the earth and put them, put some water in there. But I think that as a collective, we have still had a lot of obstacles in getting those magic beans to actually go to the castle in the clouds. Or in the clouds, sorry. And that's where we want to go, right?
Matt Coles:They're hydroponic beans, aren't
Izar Tarandach:yeah, so now this comes and perhaps put some water on top of those beans. Because people still love the appeal of authority, right? So now we can come and say, hey, remember when MITRE was talking about this and you decided that it wasn't important enough for you? Remember when, um, I don't know, CISA itself was talking about this and you didn't think that it was important enough? Remember when I gave you the book by Brooke and you didn't think it was enough? Or the book by Adam and you didn't think that it was enough because you're not writing the next Star Wars? Now it's the FBI telling you. Is that important enough for you? And for some people that will.
Chris Romeo:I don't think so.
Izar Tarandach:Perhaps.
Matt Coles:So here's the problem, uh, as a Sorry, my, uh, my assistant decided to jump in there for no reason. Uh, so here's,
Izar Tarandach:is always a reason.
Matt Coles:Yeah, I think here's, here's the part of the problem is, um, so, so the, the alert says, well, move it is move, move it as a problem and they use SQL injection, but who needs to know that? So corporate companies need to guard against move it, but the companies that need to guard against the thing that move it leverages is the developers of move it or the developers of software who use SQL, right? And so they're a little bit removed from, from the, the recipients, right? They're the recipients are removed from the, where the, where the action happens,
Chris Romeo:Let's uh, let's change gears for a second. Let's get practical. So, I was making fun of this at the very beginning as far as not being actionable. Because there's nothing, there's nothing you can do and there's nothing you can really take out of this to, to, to create change inside of an organization. So if we're trying to say, say we, let's just make a fictitious organization. I love to use Acme Corp from my cartoon days. Um, so we've got a, we've got a fictitious corporation, Acme Corp, and you come in, you are, you know, running AppSec for them and, and it's a relatively new program. And SQL injection is one of, is the biggest problem that they have. How are you going to organizationally change. The response to SQL injection. How are you gonna, how are you gonna squash SQL injection programmatically? Technically? Um, procedurally, if I could think of how the word that process roly, but that's not really a word. Um, but yeah. How would you guys, yeah, I mean, how, how would you guys, where, where would you start? How would, how would we do this? How would we, how would we actually add a paragraph to this that was actionable?
Matt Coles:Well, we know how, so first off, you're, you're, you're starting in this scenario with, we assume that SQL injection is the biggest problem.
Chris Romeo:I'm just, yeah. I'm just picking on it because that's what the alert's about.
Matt Coles:So let's assume for a moment that we've already, there've always been, has already been some work to know where SQL is being used and more specifically, Uh, we have databases, they are SQL databases, although in, I guess in theory, no SQL databases can still be susceptible to SQL injection like attacks. Uh, and so, um, but we know we have SQL databases, therefore we know we have a potential for SQL injection, and we know what call, code calls or reads from, either reads or writes from the database. Right. That has to have, so that, that's the first thing, right? We need to start itemizing where SQL injection can occur,
Chris Romeo:Okay, so inventory.
Matt Coles:right? Inventory. And obviously with that should come architecture and design. So the beginnings of a threat model, if you don't already have a threat model,
Chris Romeo:Does inventory in your world include detection? Is that how you're inventorying? Are you talking about inventorying use of SQL or detecting and inventorying where the SQL injection problems lie
Matt Coles:uh, I'm talking about in, I'm talking about, um, identifying where SQL injection can occur. So that would mean any code that calls into the SQL database. Okay. For any interface to the database, right? Because that's, that's where you can have SQL injection. That doesn't mean you do, it just means you can, right? And so knowing that you have, uh, you know, and then figuring out, you know, is that publicly accessible or not, right? Or how do you get to that database is important. That gives you your, your scope of effort
Chris Romeo:So we've got our attack surface scope.
Matt Coles:Yeah. And then you can probably do, you can probably do programmatically, right? So if you have, if you're writing your own source code, if you're building code, And you have static code analysis running, or if you have telemetry on your database, um, or you have a database access layer. Uh, that allows you to, to get some, some metrics. I'm sure, I'm sure that's, I'm pretty certain that is, that is, uh, automatable. Um,
Chris Romeo:so then after that, so now we have to figure out, so I think in this, in this example, we can assume we, we've already, we already know SQL injection is our biggest problem, but we would have some type of detection we would have to do so that we could use tooling, right? We want, we would want to use tooling to find the easy ones. Right? Like we don't really want to code review our entire millions of lines of code looking for SQL injection. We may have to do that for some of the more difficult ones, but my thought is we would run some type of static analysis tool to try to find the, at least the low hanging fruit. Right? Like let's knock out the ones that are easy to find.
Matt Coles:Yeah, well, I mean, that's, that is, I guess that's, that needs to be part of it. When you're doing static code analysis, you identify that SQL injection can occur and may find vulnerabilities in, in terms of using, you know, non prepared statements or failing to input validate, et cetera, right? So. That helps with the inventory part. That gives you your scope. Bark!
Chris Romeo:And then there's an education component, because if we have this many SQL injections, people don't understand what it is, how it impacts our code. And so there's probably a smaller piece of a bigger education move. where we focus in on SQL injection and we provide training on it. We go to people's standups and talk about it as security people. We, we try to, we try to spread the news far and wide about this problem, SQL injection. The, the, the important piece there is to, is to tie it back to why do we care? Why do you as a developer care about this? I think that's the, the crucial education piece. It's not developers are smart. You can tell them prepared statement and they'll go figure that out. You don't have to show them how to do a prepared statement. But when they, and, but for me, I've always, I've always had big success when people are like, when they understand the why behind what, what's happening, why they have to do it. When they don't understand why, that's just, you're just asking them, you're just basically saying what's in this alert. Just here's a bunch of facts that you should know. Why do we do this? We do this because if we have SQL injection in our production code, our customer data can be captured. Exfiltrated from our systems. And we may go out of business if we lose all our customer data. Now developers are more interested.
Izar Tarandach:two things to add to that. First of all, I agree with everything that you guys said, but, not but, and with what Chris said on developers being smart and us being able to tell them, hey, this is the right way of doing it, so please use it. We have to be also careful with the fact that there are some super smart developers out there that will not think twice before they say, that is the way, it's not performing enough, my code needs to fly, so I'm going to write my raw queries myself, thank you very much sir, and reintroduce the thing with the certainty that we put all the mechanisms in place, so that's one. So, Mind the outliers, and second, guardrails. So we have design guardrails where we can tell people this is how you deploy a database, this is how you separate roles and access, and try to not stop SQLI, but to at least mitigate the effects, and how you plan your tables and cross things so that you don't have like, Two permissive select that brings data that lives in a different table, but it's indexed by this one and whatnot. And then we have the operational guardrails, which are, hey, this is how you deploy this thing, and this is how you use this thing, that should cover the smart and very smart developers as well.
Matt Coles:And I would, I would add, I would add to that just, um, you know, so the, the, the next piece to that may also be taking that inventory and taking the other things, the guardrails you're talking about, doing the analysis, doing some analysis to say, are, are multiple pieces of code calling into the same
Izar Tarandach:Yep,
Matt Coles:the same facility and actually putting, uh, a common construct in place that they can call, right? So, so minimize, minimize the code paths,
Izar Tarandach:Yep, eliminate the class by
Matt Coles:Yeah, build, give them a building block that they can use. So, so you only really have to deal with the, the super smart ones who are going to go outside the bounds, right?
Chris Romeo:Yeah. And
Matt Coles:mind, mind the, mind the outliers, Izar, that you had, that you highlighted?
Chris Romeo:outliers. That's, well, that's where, that's where ORMs, like we talked about that in a previous episode, that's where ORMs come into this. And the way that I'm crystallizing all of this, and I've been thinking about this the last number of weeks, it really comes down to patterns. So you need to provide a pattern for database access because there's no reason, and it can be a paved, you can even call it a paved road. We could, we could go into that analogy. It's not a guardrail. I mean, you have guardrails to ensure that people are staying within the lane and how they're accessing databases, but you could also have a paved road pattern that says, here's how you use an ORM and here's the things that you can do to set it up in such a way that. You are maximizing your protection, but also maximizing your performance of the code that you're writing. And so I think it, it really, that pattern is, is a very powerful construct. And it's not like it's a new thing in software design. It's a new thing. It's just a thing that nobody really uses. We don't use it enough. It's that idea of a security pattern that can just provide the pieces that we need.
Izar Tarandach:We
Matt Coles:do you consider, oh, go ahead. I was, I was just really from a technical standpoint, do you consider a, a data abstraction layer on an ORM to be the same thing
Izar Tarandach:I see that as the implementation of, one implementation of the guidelines, if we call them paved roads or guardrails.
Chris Romeo:Yeah. I don't see them as the same though. I don't see a data. So the, and,
Izar Tarandach:It's not the same, it's one instance.
Chris Romeo:Yeah, well, the data abstraction layer, you're writing yourself. Right, it's, it's developers. Now, I would say if you have a data abstraction layer that's provided by a third party, like as a library, like a very well battle tested service, then that's, you're kind of just mixing the names of things. A data access layer, um, That acts like an ORM is an ORM. But if you're creating a data access layer, that is a custom piece of code your developers are creating so that they can funnel database requests through it, then that's where I see some difference between the ORM and the data access layer.
Izar Tarandach:I don't know, the whole thing of the paved roads and the guardrails, and yes, there is a naming issue here. Some people, me for example, I refer to a guardrail as any kind of safety device that I can put in front of a developer, that's going to lead them through a paved road. And we, we talked about this in, in previous episodes. The page road for me is collective experience and, and empirical data show that this is the safe, secure way to go. Guardrails,
Chris Romeo:paved road ahead that what makes developers use it as it's easier than it has to be easier than them doing it by hand.
Izar Tarandach:we, we have to be honest, not always. Right. We, we, we try to make it simple, but not simpler than it needs to be.
Matt Coles:Maybe
Chris Romeo:didn't say simple. I said, easy, simple and easy are two different concepts.
Matt Coles:need a, we need a bowling alley analogy here. This is the bumpers that you put up. So you don't get the gutter.
Izar Tarandach:Yep, yep,
Chris Romeo:Security gutter ball. Yeah.
Matt Coles:the things I want to just highlight from the, from the, the, the alert, the actual paper that they refer to is, um, is actually to make sure that when there are SQL injections, so realizing that there will be escapes and there will be issues. That they get, that they get classified properly. CVEs get associated with cws and cws. are what's used for the analytics for things like the CWE Top 25 and, and other things, but also maybe how, um, how you, you, how they get identified as examples for things like developer training or retraining or other things. And so if you, if, if vulnerabilities get created, then they're not properly mapped to the correct CWE, then we're missing important information. And so one, one of the really little tidbits that's in the, in the. The security design doc that they, that they issued for this is make sure that you associate the right CVEs with the right CWEs. In particular, if you have a SQL injection vulnerability, use the proper CWE so it gets classified correctly. And that's, that's really important. That's first off, that's recognizing there will be escapes, right? We can't solve, we're not going to solve this day one automatically just because the FBI said, um, you know, this is, is important. But also then now putting the, putting the, getting the data correct. In CVE, and notwithstanding any of the current NIST issues with the CVE database, which is probably worth a future discussion, that data can exist so we can do the proper analysis.
Chris Romeo:All right. Well, I think this is a good place to, to, to end the conversation on this SQL injection design alert, I think to summarize, we don't disagree with anything that was said in it. We just, we were just struggling to figure out how it was going to have any impact across the industry. And we'd love to see it have a giant impact. As we said, when we brainstormed about ways they could, they could partner with people like OWASP to get the word out, to put out a joint release that says we're all taking this thing seriously and we need to finally squash it. That would be a powerful thing, but that's not what we're, that's not what appears to be happening with this thing. So, uh, CISA, you know, find a way to do it. We were, we're behind you. We're not, we're not against you. We're, we're with you. We just want to see, we want to see these things maximize their impact across our industry. So, uh, folks, thanks for listening to another episode of the security table. Tune into wherever you get podcasts from to find the next episode.
