What it’s Like Leading Product Security – CISO Talk EP 37

Hey, everybody. Welcome back. You've joined us on another episode of CISO Talk.

I'm joined today, of course, uh, by my co-host JJ Jennifer Menella. How are you, jj? I'm great, Mitch.

You're in a different locale than normal. I hear you're on the move. I am on the move.

I have a very boring not background happening right here. Sorry folks. But yes, poor decision.

Poor, poor life decision choices, decided to move some stuff myself and, um, that failed miserably. I mean, it's moved, but it's just not actually finished moving yet. Sounds like.

Uh, let's, let's, uh, replace this cabinet in the kitchen pretty soon. The whole kitchen is being remodeled in one of those life decisions, right? Well, there was, there was some of that.

Yes, we did. Yes, yes. Well, great.

Great. Um, we have a really special guest. You know, Lisa A.

Little bit, at least a little bit better than I once she introduced Lisa, and then, well, Lisa, if you tell yourself, uh, tell us about yourself. Yeah, sure. And I'm, I'm not gonna do Lisa, this the, the disservice of trying to explain what, um, she does exactly in her role.

So I'm gonna let her do that. But I've run into Lisa a few times at events here locally in the Raleigh area, um, seen her speaking at BSides. Um, and it's been a really fun and engaging conversation.

And, um, just watching Lisa, what you do and how you do it and how you explain it, it's been really fun. And, uh, thank you for joining us. It's great.

Great. Thanks for having me. So I'm a senior director at Dell Technologies.

I'm in the product and application security team. I have a bunch of things underneath me. Um, vulnerability response, otherwise known as P cert, product security, incident response team.

I have our, um, champion program, our security training program. I have a customer trust aspect of all those fun questionnaires that come in from our customers about, uh, what our security practices are. And, um, you know, and, and I also have bug bounty underneath me, and I'm also, uh, driving the SBO initiative for all of Dell.

So that's been a, a, a, a big fun adventure. I don't know how you found the time to join us today. That's a, that's a, that's a large plate you're eating off of my friend.

Uh, but one of the, one of the things that, um, that I saw you kind of talk about doing is, was the SBO panel. Um, can you give us the quick recap of what you guys talked about there? And then I think Mitch and I might wanna ask you some specific questions about how that works.

Sure. So, um, software, Bella Materials is a fun US bomb for those that aren't aware. Um, really what, um, the goal is, is to make sure that you have an inventory of all the type of things that you put together in your software package.

Um, sort of if like ingredients, if you were making a pasta sauce, you would have tomatoes and onions and garlic, and that would be your ingredient list. Um, if you buy Rotten Tomatoes, you would wanna replace them with new tomatoes to make your sauce. Uh, same type of thing with, uh, the UR bill of materials.

The idea is, is if you know all the materials and bits and pieces, um, that if something has a security update and has a vulnerability in it, you wanna replace that with, with that new update to whatever it's using, you're using, whether it comes from a vendor or open source. Um, and we wanna do that because especially with open source and vendors is open source, vulnerabilities are publicly known and the codes available, and therefore they're more easily exploitable. Do you think of that fun, uh, you know, blog for j uh, vulnerability we had, we had not too long ago.

Interesting. Um, I'm curious, did SBO get introduced by you or someone in the security organization? Was it brought to you from the development teams?

How did that surface as a, we need to do SBOs and let's go down this path? Yeah, no, actually, so, um, that's a really good question. The, um, I think in general, every uh, security team will say, yes, you need to know your inventory, you need to upkeep it.

Um, it's your code that you're, you're utilizing. Um, and so we've always had it as part of our S D L practices, know what you take and update it. However, um, the SBO initiative really got a lot of push by the executive order that Joe Biden put out.

Um, and so it's part of, it's part of that. And, uh, with that, um, you need to be able to, uh, provide that, that bill of material, um, in order to be in the market with, uh, the federal agencies. Um, so it, it's a good and a bad thing that it's part of the executive order.

Uh, the good thing is, is that it sort of, um, upped everybody's game because now it's a regulatory ask and not just a, Hey, Lisa, the security person is saying we need to do this. Um, but then there comes some, you know, bad things about it is, is that if you publish an A spam, you know, do the bad people now know what you have as your ingredients, therefore they could attack you better, you know, quicker. Um, and, uh, and so that could be a little bit, a little bit scary.

