Reasonable Software Security: Do We Really Need DAST?

In this episode of the Security Table, the gang discusses reasonable software security. They explore whether current application security tooling, such as dynamic application security testing (DAST), provides a decent return on investment. The group acknowledges that the value of security tools depends on the organization's context and specific needs. They also touch on the importance of understanding a company's risk appetite and how this can inform what is considered reasonable security. The conversation concludes with the idea that reasonable security is not constant but a function with various arguments.

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

Transcript

Chris: 0:10

Hey folks. Welcome to another episode of the Security Table. This is Chris Romeo, joined by my good friends Izar Tarandach and Matt Coles. And today we're gonna tackle an issue that came up as we were walking our way through the National Cybersecurity Strategy. We finally made it through three episodes, but we came up with this concept or this idea of reasonable software security, and I don't even remember how we got there, but this is an issue that I really want to tackle. I want to understand and discuss and debate what is reasonable software security, especially in the context of thinking about all of these different national cyber strategies and secured design and secured by default documents and things that are coming out. We can even look through the lens of are those reasonable? But I think based on the experience of the group that we have assembled here, I think we can come to a pretty good idea as far as what's reasonable. We're gonna start with an example though, because we want to illustrate this point. So I did a talk at RSA conference, the state of the Union of application security last week. I guess that was this week, but it'll be last week when you listen to this. So pretend you're in the past or the future, whatever you wanna do. And I made a, I put a slide up that showed various tooling that we have on application security, and first of all, one of my big points was too many people think AppSec equals tools. That's a whole other episode right there, but let's pinpoint this one particular issue. I drew a line, and under this line I put the things in application security tooling that I don't think provide a decent return on investment today. And so one of those things that I put on that under that list was dynamic application security testing or dast. And the reasoning that I don't, and the reason I don't see the value in what das can provide, and ultimately I will say I think DAST is unreasonable, is I just don't see the return on investment for the findings that I get out of running a DA tool. That's one issue. Second issue, I don't see DAAs being able to run at the speed of DevOps. So if I can't do something at the speed of DevOps, like I can do pen testing, I can do bug bounty as a secondary way of checking my live applications for known security vulnerabilities. But anything that I do in the pipeline perspective, it's gotta be able to be fast enough to keep up with the speed of software development that I have doing. And so eza. Matt, am I being unreasonable? Here, like what are your thoughts on this idea of me making this statement that DAT falls under the line as far as what people should do from an application security scanning perspective?

Matthew Coles: 2:51

I think you're being unreasonable, Chris. And I think it's important what you're highlighting is really not the, not a security problem, but a business problem of diligence and assurance. Versus speed. So DA sast. If we're gonna look at software applications, secur static application security testing. Traditionally code analysis, but other things as well. And desk dynamic application security testing. Traditionally whether that's web application or vulner network vulnerability scanners, they are slow because they're thorough or they can be tuned to be thorough. And that builds up assurance. So there's a business driver to be fast to deliver code. But if you do that and you not take into account assurance and assurance does take time because, developers, you have a lot of developers writing code. They get either compiled or interpreted by a various frameworks and integrate with other components. so it takes time to do that analysis and. Doing that analysis gives you assurance that security I know great gives you assurance that security is present. And so you can make a informed risk decision. We've come up with, we've talked about that in the past I think that this directly goes to the question of what is reasonable security? If you ignore those aspects and you don't focus on. If you don't, if you annoy those aspects and you avoid that kind of analysis, then you may be making unreasonable measure unreasonable an unreasonable approach deferring your security until later. And the important part about the So I'll leave it there and

Chris: 4:41

so let me.

Matthew Coles: 4:42

in if you

Chris: 4:43

Let me react to a couple things first and then use our comeback around. And I just want to let you guys know, I can translate dog. And your dog was actually agreeing with me and so I, you probably didn't know that cause you, but I could. That's what I could hear there. So I want to, I wanna be careful to separate SAS and DA. In this modern age right now, because yes, there are SaaS tools that are thorough and run for a long time, but there's also SaaS tools that move at the speed of DevOps that can exist in the pipeline, that can run the checks and things that they need with a decent amount of speed so that you don't have to do them out of context. And

Matthew Coles: 5:17

are right? That's much.

Chris: 5:21

