Chris Romeo, Matt Coles, and Izar Tarandach attempt to demystify the concepts of Application Security (AppSec) and Product Security (ProdSec). They find that even defining and differentiating both concepts is challenging. Various articles exist about AppSec and ProdSec, but the industry is generally confused about these terms.
Discussing the role of hardware in product security initiates an animated debate. Questions arise about whether the presence of hardware makes something more of a "product" and how software-only products differ from those with hardware components. Supply chain challenges, the significance of hardware in security considerations, and the potential overlap between AppSec and ProdSec become central themes of their conversation.
They make progress during this spirited discussion, but the hosts conclude without arriving at a definitive answer. They humorously acknowledge their collective confusion and agree to revisit the topic in future episodes. This conversation deserves a part two, emphasizing their commitment to understanding and clarifying the nuances of AppSec and ProdSec.
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
Chris Romeo, Matt Coles, and Izar Tarandach attempt to demystify the concepts of Application Security (AppSec) and Product Security (ProdSec). They find that even defining and differentiating both concepts is challenging. Various articles exist about AppSec and ProdSec, but the industry is generally confused about these terms.
Discussing the role of hardware in product security initiates an animated debate. Questions arise about whether the presence of hardware makes something more of a "product" and how software-only products differ from those with hardware components. Supply chain challenges, the significance of hardware in security considerations, and the potential overlap between AppSec and ProdSec become central themes of their conversation.
They make progress during this spirited discussion, but the hosts conclude without arriving at a definitive answer. They humorously acknowledge their collective confusion and agree to revisit the topic in future episodes. This conversation deserves a part two, emphasizing their commitment to understanding and clarifying the nuances of AppSec and ProdSec.
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
That's true. That's true. Hey, folks, welcome to another episode of the Security Table. My name's Chris Romeo. I'm joined by Matt Coles and Izar Tarandach. And if you remember the 1990s, by any chance, you remember the show Seinfeld. Seinfeld was the show about nothing. This is kind of the podcast about nothing. Right? No, come on. We're talking about lots of things. We have, we have, uh, serious conversations about with us sitting around a Chinese restaurant for the entire podcast episode and nothing really happened. No, that's a, a Seinfeld
Izar Tarandach:we can still say,
Chris Romeo:hello. And if you
Matt Coles:No No security for you.
Chris Romeo:If you know, yeah, that's
Izar Tarandach:HELLOOOOOO!
Chris Romeo:No security, no security for you. All right. What other Seinfeld reference can we make a security analysis of here? I mean, there was the double dip. Double dip was invented in that episode where George Costanza is at the, I don't remember what he was doing. He's at that party and he dips his chip in the second time and the kid is across the room. He's like, what are you doing? You double dipped. I don't know what the double dip analogy is in security, but. I don't know, it's somewhere.
Matt Coles:I'm sure it exists.
Izar Tarandach:One year! It's when you have two formats of the same SBOM.
Chris Romeo:Okay, that was, uh, that was good. That was good. I, uh, that's, that is
Izar Tarandach:HAHAHAHAHA! These vulnerabilities are making me thirsty! Yeah.
Matt Coles:I was, I was going to say, I was going to say something like you're, you're, you're streaming your lugs to SysLug and Splunk at the same time. I mean,
Chris Romeo:Oh, there you go. Now here's one. Here's one for you though. I bet you, there's a lot of. CISOs that are standing before the board and would like to say the following. So we started building our security program, yadda, yadda, yadda, and then the FBI showed up. Imagine that as a board presentation, so. Okay, we gotta talk about s we gotta this is the this now concludes our Seinfeld. Uh, memorabilia section of the security table. Let's talk about AppSec versus product security. There's been a number of different articles written over the last couple of months that we've, we've taken a look at and let's, we want to, we want to set the record straight from our perspective, as far as what we think of as the differences between these things and similarities. And so, shall we start with a definition of AppSec? What the heck is AppSec?
Matt Coles:Izar, do you want to go first?
Izar Tarandach:Ah, you know how I'm with definitions. You go for it.
Matt Coles:You know how I am with this topic. So, uh, since we've had a low back conversation prior to joining on the
Izar Tarandach:Cool. Cool.
Matt Coles:Well, actually no, so when we actually, Chris, if you could start, cause this ultimately this episode really is to, to, to give our perception of what AppSec and ProdSec are. Given, and the, the statements being made in these articles, uh, you know, from, from various sources, um, either some of these things are brand new to people, um, or, and, or certainly there is confusion in the industry about what these things mean. So, what do you think application security is?
Chris Romeo:Yeah, let's uh, let's work our way through kind of a definition. Now I just happen to have done my own definition in a talk I did this previous year, the Application Security State of the Union, so I'll give you the definition that I put together for that perspective. So I think of application security as the people, process, tools, and governance that are required to properly secure applications. So for me, I go back to, I I'm always more, I'm always a bit of a programmatic thinker, like that's just tend to be how I approach the world is how do we programmatize this thing that we're trying to do? And so for me, application security is what we need to do for the people, the process. Processes, the tools, and the governance to properly secure our applications. So,
Matt Coles:so, yeah, so really briefly. What do you define as an application?
Chris Romeo:An application is anything that has, anything that is made up of software.
Matt Coles:Oh, that's interesting. So let's introduce product security now. So what's a product?
Chris Romeo:Yeah, so, but see, I tend to think of product security. Hardware and software application security software, and some of that is just where I grew up. As we were talking about before we, before we hit record on this episode, I was at Cisco for 10 years. Cisco has 27,000 products that are Not really, not quite that many, but they have a lot. They have, and in those days they had metal boxes that were routers and switchers. Switchers. What's a switcher, a new word here. Routers and switches that were, and I used to think of them, there was the metal box component. And then there was the the bits that were going into it to drive that metal box. And so I tend to, in my own mind, based on my experience, I tend to attribute product security as the things that I have to do to secure these metal boxes running the software or You know, you can extend it to cloud services and everything else that's a product. But I think of AppSec and applications as more of a general, general thing. Like, I don't think of applications as something that you sell. Like, you don't sell, like, I can't go, I'm going to go sign up for this new application. Nobody says that anymore, other than maybe in the context of mobile apps. That's what an application is in the use of that term. So I've talked enough. You guys tell me what your, what your, uh, how you break it down, how you separate it.
Matt Coles:So generally I look at products, products as things that a company sells. So they deliver to customers versus the things that they deploy themselves, either internally or for their customers, you know, exposed to their customers like a cloud or SaaS service. Um, but the product security would be securing the things, whether those are physical or, or non physical. Things that gets, that gets shipped externally and sold, you know, and, and either sold or given or used by customers. So, uh, potentially, or most likely, mobile applications, because those obviously go. That's software only that goes, that gets delivered outside of the company. Uh, certainly the bits that run on the product, on the physical device and the physical device itself. So the people process, processes, etc. Uh, you know, infrastructure, networking, etc. That might get delivered with that, that physical box, uh, and the firmware and software that it runs. Uh, and any operating software, you know, if, if we don't. Thick clients are not as prevalent today, I think, but, uh, you know, when we used to have desktop software that controls, you know, the boxes, um, the, those are products too. Applications being things, business applications, especially being things that the business uses to, to Do all of that work as well as the things that they may then expose to to customers like, you know, License management and support systems and things like that And and so product security is is making sure that from a physical physical up Right, in the stack, security wise, and then applications, of course, would be anything that sits on top of the, on top of the infrastructure. If we think of the cloud model of, you know, SaaS, IaaS, PaaS, um, right, anything that sits on top of the, the infrastructure, at least, is the application, right, the software portion. Izar, do you, how do you feel about, about that?
Izar Tarandach:Well, so you guys know me, I like to think in terms of analogies, right? And when I went looking for one that could cover this. Luckily, my wife was watching one of those, uh, home improvement things on TV. And I think, and I know there are holes in the analogy here, but I think that what came to my mind was the difference between the interior designer that's turning a room in a building into something functional and that works for its purposes and that explores well the space. And that for me is an application. And the prod security is the architect or engineer that comes and builds the whole building around that thing, including all the plumbing and all the codes and all the safety and all the, all that kind of stuff. So, first of all, I was very, I don't know, very, uh, uh, I don't know if surprised is the term by the question itself. And especially when I read that some people think that Prod Security is an emerging new thing. Because, to the best of my recollection, we have been doing Prod Security for, Matt, how much is it now?
Matt Coles:It's been a long time.
Izar Tarandach:Long, long, long I mean,
Matt Coles:mean my, my, my title, my title and your title. Actually, we were both product security engineers for a
Izar Tarandach:We
Matt Coles:of
Izar Tarandach:came to work in the Prod Security office,
Matt Coles:in, in the mid, in the mid 2000s. I mean, so this is not a new, the term is not new. Maybe the scope has changed.
Chris Romeo:I think it's exposure to the market too. It's exposure to specific companies because product companies tended to be the leading. Organizations that were deploying product security offices and product security engineers. I mean, we had it at Cisco. We were product security at Cisco Um, and that's, but that's because we had a company that was driven by a lot of different products that required That level of thing. And it was funny at Cisco, Application security became synonymous with what InfoSec was doing Securing the business applications and the internal applications. And product security was what we were doing as we were serving the business units and technology groups to help them build secure products.
Izar Tarandach:So, another thing that I saw in those, in those articles was that there was a tendency to go for the cardinality of the thing. AppSec is one, PodSecurity is many, or PodSecurity is one and AppSec is many, that kind of thing. And I think that I prefer best Chris' approached to defining AppSec and he went straight where I wanted to go, the PPT, the people, processes, and tools. And I think that I would extend that and say that to me, product security, application security is one of the tools and processes that goes into product security. So if I'm looking at some kind of relationship between them, some kind of Venn diagram between them, I would say that to me, AppSec falls. in the middle of the, the, the ProdSec bubble, but it goes a bit outside because it can exist as its own thing, right? What would make it exist as its own thing, I'm not so sure. Is it a size thing? Is it a focus thing? Is it a... Like, if somebody comes and says, oh, what about internal applications? Yeah, what about internal applications? They don't need the same standards and, and scrutiny that a product would need. Why not? Why have two processes? Why can't you treat your internal stuff as a product, right? You probably gain a lot of stuff in there. I guess that you would probably not lose, but you would have a, a, a bit of, uh, Waste in there, as Jim liked to put it, but uh, I don't see why not. So I'm still a bit murky here on the,
Matt Coles:I think there's a lot of overlap. I think there's definitely a lot of overlap. I think what you're highlighting is there's inefficiencies if you separate the two, right? But I think that they are different. If we look at business systems, you know, things that a company deploys versus things that they sell, especially if it's associated with hardware, especially, right, the rules are different. Uh, and so while there's, there's some inefficiencies if you separate them, because things like the same vulnerability scanners that we use to look at the firmware on a box, uh, you know, can target a, a dust, I mean, a business application, right? A cloud, a cloud application or web application. The same, whether that web application is running, you know, in a, You know, a private cloud versus a, uh, on, on the box or on, on somebody's desk. Uh, so there, there's no reason to separate those, right? Those are dual purpose, uh, tools, for instance. But... The rules that govern what you sell and ship, right, need to follow a different set of rules than, than how you deploy, right? Let's take about, think about like, uh, connectivity, right? In the business environment, you own the, you own the network. Right. The company owns the network. When you deploy it, you're going to have certain requirements. You have a known infrastructure that you're, that you're deploying into, you know, say they're on Azure or AWS, or they have their own internal, you know, network and infrastructure and, and, you know, log infrastructure and whatnot. And those are the rules that govern that application deployment. When you're selling something, You're deploying that into a customer's environment. They're going to run their own firewalls, their own network infrastructure. They may or may not be in a cloud, a public cloud or a private cloud or a hybrid cloud. New concept, multi cloud these days. Uh, you know, these are, it's a lot more. Open, but you also have to be careful of things like, uh, inbound, inbound network requests and poking holes in the firewall. Um, or what regulations you have to, uh, have to apply. So the design requirements and standards and patterns that you use and some of the, um, some of the, the constructs and systems that might get deployed and how you secure them and your threats that you're looking for. will differ, I think, and you'll have a broader, a broader set of things to look at if you're talking about the thing that you deliver versus the thing that you deploy. However, I can see where you think that if you wrap this, a set of things, even if you deploy it locally, you wrap a set of things as a product, especially if it has a customer facing aspect, like a business application that may like a support system, right? If that's your, if that's your business, That is your product or, and, and they're like Twitter, right? Uh, or X or whatever it's called these days. Um, you know, that is a, that's a business application that's deployed for customer use. That's, that's obviously it's product. Although some people, I guess say we're, we're the product, not the business system. But so is that an application or is that a product? It's not something they sell. It's something they sell, but it's not something they deliver.
Chris Romeo:Yeah, and they deliver it via mobile app and... API endpoints and, and other things. Okay, so I got a different, a different way to, I've just been thinking about a different way to frame the question. That may, maybe this will, maybe this will unlock something for us, maybe not. Why is there an application security industry? Meaning there's a whole cottage industry of tooling and consulting and everything else, but there's not a product security industry.
Izar Tarandach:A, perhaps because there isn't a need for one, because we all understand that a big technical part is being covered by the AppSec one. B, perhaps there is, we just don't take the steps to call it such, because, sure, you are a VP of Prod Security. That means that you have a certain number of, uh, almost preordained functions under you. And that makes you fraud security, because as, as Matthew said, that there are, there's a number of things that need to be, to be covered.
Chris Romeo:Do you use the same tools in product security as you do in application security? Or are there other tools? I can't, like the way we approached it when I was in product security, we didn't do anything differently than, you could have called us, you could have swapped out AppSec for product security in the core set of services that we delivered. Right. In our secure development life cycle.
Matt Coles:If you, uh, if you introduce hardware, there's a difference, I
Chris Romeo:that's, that, I was, yeah, that is where things got different or, or there were additional things that had to be considered. I mean, we were dealing with, um, Root of Trust and I can't remember what the, what's the thing called? The Hardware, um, Trusted TPM, the Trusted, yeah, TPMs. Like,
Matt Coles:So applications don't generally deal with TPMs because that's all virtualized or, or, you know, abstracted away from the application developer. But when you're delivering a product that has physical components, you obviously need to understand that.
Izar Tarandach:concepts
Chris Romeo:there... Is there a product security industry and I'm just not aware of it? Are there tools that are targeting the product security industry? Or is this like a dead end?
Matt Coles:Well, so I, I think it, I think there, it is. There is, but not by that name, there are security tools targeted at product developers
Chris Romeo:Okay,
Matt Coles:as opposed to security teams. So I think, uh, obviously we're going to debate here a little bit, but, right? We, as I mentioned earlier, we, we, the, a lot of the tools are dual purpose or rather have, you know, they have no specific purpose other than looking at software, you know, looking at web applications or looking at third party components in, you know, inventories or, or now analyzing for vulnerabilities or code analysis. All these tools will work whether you're doing application development or firmware development. So in terms of. And I guess, I guess this is the, I guess maybe this is the interesting part about why people see product security as new, even though it's not new, is product security was very much, I think, has always been and really is associated with, uh, I consider myself part of, or more closely related to an engineering or engineering function than a security function, especially if you look at security being IT security or cybersecurity versus product engineering. Adding security to product engineering. And in fact, that's, I mean, that's a lot of how we approach things, right? Is we want to focus threat modeling at developers. Well, that's product, that's developers doing product work, adding security into their role, into their day to day lives. Uh, for, as an example. So, I think there has always been a strong engineering tool focus with security and AppSec.
Izar Tarandach:Good
Matt Coles:at security, at security teams doing application security. By and large, I think many of the tools are going to be the same though. Again, unless we're talking about hardware, you know, if we're looking at ChipSec or any of the glitching tools or things like that, most IT teams probably don't have a purpose for that unless they're attacking network switches. Um, whereas, you know, product developers have a need for that and maybe even a dual purpose need. You know, logic analyzers can, can look at hardware, not, not just from a security standpoint. They also may use it for quality and support purposes and test engineering and whatnot. And so I think that it's maybe it's been always there. Um, or it's always been available without maybe that label on it, which is actually starting to open up my mind as to why there's a, this, this thought that it's, that's a new thing, even though it's not really new. Izar, I know. you're.
Izar Tarandach:I don't know. The, the, the more we, yeah, the, the more we talk about it. I'm, I'm asking myself if this is not one of those cases of, uh, Uh, what's it? A difference without a distinction? Or a distinction without a difference? Because, yeah, I, I agree that the tooling and the processes are probably similar, but again, that Venn diagram, the, the part of it, of AppSec that, that slips out of ProdSec to me is so small, so, so edge case that I ask myself if it's not just Too much of an edge case to actually say these things are different. Or on the other hand, you could put on top of prod security, a number of things, people and processes that really don't belong in AppSec,
Chris Romeo:Let me give you another example. Let me give you another example. that I think could be, could be an ill, could be illustrative for us. I like how I worked that word in there. Illustrative, that's a big word. PSIRT, Product Security Incident Response Team. We
Matt Coles:Versus CSIRT.
Chris Romeo:CSIRT, but now see, now there's another, see, for me, CSIRT defends the network, PSIRT defends the products that we build.
Matt Coles:Yep.
Chris Romeo:That's, again, so, but in AppSec, we don't have a PSIRT. There is no such thing. Have you asked a, someone in AppSec, the AppSec program leaders? Uh, who, who runs your PSIRT? Most times a director of AppSec does not have a PSIRT function. So is this something that we can unlock that is a difference between AppSec and ProdSec?
Izar Tarandach:Again, I don't think that it's a matter of a difference, I think that it's complementary. If we already agreed, and I think we agreed, correct me if I'm wrong, that AppSec is part of ProdSec, then that would just be another bubble on the side of AppSec, just as you
Chris Romeo:going to, I'm going to, flip it back on you the other way. ProdSec is a part of AppSec because AppSec is, when you think about the, I'm just talking about from a public perception, like you ask 10 people. What AppSec is and what ProdSec is that probably nobody can probably give a great definition. But AppSec is
Izar Tarandach:who should know, or just any 10 people.
Chris Romeo:any 10 people, I'm just gonna go to the Walmart here in my town and ask people. But,
Matt Coles:And by the way, sorry, sorry to interrupt, Chris. By the way, I, we've had these conversations. I don't mean just the three of us, but other folks in the security space have had these conversations. I've been part of, of some of these. None of us have a good understanding, I think, even within the security space of what this stuff means, right? Are we cybersecurity? Are we InfoSec? Are we AppSec? Are we ProdSec?
Izar Tarandach:We are too busy securing stuff. I don't care what's
Chris Romeo:ha,
Izar Tarandach:the color of the t
Chris Romeo:me whatever you want, I will just show up and secure your
Matt Coles:But, but I think it's important that the way you're asking the question is interesting. And the way that we're responding, I think is, is doubly, uh, not adding, maybe not clearing up the confusion for folks if they're listening to this now, um, you know, the, the processes that a PSIRT or that a CSIRT follow are probably 90 percent the same. Where it gets... Where you have differences, again, is PSIRT deals with, potentially deals with hardware, right, because you have physical devices. Although, CSIRT may deal with physical devices in terms of network infrastructure, especially, you know, access points, but also other things. People security, potentially. And so you have, you have a Venn diagram of a lot of overlap and then some, some pieces outside of each of them that are unique, I think So there's a lot of overlap.
Chris Romeo:making it, I don't think it's 90 percent the same. I think it might be 50, 50, 50 percent the same. And I've, I mean, I've, I've had a chance to work. I didn't work for PSIRT at Cisco, but I worked closely beside a lot of people from PSIRT. And, um, you know, having done incident response in the past, like, And like I said, CSIRT is about the network, PSIRT is about the product. Yes, there's going to be some overlap, but that focus really changes the core of what you're doing as an incident response team. Right? Because the PSIRT team is responsible for most of the time being notified about a problem. Out from an inbound source, going to the product team, testing, helping the product team through the process of fixing the issue, and then running the communication process to ensure we tell the people at the right time. Now, when I think about CSIRT, CSIRT is, um, has no real outbound. They don't report to the, to the public as far as what happened, what's happening, what they're doing. They may, they may receive an inbound. If they get an inbound notification, then things are really bad. Like
Matt Coles:Well, or, well, or they're running a bug or they're running a bug bounty.
Chris Romeo:bounties
Izar Tarandach:Yeah, that's exactly what I was going to ask.
Chris Romeo:bug bounties is another, but CSIRTs don't run bug bounties, right? Like,
Izar Tarandach:No, no, no. SIRTs don't run
Chris Romeo:product, is a product related thing.
Izar Tarandach:Exactly. So, let's look at that for a second. Products run bug bounties. Applications, sort of not.
Chris Romeo:Oh, they run bug bounties.
Izar Tarandach:Can we agree with that?
Chris Romeo:lots of application providers run, lots of SAST tools, and like people that are building applications, they're running, everybody's running bug bounties these days.
Izar Tarandach:So, those are not products?
Chris Romeo:I mean, they are products.
Matt Coles:Oh
Chris Romeo:to Matt's definition, that we're selling. If you're selling them, it's a product.
Izar Tarandach:If I'm a
Matt Coles:them,
Izar Tarandach:SAST tool provider, And my tool just happens to be SAST. I'm selling you something. I'm giving you a service. You're giving me money. How is that not a product?
Chris Romeo:No, I'm saying it is. I'm agreeing it is. Because there's money being, changing hands. But it's also an application. It's both.
Izar Tarandach:It's a product that's made of an application, which we agreed already.
Matt Coles:it's a product made up of an application. Products that have hardware, right, but products that have hardware also have applications as building blocks. So are we suggesting
Izar Tarandach:you the truth, I don't see the,
Matt Coles:is product security the superset? Because it includes applications and other things?
Izar Tarandach:I don't see the hardware as such a differentiator here. If I think about something that I'm selling
Matt Coles:not dealt with hardware before?
Izar Tarandach:yeah, but you know, it's, it's like it has some stuff that's different, but there isn't enough stuff in there to put in a class by its own.
Matt Coles:know a bunch of hardware engineers would say otherwise.
Chris Romeo:I do too.
Izar Tarandach:Dude, I, I, I know a lot of people who think that what they do is the most important thing in the world we included, so,
Matt Coles:Well, okay, so hold on, so hold on, so hold on. Let's talk about, let's talk about the, let's talk about the real elephant in the room on that. That's the difference between hardware and non hardware. You actually have to build something and ship them somewhere so you have all the supply chain stuff that you have to
Izar Tarandach:that, but that doesn't
Matt Coles:I deployed through CICD and it's present.
Izar Tarandach:Okay, let me give you an example, okay? I have this amazing thing here on my wrist.
Matt Coles:Yeah, it's a product.
Izar Tarandach:and a product. And they decided, it's a hardware product, great, great. And it runs a specific version of an operating system.
Matt Coles:Yeah, same here.
Izar Tarandach:now they decided, no, now they decided that they're not going to give me more upgrades. And half of the functionality is dying because Google on the other side decided that I have to have the newest version
Matt Coles:Oh, sure. No names, huh?
Izar Tarandach:to run. Okay, now note that Google, the Google app, app ecosystem is a completely different word. You just know now that it's an Android thing. It's not an Apple thing. So, but that you knew from the shape. But anyway, so my point is, if I can remember it is, okay, this, this thing is hardware. Great. So according to your definition, it makes it more of a product. But you know what? It could not be hardware. It could be an app that lives in my Windows machine, as if I had one.
Chris Romeo:That would
Izar Tarandach:No, not sure. I have one. It's my game box. Anyway, so it's running into a Windows machine, and what all it does is run exactly the same apps. Is that thing less of a product just because it doesn't live in a
Matt Coles:I'm not saying it's less,
Chris Romeo:doesn't have hardware
Matt Coles:well, I'm not
Chris Romeo:it on your wrist. That
Matt Coles:I'm not saying it's less of a product. I'm not saying it's less of a product. I'm saying that it's a different product. It's a product that has different, it's a product that has different aspects. Software. alone has different criteria for security than hardware and software.
Izar Tarandach:Okay, okay, okay, okay, okay. Another example, you have this firewall box, wonderful firewall box, right? You can get it as a 1U, you stick it in your, in your stack, everything is beautiful and great. It just so happens that you can also get exactly the same functionality in the form of a virtual machine that you stick in your network, okay?
Matt Coles:on a virtual machine, on a VM server
Izar Tarandach:On a virtual machine, yeah,
Matt Coles:that you deploy?
Izar Tarandach:Yeah, yeah. Is one of them less of a product than the other?
Matt Coles:It's different.
Chris Romeo:There's still hardware underneath in the cloud environment.
Matt Coles:yeah, but you're not, but you as,
Izar Tarandach:I can't do ones and zeros in my
Matt Coles:but as the, but as a supplier of, as a supplier of the product of the supplier, the product, the software only product, you're not governing the heart of the hardware runs, nor do you necessarily care how the hardware runs.
Izar Tarandach:But does that make my product less of a product?
Matt Coles:Oh my god, we're not talking about making it less of a product! We're
Izar Tarandach:Then why are
Chris Romeo:caress about pro,
Izar Tarandach:why are you sticking to the hardware?
Chris Romeo:what is it a one to five scale of how much of a product you are? Well, you're about a four. I mean, you're, you're almost the, the most
Izar Tarandach:But if you had hardware,
Chris Romeo:Yeah,
Matt Coles:mean, if we really want to go that route, we could talk about wireless sensor networks that, you know, run, you know, environments, you know, smart fields and things where you have thousands of wireless devices out in the field talking to it. EdgeGateway, how much of a product is that?
Chris Romeo:My primary question is why am I more confused now than when we started this
Izar Tarandach:I'm totally confused. I have no idea where I went.
Chris Romeo:I've got to go read the articles again and try to see if I can find some wisdom
Izar Tarandach:no, no, seriously. Let's bring it back then. Let's bring it back. We're almost at time. So let's bring it back. Okay, so, who... Contains whom?
Matt Coles:I'm going to go with product security includes application security.
Izar Tarandach:Great. Okay.
Chris Romeo:Hold on. I'm going to go on the, I'm on the other side.
Matt Coles:in part, and I have to say in
Izar Tarandach:to go there. Now we
Matt Coles:have to say in part, we do need to, we have to have, we have to further this conversation somewhere, but product security has parts that, actually, let me, let me take a really brief step back. If we look at product, if we look at application security, securing applications, and we've defined web applications and desktop software and mobile applications as applications. And those can be part of the things that you sell, like that watch that you were showing earlier. Then products must contain applications. Product security must contain application security. However, applications can be on their own and not be part of products.
Izar Tarandach:Yes, but then, but then that application becomes a product.
Chris Romeo:Yeah. And I'm going to, I'm going to come at this from a different direction and I'm just going to go purely based on market share. And I'm going to say application security eats product security. Just because application security is the thing that exists in the market. There isn't a product. I mean, that was a, that was a trick question. There is no product security space. There is no, it is, there is an AppSec space of products that are built, that are used in, in product security programs. Um, but there is, I mean, there is not a, there is a... appSec is really what everybody refers to what all of us do at this point. I mean, for example, hold on, I have to go check, um, on the open worldwide product security. Program, uh, website. The OWP, no wait, there is no OWP, there's no OWPSP. There is, is that right? Okay. There is OWASP, which is the Open Worldwide Application Security Project.
Matt Coles:Uh, what was it called before they had a name change to try and bring a bigger tent?
Chris Romeo:it's just web applications,
Matt Coles:Web application. Yes.
Chris Romeo:point is, application security is at the core of that. And, I mean, at the end of the day, I don't really care what we call it. We're still going to do the right things to secure the hardware. and the software that, that go into products and applications both. My point is I think AppSec has just become, it's just the same way AppSec replaced SoftwareSec. We used to call software security, was used to be the thing, and then AppSec kind of took it away and squashed it, and now people, nobody really uses software security anymore. We don't really, we don't really say that or use it as a term as much as we used to 10 years ago.
Matt Coles:That's an interesting, that's an interesting statement. I agree with you. It's interesting because maybe that's where the problem lies, right? That within product security, you have software and you do software security of products... Or you do software security... Products that are either software or that contain software. You do software security. Applications can be something different then, right? But that, that's, those terms are now sort of munched together, as you, as you described.
Chris Romeo:I'm just approaching it from how the industry sees it, like how... The external view of this.
Izar Tarandach:But now, now, just to put it in there, um, as you guys were, were talking, I was looking into the inside tomes of wisdom and experience. And I remember one place where it worked, where. There was a distinction between product security and application security. And the distinction was that prod security could stop releases, application security couldn't. Because prod security was much more enmeshed with the product side of the thing with the, we have to push stuff out because we have consumers waiting for and paying for stuff than AppSec. So the escalation of risk was AppSec, ProdSec. ProdSec makes a decision, go, no go.
Matt Coles:Interesting. The, the other aspect, and I know we're getting close to the end of this episode, but the, the other aspect is, would you consider, if you, if AppSec, is AppSec closely tied to cyber or IT security? And if so, are products, is product security,
Chris Romeo:you're not gonna take us there, are ya?
Matt Coles:I, I, you have to.
Izar Tarandach:can
Matt Coles:not
Izar Tarandach:go with asterisk security?
Matt Coles:well, they're just security then. That's awesome. We can do that.
Chris Romeo:Asterisk.
Izar Tarandach:Can we just go asterisk security and that's what we do?
Chris Romeo:with it. Well, you know what? We're out of time. So we're gonna have to come back and revisit this again. Um, we were hoping for some clarity by the end. I think we just, we just threw some more mud in the water and stirred it up. And, um, made some, some security soup. I think is what we did at the end of the day. But we'll continue this conversation. We'll find, uh, we'll try to find clarity. That'll be our goal
Matt Coles:and maybe we'll get some guests on to, uh, to help us answer
Izar Tarandach:Yeah, perhaps we can bring someone who,
Chris Romeo:Smarter than us that can come and just tell us what it is. That's what we're going to aim for.
Izar Tarandach:Yep, that would help.
Chris Romeo:We'll debate, you know, we'll debate with them. No matter who we bring on, we're going to debate with them about what it means. But folks, thanks for listening to The Security Table. Stay tuned for a future episode where we will provide clarity.