And also the whole idea of, um, what is a customer gonna think if I say I'm using open ssl, uh, version one X or something, right? Um, then the customer might be like, there's a new fix that came out for that version. When are you gonna fix it?

When are you gonna fix it? Um, you know, and, and it may be that we're not even vulnerable to that vulnerability, and therefore we don't need to apply that security update right now. So there's a lot of lack of that information because within, um, when you consume something like an open S S L or, or, or some kind of open source, you don't necessarily use all the components and parts of it.

Um, that's where in the talk, when we, we talked about it, we talked about the next journey of sbo, which is, which is V and um, that it, it's an exchange of information, meaning I'm gonna go and tell you, uh, for that new vulnerability that came out with something that's within my sbo that you as a customer might be thinking, okay, are they affected? I now have this vulnerability in me, um, to say, are we investigating, is it really applicable to us or is it not? So an US bomb alone, uh, is just a, a, a piece of information.

Um, the, the part to make the full story is, um, you know, the applicability of, of the vulnerability really. And if you need to, um, you know, if an you need to do an update or grab that latest, uh, open source component, I'm gonna ask this because I feel like from v vulnerability management, which luckily is not anything I've been primarily responsible for, but peripherally responsible for, um, with and through clients. And it seems like it's already such a challenge just when you're talking about traditional assets in an organization.

So I'm curious in, in a company, you know, the size and scope of Dell and, and others that have not just one piece of portfolio and one little kind of chain of product line, um, but a large robust organization with lots of departments, lots of projects, lots of products. Um, how do you, like, how do you even tackle managing that centrally? Cuz you, you're responsible for so much.

Is it all handled in one place centrally? Um, or does each department have, how is that carved up? Yeah, so, so within Dell we have a high hybrid model.

So, uh, within my team, I have what I call P CERT engineers and P cert PMs. And then within the businesses they have champions. So it's sort of a partnership.

Um, the, the ultimate understanding of the risk, um, and, and what's going on in that is, is sort of what I'm in charge of and making sure that teams are following the correct processes and policies. So, um, uh, I'm very heavily involved with First and First has a PSER services framework. And our, our, you know, we follow that from discovery, trans analysis, remediation disclosure, like that, that workflow.

So, um, within my team, we set the policies, the processes, we have the tooling to capture the vulnerability and make sure that that process is really happening. And ultimately that disclosure to the customer is, is happening so that the customer knows, hey, there was these vulnerabilities. Um, you're right, it it, it's very difficult when there's a, a lot a, a big portfolio.

Um, but, uh, I think working and partnering with the business teams, um, you know, to make sure we're understanding what's going on. There are some, um, of our product teams that can address things extremely quickly and some where it just takes longer to build, you know, when you're thinking big servers and, and stuff like that. Um, it, it could, you know, it's a lot easier than throwing out a BIOS update, uh, or sorry, it's harder than throwing out a BIOS update.

Um, so, so, you know, I, we have to think about that. And ultimately it all comes down to, you know, the risk and how quickly do you react based on the risk, you know, utilizing scoring and severity. But thinking even beyond scoring, um, what's the risk of the customer?

Um, is it in a protected system? Um, you know, uh, there's a lot of those type of things that, that come into play. I follow question with that.

Is it sounds like, um, looking at it from the outside, that managing, you know, SBOs is pretty tedious and intensive and, and the, the vex and the exchange system is gonna be kind of a different way to approach this moving forward. Or maybe you can correct that if that wasn't quite right. Um, I'm curious where you see, like Dell aside, just in, in the world of where we are with managing vulnerabilities at that, at that level of granularity, where do you think we will need to go as an industry to have that tipping point of the security benefit outweighing the detriment to security that we get by just having busy work, trying to keep up with something?

Yeah, no, you're exactly right. I mean, I think that's one of the things that, another downside of the executive order in a way is, is that if the focus is so much on, I mean, SBAM was such a catchy name it, everybody was saying it. Uh, I I love Alan Freeman for it, but, um, you know, it, it was just, that was everybody.