They are graph, but I mean they're all effectively, if you go deeper into SaaS, right? You start creating code graphs and things like that and you start looking for reachability, that's a different level than you gotta de decide what is the definition of SaaS, right? Is it a full code graph and software composition analysis capabilities where you're bringing libraries to the graph and you're be able to analyze everything? Or is it. What's the purpose of the security school security tool running in the pipeline. And so that's why, that's my challenge with das. Could, can you, if you could give me a das tool that will only run and check what was changed with my code commit. Now we're starting to talk about something. Now we got something. Cuz you could do, you don't have to scan the whole application, you could scan the whole application out of band. But if you could scan just what I changed. Now we're starting to talk about something that can move with the speed of DevOps, but I don't think any of these tools do that. I've talked too long. Eza, what are your thoughts on this?

Izar: 6:21

So in my constant search to be a better security or security professional, I am really trying to stay away from absolutes. and think that this is a great discussion, because of that. Cause at the end of the day, the question is reasonable to whom? So we are talking about, it sounds like we are talking about this hypothetical organization where you have DevOps running at the speed of light and things happening at the right way in the right order. But, As professionals, we are serving a spectrum here of people. We have the startup with one guy, and we have the multinational with thousand people in the security team. And then comes the question, what's reasonable to whom in that spectrum? Perhaps to that guy the startup guy that is his way to check for a 10 he runs it once a day. Bit of his development and, that's reasonable. And the other side of the spectrum, as you said, it's not Perhaps we need is again, calibrate when are we running this thing? Why do we have to run it against the whole product? Going to, to your point of just go to the the changes perhaps. I don't know. I might be thinking of buying the sky vision, but. we are asking so much of the developer, why can't they like run it locally on whatever changes they know that they made? They can point it to the right place. They can point to the place where the, so it, it's just one more unit test, one more thing in their testing workflow. So my thought is that it's not a matter of you are being unreasonable or not. I think that your point had a very real. with the category of tools, right? But the answer is not in let's change tools. It is, let's change how we use the tool. It is not is it bad for everybody? Is it good for everybody? Is it good for enough people so that it's still deserves a place in the

Matthew Coles: 8:27

And maybe we should just take a brief moment to talk about, cuz Chris, you raised the notion of there are different types of SaaS tools, right? And grip all the way through, co code, code graph generation and reachability and code coverage tools and other things brought in into that. DAAs, I think we have a similar situation with DAAs, right? Just based on the nature of the vulnerabilities that it, or weaknesses that it tends to find, right? So on a per pa, let's say, web application scanners is a good example on a per page basis. So if somebody's gonna load it, if you go to a webpage and you go to a particular webpage, you're gonna find particular problems with. Cross site scripting, for instance, that may live because of a form element that's present on the page or XML injection or other things that may exist specifically because of the page that you're looking at. You go that URL or you look at that page. But there's a whole class of issues that das tools can find, which require. Logic, migration through the application when that requires authentication or other activities to get to the page in the first place, that sets up the conditions for the vulnerability to exist, And so it, it's, it was, it's certainly unfair for me to have said that you're unreasonable and as are rightly called out, that what Really? It's a real much more nuanced than that. right? It's this notion of throwing the tool at a, at something and require it to be and accurate in all cases as Tailoring it a particular use case to and I'll call again to the assurance case. To meet the assurance claims or to meet the assurance objectives that you have in terms of what you consider as reasonable from a commercial standpoint. Versus what your customers or regulators or others may, might consider reasonable from a due diligence standpoint.

Chris: 10:14

Let me reflect on my experiences with das and I'd love to hear if either of you have had different experiences and perhaps I, obviously my experiences are jing, my, my conclusions here, right? Like I can only reflect on what I've experienced and what I think, what I've heard other people talk about, but. So a number of years ago I had a requirement procurement requirement that I had to have D for a web-based application. I immediately. I didn't want to do it, but it was a procurement requirement. And I didn't have any choice. I had to do it. And so I went and I said, okay, I'm gonna look for, because I, I'm not a checkbox compliance person. I like value for my dollar, especially, when you don't have a gigantic budget. Like I want, I wanted some return on my investment here. I wanted to see value coming out of this. And so I looked at. All the different providers of das tools that I could find in the market. And I noticed a number of different trends. One, nobody could really scan a single page application. And we live in a world of, and we have lived in a world of single page applications that are driven by React and Angular and all of our other frameworks for a number of years now. And so I noticed there was definitely an innovation miss on being able to understand and scan. Something like a single page application. So that was my first challenge. And but and that was really my primary challenge. I was looking for value coming out of this thing. What am I gonna get? I wanna, I'm gonna spend this money, it's more money than I wanna spend. I wanna see the results coming out of it. And I can say that running that thing for a number of years as a contractual requirement from a procurement team, I never got a single finding out of it of value. And maybe I'm just driving teams that are really good at AppSec, we know that's not the case. Like developers make mistakes as they go. I know there were problems in that thing because we found them with our other tools, with our SaaS tools and things that were running in the pipeline. We found issues, but I just never saw the value proposition there. And so I'd love to hear if you guys have different experiences, like I'd love to hear your side of this cuz maybe you've had a really good impact. From DAAs and you can help me to see this a little bit differently.

