Managing Technology Supply Chain Risks with Corey Amsler | Qualys QSC 2023
Corey Amsler, director of cybersecurity at General Electric Vernova, discusses how to assess, prioritize and remediate technology supply chain risks
Transcript
This is Textron tv. Welcome back to the Quass Security Conference Americas. We're here with Cory Amsler, who's Director of Risk Management EVM over at ge.
And we're talking about how to deal with customization of the Quass platform for providing vulnerabilities. 'cause well, not everything is quite as it appears sometimes. Corey, welcome to show.
Thank you. Thanks for having me. You did a whole presentation on this topic, so maybe just walk us through some of the high points, but I'm not even sure people are aware that they can do this.
Right. So, uh, we had some challenges with detecting some vulnerabilities, uh, with DMDR that, you know, sometimes the detections weren't built quick enough or we had some custom configs inside our network that, you know, weren't taken into account whenever those quids were created. So, uh, we utilize Qualys custom assessment and remediation or car utility or is able to, you know, really bring it in-house when we need to.
Most of the time we still rely on qualis, but on those niche cases we actually detect the vulnerabilities based on our scripts and our testing. And then we're able to create, uh, quids off of that. 'cause Quals just released a new utility feature from CAR that is called custom quid creation.
So any of our detections from a vulnerability perspective, we're able to, to put right back into VMDR. Not everybody is GE and they probably don't know how to write a script. How hard is it to do this?
You know, KWA is made it actually really easily, uh, if you know Python, you know Pearl, you know, bash or PowerShell, any of those, you know, regular scripting languages, uh, you can write any of those. And what we actually found was from an application team perspective, right? The one we presented on earlier was about Oracle.
I don't have that expertise on my team. So I actually had to work with the application team and we were able to work together, write the detections, write the scripts, and ultimately it wasn't just about that vulnerability, but it brought our teams together to make us more cohesive as a company on being able to detect the vulnerabilities and remediate. 'cause now they understand the other side of the house.
So if they work on the detection process, they take their remediation is a little more engaging for them because otherwise it's just a random spreadsheet from security, right? Right. We are no longer that evil person on the other side of the wall lobbing bombs over to them, right.
You know, that everyone gets on a Friday afternoon, oh, I gotta go patch this. What? Right?
We are partners with them though, and they're able to, to reach out to us and say, Hey, I see you have this vulnerability that you're saying we have, but we actually don't and here's why. And we're able to work with them now and there's a much better relationship. Is it easier or harder with, I'm assuming you have some custom applications of your own versus, you know, stuff that you might get from vendors Or is it harder to kind of find vulnerabilities in the applications that you guys write versus vendors?
Or is it roughly the same or you know, what, what's the experience like? Yeah, There's challenges across the board, right? Because no matter where you have developers, they all develop different, right?
And then just like qualis, sometimes one of their technicians will write a script and write a detection and it works perfectly. Other times maybe a different technician got that, uh, vulnerability assigned them or CVU assigned them and their detection might be flawed. So A lot of times developers will say, well that's not internet facing, or I didn't actually use that piece of code in their production environment.
But then it turns out well it is. So how often do you have a conversation where, you know, the assumptions being made aren't quite what they are or should be? Yeah, I think Ed had, uh, his presentation earlier today that he said, you know, it's takes two days for the application team to be done arguing that they didn't install that right.
Or they're not using that. So, you know, have bringing them closer to the source right. And having their skin in the game allows them to Dr.
Knock down those walls, right? And say, okay, instead of me saying I didn't do that and ignore you for two days, they're like, you know what? Why is it saying that?
'cause they trust it more. Why is it saying that I have this, let me go take a look real quick. Do you think as the outcome of this, they might be willing to engage earlier with you guys before they actually deploy a piece of software to have this check because you know, it's less painful to do it earlier than later.
Yeah. And maybe they won't view security as quite the obstacle as they used to. Yep, absolutely.
We saw a shift left mentality, right? Uh, where we're bringing in, well they brought us in right? When they're building those containers or, you know, making gold images, you know, looking at the registries within their um, CICD pipeline, right?
Using some of the Qualys tools there and some of our other stuff, we're able to now see that and prevent stuff from even going into production that has vulnerabilities. Are they also willing to trust you more to remediate certain vulnerabilities that may not be, you know, a, a, a complex issue or it's not a, you know, super mission critical application, but it doesn't necessarily always require them to go implement the patch? Still working on that one, right.
You know, everyone I come from, you know, the other side of the house where I used to run patching for five years, uh, for the whole enterprise from an OSS level and yeah, letting go of that control people don't feel good, right? So you, I think in the next couple years though, we're gonna see that and hopefully we're one of the leaders that do see that melting together and having where security can use some of these tools or we, the tools are built to where the infrastructure team also has the ability to get in there and do it from the same tool. There are also other ways to mitigate things without patching.
So you can implement those tools while you wait to have this conversation Working on that one too, right? They, they have infrastructure teams now deal with infrastructure and app teams now deal with the mitigating controls as well. I know Qualis just released or announced, I don't know if it's live yet.
Um, part of their true risk eliminate is that capability for mitigation. I mean it's really enticing. I'm excited to go back to my leadership and talk with our CIO and CSO and CTO and say, can we use this and allow us to do some mitigations there?
We talked about ship left and developers will say, you know, ship left sounds great, but it's just more stuff on my plate that I prevent me from coding my application. And they say the cognitive load is too high as they get exposed to more of this, you know, does that mental barrier start to come down? Yes.
On some and I hope on others, right? You know, it really depends on the relationship you have with each team. We see some developers and some applications are willing to do that 'cause they understand, hey, if I adopt this in the front end, I don't have to worry as much on the back end and they're not gonna bother me every week because I know that I am putting code out there that is good and already, you know, remediate all those vulnerabilities.
I'm not introducing stuff that's been a year old. Especially when they know they're gonna get bothered at four o'clock on a Friday. Right?
Yeah. That's it. Um, we've been talking about DevSecOps processes for a while and bringing together the developers in the security teams.
You know, is it your sense that we're making real progress here? I feel like it's a long time coming, but you know, where are we? Yeah, it's a long time coming.
Right? And we're seeing that pendulum shift because how many years ago was it where the developer said, oh, we don't even need security. We're gonna take care of everything.
Well we saw that was a lie. Mm-Hmm. Intended or unintended.
They just, that's wasn't on their, their priority list, right? They have to write code, get out and meet a deadline for production. They don't necessarily care about security.
Mm-Hmm. So whether they did or didn't, they weren't able to have the time to focus on it. So you still need security there.
And I think we're getting better and better at that. Uh, 'cause it's so much more important. It's out there more in the world.
The news every day where you're seeing vulnerabilities, you know, have extreme impacts over, you know, utility companies, um, you know, even governments right? Getting hacked over and over again. 'cause they, they paid ransomware and they don't fix the exploits so they see the importance.
Can we get better at kind of creating some institutional memory? 'cause what I see happening is developer A goes out downloads component, has vulnerability, gets fixed, developer B goes and finds another repository, downloads the exact same component, has the exact same vulnerabilities and neither one of them knew what the other one had experienced or done and could have maybe learned from the other. But how do we kinda operationalize this a little bit?
Yeah, I think you don't, I mean there's always education out there, but I think from a company perspective, you actually have to tighten the reins a little bit and say, here's the repositories that we already have vetted and these are the only ones you're allowed to, you don't have the the wild goose chase 'cause someone went out and you know, pulled something from the internet. If you tighten those controls with the partnership of the developers to say, okay, what are the registries and repos that they trust? Bring those all in-house and then make it, you know, where they have to use those.
And then you have a robust process to add new stuff in there. I think that that really is how you kind of solve that. So They have to buy into this process.
You can't just impose it per se. Right. And that's where this, you know, it's full circle.
Uh, going back to the application teams and working to help develop the, the detection scripts knowing that they have skin in the game there. Hopefully we can eventually get to that point where they allow us to bring that dynamic into play where, you know, we buy in where it's all just one repel repository and we're able to go, Are we long term gonna maybe measure this activity? And I asked the question because a lot of security people are scratching their head between, well, what exactly is the difference between a developer who's too busy and a developer who's just too lazy?
Yeah, that's a, a great question. And honestly, I, you know, how do you measure it? I think you probably could, uh, based on each developer, and I'm sure I haven't looked at, but I'm sure Qualys and other vendors would have that capability, right?
Uh, based on application, how many vulnerabilities were introduced. And then once you're able to scorecard it, I'm sure some CIO out there, uh, would and CISO would take that and run with it and the application developers would finally perk up and change. Alright.
We can only hope. Yeah. You've been at this a while before you began this adventure down into the rabbit hole of application security and how to manage all this process.
What do you know now that you kind of wish you knew when you first started? Hmm. That's an interesting question and I think from my history of even patching on the other side, but the OSS side is, um, you know, building those relationships, right?
That's important in life on everything. And I think it's really important with the, the developers and security. 'cause you know, instead of each one hating each other, you need to come together and work as a team.
So I'd say that's the thing that's really opened up my eyes is building those relationships, getting in the trenches with them and knowing that, having them know that you're not just trying to be a, a hammer to their nail. Right? But you're trying to, to be a good partner.
Everybody these days is talking about ai. Do you think AI can be applied here and maybe save us from ourselves and hopefully in a way that won't kill us? I think you have to be cautious with ai, right?
I know Qualys is doing some AI and machine learning and it's fantastic for how they can can do that. Um, but when you're developing code, I thought a lot of people would know about Samsung and how they use chat GBT and now their code is up there for everyone to see. So, you know, uh, every business needs to be cautious on how they implement it and are they going to just do it in-house?
And you might even see where, you know, data centers come back into play 'cause you want to own everything and you want to even own those disks that that's going on since you're so cautious about it. Mm-Hmm. We've heard the phrase that every company is a software company now, and I think we've seen GE evolve over the years and it's pretty much true and it's impacted their business models and everything that goes with it.
Does the senior level executive team kind of appreciate security more and what goes into all of this because they're recognized, they're recognize their greater dependency on software and they're kind of understanding this supply chain and the whole ecosystem? Yeah. Uh, I mean, absolutely.
You look at, you know, a hundred years ago, yes, we made power plants or power devices. Yes, we made aircraft engines, right? But there wasn't this tech behind it that there is now and all this interconnectivity, right?
And you got hackers and nation states that are always trying to break in. So by bringing that up and showing it and showing the evidence to our board and our senior executives and our c-suite level, they understand now the importance not just on our applications that we're developing and, and provide out to customers, but also on the internal apps that allow us to still make those aircraft engines and the, the turbines and even the, you know, the wind farms and everything. I think it's no secret that the attack surface is much broader than ever and it keeps getting wider and wider.
Um, what are the challenges in keeping pace with that from your perspective? 'cause it seems like, you know, especially a company like ge, you can wake up every day and there's a new app somewhere. Yeah.
New app somewhere. Uh, on one of the demos today, they actually had a toothbrush was found on the network. I mean, who would've thought of toothbrush has to have an IP address and a Mac address.
What the heck? So, you know, you'd say wake up every day. I mean every, you know, how do you sleep right?
With all this changing. So you just have to have confidence in your team to be able to, you know, go out and first understand that you don't know everything and then every day make strides to try and find out more. Right.
Next year it'll be a toothbrush with a memory card you can plug in and that'll be even better, right? Yeah. Yeah.
Um, How do you cope? There's a lot of things to worry about, can keep you up at night. It could probably stress you out and cybersecurity folks are, you know, it's a, it's a tough gig sometimes.
Yeah. How do you, you know, what's your advice to folks in terms of how not to lose your mind? I think and, you know, sharing a little personal experience, I actually, um, lost twins, right.
Um, right before, um, you know, they're supposed to come. It was a premature birth, right? So, you know, I've had my heart ripped out and my wife and I made through it.
We have four healthy, happy boys now. So it's a great, great, congratulations on that. Thank you.
So, you know, we're, we're great and healthy, but that taught me that a job is just a job. Not that we don't wanna do great, right? And we don't wanna propel ourselves, but there's things bigger in life than work.
And if you know that you're gonna be able to work at a high level because you don't worry about the risk per se. Mm-Hmm. And do you worry about every loss or do you kinda, it's like football, right?
You can't win every game, so you're just trying to win most of the big games. How are you thinking about that? Yeah, uh, you know, it's just like, you know, critical, high, low vulnerabilities or even the, the true risk score typing that Quas has now, you gotta pick the things that are the most important and focus on them.
Whether it's the external facing assets and, you know, maybe a, a low vulnerability on there is actually more important than a critical vulnerability in your sin that's deep in your network that no one actually can get to. Well, there you have it. Yeah.
Folks, we learned two things here. One is it's important to track your mental health and make sure you're not driving yourself crazy. But the best thing you can do for your mental health is make friends with the people who can help you out, out.
So spend some time, walk around and shake hands and, I don't know, buying pizza. That works. All right.
Thanks for coming by. Thank you.