The, the, the thing to say, um, and I think that a lot of people lost focus about what we're really trying to do. And really dependency management is, is the key. Um, you need to know your inventory, uh, but you, once you have your inventory, you need to match it with about knowing the vulnerabilities, and then you need to match it with being able to address the vulnerabilities.

So the important part is being able to have a, you know, a, a a process to be able to handle any of the vulnerabilities that are coming in. Um, and, and, and so when I think of the industry as a whole, I think having a more mature process in handling the vulnerabilities, making sure that if you, if you consume something, that you have a way to know about those vulnerabilities, that you have stronger relationships with your vendors that you're, that you know that you're getting code from. Those are the type of things that you really need to be focusing on.

I mean, the usal is just, it's just the inventory, right? And, and the majority of the time product teams knew their inventory, they just, maybe they weren't completely paying attention to it, and now this is gonna shine a light on it. So that's where the focus needs to be on, is knowing them, fixing them, and figuring out how to fix them in a speed.

If you think about open source vendor code, a lot of the times we get that code and we write so much code around it. We weren't thinking that we were gonna have to keep updating it. So how do you figure out how do you decouple some of that open source?

How do you, so that you could quickly apply that update? So those are the other things that I think us, us, as an industry need to start thinking about. That's a really good point because, you know, there's numbers around how much, what percentage of our software we ship is actually open source and can be 80% here.

Some big numbers, maybe it's less than that, but it's in, in, in my experience, running product development team on a much smaller scale is there's still, it can be introduced through a number of factors. You mentioned, partners, business relationships, vendors that, that you're maybe, uh, bundling or reselling or part of your solution. It can be developers, this is a great new open source project that will help us, blah, et cetera.

How, how do you, have you had to put in new processes to help manage the introduction of software? And what risks come with that? Is it still kind of developer centric and then we examine what they're doing?

Or do you control it more? I'm just curious, in a big organization, maybe you have more centralized things, but maybe not, I'm curious how you do that. Yeah, it's, it's a little mixed.

Um, I would say the, the big push is, is is that vetting of the open source is become more important. Now. I think before people would just grab it.

It's, it's the same thing actually with vendors too. I mean, those, uh, in the beginning I was talking about how I have this customer security, customer trust aspect, and a lot of it's those questionnaires that come in, you know, it's the same thing doing that on your vendors. What are their security practices?

Are they doing scl? Do they have vulnerability response? Um, so, so that vetting becomes way more important.

Now, um, in open source, it could be as simple as, um, you know, are they even assigning CBEs? Do they have developers that are working on it? Um, do they have a defined end of end of security support life, like, for that open source?

Like, do they have some of these basic things? Have they, you know, when they have a vulnerability, are they quickly addressing it? Have they said that they'd done any security practices?

All of those type of things you need to look at. And so we're spending more time, I think, figuring out how do we vet them, them better. Um, but there's a lot of old code, right?

And code, and we made a lot of choices. So now it's like running our own type of S D L type of practices on the code that we're getting or that we've gotten from vendors, or we get from, um, you know, even from open source. So a lot of that energy is, is, is now like one of the things that we're paying attention to.

How is, how is it different in the world of hardware? Um, my, my bits of exposure to it from my OT devices to, you know, specialized, uh, hardware devices, you know, it's not all running Windows and Android, right? Or, or whatever software or Linux.

Um, a lot of it is sometimes a specialized operating system, you know, very driver level, you know, hardware level kinds of code. How is that different than what maybe a insurance processing organization might have to deal with? Yeah, I would say it certainly adds more, you know, complications to the equation.

Um, you know, with hardware, it's, the first question is, is can, when there's a vulnerability, can we fix it through the software? Uh, or, or do we have to go and have the hardware and view something on it? Um, so that's, that's the part that makes it difficult.

And when you have hardware that has a vulnerability, you can't fix it with software, is it, is it something that you're, you're, you're actually gonna fix or be able to fix? I mean, if you think about back of like the spectrum meltdown and all that, there was no fix, right? There was a lot of stuff to help protect, uh, um, from it.

But, but you know, I, I think the reality is, is that with hardware, oftentimes your best fix is to get new hardware. Um, if you, you know, if you wanna stay on the most secure version all the time, you're, you're getting new hardware all the time. So having a good practice to do that.