Matthew Coles: 12:28

So I think I don't know that I I don't, not sure that I would be able to, Alleviate what you were talking about, but I think value from das, first off, it's probably important to mention, so single page applications that you're talking about. Wanna make sure single page or single Because obviously you may have the URL that doesn't change and you're navigating through an HX application, for instance or that has multiple pages that are within the application. But the URL itself never changes. So things like spidering doesn't work very well, right? You have to navigate through the site. And that's a challenge that requires a human to do, to train it, or you provide a postman collection to make that tool effective because you have to help it. There's nothing on the system that, that gives a hint as to what the navigation should be through the system, right? There's no page tree in that respect. So those techniques, I think, get developed over time that, that help, help alleviate that problem. And I would highlight just a co one tool in particular. And actually there's two tools, right? There's Burp, burp Suite, which, which pen testers tend to use, and then Oasp Zap, which do very well in those situations if trained properly. And I know that there's others out there tools from formally ibm m and ver Callis yeah callus as well. Various dynamic web scanners that can be trained and once trained, they may be more effective. So part of this is the tool relying on the tools to automatically do everything. Correctly has changed because the technology has changed, right? The URL used to be something that mon got modified every time you make it a click and that no longer happens. So the tool had to and you can't really solve it, I think, in all a hundred percent of the cases. And so that's probably the, maybe, actually, maybe that's the biggest comment I wanna make, is the technologies.

Chris: 14:18

The training side.

Matthew Coles: 14:19

The technologies that were, that are part of the stack have evolved and the tools haven't always kept up to speed things over time.

Chris: 14:27

Yeah. Let me react to that. And then he, I wanna come back to you, when I, first of all, I love Owas app and I love Burp. Neither one of those was created as a DA tool. right? We, they're bread and butter, zaps, bread and butter. We all used it when we first learned about Zap when it first came out. It's a proxy, right? It's a proxy that lets me turn on the proxy, stop a request as it goes out, look at it, analyze it, modify it, hit the button to let it go, get the response back. I can debug. I can look for issues in the way that data's being sent back and forth. And so Zap then grew to become a DAAs tool. But it's bread and butter I think is still in the kind of the manual testers. And I think Burp is the same way. I don't think, I remember Burp starting as a more of a pen testers tool that you were using to modify requests and things and have all the and they're great at that. All the tracing and being able to track past things. I did, oh, I can't remember what I did. Oh, let me look in the history and I've got all that there. But yeah but I love both of those tools, but I don't think of those as das first tools. I think of them as das second or maybe third or in their priorities.

Matthew Coles: 15:35

but quali, Qualis and other tools have adapted to those changes in the technology as well to, to support things like training through a, through an application, not relying on discovery. So discovery being technology here, that, that allowed you to not get or caused you to not get value most likely out of the tool because of the nature of the

Chris: 15:54

Yeah.

Matthew Coles: 15:55

Right.

Chris: 15:56

Now I would expect the technology at this day and age though, to be able to, I shouldn't have to feed it a bunch of manual work that I did to understand, like I could probably, like within six months from now, I can point chat G p T at it until chat, g p t to use. Its, has browsing capabilities. Now I can tell, I can point it at that web app and say, tell me all the different routes that exist. Create a route map for me from that.

Izar: 16:23

so here's the thing. I am five seven, which in barbarian unit is one 70 centimeter meters. And as such, am a big lover of low hanging fruit. And I think that's

Matthew Coles: 16:39

You should mention that your, you should mention that your martial artist as well. Just to put this in the context,

Izar: 16:44

