Welcome. Welcome.
We're so glad to have you here with us today as we discuss an important and timely conversation on vulnerabilities in cloud native environments.
And we're not here to just talk about understanding the challenges. I mean, that doesn't do you guys any good. It won't drive any results. So we're gonna focus on equipping you with clear and actionable solutions, insights that you can take back, discuss, potentially implement with your teams.
And we have a an amazing guest with us here today, and it's going to be a really good conversation. So please feel free to engage in the conversation.
Let us know if you're, you know, seeing challenges in a particular area. And if we have any insights, we'll be happy to address it here. This is your time. So quickly introduce our speakers. Erin Stefan, director of product marketing here at Aqua. Erin's been by my side for countless webinars at this point. Erin, I don't know how many it is.
I know. I know. It's becoming our favorite thing.
Yeah. I like it.
Erin's a familiar face at the industry events, delivered presentations at RSA, BlackHat, KubeCon, you name it.
Her expertise, her passion in cloud native definitely makes her an invaluable voice in our wonderful community. And then we have Ed Imaroso. Ed's the founder and CEO of Tag Infosphere, former CISO of a a really small telecom company.
Ed, what was it called? I think it was called AT and T.
Yeah. I think that's what they call themselves. Okay. Right. Right.
And, Ed's also a professor at NYU.
True visionary, has not only shaped modern security practices, but, Benjamin, you continue to inspire, the next generation of leaders in our field. So thank you. And, before we kick things off, everybody, we're gonna have a relaxed conversation about two recent articles that came out, and we'll highlight why these topics, are so critical, and it will help steer the conversation. And, I will drop a couple links in the chat so you guys can follow along.
But before we get into that, I wanted to do something for for the audience. This book, it's called, It Always Seems Imposter Still Until It's Done. And, I'm gonna flip to a random quote. I keep this by my desk all the time.
And it's not about zero trust. You know? I mean, might seem impossible, might never be done. But, seriously, this is for those of you who are here with us today because this whole cloud native vulnerability management thing might feel a little overwhelming.
We know it's dang confusing, and, you might not know where to start. So let's do it. Ready? Totally random.
What are we gonna get?
How's it going?
Do the big scene first, and then you can do the small scenes and have fun. It's great advice for life. I say it to my kids. Do the hard stuff first, and then you can go and do whatever you want. Bruce Willis.
I thought you were gonna say, like, Steven Spielberg or something.
Then do the hard scene first. Is that what you said?
I guess so. But yeah.
So and that also too, like, you know, we're we're here to talk about some challenges, but I think, before we another before we get into the articles Let's stay with that quick because that's an interesting one.
Like, for cybersecurity, a lot of there's two ways you can, you know, skin the cat here. One is if you're if you're investigating or or sort of determining whether some mitigation process works, sometimes you might like to do it on some dopey vulnerability or something that's throwaway.
Mhmm. Yeah.
But Bruce Willis, you know, noted cybersecurity researcher is saying, is, you know, jump to your highest priority thing and go fix that. I mean, I you can see how that does obviously, we fix the the stuff that's, you know, really high priority quickly.
But sometimes when you're testing, you wouldn't. Right? Does that I don't know what you think, but I but usually, I like to try new stuff on dopey things. But then, yeah, I mean, if there's a high priority Sev one here, k. You do it at two o'clock in the morning if you have to. Take some I'm just we're I'm just going after Joe's nerdy book there. There he's got there.
So I don't want a copy of it now.
Well, I think and too to that point. Right? Like, especially in this industry, especially with everybody saying prioritize, prioritize, but the challenge is, like, how do you even know what is the hard thing? And without the right context, without the right connection right, you could be spending a lot of time thinking that something over here is actually the most severe, the most critical.
And I think the reason you brought up this book, though, right, the reason we're having this webinar, how many head banging moments do we have of, like, the list, the pile of list of things to do when you think you're making an impact, but you're not? And how do you even make a smart decision when this comes through? And I know we're not talking tools and technology today, but just that challenge. Right?
I'm sure, Ed, you've experienced that in in your days and your teams, and how to keep people motivated to kinda keep trying to get that pile to slowly but surely sink down.
Part of the problem is that in complex environments Mhmm.
You know, let's say you got a SOC team that knows what they're doing.
When you go to one of the the lead analysts and you say, how did you know that that was a high priority?
Yeah.
A lot of times the answer is something like we just knew.
You know? And and it goes and in their mind, they're connecting the dots from this is the vulnerability to these tools are dependent on that, to this cause this to break, to, oh my gosh, we have a whole business unit, critical vulnerability, and they're kinda doing that in their head.
And we we can't that that's not a sustainable or scalable approach. But that we all grew up doing this. There are always gurus who kinda just knew. That's kind of an unstable approach. So we gotta get away from that.
Well and unstable when we look at you know, we just ended the year. Right? Happy twenty twenty five. Welcome to the new year.
And we look back on twenty twenty four in the vulnerability database. Right? NIST, another record year. Another I think it was forty thousand some, Joe.
Right? We looked at the graph the other day. I mean well, perfect. Yeah. You're you have it on your screen.
Like, it's it's almost yeah. There we go. Like, how could you even keep track? How can anybody keep track?
And every year, you know, every blog article, every news article you go to record number of vulnerabilities. So how do you even prioritize when the number keeps jumping and jumping and jumping and jumping?
Like I wish that was my bank account.
Yeah. I thought that was, like, Tesla stock or something.
I mean, look at that.
Yeah. If you want to go to the that's not a good that's not a good story. That's that's not a good Yeah.
And I wonder right.
How many people are experiencing the same thing? Right? I think one of the other the articles as we're preparing this webinar and we're talking. Right?
And we're we're talking to customers, you know, like Joe mentioned, you know, at events. And it's not only just the record number, but so much so that then how do we even keep up? Like, this this backlog from the people that are that we trust to put this information together. Right?
The fact that there even had to be a pause in the vulnerability database, because there were so many, because we have to make sure they're accurate. Like even the experts, the experts, experts, experts, where all of us get our information are struggling. So how can any of us who are supposed to, you know, come in, do our job, build the tools, the technology to help do things? Like, this is a real real problem.
Right, Ed? I mean, a real problem.
Go show that, show that Tesla stock thing again, that that diagram. So that thing, if you show that to a bunch of grad students and you say now, how do we deal with this? And you pause and you demand an answer. There's really a one word answer to how you put up with that.
You wait, and then somebody eventually in the back of the room will raise their hand and get the right answer, which is automation. I mean, that's the only way you can handle scale. Because if you automate properly, then the scale shouldn't matter because you can keep up. I mean, if you can generate these problems, then I can handle the problems.
It's when you have manual processes in your vulnerability management team or in your SOC where and and I'll I meet all these people as I do for a living. I I yak, gossip, and coach and talk to these teams. And, you know, we'll ask them how do you do such and such, and they'll always wanna try to impress you by saying, well, I keep track of them. I I have a a feed that comes in, and I review it, and I call this person, and we discuss it.
And as soon as there there's these human interactions that are going on, I'm not impressed by that. I'm impressed they're smart, but that doesn't scale. So when you get a diagram like this, it breaks somewhere in there. Maybe it already broke, but at some point, you realize that it's it's not gonna work anymore.
So I hope for people who are listening here, if you have something that's manual, then it it only scales to x, whatever x is depending on, you know, your local circumstances. But, eventually, it'll break.
Yeah.
So this Aaron, this is, like you know, I I wanna talk about the, article about the NVD and the fake CVEs, but, like, how many of these are are real?
You know? So let's, let's pop over to the, you know, the, situation that, we find ourselves in here. Erin, do you wanna chat, about this one real quick?
Yeah. Yeah. Well, and I even wanted to call out, you know, Thomas, our friend in the chat here too. So not to mention, you know, we're only on day sixteen of the year.
We already have two thousand. So, you know, off to another record start. I don't think this is the Guinness Book of World Records that anyone wants to break. But, you know, even this again, another another article that we found and, again, sharing with Ed as we're putting together this article.
But the fact that there were so many coming in that we actually had to pause. Right? Like, whether or not you know, are these true vulnerabilities? Are these ones that we need to have the process right to get the categorization right, to go through it, to get the CVE number?
NIST was literally unable to keep up. Like, we couldn't even bring these vulnerabilities. All of these things that are being, you know, submitted, we don't even have enough time to go through and make sure that they're accurate in order to give them to the organizations right through the tools to the technology so that all of us can be aware so we can actually go in and prioritize and then, you know, fix, remediate, mitigate, whatever we wanna do. So another just crazy impact here of, you know, it's not just us. And I'm sure, you know, many of you, you know, especially if you're sitting in your office or especially if you're remote and you're like, is it just me that's having this super big challenge keeping up? Is it just my organization?
It's not. It's, you know, the databases, the people that we rely on. You know, even last year, they had to take a pause. They literally had to pause to make sure that the processes that they had in place, that these were real CVEs.
And that's a challenge. Like, that's you know, that keeps people up at night for sure.
So and I don't know if you had any additional comments on this one, but couple of things.
Yeah.
First off, I wanna tell you a story about somebody I knew when I was a little dude, when I was a little kid. My dad was a computer scientist, and there would the guy who'd been at Bell Labs and then went to Stanford Research would come over. Really interesting man. He would read our eyeballs and tell us stuff, and and he was a computer security researcher.
His name's Peter Neumann, still around. And he started this things thing called the risks index. Mhmm. This is to computer systems, and he would keep track of them.
I think ACM sponsored them. My wife's a grad student in the eighties, nineties. I would read them. And he would post one a month and then one a week and then a couple of week and then a few a day, and it got to the point where couldn't do it anymore.
Like, think about that. It was like he was telling us about where computers would fail and cause a problem, and that was news. Like, it was it was something that you could do as a forum. Mhmm.
I don't know when he say he might still do something, but nobody reads it because it's like, why we have a thousand a day.
So that's the first thing. The second problem is that I think I'm a little contrarian in all of this. When I see the increase, I actually think that's a good thing. Like, I don't want people throttling because they don't wanna annoy somebody who's running some open source project.
Like, well, not really sure if this is a problem, so I don't wanna get, you know, like, sort of, you know, called out on, you know, hey. Such and such is bothering me with this dumb thing. That's not a real problem. I may not know.
You know? I mean, if I see some problem that looks like, misinterpretation of IP source or something, then you know what I mean? Like, I don't think it's always so evil if I'm not sure to bring it to the community's attention.
And then, yeah, maybe it's not critical, but I thought it was. I I do get the fake thing. There's no question that there's people mischievous, definitely. They may be even malicious.
I don't know. Yeah. But I think there's probably a lot of those, like, Joe, you were saying how many are real? I don't know, but I, I don't think false positives are so always evil.
And that's why I think having processes that scale allows us to say, look, if there's an issue, raise it for God's sake. We'll figure out whether it's an issue. But if it's manual, then you get pretty annoyed. Like, you know, people running projects get ticked off.
They're like, bothering me with all this nonsense. That's not a problem. What are you an idiot or something? I mean, that's what you read in these narratives and it's, again, none of it scales.
Yeah. Well, I think exactly that point, what happens when it is malicious? So then there's this line that you're crossing, right? Cause you, you raise a really good point.
Let's submit it. Let's make sure we found this. Let's alert the community, right? This whole community of people who are trying to do good, trying to work fast, trying to build better, stronger applications, features, whatever it is.
But what about in those cases where people take advantage? And that's that's the whole world. Right? That's that's why we're all in security.
But, you know, that's that's another just punch to the gut when you're try trying to trust trying to do the right thing, especially when you have your long list to get through. And then here's a CVE that's fake and malicious, and now people are going and attacking something when you're just trying to do your job and and fix it. Like, that's a really crazy world to live in, to come into, you know, twenty twenty five. And, again, another thing just to be prepared for.
And that's why we have these discussions. Right? That's why we bring in experts like you. Right?
To you know, everybody faces them at different different levels, and there might not be an answer now, but bringing the awareness and having these conversations, and I think, Joe, you mentioned this. Like, we'd also love to hear from all of you in the audience. Like, please share as, you know, we're going through the conversation how you're tackling some of this in your your organization as well. But I'll pause there and and any response, Joe or Ed.
I was gonna say, like, you know, I was just listening to you both, right there, and it remind me of, curl, which was, you know, not too long ago. And Mhmm. Everything they were saying was, like, carbon copy of the second article that we're here to discuss. I mean, this this poor, maintainer, he got so overwhelmed that he just pretty much gave up on his project.
So I wanna just share my screen again here, give this one to you guys.
Oh, this is the guy who turned off and made it all read only.
Yeah. Read only. Yeah. That's what he did. Yeah. I mean, it just shows you, current system.
It's creating unnecessary pressure on the devs. I mean, is it the validation that we where we need a better process?
All we like, at the end of the day, all we really have is time and wasting it on, like, low impact stuff, like, that they're dealing with.
It's it's just it opens so many other risk avenues.
It's the the core issue here is that communities like open source have always thrived on members and researchers being responsible.
That's it just the whole thing kinda breaks down when you lose that assumption. And, you know, we we've all been part of those communities, and you tend to gang up on somebody who tends to be irresponsible.
And it can get real weird real fast. You've all you've all seen that. But, again, the the assumption when you're running a community is that the researchers and the participants are responsible. When that when that is true, then wonderful things can happen. You can build great utilities. You can share software. You can make progress.
But as soon as they get so big, I guess, I don't I'm no psychologist, but some small percent of any group is gonna be, like, you know, really weird. Right?
There's always gonna be bad some bad apples when you get big enough.
And I think a lot of these projects are getting big enough that we're just seeing just the math of it is that there's gonna be some people who are malicious. I just would again reiterate that when something's deliberately malicious and fake, that's different than somebody innocently posting something that they made an incorrect assumption about. Those are different.
The second is responsible, but maybe not experienced.
The the first might be super experienced and irresponsible.
So the responsible part is what's so important. We've always had that. We have that in incident response. Right?
It's all or in reporting, like, when you find a vulnerability website or something, You know, responsible reporting is what we all rely on people doing. The Internet grew up because most of us are pretty responsible. And when you're not, you have these security issues and these these coordination issues. So, I think this article is a good case study in what can happen when, a moderator gets pretty annoyed and just says to hell with it, you know, which is apparently what happened here.
Talking about an ethical dilemma. Yeah.
But it's that responsibility, and that's a hard thing to check for.
You can for competency.
Like, if you're if you're a novice in an area and you start participating in a forum, maybe some prior open source project or something, and you're just not understanding, then you will self select out of that group. I mean, what what's the point? If you're not following, you're not contributing, you'll get it. Then you better go, you know, go go take some classes or some go take a sands class or something or to to just apprentice with somebody or get some help. You'll self out of that. So that that's not the problem.
But irresponsibility is hard thing to test for.
You know, there's no security control for that.
Again, like what you guys do at, at the company at at Aqua, like, when you work with a vendor, when you're working with something that's automated, life gets better. You know? You do you do have some help. And I again, for me, when I'm, you know, talking to teams either informally and I'm usually because I'm such an old dude, I'm usually talking to the managers now.
But, you know, usually with the managers, I'm always asking, take me through your automation journey. What are you trying to do? And if that's immature, then you're always gonna have problems within this area. So that'd be my main you you started, Joe, by saying actionable stuff for people listening.
Really go back and and test how scalable your process is. Could you handle twice as much as you handle today? If that if we flip the switch and next week it was double volume, could you do it? And if you say, sure.
Walk in the park. Well, then you got a little bit of headroom left. But if you go, no. I I do see what you mean.
Then you it's good. Twenty twenty five be a great year to rethink that Because if that diagram you showed keeps going, then, you know, I think it's gonna go through the roof like climate change or something.
I think Well, then what are you gonna do?
Right?
You made a really good point right there, Ed. Right? Like, this is shifting, right? If we have, I'm sure many of the organizations, and again, you know, if anyone feels comfortable putting in chat people that are in this cloud transformation, right, that are moving from this traditional on premise.
So, you know, you and I have spoken about this before Managing vulnerabilities on your lap, like endpoint or server is so different than managing cloud native vulnerabilities. And that's really the point of our webinar today. Right? This is what we wanted to talk about.
But your point of like, if you turn the dial up, does it still work? I mean, that's really what a lot of organizations are facing with in this part of, you know, multi cloud, you know, if there are multiple public clouds, if they're in hybrid still, you know, a whole total shift in how managing vulnerabilities used to be on some of these legacy systems, more monolithic applications to moving now to we want faster, right? We want to enable DevSecOps methodology, right? We want to secure, we want to include that security.
And, you know, as part of automation, we want to go fast, fast, fast, fast, fast. But how do you do all of this? And how do you manage these vulnerabilities in sort of this? We call it, I mean, it's not new for us, but maybe some of this new world of people who are just, you know, beginning this this transformation.
We got a little reprieve when for a lot of companies that went from, monolithic to cloud Mhmm. The apps and workloads.
You got a reprieve because like that whole that whole shared responsibility thing that you get with cloud Security Alliance and things like that where the infrastructure's covered. Like, I'm not sitting worrying about patching Exchange servers. You know? I mean, that so life got better there.
And Yeah. I'm like, oh, wow. I I I don't have to worry about theoretically, like, half the problems I used to worry about. But what you did see is everything became different.
All of a sudden, like, all of your your comms utilities, all of the a lot of the libraries, all totally different.
Yeah.
Had to relearn what all that stuff meant because you didn't have that, you know, in a data center. Any of you running an SDN, it just was different. You know, public cloud is different than private cloud. But now I think what's happened is it's kinda caught up.
Yeah. Alright.
I wanna attach exchange service, but I get a gazillion other problem because we've moved so much complexity to the cloud that it's just gotten harder. And I think it's with AI and, you know, as we as we really start to multiply the ability of, our infrastructure to do stuff, I think that that diagram probably will keep going up. So you might as well just assume that it's gonna get out of control for anything manual, I guess. That that I don't think it's gonna go down. Right? That seems odd.
No. No. Let's not let's not forget all the amazing things that that cloud native allows you guys to do, the innovation.
No. You belong there for sure. You wanna be in cloud. Look. You wanna use computing.
Right? You want when you you want to automate and build utilities and run workloads and I mean, that's why we're all computer scientists. We wanna use it and do it. We want it to grow. Mhmm. But but but, you know, if they're gonna be vulnerabilities, then they grow commensurate with your increased computing and apps and usage, then you have to do something to deal with that, and it can't be, you know, subscribe to a feed and read the stuff and decide. That ain't gonna work.
So you can't assume that you're secure if you're in the cloud?
I would say, and I've said this a zillion times, you're better off than you were before.
And I know that's that's contra like, I've been I've worked at a big bank. I've been on their board, and that would be a controversial statement. They feel like once we went to cloud, it was this evil transition that we were forced to do. Think it's the wrong thing. You had this fake nail of perimeter protection.
Yep. Like, if you break, like, that was just kind of a joke. Anybody who's a garden variety hacker knows that in the old days, when you hid stuff in a data center behind your firewall, That was just a layup to go in and, you know, and hit your apps. Now if you do it properly in cloud, it isn't perfect, but it's better.
It's definitely better. Go find somebody who works in a nation. Say, go go down to Columbia, Maryland. Ask them.
Hey. Is it easier now or harder? They'll tell you that, computing architectures now are better than they were ten, fifteen years ago. I don't think anybody would dispute that.
But it's not perfect. It's still a lot of problems, but it's better. So we do belong in cloud. It's just you gotta do the security part of it.
Well, then when we were talking, Ed, right, like, prepping for this session, you talked a lot about, like, it's not it's just different. And so it's it's not one or, you know, better or worse or whatever. It's just different. And so I think you shared a lot of of points with us just about, you know, yes, vendors, but just shifting in, like, organizational responsiveness and not being able to make assumptions, anything else, you know, from as you were building teams, right, as you were running these organizations, as you were working for that teeny tiny telecom company, Anything that, you know, as you were part of this transition, any, you know, guidance or thoughts or best practices, anything that you would share with the people listening today?
I mean, Erin, it could be dopey stuff like nomenclature between different cloud services. You guys deal with that because you handle and you work with all of them. I mean, Amazon, Google, Microsoft called the same thing sitting on the table. You're looking at the three different names for that. It's you know what I mean? Like, when you're when you're cataloging vulnerabilities, then you just multiply the thing you're tracking by three in terms of nomenclature, not the problem.
Conceptually, the problem's the same, but they're calling them different things, and that's a disaster. I know Cisco used the or, MITRE and Mhmm. Mhmm. So these cataloging groups try to fix that in your GRC and your vulnerability management tool on you guys. Everybody tries to normalize.
But I'm just saying, when you're dealing with these three different groups, they they use different terminology. That's a a very trite example, but it drives you crazy. And in the business I'm in right now, where we write about these things and try and train and help, it's a disaster.
You know what I mean?
Like, you guys have to deal with that. But it goes up from there. Obviously, there the when you go dig into the underlying infrastructure, let's say there's some weird open source problem and you wanna know whether or not it lies at the root of some, some hosted environment that you're working, say, with Google.
And you you I don't know. You call over there or you read their blogs. It'd usually be there, like, Venables or somebody would post a blog saying, we don't have this or we do have this. But then you have to go read two other blogs to see if they have the you know what I mean? It's everything times three, and I'm ignoring Alibaba and Oracle and all these other Yeah.
Yeah. Right.
But also I have clouds. But there's three big ones, obviously. But so all of that stuff in practice, you know, the people who are listening to us today, I'm sure resonating that it's just flat out different. You did Yeah.
Data center that way. You picked a vendor, and you work with them. Might have been VMware or something. But now it's all this and then we didn't even talk about SaaS, which is, just stands out as well.
But just for cloud, it's it's it's complex.
Yeah. Definitely.
Lot of, change to serve, if you will.
And I kinda wanna wanna pivot, to how the challenges affect, specifically the security team, and the relationship, you know, with continuing education. Like, what does it mean for me, the attendee, these these changes? What do I need to do? Is there any, like, opportunities for training or, like, how do I sharpen my skills to be able to, you know, keep up with this stuff? Any tips or tricks there?
I mean, there for me, that you're you're singing my song there. I mean, I devoted my whole life to that. Here here's the way that people should think about education favorite would And my favorite would be SANS and, you know, that I've always been friendly with that group. I think there are and there's others.
You go pick your favorite stuff. But and I'll get you guys would do training for your customers on your platform. It is, alright, everybody, you know, you know, log open your browser, you know, go to such and such address. Let's download the software.
That's really immediate urgent stuff. The problem is the half life on that is short because the instant you change, you know, the software, change this or that, it's, it's a problem. And that that's why for something like that, I don't call that education that's training. Now at the other end of the spectrum, you get some academic, you know, in a master's program.
Like me, I teach a master's program at NYU.
You know, pontificating about some general high level concept that might have a very long half life, but you have to twist yourself in a pretzel to connect it to the stuff that you actually do day in, day out. That's why people get so mad at academics because, like, what do you know? How does this apply to me? You know, what I have to interpret? Those are the two ends of the spectrum.
I think you kinda need to live across that spectrum. And and the the problem is a lot of the people probably listening now would be nodding at the pejorative comments about the general stuff, and we connect more to the day to day hands on practical. I just ask you to keep an open mind. Like, there's a reason why you want to be a little more high level.
The like, my favorite guy or my favorite technologist ever was, Richard Feynman, His greatest physicist, I think, who ever lived. And he would always talk about how when people focus too much on the training and then you Mhmm. And ask them if they really understand, they usually don't. And he never knew the names of things, the specifics, but he knew the concept.
And when somebody would say, hey. Like, he'd you know, have you ever heard of any like, in this world, if he was a computer science, have you heard about the CVA CV that touches, you know, such and such library? You go, no. I I don't know that.
And they go, what are you, an idiot? You don't know that. But then if they describe the concept and we go, oh, and they need to explain it perfectly, just not in the context of the specifics. That's where academia should be, and that's where education should be.
It's just a a lot of professors are too lazy to take the time to really know what's going on. So it it's a hard thing for those of you listening. I I think you should balance the really practical training with trying to take a a little dose of some things that are, that have a longer half life.
I do encourage people to go to get a master's degree at your local school. If you work for a company that has tuition reimbursement, go do it. It's not gonna be immediately translated to your work today, But I think you'll find that over time, you might actually be applying some of those concepts. Like, Joe, you read the quote from the, that sage, very wise actor, Bruce Willis.
But it's he he makes a point, and there might be a time where you would that would hit your brain and you'd go, oh, that is a good idea, and you'd apply it. But, you know, obviously, he's he's providing this very, very general stuff. So I think my message is that as you're training a team, as you're educating a team, there's a spectrum, and it would be a mistake to be too biased one way or another. I think you do wanna try and make sure there's balance in the way, you build your own career and build the careers of the people who work for you. I hope that's helpful advice.
Yeah. Definitely.
I think to just to go a level deeper. Right? Because we have a lot of practitioners, I'm sure, on the line, but also a lot of leaders who are leading organizations. So any change in your advice sort of given those roles.
Right? People who are in more than, you know, hand to hand combat of just trying to keep their head above water. And then the leaders that have to lead and motivate and research and do all of the amazing, wonderful things, but also very time consuming as we're talking about when there's fifteen different names for the same thing that you have to keep on top of. So any difference in advices depending on, you know, sort of your level in the organization?
I would always demand that my team do the training with any vendor we're investing in. You know how sometimes I like, for me, I'm a dad. When I buy you know, if you buy stuff for the kids, you're putting it together in the garage, you don't read the instructions.
You always finish, and there's, like, this little knob that you didn't you go, where did this thing go? It's done.
I think it's I didn't get it.
Like, it's like that. Like, the first thing managers should absolutely demand. If I invest in a platform, there's always training involved, and that should be some boxes that had better be checked. And and no skipping that step.
Now relax, boss. We know how to do this. We don't need to go through that. The answer should be no.
You'd go through the training. So that'd be good. Alright. But then at the other end of the spectrum, I also like to see teams demonstrating to me as manager that you're investing in your career and that you're taking some computer science classes and you're learning about AI and you're doing things that maybe I can't apply immediately, but you'll eventually apply.
Like, now that I'm in a different part of my career, I find that those general things, like, I just brought up Feynman in physics, you know, and it had nothing to do with computing. You'll find that those things apply. They have a much longer half life, and they'll they'll apply more generally. So so maybe the one, to do for people listening, I'll bet a bunch of you are resigning and renewing licensees.
This is a very popular month to be renewing licensees.
Go back and look at the what it is you'd look at what you bought and make sure that, you know, item twelve c paragraph four that says, you know, we'll provide quarterly training to your team. Do it. It's get get it on the get it on the calendar now. Go schedule that stuff.
And you paid for it. You should do it.
Well, even the pace of cloud native, right, how fast these things happen. I even think about and, you know, we'll do a little plug for Aqua and team Nautilus. Right? Our our threat researchers who are constantly hands in in the wild with their honeypots, finding new research.
And if you don't follow the thread, again, shameless plug, please, you know, check out our blog for team Nautilus findings. But, you know, we've even just been talking about how do we get this information and how do we share it and how do you stay on top of it? And so when you have, you know, experts in the field who are delivering this kind of information, making sure, again, not to say, here, add something else to your to do list, but exactly to that point. Like, the pace of cloud native, the threat actors that are always getting smarter, it seems.
You know, how do you keep on top of all of these different changes? And even if it's just a five minute, you know, quick debrief with your team or keeping updated, especially when you have access to these resources, I think is incredibly important, especially in this world and especially in your transformation. How things were in the old world and how they are today in the new world and how you manage vulnerabilities, cloud native vulnerabilities is a whole different beast that, you know, we understand you're all trying to tackle.
I agree, Andrew.
Ed, I got this one from you. But, traditional, like, handover practices that people may have become accustomed to. Say, you know, you're working in a DevOps group and or your security team and you get a new hire.
How like, what does that transition or or, you know, passing of the keys look like, and and how do you ensure that it works well? Because I can't see there being, like, a blueprint for everyone to just, like, pick up and just run with.
It depends.
Right? I mean, when you're when you look at the typical sort of DevOps team or security team Mhmm. What I what I've learned is that the way they tend to look is the way the baseball team looked in Sandlot. Remember that movie?
Were you guys were you guys Myers.
I always wanted a pair.
Did you love that movie? Like, with that hawk. Yeah. You know the movie, Sandlot? Yep. Yeah.
Yeah. Yeah. Mhmm.
So if you look at Sandlot, there's one guy on the team that's amazing.
There's another couple that are pretty good. Like, Benny makes the major leagues. The other two, couple of good players in there. And then a whole team of people that do their work and are helpful, and they found out the team. But they're not you know, that's just there might be other things in their life that they're world class at, but it's not DevOps or it's not security. They just do it for a living.
That's how every team looks. And by the way, that's why nation states beat the pants out of so many enterprise security teams because they look like an all star team, and we look like sandlot.
Like, that's every team I've ever seen, every team I've ever been part of. That's just a fact. So when you bring somebody in, what are you bringing them in to do? Like, did you hire somebody to come in and help clean up your, you know, your Oh, really?
A little bit, and they're you know that they're an average contributor, and that's okay. And you brought them in because it's a somewhat mundane job. You're not paying him a ton of money, but it's sometimes speed. Or did you are you really bringing somebody in that you expect to be the superstar?
Or is it some kid right out of school that was your intern, seemed to work hard? Let's make the intern a developer now, pay them a full salary, and we don't know what we're we're not sure yet. It all depends. Like, when you're hiring people as a manager, what are your expectations?
Now it what should happen, if it was perfect world, is that everybody's an a player. You only hire the best.
Everybody's gonna be great. And anybody I bring in, I have the expectation that they're gonna be the best contributor in the whole team. Yeah. But what really happens in practice, that never happens in practice.
And I'm sure everybody listening here knows what I'm talking about. So when you bring somebody in, the question is, what's the expectation? What are you trying to accomplish? Where do you expect those people to to, to fit into the team?
What is it you're trying to do? And then the training should be laid out accordingly.
That that now if if you bring somebody in senior, training shouldn't really be part of the equation. You know, that bringing them in, pay a bunch of money. They've got, you know, seventeen years experience in exactly the domain that you're working, maybe an OT team, and they used to work at, you know, a car company doing, you know, with the chief sec chief product security officer. They're coming over.
Yeah. Then they should hit the road running. But if they're coming in with the, you know, adjacent skills and they've never done what it is you're doing, then you gotta train the heck out of them. So Yeah.
Joe, there's no, formula. It really does depend. Erin, I don't know if you have any thoughts.
Yeah. No. I think I completely agree. Right? And especially, you know, depending on where these people are growing up, right.
Or cutting their teeth, especially as, you know, again, organizations are shifting and Joe and I did a webinar a few months ago before the holiday time just on DevSecOps. Right. And those changes that I know we talked to you a lot about that, Ed. Right.
And just, you know, new world, new methodology, go fast, but stay secure, but bring in automation. And so as you're thinking of teams, right, like how did these changes sort of bubble down to them? And it's one thing for your leader, right, to say, we wanna enact something like a DevSecOps methodology in cloud native because we gotta be competitive. We gotta get these features out, but, oh, crap.
We had this security issue or this bug, but we gotta fix it fast. And, you know, are developers responsible for security? Is this just, you know, the security team? Like, it is.
It's right. It's a sort of direction. And, again, shameless plug. If you haven't watched the DevSecOps webinar, definitely go, you know, go take a look.
But, you know, and just some of these constant questions that I'm sure a lot of folks on the phone have is, you know, we're not just moving technology, but now we have different best practices and different methodologies that we're supposed to implement while doing our day job. While, again, if we talk about the core of this webinar, how the heck are we supposed to attack all of these vulnerabilities when they're, you know, going crazy and we're bringing in all this new tech and methodology that we're all supposed to be on top of?
So The best flex for developers is that when managers incent things that are visible like, if you told me as developer, hey. Next week, we're gonna push a new button. You can download PDFs. You'll see it.
It's highlighted. It's an enhancement to the UI. Everybody claps. They can't wait to show customers that they've got this new UI button.
Right here. New feature. But if I say, hey. I just implemented Aqua. We got some better protection here.
This is gonna help us with our compliance. Then they're gonna go, oh, when are you gonna get to something that I can really care about? You know, again, that's what a a bad manager would do that because they go, oh, that's like, yeah. I'm I'm I'm I'm glad you're doing that, but when are you gonna do a real feature?
That's a bad environment. That's what agile is all about. It's about changing the culture so that we're incenting, and we are rewarding developers for making progress in areas that may not be immediately visible to customers. But, boy, they'll be visible to customers if you don't do it.
Right.
So so that's the problem. We I'm sure a lot of people listening work for someone who they just sort of sigh when you say you're gonna spend some time on security, but they get excited when there's a visible new feature that customers can see. That's a problem.
Yeah. I think it's probably, like, mindset in the company too. Right? Like, you have that security first mindset across the board. Yep. Everybody has it.
Just gotta do your best to try to instill it. But, I wanna transition into the final question.
And, you know, we we have to be confident in our ability to reduce risk, to build resilience, in cloud native with with, you know, the sheer amount of vulnerabilities and the fact that it just never stops, like, you know, you go to bed and you wake up to, I don't know, like, five hundred new vulnerabilities, that's gotta be a lot to deal with.
How like, you know, I guess the point that I'm trying to make is, like, does it does the initial, like, implementation and the the tailored, like, deployment from the vendor help to make one's life easier down the road? Like, how how important is that to to someone like yourself and, like, the vendor, like, takes the time to really know, you know, your environment. Everyone's different, and they, I don't know, like, the white glove service you to make sure that this fits.
I was hoping Bruce Willis would have some advice, but, no Bruce Willis quote there. Or the Demi Moore is not in there either.
You don't have any of those, quote any page to Gruber.
I mean, Joe, that's the whole that's the whole point. Like, if you were at the point now where automation and that implies platform.
I mean, unless you're writing your own code, you're gonna be working with a vendor. That's the way you deal with this. Like, if there's a what's the point of all this? It's that you gotta automate. You have to have some platforms that work. And you better pick your vendors wisely.
Like, in cloud, there's a couple. You guys are one of them that that I would trust. You know, there's a whole long tail of solutions I'd be a little nervous about. But I think as long as you got a reputable vendor that understands the problem, that that's your you know, you're you're already halfway down the road toward a solution.
What the evilness here is just trying to put something in place where I'm just, you know, using a bucket brigade thing, man manual bucket brigade may ain't gonna work. But picking good platform vendors that are dealing in both real time and also in, so there's posture and there's real time coverage. You need all of that stuff in cloud.
As long as you're thinking along those lines and trying to make sure that the partnerships are good, you shouldn't have to worry about there being five hundred new vulnerabilities. That should be taken care of. If you're if that is a problem, then that is the problem. That's the point. Like if, if you, if you're thinking about that, that's, that's the problem.
Well, and I'd love your take to it. I kind of mentioned this when we started, which I can't believe that was almost fifty minutes ago, but, the connection, right? Like it's one thing a lot. If you, you know, even just go, how do I manage these cloud native vulnerabilities?
And everybody will say, we'll help you prioritize them. But how important to you, especially, you know, in this role is that connection, right? To be able to take that context of what's really running in the cloud. Right?
You're running live applications all the way back to the developer. Right? That line of code that it was written. How important to you is that?
You know, it's it's it's changing a mindset, right, of prioritize. Just, you know, we've ranked these things as critical. Go attack the critical.
But to what end? Like, how important do you feel is this sort of connection between, you know, what a lot of people claim as code to cloud, but that code to cloud and back. Right? That connection of what's running in runtime, what's real, what's severe, what's exposed to the Internet, and how can you go and fix it faster with that, you know, exact line of code with that developer?
I mean, that's cybersecurity, Aaron. It's it's figuring out, picking your battles. And if you're working with a good vendor, then they're going to help make sure that the handful of things that really do matter are the ones that that fix. We've all had the experience, for example, of some vendor saying, hey.
I'll scan your thing. Like, may like, they'll say, I'm gonna look at your m three sixty five and tell you where you misconfigured and get a report that has eighty seven thousand things you did wrong. And you might have an out of the back out of the box deployment. You read them all, and maybe you change one thing.
You know? Like, they they got a point there, but then the other eighty six thousand nine or whatever, you just go, this is all space junk. Welcome to cybersecurity. I mean, that's that's the problem we've all dealt with.
So so really, like, Joe, your example, like, five hundred CVs, you know, or or vulnerabilities or whatever being reported. You want automation, you want intelligence, you want vendor support to be going through that and bubble up to you the one or two things that really do look like they could be severe issues, and that's what you spend your time doing. And, again, even there, automation needs to be the solution. We've got to get away from over dependence on human beings making decisions here.
Humans, the people listening, we need to be curating the automation. That's the thought process that should be going in your mind. How do I oversee this? How do I, as a human being, curate that craziness of all the that chart that you showed with the CVs?
That's what's coming. So you gotta curate that you can't be in the middle of that.
Well, it's complemented by the point you made earlier, right, about your developers, about your teams being trained and educated. And if we can bring in, you know, the mindset shift. Right? If we can bring security all the way to the beginning, if we're providing as, you know, leaders of organizations, our development team with these resources, with this training, with, you know, accessing what is available to the vendor, then not only are we tackling sort of this prioritization problem from a context perspective, but also if we're smarter about security and if we have a security first mindset, the shift, then hopefully the ultimate goal then less is coming in to begin with.
So hopefully there's less that we even have to worry about when we get sort of to the end of the process. Right? Or the the prioritization of the list essentially goes down if we're combining exactly what you said, this automation, this education, this security first mindset shift, acknowledging the problem as it is, right? Wow.
This is really sucky and this is really hard, but listening, you know, showing up to webinars like this, listening to leaders, you know, having these open discussions, that that all makes an impact. So those are some really good points.
No. I think Aaron just gave you your highlight reel. That was cool. That little piece.
I was just thinking about, oh, that's gonna make a nice part that you put, like, you know, the webinar, you put the little snippet up.
You know? And I think Aaron's little piece, that was pretty darn good.
Whatever you just said, that was good. So but, I mean, I think that encapsulates it for sure. Nice.
Well, team, it's, ten of. I wanna leave some time for questions, everybody.
Looks like Thomas, dropped in the q and a. Just yeah.
We hear you, Thomas.
So, yeah, day sixteen of the year. Man, it's crazy.
Alright.
Daniel asks, is the recording gonna be shared?
He needs a link for his manager.
Nice.
Or it will be. Give me a couple hours, and I'll get the link over to your inbox.
Well, and two, while we're waiting for the questions, right, Joel, like, we talked a lot about problems. Right?
And we gave and Ed gave some wonderful answers of solutions, but there's a part two of this webinar if I'm There is.
Next week.
Next week, we're gonna show you guys this in action. Right? So, taking these insights and applying them and, just showing you how it works.
And, look, there's one more question, though, in the chat. Secure by design. Mhmm. Are thoughts on it, in the cloud?
Well, Sys has made a big deal about that, and I think that that's good.
The these sort of aphorisms that are filled in with, you know, some examples, I think they're okay. Like, the problem with secure by design it's not a problem, just the situation. Is that ten people will interpret that ten different ways? Like, I'll I'll make a claim.
I think I was complaining about something on social media, and somebody was like, well, that's what secure by design is. And then I'll talk about some other completely different thing. And they go, well, you know, that's what they meant by secure by design. Like, oh, wait wait.
Like, what? So I do understand. I've gone through all of that. These are well meaning concepts, and and I think that that's fine.
But a lot of times, those those broad generalisms get applied to an awful lot of different scenarios. So use them as you say, see fit, but partly systems made a big fuss about it.
All people trying to do good. Right?
But sometimes It's all. Well do many things.
Yeah. Hey. Let's go team here.
Yeah. Yeah. Yeah.
You know? Yes. People. I'm not gonna see a lot. Obviously, we're filming this beginning of twenty twenty five. So we'll see a lot of changes, it says, over the new presidential administration.
Yeah. Yeah. Yeah.
How that goes. Mhmm. Mhmm.
Yeah. We'll have to, catch back up on January sixteenth twenty twenty six and do a year in review.
But yeah. So, everyone, I think it's time to run through a quick recap of the the takeaways. And Yeah. The the q and a is still open, so feel free to drop them in there. But, thank you again for joining us. And as Aaron said, same time next week, we'll be showing some some demos and providing, a little more insights into how Aqua can help you, with with these challenges and and innovation and allow you to manage these vulnerabilities with confidence and and clarity. So talked a lot about the rise of fake CVEs.
It's not just noise. It's definitely a real problem. We've explored how cloud native architecture, it demands new approaches. You know, it's it's an opportunity to think a little different, and we've heard some strategies to take back control. And I think that also includes the people that are on your team. Right?
How can you turn them into, Spartans from the movie three hundred? You know what I mean? It's it's it's not like David versus Goliath, but, we understand how overwhelmed I can feel. And as Ed said, there's vendors out there that can help you. Take a look at that contract. If they're offering services, take advantage or training.
I just was talking to Yoneer, our, curriculum director, and, Aaron, he just uploaded your DevSecOps webinar as a Nice. Course last night.
Nice. Great guy. Yeah. So next week, same time, a little deeper into the how, and provide actually the you're gonna walk away with a four step framework that that you can take as a as a takeaway there.
Yeah. Yeah. And is our presenter. Right? Our wonderful, field, CISO CTO, and he has these conversations. You know, he's on-site with customers day in and day out, some large massive enterprise customers who are customers who are having these same challenges and has developed this really effective framework again knowing that, you know, not one size fits all, but I think he'll come with some really, really powerful, helpful tips. So that'll be a good one to to to look at.
You want questions. So ask him as many questions as you want.
Yes, yes, yes, yes.
Yeah. And I wanted to say, Joe, we had a good, Brian just, jumped in the Q and A, not a question, but, you know, just sharing with the, with the group that an observation on secure by design is ensure your engineers keep up to date with principles of security and to utilize, OWASP as as a channel to do so. So great great tip, Brian. Thank you.
Ed, Aaron, thank you so much for sharing Thanks for including me.
Look forward to the next session. Thanks, Eric. Thank you.
For making the time to join us. We'll see you next week.
Yeah. Thanks, guys.