But we know that there's a lot of customers and a lot of, uh, uh, a lot of, uh, things that, that run a lot of important stuff, uh, that's on very old hardware. Uh, so, uh, it, it does, it just makes it a little more difficult. But, but the majority of the time, I, I feel that we usually, usually can fix the vulnerability through some kind of software aspect around it.

Lisa, you talked a little bit earlier, I'm switching gears a tiny bit. Um, but you talked earlier about managing security training programs, and I'm curious about what the scope, because that could mean, you know, in employees, your team members, your partners, your peers in other parts of the organization, customers, et cetera. Um, I'm curious what all you're responsible for and kind of what's been working and not working in just generally in that space.

Yeah, so, so we have, um, with the champions, we have a champion, uh, training path that they need to do. Um, and, uh, new employees need to, to cover it with if they're a new champion. Um, and, and it's a, it's a little longer path, it's a little more intense because the champions are the ones that are supposed to be leading the way of security within their, their business.

Um, and in the, in the P cert side, they're the ones that are supposed to be helping to make sure that the process being pulled and address the issues. So, um, there we have a, a belt system for training that we, we have, it starts with yellow belt goes all the way up to black belt. Um, and so each training gets a little more intense, um, for the general security training.

It's across the whole, uh, the, the whole company. Anyone can take it. Um, the, uh, every developer and every new developer has to, um, take the, um, at minimum the, the yellow belt training, which is our first belt series.

Like I said, as you're a champion, you start doing the higher belt training, but, but anyone's welcome to go down the path that they have that passion. Um, so there's a, there's a lot of developers. I thi I think there's probably about 20,000 at least developers don't quote me exactly.

But, um, you know, that we're responsible for making sure that our, our trained on the security practices. Um, you know, and, and we have over a thousand, about a thousand champions too across the company. Lisa, are the champions dedicated people, like, is that their role in the company or are they tapped to kind of be an overlay for security on top of their normal roles?

They're tapped on top of their, their normal roles. Um, there are some that are more dedicated than others, like, uh, more of their time, but generally it's an extra type of thing, which is, you know, always a little bit hard, hard. But, um, you know, most of the time they're passionate about it.

And I'm, I'm really lucky, you know, in, in Dell you have like the top people, Michael Dell himself saying the word security all the time. So, um, you know, it, the, it it's just a natural part of the conversation now where, you know, if I think back a few years, it just, it just wasn't, um, so it, it makes it a lot easier. Um, you know, before we were constantly changing culture.

Now culture has changed and now we get to take advantage of the fact that culture has changed and help drive the initiatives. And usually the, um, the, the business is, is we're partners in a way instead of, oh, here comes the security team telling us what to do. It's more we're gonna drive because they wanna do it just the same.

Yeah. And I assume too, if, if the champions has a normal role in an organization and then this is something on top of it, I would assume it makes that an easier conversation with their peers because it's not just somebody else swooping in that doesn't understand what they're doing and how they need to get their job done. It's somebody who's a part of the company already.

So that sounds like a really cool model. Yeah. Well, yeah, and you, you have to think it's gonna help the resume too, cause security is a, a good, a good thing to have on your resume about now.

Oh, yeah. Well, and I would think most effective would be the security champion as someone to go to, you know, person to help, but they sort of have an oversight, not a, well, maybe, I guess in some organizations it could be formally, your, your role is this, but you, you want people to, you wanna be accessible to people, right? Versus the, you know, the hammer.

Um, how do you balance that? Because there's always, you can make it more secure, but there's other factors too. Well, right, and, and that's where it, it, you know, you have to bring the risk in, into the equation to say, is it worth it?

I mean, anytime you go to any developer and it's like, you could do this really cool feature, you can fix a vulnerability, um, you know, it, it, it, it's not the most attractive thing all the time, but it's, you know, protecting the company and protecting our, our customers. And so you, you know, we, we each really try to like ham it up. Um, it's a really important role and, uh, it, it's, it's, uh, helping, you know, support our customers and making sure we're not showing up in the headlines, which is always the biggest fear of every security person.