so the, my, my point here is that, you know what, again, we you were, you guys are going towards the The medium to advanced parti partitioner in there, the one that's able to get a proxy and elevate it to a desk like tool or the person who's able to craft their own the interactions in the requests and all that good stuff. But again not the whole word is that some people do need to point at one url, click a button, and get something at the end of the day. because that's where they live. And I think that it's good that we have that solution for them. And while I do agree, I'm huge fan of both Burp and Zap And God, the way that zap has advanced in the past few years with that and all that stuff it's just mind blowing. It advances towards a point where you need to, sorry, almost be a pain tester to take everything that you can out of the tool. And have to realize that, especially ourselves as trainers and educators and other good stuff, we have to realize that the tool itself has a role in both providing the low hanging fruit and being a vehicle to, to teaching people and to training people to go to the next step. So I think that it's good that we have those, simple tools and by God I would never call web inspect simple in, in any way, shape, or form, but But think that it's good that we have those engines that almost could. That, that we can point people to and simple applications to and still get something out of it. It's not oh, I don't think that this can give me anything useful, or, oh, it, it didn't give me any findings, so that means that I must be not. We all know that not where things leave, but to be able to say, Hey, at this time, what I can do with this, with the resources and knowledge that I have, I think that's pretty reasonable.

Matthew Coles: 18:46

You should also probably keep in mind here the reason for Running das, you started this Chris, with the reason why you ran DAST was because there was a checkbox requirement. There was a procurement requirement. You must run

Chris: 18:59

I was being forced.

Matthew Coles: 19:00

you're

Chris: 19:01

was being forced to.

Matthew Coles: 19:02

But if you had, knowing if you had a webpage single. If you just had a single webpage application. You may not choose to run a tool like that because it would be too expensive, not enough value. Cost benefit wouldn't work out and. There's other means like analysis or even manual code review that can be just as effective to find the same problems rather than spending oodles of money on a scanning service or scanning tool. And some realism, I guess some common sense needs to be applied eventually here of what is the best. Tool, and I'm using tool more broadly here than something you buy. But what is the best option for finding, for meeting the goals, the objectives that you have with respect to security based on the technologies that you're using? And so with that, that's the, that should be part of what is going back to reasonable security, right? Reasonable security is, there's a set of best practices that says if you're looking to do x. Run, run or do y and you may have a collection of those things and should take into account,

Izar: 20:09

it. Is

Matthew Coles: 20:12

is it?

Izar: 20:14

let's go back to that later.

Matthew Coles: 20:15

But the question of what is reasonable should be based on this X versus Y thing what could, and what should you do? Versus what will you do because of all of benefit analysis that gets done and the value that you get out of it directly. Back to your point, Chris, about I wouldn't run desks because wasn't gonna get much value. It wasn't seeing much value out of it. But I have other things in place, other defenses and other techniques that I applied that can give me the exact

Chris: 20:44

And that's where I was. That's where I was, like I, we had SAS and SCA with every commit, every PR that's going by. We had code review happening and we had rasp agent running in the runtime of the application itself,

Matthew Coles: 20:57

a waff, would assume

Chris: 20:59

no.

Izar: 21:01

Look

Chris: 21:02

no, that's a whole other don't get me fired up again. I was supposed to constrain this to DA and not, you just threw that hand grenade to me and I caught it and I went Yes.

Izar: 21:12

So ca, can we agree that at the bottom line? Okay. I think that we can safely say that the best security tool there is out there is a very experienced, very talented security engineer that can find a problem, create a POC that proves it, and point to the line of code and say, this is the solution that needs to happen in this line of

Matthew Coles: 21:31

And is a robot

Izar: 21:32

Can

Matthew Coles: 21:32

And is a robot who can work 24 7 and be infallible.

Izar: 21:37

Later. That's the next step.

Chris: 21:39

that way. Infallible.

Izar: 21:40

would be the, no the best tool would be that person doing those things right? And what we are constantly trying to do is create some way to multiply that capability Millions.

Chris: 21:51

Yep.

Izar: 21:52

and that's where we start failing because we have to reproduce a lot of talent and a lot of conceptual stuff chat PT apart, it's still very hard to do. And then we go to those absolutes that my cest found, this set of things my best found this set of things. Mayas identified this set of things and my resp complied about this set of things. What I'm lacking here, and that I think would go a lot towards that best of all best tool is I haven't seen yet something that brings together all those and says the amount of evidence that I have that this thing is a true positive based on all this sensors. Is this much.

Chris: 22:41

That's why

Izar: 22:41

keep talking in silos. I'm running sas, I'm running desk, we are talking best each other in the tools.