Speaking of showing up in the headlines, one of the things that I, uh, that I saw you doing at BSides was the, the skit where you were talking about the vulnerability disclosure process from both sides of, you know, the organization and then also the security researcher and kind of what that dialogue and the thought process is driving the dialogue looked like. And, and when specifically what stood out to me is, is kind of when you were choosing to communicate and, and not communicate in specific methods of communication. So I'm curious if you'll share a little bit with the, the listeners on, uh, on that, cuz they won't have had the benefit of, um, of the whole skip.

Maybe we can find a link if it was recorded, and we'll point them to that after the show. It It was recorded. Yes.

Uh, it was recorded. I, I did see it on YouTube the other day. Um, so it, it was, uh, it was a lot of fun to actually do a skit, uh, to get a point across and to educate people.

Um, but really it, it is difficult dealing with researchers. I mean, we're so appreciative of the researchers and, um, Dell has a bug bounty program where like one of the first to have, you know, server and, and, and products, like every part, part of our portfolio is part of this public, uh, bug bounty program. So we're really excited about that.

Um, but you know, with that, it's like how often do you communicate how, what are you, if you telling them too much information? Like what, like, and things change through the whole part. It's like, you think you're gonna get your fix out on this date and then covid happens, or some, you know, or, or somebody gets sick and then, um, something breaks and then you're, they're doing a paper or, or they're about to publish a paper, or maybe they're going to speak at Black Hat and you're trying to get your timing to match your timing.

And then, um, so it is, it's a, it's a lot that you have to think about, um, with it and understanding the motivations. Is the motivation of research paper, is it talk, is it to get hired? Um, you know, is it, is it the researchers are trying to, you know, get bounties and bug bounty money?

There's so many different things and, and you, you know, when they're also maybe juggling talking with, you know, 10 different vendors right now because they found a lot of this vulnerabilities and this might be the most important thing for us, but maybe not to them, or it might be the most important thing to them, but maybe not to us, you know, like, because we're always looking at the risk and the severity and, and all of that to figure out how quickly we patch. Um, and so there's a lot to the equation. Um, and we're so thankful for, for the researcher community, but it's not, um, it's not always, uh, you know, rosy sometimes.

Yeah, I imagine that's just, it's as sprawling and challenging to manage as, as something like an SBO or, or a granular inventory with all of those kind of dependencies related to it, because it's not like, Hey, George, just go fix this one line of code. There's a cascade of stuff that happens after it. And it may not even, I think you gave, um, like, uh, an ssl uh, TLS example earlier about the, there may be something that they think is critical, a critical vulnerability, but the manufacturer looks at it and they understand the full context of it and what hand or can't happen with that vulnerability past what maybe a researcher sees from the outside, um, and, and scores it differently.

So I imagine there's a lot of Back and forth in negotiation and conversations and education, uh, a lot of the times too. And it could be that they, they told us about something and we're about two weeks just to ship a new version out there. So it's like, then we have to just, we're just kicking off the whole new process of when we're gonna, you know, when's our next fix?

How many versions are affected? How many versions do we need to fix? When are we gonna fix them?

Like, there's a whole release train, are we gonna do it as a patch or is it gonna be, you know, a whole new version? There's so many different things that are going on in the background, and that's what the skits about is, is that, you know, is what, what's going through maybe a researcher's mind and then what's going through, you know, the vendor and, and all the work and the background that they're trying to do. Um, and, and making sure like all the things are coming together really nicely and we're all prepared and, you know, working with PR and legal and, uh, there, there's a lot that goes on.

So, ba based on your experience, just through, throughout being in the industry, what do you see is, I'm gonna ask a two part question. What do you think is the most volume of, of what is my words are not working today? What is the number one motivation of the researchers?

Are they looking for, you know, publishing a paper money, et cetera? And then the follow on related question to that is, is, is the bug bounty a large part of your vulnerability disclosure program? Or are there other paths into that for somebody who's not seeking that monetary bounty?

Yeah, no, there certainly is. Uh, almost every, uh, company has an email address that you could just email to hopefully use a P G P key or some kind of encryption if you're telling us about something. But, uh, yeah, an email is, is usually there and somebody has a base webpage somewhere that says, this is how you can report a, a vulnerability.

Um, a lot of companies are utilizing Bug bounty, especially for the platform. Um, so even if you don't wanna get paid, you could still go through the platform because then it's just an easy way to communicate. Um, so a lot of, a lot of, um, people in the industry would rather you still go through that.

Um, but there is email, so anybody can report anything. Um, I think that motivation through the years has changed. Um, in, in the past people usually weren't getting paid, uh, right, when in their motivation.

Some people just want security to be better. Um, some people want that CDE because they're trying to get their fame, um, in, in knowing, you know, being known as that researcher. The media has definitely, uh, upleveled everything.

Um, you know, ever since heart bleed, uh, it, it's been a storm of it. And if you name the vulnerability that you find, um, you know, that's, that's something that, that, you know, is always fun to deal with. So I, I don't, I, I don't know, I think it depends on, on what state of maturity that researcher is in.

I think in the beginning they're, they're probably thinking, I just, you know, I wanna make sure I could get paid and be able to, you know, survive doing this thing. And then I think down the road they're less about that, that money, and they're more about their reputation, which will lead to future type of money. Like maybe they, uh, start up products or their own company or, or something like that.

So I think the motivational can can change and it's sort of all over the map. I recently read an article, I'm sorry, I'm, uh, switching gears slightly here, but I'm curious on your opinion. I recently read an article that talked about, um, the status of bug bounty researchers in terms of employment status, especially in California and states that are starting to crack down on the use of contractors.

And so it was this, this long article, uh, like it multiple pages about how I guess the state of California is trying to crack down further with these kind of independent contractors through, through bug, specifically through bug bounty programs. Mm-hmm. And they are trying to force organizations, um, to con, I don't even know how this would work, but to convert them to full-time employees.

And I'm curious if you've, if you've run into that at all. And, and if not, what, just what's your, what is your opinion on that? Yeah, I, I I would say we have definitely hired, uh, people who were, um, researchers and, and you know, that, that found vulnerabilities and we offered them jobs.

Um, we also just, you know, most of the time when you're looking for, to hire anybody in the security space, at one time they probably did some form of, of bug bounty or, or, or, or some aspect of it. So, um, most likely you're, you're gonna get somebody that was in that space at one point. Um, I, I don't know if I feel that it should be that they're a contractor or anything like that.

I think a lot of researchers like to have their own control. Um, and if you, you put a contract around it, it it would lose that, you know, they would lose that control and there's so many other options for them. Um, so let's not make it hard.

Like, I don't want them to go the wrong way. I'd rather them come to the company and it'd be really easy. We try our best to work with you so that it is easy, um, so that you come back again.

Um, the last thing that a company wants is to be zero date, um, you know, or be in the black net and like all that stuff. So you don't, like, I think if people are trying to make it more difficult, it makes me a little nervous because they could always turn the other way. We want 'em to be the good ones.

Yeah. It felt like it was, you know, I don't know the backstory to all of that. I'm curious to read more about it, but it felt like the government was helping too much.

And if, if the, because with a bug bounty program like that, and independent researchers, you get, you, the industry gets the benefit of each person's areas of expertise that overlap into something that's way more robust Absolutely. Than hiring one person into that role. So yeah, I felt like that was, uh, help helping too much as my mom used to say.

Yeah, Well that's why, you know, pen tests alone aren't, aren't, aren't enough. That's just utilizing the crowd and the different skill base is really the important. Exactly.

The important piece here. I'm interested too, your, um, cause you've had a, this great career where you've been a software developer, worked on lead and software teams and, and moved into security and incident response. Um, and through that journey, you know, how we use the cloud, what the cloud has become and how we develop software, but internally and also on the cloud, and, you know, things like DevOps and automation of it, uh, of tools, tool chains and workflows.

Um, now, so the software that, that you're providing can be plugged into other people's automation. Hopefully they are. There's a lot of stuff that Dell does that's intentional for that.

Um, and not to pick on SolarWinds again, but that was very much of an attack that's about getting into the software development process, change chains. I wonder how do you look at that as, as part of your role of how you maintain secure software and it's being used in more than just in a data center, you know, running, running servers and keeping data secure? Yeah, no, that, that's a, a great question.

And so that's sort of the evolution that, that Dell's on right now. com. Um, but we're really evolving into, um, more of the offer space and as a service space.