Chris: 22:47

One of the other things I talked about in my RSA talk was like, I see SAST and SCA coming together. I don't see the necess, the necessity of two separate tools.

Izar: 22:58

Yeah,

Chris: 22:59

Doing there should be a, I don't know what we would call it. We'd have to find a way to blend the two sets of acronyms together into something funny, which I can't think of off the top. off the top of my head. Or Nast Did you call it nast? It's Nast sct. Oh, I like that. Ooh, you heard it here first. SCT is a new category of application security tools. But you think about to, to the point I made earlier about we're talking about SaaS and getting to the code graph. right? If you're going to that level already, you might as well just plug the dependency information into everything that you were able to exhume from the source code that you went through and scanned to build the graph out. Like why not pull the dependencies and whatnot into it, into one big picture, and then find ways to look through the whole thing and look for challenging points. So I think that's

Matthew Coles: 23:43

we should,

Izar: 23:44

people will.

Matthew Coles: 23:45

sorry. We should plug a tool that actually does that. If you, if we're gonna talk about that. Veracode.

Izar: 23:51

Which is

Matthew Coles: 23:53

yeah. Has an offering through their SaaS platform that has, that provides that correlation, I believe, or at least it used to. I don't know if it still does, but it used to.

Chris: 24:02

If we're talking about, we're talking about live tools, then let me tell you like what kind of got me thinking about this. So Shift Left has recently, just in the last month or two, rebranded as Quiet ai. Q W I e t, but they are, they're doing two things that got my attention. One of them is this code graph with this full on kind of combination of dependency, vulnerability information, and source code vulnerabilities. They've also are the first company that I've seen that's applied the AI model directly into the tool. Now they did it. I asked cuz I had the same skepticism you did, Matt, that I just saw on your face. I asked them, I said, Hey, everybody's saying this. Like, how'd you get there? How'd you get there so fast? They had a, the whoever funded them had a partner company that was doing AI models. And so they were able to take some existing work and apply it to apply whatever source code scanning knowledge. I don't understand, I'm, I can't even pretend like I understand how all that works, but they were able to extract that into a custom model that then they attached to their tool that's in production today. And so that's what really got me thinking about that whole process though, is that they had already started to bridge SAS and sca and I saw another number of other vendors at the RSA conference that are. Either building their own tools and giving you an all-inclusive pipeline that has SaaS, s e a, other things that they're, they've built them themselves. So they're all fully integrated to begin with, to ease our's. Point about, silo silos and the challenges we have here. But then you also have the challenge of there's no longer best of breed. There is only, oh, maybe your SAS is great, but your SCA is, eh, not that great. Now I'm locked into your pipeline. So that's.

Matthew Coles: 25:49

stack B, not trick from

Chris: 25:51

Yeah. And this is Chris Romeo reporting from the RSA conference floor. Like I felt like I just gave you all the dump of what I saw, but

Izar: 25:57

but wait. Brooke told us that there is a company there that said that they were going to protect everything. So I guess that we are out of a job,

Chris: 26:05

I guess we can just end the podcast here. This will be our final episode because we have heard that security has been solved and we are able to just maybe take up, I don't know what we would do. What would we do with our time? Who knows? Who knows?

Izar: 26:18

Next week, privacy

Chris: 26:20

oh, okay. So if we're, listen, we're already talking about tools I saw at RSA conference. I'm gonna keep going cuz this, I saw something interesting that might catch your attention that I had. I haven't seen anybody.

Izar: 26:30

m on a presentation.

Chris: 26:31

It's No, it's a, yeah, it's a it was a, no, it was a single pane of glass

Matthew Coles: 26:34

Oh,

Chris: 26:35

for

Matthew Coles: 26:35

Wait,

Chris: 26:36

No, I'm not that's not what I'm, that's, that was a joke. That was going back to the be the beginning.

Izar: 26:41

Tell me more. Tell me more. Of that. I'm interested.

Chris: 26:43

the beginning of the security table. That was our joke that ISAR was.

Izar: 26:46

money. Take my

Chris: 26:47

It may have even been one of the first words of the day. It might have been a single pane of glass, but lemme tell you about this other company I saw cuz it's pretty interesting and I haven't seen anybody else do this yet. Company's called

Izar: 26:57

gu.

Chris: 26:58