So it we're also evolving our security team to be able to, to look holistically at, at everything. So when it, you say an offer, we're looking at, you know, the infrastructure, we're looking at the product, the Dell products that are going in, and every, every piece in it of it. And when you think about the, the, the, there's a product, let's say it's a Dell product and there's a vulnerability in it, we want Dell to release that vulnera that that security update.

Well, now Dell's our own customer, so you know it within Dell, it, our infrastructure needs to be patched or we're putting that, that product in our customer environments, but we Dell are managing it. Mm-hmm. That's a lot of the, as a service type of space.

So we're deploying our own security updates in that. So you have to look definitely broader. I think we're gonna see that the, and, and we're doing it ourselves.

We're gonna stop utilizing the words like products and applications, and we're gonna think about Dell managed and customer managed and Dell hosted and customer hosted. Like where is the environment, all the different pieces of the environment, how do we make sure everything's being worked on and works magically and there's security in every, every aspect of that offer. And, uh, so I, I definitely know that we're on that journey.

Um, I'm excited we're on that journey and, uh, a lot of the industry is, so you're, you know, you, you brought up a really good topic. You're on this journey of yeah, you're a product company, but you already are a managed services company. Yeah, absolutely.

Yeah. Interesting. Lisa, I'm gonna, I wanna ask if Mitch is cool with, uh, jumping into this.

I have to ask the, what's, what's bugging you questions. So we like to know, like, in your world, no limits what's happening in Lisa's head that's kind of, I learned a new word recently, n******g. N******g, like nagging n******g.

Nagging, Yeah. So like a nagging thing. Lisa, what's bothering you?

What's fogging you? So I, I think what, what's bothering me or what's making me nervous is some of the regulatory and compliance things that we're seeing that are coming from all over the place. Um, I would prefer that, uh, a bunch of countries got together and worked together on something that was absolutely realistic.

Um, you know, there's, uh, been talks of, um, no vulnerability. Uh, you, you may, you can't ship a product with any, any vulnerabilities like that. It's, it's a, it's this unattainable and unrealistic.

Good luck with that. Yeah. So, you know, I I I really would like, you know, some more realisticness about, um, the regulatory and compliance ass.

And to be honest, most of the people doing the regulatory appliances have never worked in a big company or a, a company. They've always been in the government. So they think, oh, you could go and do this.

And, um, and, and I love that they have the passion and they wanna make things better. And for example, same thing with sbam. Like there's good and there's bad about it.

Um, and when you have a regulatory ask it up, ups, everybody game, uh, everybody's game. But we have like, there's some unrealistic expectations, like no vulnerability. That's been really bothering me lately.

Your your point about SBOs a really good one because SBO itself, that really doesn't have any value. It's the fact that you understand the, uh, code composition, the makeup of all the software that's part of your software, but you have to be able to do something about it, right? Just cause you know that all it is is a report, right?

It's just information. And, and by the way, it's also information that's changing maybe by the minute sometimes and, you know, in multi-product development teams. So yeah, I like your point about it's really easy to get fixated on the thing, which isn't really the thing, right?

It's only a mechanism to communicate what's happening. It's about how you use that information and how you maintain the security of that and ma and now it's just transparent because of it, and yeah. You have to do it cuz of regulatory rules or orders from the government.

Yeah. Yes. So many of them really are, I mean the, the shipping with no vulnerability, I think everybody listening probably just started laughing because yeah.

But it is crazy how many of the people that are writing these policies, they do mean, well, I don't have any negative feelings towards them as other humans, but they don't understand what they're asking. And I think frankly, it's dangerous because the only thing everybody can do is start twisting the truth enough to make it sound like they're meeting a requirement. I mean, the industry as a whole, if you're, if you have to check some boxes, you start massaging the language of how you can check those boxes and work that language.

And I'm not speaking about this one specifically, but, you know, but there are so many out there, whether it's platforms and software and patches or iot or ot, when you read the regulations, they're, it's not doable. It's just not. Yeah.

I, I think the problem is it's that you're gonna get some companies focusing on the wrong things just to check that box mm-hmm. When they really are maybe immature and just general vulnerability response and they should be focusing on that. So that's, that's the, the, the, the downside here is, is that let, let's have those in the industry get the basics down and that are important.