No. Company's called Priv. Priv Aue. They were in the early stage expo and what they're doing, they have an engine that scans source code repos for the usage of p i I. And so what they do is they give you a view of how your, so how your app is using p i, they're not scanning this repo for p i cuz there's none there. But there is references to using things like emails and what it lets you do is it lets you take your privacy policy and build up. A standard for your applications as far as what P I can be used, how it can be used, and then it'll go through and flag any, anything that's outside of that policy. And so it was interesting to me because I saw, this is the first time I've seen anybody apply that type of technology to the world of the, kind of the concerns of privacy. We've always been scanning code for security vulnerabilities, but I thought that's an interesting kind of new area that's being defined.

Matthew Coles: 27:54

ever used,

Izar: 27:55

So it.

Matthew Coles: 27:56

sorry, if you've ever used a SaaS tool, And some of the experimental checkers that, that many of, many tools I think have nowadays horrible, false ne false positive rates when it comes to, oh, you're using p i cuz you have email in a variable name or in right? And therefore, oh, it's hard code it. You have hardcoded password or you have a sensitive information needs to be, no, it's just a variable name

Chris: 28:22

it.

Izar: 28:23

so I, I have a term for that I've been using for a while. It's called rumor based detection,

Chris: 28:29

Rumor based detection.

Izar: 28:31

I heard that you are using private data wrong here. So I think I'm gonna flag it. I heard something that looks like N here, so I think I'm gonna

Matthew Coles: 28:39

Yep.

Chris: 28:40

Yeah. So I. I think these folks are, I think these folks are further along than the experimental checkers. So it's worth, it's worth taking a look. It's a new category and it's, we know it's needed because we've never, nobody's ever really dealt with p i in how you're using it in applications, other than I've only seen people do it manually. I've never seen anybody have a way to understand how PII is being used, and they were telling me that. I know a lot of their customers, it's the legal teams, it's the privacy teams or the ones that are using it. They're the ones that want to know what is our exposure, what is our risk, what's our liability ultimately for using p i across, and imagine you have 5,000 applications, gets tough to really understand what is, how mu, how good are we at protecting the privacy of our customer's data.

Matthew Coles: 29:28

wonder how reliable that can be at static analysis time. Because you don't, cuz this application doesn't have the data itself. That That needs to be protected. And how do you tell the code? You're gonna read data from a database, and that data has certain attributes that says it's private data, customers, social security numbers, for instance, and without either using descriptors or annotations, or really interesting names,

Izar: 29:54

you're saying that Mrs. Context,

Matthew Coles: 29:55

right?

Chris: 29:58

Yeah, I didn't get that deep into the demo.

Izar: 30:02

Look, sometimes I feel like nobody does anything with p I, right? Whatever. So any tool in the space is more than welcome. And if they take this. I had by far. Hey, great. experiences with p I based tools of late in couple of years of late have been that, first of all, you give me a data DA catalog. So you tell me what's important for you. I'm gonna find where it is and I'm gonna label it. And then the legal looks at you and says we don't know how to do that. And then security looks at you and says, I don't have anybody to do that. then Deb says data catalog. What's the data catalog? meanwhile, everybody goes putting APIs everywhere and Lord knows what. So a, anything that can take that guesswork and handwork off of mapping data catalogs. I think data dictionaries is a

Matthew Coles: 30:55

Okay.

Chris: 30:56

Yeah. All right. So let's tease out a future conversation cuz I feel like we just scratched the surface of reasonable software security. Like we didn't really, we worked our way through that example. And you guys, you gave me some stuff to think about as far as am I being too harsh? Perhaps, maybe I've been, people have said that. Maybe I'm too harsh. It's okay.

Izar: 31:17

Hey, Matt said that I was going be that I was being advanced. It's the first time in my life I'm still trying to. Absorb the comment,

Chris: 31:24

Enjoy the moment, enjoy it.

Izar: 31:26

indeed.

Chris: 31:27

Yeah. That's a good, that's a groundbreaking moment, being advanced.

Izar: 31:31

Or just to say, not quite enjoy, but something a bit more nuanced, but.

Chris: 31:38

Yeah. So like where do we go? What? Like before we wrap up, we just got a couple of minutes left, but what if we think high level, If we had to, if we had to say three things in the world of application security and product security are reasonable, they're reasonable activities. I mean we're all gonna agree on threat modeling cuz we love it and we think it's the best thing on earth. So we can just put that one, that's one. So we've got one slot taken up by threat modeling just because of the value from being able to understand design and understand what it is you're actually building and thinking about security and privacy. Characteristics of those things, but if we had two other things we can put on the list, what's reasonable?