But now if you force 'em to do something, they're gonna spend all that money and time there when they really should be focusing over here. So Yeah, I love the programs that include a maturity model Yeah. With the control set or framework so that you understand, you know, instead of looking at a thousand little tiny line items, you understand that these 10 are the first ones you need to do before you even try to tackle the other however many hundred are out there.

Um, so I mean, context is so important. I think that's maybe the theme of, uh, our conversation today. I'm curious, so may maybe last question before we wrap up.

I'm curious, what are the topics that you seek out information on that you listen to? Podcasts or a webinar or videos or reading or what, what's on your kind of topic list of, of trying to keep up on? Yeah, so, so a lot of it is more keeping up with my network and my peers in the industry and making sure that I'm, I'm learning and paying attention to what they're doing.

Um, and uh, the other part of it is listening to our customers. So, um, there's a lot of insights that we have from those customer inquiries, the things that are important to them, um, and, and taking that to figure out where we're heading. Um, and then for regulatory type of stuff, um, my, my legal friends, um, are, are really, uh, are really helpful.

Um, I, I think for me, my, my general like go-to thing is, is I get an email every day, it talks about the top sort of news in the security space and I look through it and I think, okay, ransomware, I usually get to skip that in my space, luckily. Um, and then, you know, it's, but it's more like, oh, this, this, or if I see a one of my vendors on there, I'm like, uhoh. Um, so it's, it's, if it hitting a hotspot, that means our customers are seeing it and I need to make sure I'm prepared to be able to answer their, their question or, or, or hopefully we already know about the issue.

So, um, tho that one, you know, top six type of security media things and a little blog post like that emails me, it's, it's perfect for, for what I need usually. And Mitch, I have one more question. Yeah, go for it.

We can end with this one, I think. Perfect. And Lisa, I'm gonna put you on the spot a little bit, but not too much.

Out of the breadth of things that you're managing, what if you had to pick one thing that you find the most rewarding, that drives you, that keeps you going and gets you up each day, what out of all of those programs you're managing does that? So right now, the dependency management stuff is really exciting to me. Um, I've, uh, kicked it off in a few companies.

I've never really seen it fully done, uh, within the industry being able to have that complete picture. And so I I, I'm really excited that if we have an inventory for every product and that we have a system to be knowing about those vulnerabilities, and we could programmatically tell them about a vulnerability, they fix it, we know that we fixed it, we could even then programmatically create our security advisories, um, you know, for, for our customers. Like to me, that's what's so exciting to me because I've been in, um, a few different companies with various maturity levels and like if we hit this, like we hit their nirvana to me of like, we have that perfect mature every aspect of a P cert.

And so I'm really excited about it. It's like we have bits and pieces, but that complete picture all together, uh, I'm really excited about That sounds like quite the undertaking, but pretty cool. Yeah.

Sounds like what every security person wants to know, what do we have, right? That's what we start with. Yeah.

It's like we know we have 'em and the, and the product teams know it, but putting that whole system together to be, you know, have more automation and that. Yeah. It's exciting.

Excellent. Well thank you for joining us, Lisa. You've been a fascinating guest.

Um, we run outta questions, I think, uh, JJ and I could talk to another two hours with you. Matter of fact, we want to have you back on some other panels and, and, uh, things we have going on. Um, it's fascinating to talk with you and also just to learn the evolution of how the security world has changed and how software's influenced that for you and focusing on software decomposition, um, and understanding of that just as I haven't heard that from a security person before.

That's my favorite topic. So thank you Lisa Bradley, who is, um, your title director, product and application security at Dell. Is that correct?

Am I getting that right? Yep. All right, great.

Well hopefully we see you on another panel or on the speaking circuit and in our network of appears that we're keeping up with. So thank you for what you do. Thanks for having me here.

And thanks jj. Great questions as always. As always, Great to see you all.

Welcome to the text, Sean, family. Welcome. Thank you everybody for listening and we will have another exciting guest.

I don't know, it's hard to be, keep, keep getting better and better as hopefully as good as Lisa, uh, on our next episode. I'm sure we'll have a great guest. Thanks for listening and we'll join you soon.