Izar: 32:18

I think that for me, one of them that I don't see a lot of people doing. And my God, this could be a an episode right by itself. It's the identification of the level of risk that they're under and their risk appetite. think that's something that people don't look into enough. I. That it's reasonable to say, Hey, for the size of your business and your average customer and what you do with their stuff what exactly is your risk appetite? And then from there, you could move to what's reasonable security for you.

Chris: 32:52

So it's really macro level conditions

Izar: 32:55

yes.

Chris: 32:55

dictate what security. Cuz I'm, I've heard you a number of times around the security table. You come back to this, which is good. You're pressing our thinking about. There's different sizes of companies. There's startups, there's small, there's medium, there's large enterprise. They don't all have the same risk profile. They don't all have the same ability to execute. They can't spend the same percentage of revenue to secure the things that they build. And so it sounds like when I'm list hearing what you're saying, it's like there's a macro condition that we could understand about that would help drive what's reasonable. So what's reasonable for the startup is not what's reasonable for the enterprise. You're saying one of those things would be making that determination right up front.

Izar: 33:38

I think that what I'm trying to say is that saw in the policy, in the policy that the word reasonable is being used. And I did some reading just to see what's reasonable in terms of law and we keep going back at reasonable here as a constant and it's actually a function. And I think that we have to identify what that function is. What the arguments for that function are.

Chris: 33:58

Dude, that is.

Izar: 33:58

a bit more complex than what we think

Chris: 34:00

That is one of the deepest,

Izar: 34:01

is not reasonable for you.

Chris: 34:02

that's one of the deepest things, like you should write a blog post about that right there about, it's not a,

Izar: 34:07

and deep.

Chris: 34:08

it's not a constant, it's a function. Come on man,

Izar: 34:11

you guys know something that I don't?

Chris: 34:13

that's a t-shirt. It's not a constant, it's security is not a constant, it's a function. Now I'm just trying to make it, I'm trying to market it now.

Izar: 34:20

I would use that t-shirt.

Chris: 34:22

Yeah, but that's, but that's, but that is, that, that's just, yeah. You really, that's a great way to illustrate it from a developer perspective, using that kind of developer language that, it's not what

Izar: 34:32

You always told us that security is a And yes, it is. But I'm thinking that for us security people, is a journey. For developers for companies at all, for anybody who needs to perform security, not as a practitioner. It's a function.

Chris: 34:52

Yeah.

Izar: 34:52

what we keep saying when we track model, right? You have to know how much, when too much security is too much,

Chris: 35:01

Yeah. Cuz there is such a case.

Matthew Coles: 35:02

Enough is enough

Chris: 35:04

Yeah.

Matthew Coles: 35:05

when

Chris: 35:05

All right. So we're gonna end the, we're gonna end our conversation for today here, and with our I was happy to be joined by the advanced and deep and

Matthew Coles: 35:14

nuanced

Izar: 35:15

Nuanced, nuanced, but wait. We missed the third point. Matt, do you have one? So it's threat modeling. It's the function of security and.

Matthew Coles: 35:24

I'm gonna go with, I'm gonna go with identifying some solid assurance objectives and putting a level of rigor in place, right? Rush to market is a, it needs to be balanced with what can you and what do you want to claim from a security standpoint. Threat modeling helps with architecture and requirements and design? but ultimately what you build, and I'm not saying that means you have to do task or you have to do task or you have to do whatever, but understand, make your judgment calls right? When you get to risk, you'll be sit, you'll be thinking yourself that you lined all these ducks in a row first before before making that, that decision.

Chris: 36:01

Yeah. I love the fact that you come you come back, Matt, all the time to that word assurance. Like I'm, I'm old school, like I love secur. The idea of security assurance. What can I do to prove that this thing that I'm building is more secure or is at a certain level of security or whatever is so crucial. Yeah.

Matthew Coles: 36:18

with Dev, with DevOps or DevSecOps, right? None of these are incompatible terms, right?

Chris: 36:23

Yeah, I think these are all, so yeah, we've got a lot more work to do as far as discussing reasonable software security, but we at least have a framework now of threat modeling that what we're gonna call the security function and security assurance as our three kind of pillars. To build off from. So folks, thanks for listening to the security table and tune in for a future episode where we're gonna continue this conversation and really unpack what each of these things means and how they come together to really provide reasonable software security.