All right. Welcome to Distilled Security Podcast Episode 11. My name is Justin. I'm here with Rick and Joe and thank you for joining us. So we got a pretty good episode here going with a little bit of breaches and privacy and all this stuff. I think the place I want to start, it's hot on some of the topics and we're kind of dipping into political, not really going political, but there was a story that came out with Signal. Big fan of Signal. I use it all the time.
What is Signal?
Yeah, Signal is an encrypted message app. One of the benefits about it is that it doesn't have kind of a back end server. It basically has a server to coordinate and connect people, but all the communication is encrypted from point to point. So everybody basically has their own keys that are stored on their side. And if you lose your phone, there it goes.
Like, all your data is gone, you know, into that. So one of the advantages of that is, you know, you're not relying on middle people with that, like the common thing with SMS. All the phone companies, you know, can read your SMS, you know, because they have to basically translate into a way to, you know, through some of the mediums, you know, and a number of companies have gotten hit over do you have NN encryption and, you know, Messenger came out where they put that in, but Signal has always had this with it. And it's gotten more popular, I'd say, now for kind of back end communications on different things, you know. It's gotten good, like as a security community, I'm probably preaching to the choir.
We all know about, you know, signal. But then you get some of those stories out there where like they're going over signal, you know, to not get caught for what they're talking about. In this case here, the surrogates that there was some coordination with one of their operations and they accidentally incorporated the editor in chief of The Atlantic into the Houthi strike that just recently happened. Was it Mike Waltz was the one that originally created the group and put him into this group here. And you had people like JD Vance, you had Marco Rubio, you had a number of, like, high profile people that were coordinating on this strike that were against some of the Houthis and everything.
You know, and this goes into, like, a couple of things I think are really interesting to talk about this. One, you know, the use of approved and unapproved channels, you know, into this. You know, I'm curious, and there wasn't a great explanation. I've been hearing, like, some of the stuff going back and forth, but nobody said like kind of why they use Signal into this. No, no.
And is it just a technology of familiarity that Mike Waltz is like, oh yeah, I'll just spin up a security channel and we'll, you know, coordinate with some of the low hanging fruit and stuff of that nature. So I mean, curious, you know, to talk about that a little bit. But just, you know, from the, you know, corporate side, you know, is this an all right thing to use alternate channels into this that maybe isn't controlled? You know, I can think of some legal aspects into this here. I don't know.
What do you guys think here?
We need to go first.
So I feel pretty strongly that there's like a difference, but there's a little bit of pragmatism you have to apply here, right? There's always gonna be what I think of as chatter between, if you're in a corporation, like between employees on non corporate communications, right? I think that's just always going happen.
It's probably happening on text message and messaging all the
time. Right. We're doing phone calls. I mean, know.
And if you provision corporate assets, even if you provision corporate phones, and even if they're fully separate than personal phones, either way, like people are gonna use non approved channels to talk about work stuff. People have friends at work.
Right.
They're gonna talk about work stuff. And ultimately, you could debate whether or not it's that much different than talking at a bar. But it's just another communication channel, and it's gonna be offline. So I think you have to accept the reality of that. Now, I think from a corporate policy perspective, I also think it would be an absolute operational nightmare to try and somehow ban or block or stop or prevent people from using alternate communication channels.
Yeah, I don't know how you would do it. You would have to provision corporate phones, but still they would have personal phones.
Right. So I think this is one of those places where you really need to use carrots and not sticks. Meaning like, make sure the officially sanctioned channels you have support the communication mechanisms people need in terms of like, Hey, look, this is how we share files, and here's like a couple ways internally and externally, like whatever makes sense based on how you do work. Hey, this is how you exchange short messages. This is how you exchange long messages.
This is kind of like our typically accepted ways of working, right? And you know that people are going to have, again, communication channels on the side. But from a matter of policy, I think it's super important to educate people to say, Hey, look, if you're talking about anything important, like or I should say official or anything you're representing the company or there's company files or proprietary data involved or whatever, that's got to stay on company channels. I think And whether or not you even believe that's going to be true, I think you have to set that as the tone from frankly a legal liability perspective and from a compliance perspective. Because ideally everyone does follow the rules on that.
Sometimes people won't, but then they need to realize that they're off on an island.
Yeah. And that's fair and everything. I know like I've had a couple of clients over the years, they'll actually go to like alternate mediums for like disaster recovery.
Yeah. Is it a response? Do think that's
a bit of emergency mode operations is a bit of a different answer.
That could still be approved and that should still be part of the decision of this is the out of band approved mechanism and maybe signal would be good.
I mean, look, if you're dealing with, like, major layoffs or M and A activity, and you're afraid that certain administrators might not be trustworthy, again, there are times where I think it's actually okay to use out of band But it needs to be very specific, very intentional, very clear when it's in use and when it's not in use.
Right. And I don't wanna steal your thunder. So that you brought up earlier, and I was thinking about it too, is you put something in signal. Well, I always love the feature of signal for, you know, get rid of the messages after expire them after a day, five minutes. Yeah.
They had a month on this channel.
So it goes away. And so it brings up a couple of things. Well, what if you talking about things that need to be kept because of e discovery and retention? And then you brought up, well, what if it's a conversation that the Freedom of Information Act wants to be able to pull and now it's gone. Right.
Yeah. And I do think like educating employees on, hey, by the way, if you are communicating sensitive data over a personal signal account, right, a lot of weird stuff can start to happen with discovery. Or not even if it's not Signal, even if it's whatever. Yeah, WhatsApp or just text message or what
Yep.
If you start using personal accounts to communicate corporate stuff, and as soon as there's a whiff of that, right, like because someone in an email in an official email that gets discovered says, hey, sent you a text on this. Alright. Check your signal.
Right. Now it's good.
Now it's discovery. Now your personal stuff is theoretically part of discovery. Now in signal, if that stuff is gone gone, well, again, depending on whether you're sort of on offense or defense from a legal perspective, like prosecution or defense, you could be facing a world of hurt because you could have official documentation, official communication channels where you did not sufficiently You're not sufficiently able to provide evidence about what you did or what you didn't do.
Yeah. Yeah. And imagine on a personal level, if now you are ordered to turn over your personal phone and who knows what you've been looking at, who knows what you have on there, that's all going to be at least reviewed by somebody and whether it can be put in
or not. Somebody will have to have the smarts to filter out whether it's applicable to the case or not. But they'll see everything.
And typically, you know, the way that evidence works in legal proceedings is the prosecution and the defense get to look at it. So it gets picked apart by both sides. People that are looking to maybe, you know, defend, you know, maybe defend your honor in some ways, but also people that are looking to impugn it. Even if it's just a straight social thing, right? If it makes you a less credible witness or puts you more on the defensive in the eyes of a jury or whatever is going on, yeah, they lever some things that maybe you wouldn't want to be levered and frankly have nothing to do with the business dealing that's under review.
Now, I wanted to bring up too with this because it almost has nothing to do with signal. Yeah. The way the reporter got added into this was it was either in his contacts or something like that. You can actually change your name into it, it was just the initials. He thought it was somebody else, you know, and put them a part of a group.
So, you know, it wasn't any fault, you know, or anything like that. But he thought he was adding somebody else. You can do that with email, you know, like with some of this stuff. So, you know, it's not immune to signal or other devices like
But I would say like corporate like official channels typically have naming conventions. Yeah. So like, yeah, you could do that with email, it's And
it does like There are technology out there that will flag outside people, know, so from a corporation or something like that. But if you have, you know, if you're in a big corporation and how many John Smiths you have into there and how many times you get, you know, cc'd and you're like, oh, it's the wrong one, you know, type of thing, Most of the time it's, you know, just dealing with random stuff. But
Yeah. I've worked with organizations that have absolutely had to do privacy disclosures because they the wrong they sent the email to the wrong recipient, and they're out of the organization. They're not the wrong and yeah. It absolutely
happens. And and don't worry. We password protected that spreadsheet, but then the second email we sent is what the password was sent in. So Right. Same mechanism.
But well, you brought up an interesting topic because we just I just saw this on there's a a TV show called Bad Sisters. I don't know if you saw it. It's a couple seasons, like eight episodes or whatever. And in one of the episodes, you know, kind of the the the bad guy in it took the phone of one of the sisters and changed the boyfriend's name phone number to his. And then when she started sending texts and she was cheating on her husband, he started getting them to hold it against his sister-in-law as like, look, you got to stop doing this.
All he did was change the phone number. So she thought she was texting.
And who knows anybody's phone number nowadays? Right. Know,
type of thing. Hit the send button and off went the pictures.
That's your name right there, you know, type of thing.
Well, and you brought up a good point that I think is slightly related earlier as well which is when you're using, I mean really any communication mechanism, the security of it, even if it's encrypted end to end, the end, if the endpoint is vulnerable in some way, shape or form, right, the whole channel is potentially vulnerable. So if someone's using signal on their personal phone or machine or whatever, and that's vulnerable, to your point earlier,
Oh, yeah.
Yeah. It's a mechanism. And so I do think that again, as corporate policy, you have to say official channels only. And the other thing too is even for
So they should spin out their own signal app or someone? They can.
I mean,
it's all open source.
It's actually not though, it's I haven't seen anyone do it, but I don't think that's a bad idea.
Well, does Signal have a an enterprise version?
No. No. But they have everything open source that technically you can't split it up, you know, type of thing.
I don't know if that'd be a bad idea, honestly.
Yeah. And they could probably do some additions into which groups, you know, and actually integrate it into some of the government like identity stuff and everything if they wanted to go down that route. But we all know, like, we haven't talked about the ideal solution for all this is just put a disclosure down at the bottom of your communication. Say if anybody got this or was supposed to,
unread it immediately.
Yeah, exactly.
If that would have been at the bottom, then the Atlantic would have read that
and they would have said,
We definitely aren't going to publish all these articles, all these messages.
Was like, Oh, I'm not authorized.
So, I just found this. So, the report suggests that Waltz may have confused Goldberg and Jeff Goldberg's the guy from the Atlantic's initials, JG, with those of another official. So that's what we were talking about.
But the other thing I wanted to bring up quickly though is from an endpoint security perspective, the other thing that if people are communicating on an unapproved channel that you don't get is anything in your detective stack that's watching UBA or potential indicators of compromise, you ain't seeing that, right? It's just not monitored because it's potentially a personal channel. So yeah, things to keep in mind. So I think pragmatically you have to realize people are gonna talk on not official channels, but you probably got to remind them periodically to be like, Hey, if this is trending towards official territory in any way, shape or form or you're sharing proprietary data, you got to bring it into an approved channel.
Yeah. And there was one other piece, though, and it's I think it's the first time I've heard this happening, but and it came out like I don't think signal until recently has ever been claimed to have been breached. Right. And now in the last month, there was a claim that the Russians have somehow or another breached this.
Been a lot of weird claims out there. They they usually come down and say, no, there's like the underlying protocol has never been, to my knowledge, breached, you know, into that. It's always the endpoints or the device or something like that where those are the weekends.
So if you're securing the device, it's less likely.
But if you unlock your phone and give it to the FBI, they'll copy all the contents including your signal, you know, messaging off of that, you know, like.
Yeah. And there's definitely a difference between like was the infrastructure compromised or were different accounts compromised because people maybe,
you know, they don't have infrastructure to actually respond to Like, I loved and it's actually funny, like some of the government like people will actually get really mad at SIGNAL. Like, this was years ago when they give us all the text message and they're like, we don't have anything. Like, here's what we have, some phone numbers that they talk to. Yeah. That's it. You know, type of thing. They're like, no, you need to give it this. Like, we don't have
Doesn't exist.
Yeah. Like, you know, and it takes them a little bit to be like, do you mean you don't have it? Because they give it to phone companies all the time and they get all the messages and everything, you know, coming back to them. So yeah, it's an educational thing from a law enforcement perspective, you know, if you're not familiar with some of these end to end encrypted messaging, you know, into But yeah, it's even interesting like depending on the technology, like Teams is end to end unless you enable some stuff on it. Like if you start enabling some features, it turns off end to end type of thing.
So you have to I was looking at that for some scoping stuff on whether you could do like some PII over it. It's like, yeah, is it end to end? And let's look at it.
Depends on the configuration.
Yeah. If you start doing like recording or AI or some of the stuff where it has to kind of see what you're doing, you know, type of thing, it's like, yeah, it's not end to end anymore type of thing. Yeah.
So end of the day, you still encourage people to use Signal? You're gonna stop using it?
No. I love Signal.
Yeah. I'm not gonna stop using it for personal stuff. And I think for isolated instances of professional things, it's the right move, but you just got to be really intentional about it.
Yeah. And I think a little bit different from where they're using for how we use it. Usually, at least, you know, in some of the cases, I use it in smaller groups, you know, if we're talking about different things.
We plan podcast topics over signal.
Yeah. And it's just us three really on that. But we have, you know, a bourbon group that was bigger and all that stuff. But if it's I ever use it for any type of business, it's usually one on one or a very small group. They had like 18 people that I saw into there.
Talking about some really sensitive stuff potentially.
Yeah. Not one of them knew all the people in there so you can't know and vet like all these numbers and be like, I'm sure not one of them had every single number in there, you know? So it was like, okay, they're part of this group. Somebody vouched for them, you know? So,
you know Somebody didn't accidentally add the wrong
Yeah, exactly. So you're trusting through, you know, other people, you know, into that, which almost you have to at a large group into this.
But then like what's the level of sensitivity stuff you should be talking about in a larger group? That's a different question.
And the other thing I like about SIGNAL is developed by the Signal Foundation, which is a nonprofit organization. So they're not supposed to be
They're motivated.
Yeah. They're not motivated by money. They're motivated by truly creating a secure environment. Yeah.
And I will throw out, if you don't, definitely contribute to them. I drop $10 a month, you know, with them. I like to pay back on products I use a lot. So we do this in development. We use some like big third party products, you know, in some of the stuff and we contribute to them through GitHub, you know, sponsorship program.
But Signal is one thing that I use a lot, so I give $10 a month to them. So if you have it in your budget, definitely think about, you know, and use it a lot and value it. Definitely give it
Every once in a while it comes up and it says, validate remember your PIN or validate your PIN. And then once in a while it comes up and says, you're ready to donate again. And then you just click the button. Well, that's good. Anything else on Signal?
Well, you're saying there have been a lot of claims, you know, over over time about, like, Signal potentially being compromised or not or whatever. There's I think there's another company that's been denying claims of comp compromise recently. Yeah.
Yeah. I wasn't sure where you're going with that because there was another one too. But, yeah, Oracle Cloud is denying that they had a compromise or a breach, but there was somebody claiming on, I think it was on Friday last week. Yeah. And so there's still a lot of information to be uncovered and probably have to do another update on this in the future when everything settles.
But at a high level, they said that 140,000 Orgo Cloud tenants were potentially the threat actor claims they have a list of those whose data was compromised, making up that 6,000,000 records.
Pretty big.
From my understanding Are these records on the tenants or records of their customers that they had on their cloud or?
Well, I understand is that it's 6,000,000 data records stolen from Oracle Cloud's Federated SSO login servers. So like authentication, that kind of stuff. And the hacker claimed the data included encrypted SSO passwords, Java key store files, key files, enterprise manager, JPS keys. And so but there's been a a lot of people who've been checking into this, and some of the people checking in are looking and saying, well, it might not be on the actual current day Oracle stuff. I know it's something legacy or something that was, like, de provbed and just not gone.
And, but on the other hand, other people are coming forth and claiming, and there's some good articles out there, just search for them, that there's, customers are coming forward saying, yeah, some of the data that they claim they had in their sample that they released is actual real data.
Yeah. Some journalists have gotten cuts of the samples from the attackers, and those potential customers have said, Yeah, this is legit. This is us. So while Oracle says, Nope, there's no breach, whatever, people are saying, Yeah, this is our data.
Yeah. And maybe there's not a breach of the Oracle Cloud infrastructure itself, but maybe there's some other Oracle thing.
I'm always supposed to hear some people coming out pretty immediately and be like, Yeah, it wasn't us. Type of thing. It's like, Can you just say you're investigating? Don't come out and be like, No, that wasn't us. It's like, Just look into it. You know, like, you know, there's
Well, it does feel very much like Although I would guess this is not the case. Whenever statement is, Yeah, we thought about it. It's not us, it does feel like investigation concluded. Yeah. I would suspect there's
still a How many times have we seen that? And then a few weeks later is, well, upon further investigation, we've realized that the breach has been expanded to, you know, this.
Yeah. Exactly that.
So that's why I think we'll have to do it.
I mean, it could be an insider that's, you know, copied, you know, some hard drives or whatever it is, you know, type of thing. Like, yeah, like continue to investigate it, you know, into this.
But I do think it it raises some good topics potentially around, like, okay, well because I I kinda like that we're in this liminal state, like, it is it real? Is it not real kind of thing, even though it kinda feels real. What you do?
What could
you do? Exactly. Exactly.
Well, I think the first step, if there's a reasonable suspicion, even if you don't think it is like Oracle is coming out, start resetting passwords. Start setting keys. Go through and be like, hey, we're working with you. We don't think it's us. We're still investigating, but we're going on the safe side.
Yeah, that's the exact advice. So I got a really great compliment because of what my team did for one of our clients where they are heavily supported by one of the big consulting firms. And we're doing some very point cybersecurity VCSO slash GRC and a little bit technical work. Well, we we beat the other group to the punch Monday morning, getting the email out that said, just just do that. And then a few hours later, I was chatting with the CIO, and he said, yeah.
Yeah. You you beat them to the punch, and we're already resetting passwords. Great. That was awesome.
Love that.
They're a growing company, so they don't It wasn't super difficult for them to do it and start to get the keys rotated and get creds rotated. Gotcha.
Yeah. Yeah. That's fantastic. Yeah.
And hopefully I mean, we don't know the source of the breach, but hopefully that's closed maybe, you know, or whatever it is, you know, type of Yeah. Limited scope. But Otherwise, they'll have to redo it again.
Yeah. But, I mean, to me, when we're talking about, like, well, what should you do? It's it's the typical consulting answer to some extent also of, other than the password thing, which is, I think, great advice across the It depends.
What does it depend on, Rick?
Well, like, how are how are you using Oracle? Right?
Why are they using Oracle?
Well, I mean, there are quite a few companies to which you would need to send that question. But but, like, how are you using it? What data is in it? What what scares you about how you're utilizing it? Funnily enough, I'm working with an extremely small organization right now to help them shore up some of their security, and we're just recently talking about incident response.
And they are so small that they do not they need, like, a very high level plan and then really just, like, some job aids. Like, if you have, like, six critical systems, if this one gets compromised, what are, like, the Yeah. 18 steps you do? Basically, the playbook. And they're all highly tailored to, well, how do you use the system?
Is this the payroll system? Is this the accounting system? Is this the legal data storage system? Whatever it is. And so it put me in the mind of, you know, no matter how big you are I I think people get wrapped around the axles on what a playbook is.
They'll think, well, what's our ransomware playbook? And it applies to everything that could be ransomware. And we're a massive organization with 15,000 applications, and how could I even ever write this playbook? No. Honestly, put something down so that in the heat of battle you're like, How are we using the system?
What would we be scared about? Who do we need to involve? Is this a thing that could have regulatory implications? Do we need to brief legal on it? Or is it a thing that like, No, this is just the schedule that we clean the bathrooms and empty the trash? There's
a huge What would they say? Plan is out of date the moment it's written. And in the heat of battle, you know, but without a plan, you're gonna be all over the place. So I always look to say, well, what are the first five things that we need somebody to do that'll cover the first five hours? So just get that part down and then start table topping it and figure out what your next five hours is gonna look like based on the scenario.
But no matter what you put into there, after you do the first five things, you don't know what's gonna happen.
It evolves. It has a life of its own. Yeah, exactly. So yeah, you build some architectural structures around these are the channels we're gonna communicate on during the incident. In every major conversation,
we're gonna There's a hierarchy that we're gonna follow.
There's a leader, there's a note taker, there's a task doer, whatever the key roles are. Then it just kind of evolves. But it did put me in the mindset of like, look, for every kind of major system you have or potentially critical system you have, if you don't have this checklist, what I think of as a playbook, but I've seen organizations like kind of get playbooks wrong, I was like, just get a checklist. Like, how do you use a thing? Who needs to be involved if there's a problem?
And I love the first five hours thing. I'm definitely going to take that forward. But yeah, it's exactly that.
So I thought you're going go somewhere else too, which your playbook should have this. And a lot of places may not know how to do this, but it's have you practiced actually cycling your friends? And it's more than just your users changing all their passwords. It's any kind of place where there's keys.
Oh,
yeah. Any kind of certificates, super user or service accounts. You need to recycle like all of those things.
Oh,
yeah. And if you don't know how to do it and I heard the advice for this particular item is if you don't know how to do it and we're this many days past when this thing came out, but it's so new that we just don't know, then maybe you don't do it.
I saw that. I don't know if I feel good. I'm sure either. I don't know if I personally would
not do it. Depends on the confidence level.
But if you are a really large company with so many, like your hundred thousand employee or whatever it is. Yeah. Organizations and you have vast infrastructure and you just don't know, you need to really think about it if you're not already practiced at cycling Well,
I think that's the me, that's the takeaway, though. Like, you real if you rec if this event makes you recognize we don't know how to do this, it's an opportunity to figure out how to do it. Because ideally, you're not gonna be impacted, but I mean, it's effectively then an IR test, more or less, right, that you can learn from.
Yeah.
Yeah. Didn't panic to do it.
No. And the other part of it was if you don't see any evidence that any counts are being misused after this many days, monitor for that. But don't try to ruin your company by trying to change all by cycling all the creds, rotating all the credentials if you're not sure how to do it.
That gets into interesting Yeah, I agree with
So don't cause an outage yourself.
Don't make it worse.
And when I say, like, don't panic, that's exactly what yeah. Don't cause an outage or whatever. But it does bring up this interesting thing in terms of, like, this conversation that we always have with executives, which is reasonable friction versus unreasonable friction. Right? Because if the business is like, we couldn't possibly change all our passwords, it's kind of like, okay, well, let's talk about why.
Because if that is true, well, you have a limiting function that would really impact you during an actual event anyway. Like, you probably should handle that.
Yeah. Yeah. What else you got on this one? Because I thought you were going to bring up something else because we were recently riffing on, you know, what else has happened in the news recently? Well, 23andMe
Oh, right.
Yes. Of course. Is going is filing for bankruptcy. And, you know, I think a couple years
son 23andMe, by the way.
Not me. No.
I have.
You have? Yeah. Oh, yeah. Alright. I haven't.
And so 23andMe's filed for bankruptcy because well, a few years ago, I think they had a data breach. Yeah. And then, you know, it's just not taking off like it was going to. The company value went down. At this point, they're on major sale.
Yeah. You know what's on major sale? Rick's DNA data because he had his testing done by anybody who has their stuff done. So the main reason I wanna talk about this is just to make sure that if if it's possible by the time this CAS comes out, that you can go in to 23andMe and delete your have your data deleted. That might put you in a better position than somebody who leaves their data in there, and you don't know who's buying the company and the data.
So that was the main thing I wanted to share.
Yeah. And I think it's a good idea. I have thought a couple times, tried to think through what the risk scenarios are. Yeah. So someone buys my DNA and then I go, Now what? And it could just It's fair to be like I know
it uses the DNA to test a new virus out for maximum efficiency.
Specifically on me?
Yes. For everybody as a whole. You know, type of thing.
But that's
a group
me yes. Like the other idea. Do you get on target?
They buy your DNA to then analyze where you have more likely maybe risk Risk risk factors, diabetes or something like that, and then use that for targeted advertisement on Facebook.
I'm okay with
that. No, okay.
But I do think that
People have gotten into trouble a little bit with that, you know, targeting but that's an interesting line. I don't think everybody's ever used that. Like, is DNA your medical information? Maybe? I don't know.
I mean, it is more and more, right? So I think And again, I'm not trying to suggest whatsoever that I disagree with, Hey, think about deleting your data, right? But I think it's an interesting academic risk question in terms of like, Oh, well, what's the thing? But the way tech's evolving someone muted.
Don't. Go ahead.
Alright. But the way the way tech's evolving, it's to me to think about, like, well, how could people use this? And, like, oh, well, is AI at some point going to be able to replicate my I don't know enough about how biology truly works to know this, so I'm just riffing. But could someone like replicate my fingerprint or my iris eye scan thing or some biometric thing based on my DNA? Would you
make another I don't know. In a
lab? Gartner calls it a digital twin. Yes. But anyway, I just think it's interesting to think like I don't know that there I haven't thought of any immediate risk factors, but that doesn't mean that there aren't long term risk factors of this data being out there.
Yeah, it is interesting. You know what? I didn't think, well, obviously, I didn't have skin in the game for this.
Quite literally.
Yeah, exactly.
DNA in the game.
It's funny to me because this was a topic for a couple of days. It wasn't that long in the news cycle. But I thought it was interesting that essentially if we weren't talking about DNA and any other data that we're talking about
Breaches in general.
Yeah. Just like any other company that has your we can talk about hospitals all the time get bought and sold. Nobody thinks a second about all the data they have.
Well, that's really funny because I was going to bring up something I thought you were going, but which is what should you be thinking about when you're sharing any of your personal information with a third party? But let's talk about the hospital one because I was at a conference last year and it was a healthcare conference. Wasn't even a cybersecurity conference. And I met some folks who their entire business is to go around and buy hospitals that are going out of business or bankrupt. Yeah.
And they buy them for the data set. And then that data is available and then it can be resold to other hospitals and things like that. Or also it becomes if somebody needs to get access to their medical record, it needs to be around. And they can always charge a fee for the processing of providing it. And so, you know, these couple of gents who started a business and what they're doing is going around and just buying up hospital data. So that's a thing.
Well, and I would also posit that in mergers and acquisitions, right, when someone has a legit offer on the table, or even like a half legit offer on the table, a lot of information gets shared. And I definitely know stories where people will go and pretend that they're interested in a bunch of different organizations and collect a ton of data on the market through that. And then be like, yeah. You know what? You're not right for us.
Yeah. You know what? Our funding didn't come through. Yeah. You know what? All these reasons. But you still have the data. Right. And are you technically supposed to destroy that? Yeah. But frankly, the the pre M and A agreement type stuff that I've seen in the past tends not to be particularly strong on the control of sensitive data. There's some of it, but obviously ones that are pretty
much I mean, at that point, like, you shouldn't be sharing I can't think of a use case in an M and A that you would share actual sensitive data, you know, type of thing. But there's a lot IP.
What do you define as sensitive data?
Like a customer's, I don't know, social or something like that. I can't say like, you know, somebody coming in a company like, Show me your database and get a dump. Well, here's
what I get Well, that does happen though, particularly when it's sort of a cross industry thing. So like, hey, we're
a They'll look at cross impact on their industry.
No, no.
They will look at that from their customer base.
Yeah, but I'm saying like, hey, I'm spinning up the next 23andMe. I want to potentially buy your hospital or healthcare system. But to understand if it's going to be worth it for me, I need access to some of these records. I need to see some of this stuff to understand what you really have.
So here's what I end up I
haven't been involved in those, know, type of thing.
Is probably on a weekly basis, I will get an email or a phone call that the market's hot. All the investors want to buy cybersecurity companies. Can we talk? Yours, you know, is CISO for And like delete half of these. But once in a while, I'm like, well, what exactly do you want to talk about?
Yeah. So I get on a call just because I want to hear what they have to say. And some of them say, Oh, if you jump on a call, we'll share what the market's doing in this area. I'm like, Yeah, I want to learn. Yeah. But they start probing for a lot of stuff.
How do you
know what the market's doing? Previous. Because you're having tons of these calls.
Are. And they want to know, you know, what's your revenue? Well, is it more than this? Well, if it's less than that, we're, you know, we're not interested. So I need to know if at least it's this. And like, they just go on and on. How many people do you have? How many and things they could easily find on LinkedIn and other stuff. But they're just probing for a lot of stuff even before there's any kind of NDA in place.
Right.
Yeah. But a lot of that generally is open, you know, type of thing.
Yeah. But they're mapping the market. And now all of a
sudden they have sizing exactly. Yeah.
And a lot of things there. And then they start saying, tell me about your customers. What's your largest customer? What percentage of your overall revenue is that? And I'm not answering any of these questions, but they probe and they want all this stuff. And then they want to, you know, oh, what
your actually go into the evaluation.
Yeah. It would. But I'm going with how many of these calls are fake.
Right. Yeah.
And are just people gathering data and had no intention of doing any of this. Yeah. And then selling it to other other places. Right.
Yeah. Yep.
I do think it happens.
Yeah, I get a ton of stuff. Obviously, you're way better than me, but I still get the emails and I think I've responded to saying, yeah, now is not the right time for funding. But most of it is just like, hey, we're interested in funding your DBA company that you registered. It's like, oh, you have no idea. I get the weird ones too. Those easily get deleted.
But, you know, it's very interesting.
So,
you know, I don't know. What's your takeaways for how people should think before they put their data out there?
I think it's a lost cause.
Was going to say, I think I'm slightly embarrassed to admit that I'm becoming numb to it. Yeah. Which I really hate the reality of. And I guess it shouldn't be an excuse not to try and remain some semblance of privacy. But, I mean, like when everything from, you know, the parking app I use, right, to park downtown Pittsburgh, to the credit agencies that I don't get a say as to whether or not they have my data, to, you know, others, you know, to
It's everywhere. So I don't have the answer to this. Haven't decided yet, but have you decided if you're going to go into 23andMe and delete your records?
Yeah. I mean, I will.
Yeah. It's easy to be proactive and just do that.
It's easy. And to me, it's primarily because I'm in this industry or, you know, kind of paranoid by nature, risk averse. Go, yeah, don't really Although I don't know it's a risk today, I don't really know what the risk is for it tomorrow and it doesn't hurt me to get rid of it now.
Right. Yeah, good.
Yeah. Yeah, and that's an easy target for you. Like go over the website, delete it, you know, type of thing. Right. A lot of times when we talk about like our risk acceptance on data out there, like
It's already taken hits.
Like there's nothing I can do, you know, type of thing. Honestly, I'm not going to waste my time chasing down something that's not going be a benefit. And I pay for credit monitoring and the lockdowns and all that stuff, which is great. Think that's kind of a nice little low bar type of thing. Love getting alerts when somebody does like a credit check on me and I get the alert within seconds.
Like somebody just did a credit check on you type of thing. So I like having that control, but that's also something that could impact me more than somebody just having my data potentially. Like they have my social. Now if they go to get a loan off of my social, all of a sudden that's an impact on me. That's going to affect my credit. That's going to, you know, do other stuff, you know, into that. That's what I want to avoid is time loss, you know,
into It's risk based monitoring, right? It's like what we counsel organizations do all the time. Like, yeah, you could, you know, max out your log verbosity across the board and send all of it to an aggregator and, you know, alert on it or like, think about what's important and watch that stuff.
Yeah. So I really love your takeaway. Maybe we should wrap up on that, which is you can't control what's out there. You can't control what people are going to do with it, but at least lock your on your on the on the three main credit agencies. Yeah. Lock your stuff. Get the app that will alert you within seconds when somebody attempts to do something so that you can check it out. Yeah. Because now you can go into defense mode. You can't prevent.
Yeah. Right. Yeah. Yep.
That's good. Well, you know, this would make a really great talk at B side Pittsburgh, and that's coming up.
You're on fire for the segues here.
Yeah, Beside Pittsburgh, we talked about it last time. I just want to do a quick shout out that organizing is going well. It's Friday, July 11 at Rivers Casino. Yeah. And again, we're aiming to get the biggest one yet, which will be tough because last year was the biggest one yet.
Yeah. But we still are taking talks, talk submissions. We have three tracks instead of two from last year. I was just hanging out and talking to the people who are gonna run the wireless village, and they have some really cool stuff set up, some simulations, I think, for hacking a CAM bus on cars. Nice.
And and stuff you can do. Things you could do with, like, the flipper. Stuff like that. So again, tickets, the cheapest are going to be right now until April 14 and then they go up. And we still have So
if you're listening to this, go out and get it.
Yeah, get them early because it'll Yeah.
Yeah. This will get released early April. You only have like a week of Talk
is ticking.
And the whole reason we're going to raise prices this year is because we want to be able to manage making sure there's enough food and we have to preorder that we want to get the t shirts preorder to everybody who registers and goes through that process. You know, they get a free t shirt. And so between the t shirts and the food alone, we're probably spending $50.60, 70 a person easily. Yeah. And the ticket's $20. Yeah. So you're going to get at least come to the event.
Even if you don't like security.
Yeah. Yeah. Right.
Why are you listening to this? Because you like bourbon.
Yeah. And come talk to our sponsors because they really find this to be one of the best events for getting a lot of people who are super interested. And I hear that the sponsors get a lot of good business out of Beside Pittsburgh. And the reason we keep it so cheap is unlike other cybersecurity cons that are going on in town and around, we're not in it for the money. We just do it because we love to do it.
We love to give back to the community. So we're just putting, you know, B Sides Pittsburgh out there as, you know, every every bit of money that's left over rolls into the next year.
Yeah.
So we'll have that and some some good exciting things.
Yeah. So if you haven't submitted a talk, but you have a couple ideas brewing, get that in. Submission deadlines coming. So
yeah. And if you're talking to one of your vendors right now about renewing your contract, ask them what they're sponsoring besides Pittsburgh and tell them you want to see them there.
Yeah. I love that. Because they'll probably have swag.
Yeah. So, that's about it on that one.
Great. Yeah. I'm looking forward to it. And we didn't mention the happy hour afterwards.
Oh, So the B sides will have a happy hour from five to seven and we made a big mistake last year. We didn't put that on the schedule. And so a lot of people are like, What? A happy hour?
Right.
Yeah. And so we'll make up for it this year. We'll come to that then come hang out with the rest of us, to the happy hour after the happy hour.
Right.
And we'll go find the best cocktail bars in Pittsburgh and hang out there.
We do. Yeah. Be smart. At least some of us are getting hotel rooms and everything. Yeah.
The hotel block is up.
Or the hotel block is up.
It is up.
I need to book that and everything or get an Uber home or whatever it is, know, type of thing. Yeah, definitely.
Or walk through like one and a half miles one forty five in a There are options. Plus
that midnight pizza. Yeah. Oh, that's the best pizza ever.
It is good. That is. Tastes better
than midnight. So Yeah. Fun times.
And speaking of having a drink after something, what are we Yeah.
Is this?
Segway. So
I pulled this out of the cabinet here. This is Colmette. They're typically some of the more expensive bourbons that are out there, at least from a retail price perspective. I would probably rate them as kind of middle of the road, you know, they're good with this. This is their small batch Kentucky straight bourbon whiskey. It's a blend between their fifteen year old and eight year old one. 80 six proof. We're mentioning it's a high corn mixture about 71%. Know what it I think
it reads sweet. You can taste it.
You get like a grain, a good grain on the nose and everything. And then, yeah, it's it almost tastes it's weird. It tastes a little bit hot. We all agreed like on your tongue for about a second or two, it tastes almost hot, but it's 86 proof.
And then it goes away.
And you don't get
the what did I call it earlier?
The wasabi burn. The wasabi
effect where, you know.
But yeah, and then it settles off into a nice like, you know, even flavor. It is sweet, but yeah, I don't get a lot of like different notes coming out of it. It's alright, you know, kind of thing. Like
I do like the smoothness of it, though. And normally, I'll I'll first, I'll try my bourbon.
That's good point.
And then I will drop a like, a very small chip of ice or just a little bit of water in it and opens it up. But this didn't need that. This, I I wouldn't add anything to it and just straight. No rocks. No. Okay.
Yeah. I like it.
Alright. Cheers, guys.
Cheers.
All right. I think we have, what, one left topic after this and everything.
Probably one good one yet.
Yeah. So I brought this up. I actually had a couple of different episodes that I wanted to talk about but always slipped to the end and we got too long and everything. But I wanted to talk about vulnerability management and how to do it right with this. So, I've had a few customers that particularly even recently have been struggling with this.
So they have some requirements specifically at PCI that, Hey, you got to fix your vulnerabilities in a timely manner. PCI is very specific, critical, has to be within a month. They open it up in the four point zero to say, you still have to fix them, but you have flexibility to what time you do that to. Tell me
about the flexibility. What do you mean by that?
Yeah. So if it's not critical, critical, they have a set time. Okay. One month type of thing. The rest of them, they say you can fix them per like if you have some SLAs but you have to fix them, you know, type of thing.
So you can have like highs and mids and there's been some discussions like some QSAs think you have to fix all vulnerabilities. Like I've actually heard that argument. I'm like, No, that's not a thing. So you set where your bar is on the acceptability of those SLAs, but you can also push it out to three months, six months, something
like So would you just is the right way to handle that is you have your policy and then you're memorializing your standard what you decided for your company for those ones that aren't the the criticals because that's been decided for you. Yep. And so is it mandatory to actually decide? And does does PCI expect you to have a vulnerability management policy?
And
does it expect you have a standard that says for lows, mediums, highs, this is your timeframe? So you needed a final Or
no timeframe. You could actually put it as acceptable. Yeah. Yeah. I mean, nobody's fixing all lows. Oh, for lows, you
could say no time frame.
But I suspect a QS Is like Is there a QS Like, if someone says no time frame for highs, is that like typically going to be like No. From the pond?
There are some guidance on to highs have to be fixed and everything.
But not in thirty days?
Ten years.
Not in thirty days, correct. So there are again, gray areas in PCI. It's an annual basis. Technically, you probably have to do it. They give the example of three months. Okay. You know, type of thing. Yeah.
But so, reasonability would likely be
They're going do a design review.
They've removed a lot of the reasonability from the QSA and put it on the merchant. Interesting. So, they've removed kind of doing a holistic risk assessment and do targeted risk assessments now. And you're basically analyzing some of this stuff and coming up with your own terms under this. So technically, you could come out and say, yeah, we're patching highs on an annual basis as long as the merchant can define it, like defend it and then TRA and all Like they're taking it out the QSA's hands.
Gotcha. Interesting point. Now, there are probably some abuses and all that stuff. But for the most part, I think it's fair for the merchant to define it themselves into this.
Assume positive intent.
And if the PCA wanted to crack down harder and say, Okay, yeah, highs have to be three months as well. Criticals won't I think criticals is actually too long.
When you said thirty days, it was like,
well I and it's been like that for a long time. Yeah. Critical, if you're looking at that and in the CVSS score, that's between nine and ten, you know, type of thing. Like critical to me is like zero day on the perimeter, you know, or something along that lines. Like something exposed that
anybody Remote code execution. You something like
that that's pretty likely, you know, to happen. Like, that's critical. That's a drop everything you're doing, get the IT team involved, we're either shutting it down and or patching it, whichever one's quicker, you know, type of thing. A little wiggle room with that. But you know what I'm saying, you know, into that.
But as a security leader, your intent is you're expected to make sure the company doesn't get breached. And so, of course, you would say, this is a critical. This is rating a nine or a 10. I'm not sitting here suggesting you're going to take any longer than you need. And I would prefer that you just stop what you're doing and do it tonight because I'm being held accountable for the breach, not for the financial Well, true. But you still will be. Yeah. And we can talk about that's a
whole another conversation about how to
push accountability to where it actually belongs along with the responsibility and shepherding your program. That's a different topic. In this case, if I'm responsible for making sure this happens, yeah, I'm going to be the one saying, Yep, I don't care if we got to turn off credit card processing because I'm going to get fired if we have a breach. So somebody else is going lose their job if we don't make enough money. And we'll all lose our jobs. Eventually. But which is worse?
Yeah. And, you know, it all goes into likelihood and that's a judgment call, you know, into a lot of this stuff and everything. But yeah, it's just, you know, one of those things. And then it naturally goes into a conversation of, know, from a company just relying on their Vulner scanner, Rapid7, Nessus, whatever it may be, Qualys, from just relying on what it's telling you to what you should actually translate into.
You mean when it tells you, here's the criticality rating?
Here's the criticality rating. And then, you know, my conversation always to these companies is like, okay, you know, that fits into your timeframe, whatever your timeframe says. You know, are you willing, able, have the resources to tackle all this stuff, you know, into that timeframe there? Is it that criticality, you know, into that? Let's validate that first.
So let me just clarify. Rapid7 says it's a critical, but you have the opportunity to define what Rapid7 is saying into your own terms. And you can say, well, our critical is actually rapid seven saying it's a critical plus. It's in this scope of our infrastructure. If it's over here behind three firewalls
Yeah.
And it's not PCI
Exactly right.
Then we consider that a high, maybe even a medium because Rapid7, we're not taking its rating as gospel. We're we're gonna tailor that through our own knowledge of our environment and decide what it is and put a couple other parameters on it before we
rate it.
Is that what you mean?
Yeah. Yeah. Any vulnerability scanner out there, they always take it into the context of this server sitting in a wide open network, you know, or something like that.
I don't think a lot
of people think about that. Yeah. Because, you know, and then you mentioned like three layers deep. Like I've had a lot of cases where it's a vulnerability, it's still remote code execution, you know, onto the AD server or something like that. But the ports that they're talking about aren't open to the entire company. Like for you to actually even get access to that, you have to be an admin, you know, to even get onto that network there.
Now Impact doesn't change, but the probability of
this thing being exploited Yes, only trusted people essentially going into that network there. What are the chances? They already have credentials to access it. Why do they need a vulnerability to, you know, access it as well? You know, and again, as long as you're confident that that's the design and the layers of security that you have into that as well.
Like utilizing zero trust, you know, the same thing. You're providing a good dynamic segmentation scoping into that that might minimize your impact to some of these vulnerabilities on the network, you know, type of thing. But if you have a wide open network, it could change the aspect. One of the things I commonly say to customers is if it's telling you you're critical and it's an internal vulnerability, I have a hard time believing that, you know, type of thing. Like just for the fact that you have barriers and it's only employees, like there could be a justification for it to be critical.
But critical to me is you're dropping all your daily activities and you're getting on this now. Like that's my definition of a critical into this case here. Like I am pulling your time as security, you know, pulling my, you know, card here and saying we need to do this and do this now, you know.
Don't show up to that audit meeting because we need to fix this No,
it could still be high if you have a wide open network and, you know, all that stuff and Like if somebody clicks on a phishing email and all of a sudden they can exploit something to the server, okay, yeah, I get that type of thing. But that's now a chain of events, not a single event type of thing into that. Going back to designing your vulnerability management program, really where I've seen like problems like if you have 100 assets, it should be manageable. You know, like it's not that hard type of thing.
So when you get the resources, you have to manage it.
You know, hundreds of thousands of assets. You know, I've seen some companies I've done PCI stuff where we've done thousands upon thousands of assets just in PCI scope, you know, into this. Companies
Are those national chain restaurants and stuff like Yeah,
payment centers. Actually, you know, a lot of the retail stuff, they try to shrink it down as much as possible. Where we've actually had the biggest scope is payment processors, you know, gateways and everything where the cardholder data is just a token of currency, a unique ID for them, you know, type of thing. And they process trillions of transactions a year, you know, type of thing. And every system has that card data.
That's what they do.
Yeah, segmentation is almost a mute point and we've actually gotten a conversation with like banks and other stuff where you change the kind of strategic segmentation to not centralizing what has card data but what doesn't. So you're actually carving off systems that has nothing to do with the banking infrastructure. It might be marketing or something. So it's almost a reverse segmentation approach and anything like that. But this is getting off topic, get out into this.
The vulnerability management, when you have hundreds of thousands of assets on it, it's really hard to keep up when you're getting reports from Rapid7 and it's saying like you are now four months, five months, six months behind on what we say is critical and you haven't addressed those yet, you know, type of thing. And they might be different systems out there that, you know, it's hard to patch. You know, you have to engage a local admin to do stuff. Yeah. Like
Yeah. So what do you find works well with a company? So let's put it in this scenario. You're a security director, probably may maybe a CISO, but I'm thinking more of the at the director level. You're responsible for to get it done, you're also a little bit tactical.
You need to work on this. What do they do when the scanner comes back? It shows them all this stuff, and now they need to they needed, like they can't just send an email saying, go patch all this stuff, but they need to put in some process in place.
Yeah.
Like, what are you seeing works well?
I've talked a lot. One one's one of you guys kind of.
Well, I mean, I think we we hit on some of it before, right? You have to you have to have a process in place to analyze if something's critical, is it really critical? Is it typically critical, but for us on this system, it's not that important?
And who does that go to? From my opinion.
From my perspective, it has to be a combination. Again, we're talking about mid to large enterprise organizations here. I think it has to be a combination of the team that supports the relevant infrastructure and the security team. Okay. Right?
Who's primary, though? I would typically So the flow that I've seen work well in the past is a security analyst, a member of the security team, maybe not the director, but a member of the security team takes glance at it first so that they can rapidly analyze it from the security lens and go, oh, well this is part of a segmented network. It's internal only. Yeah. Yeah, it says critical, but downgrade, right?
If it goes past like, yeah, I have no reason to downgrade this, right? There's a conversation or a touch point or a process by which you go, hey, network team, you're responsible for this asset. Security team doesn't, like, really know much about it outside of its place on the inventory and so on and so forth. We're getting a note that it's a critical thing. Like, quick agree, disagree. Right? Give them a chance to voice it. That comes back. If it's a disagree, okay. Why?
If it's an agree, route the fix.
Right. So from what I heard and I agree with you. Yeah. Security owns the definition but seeks input from other route of the team. Absolutely. Yeah. I
would take a contrarian approach to that.
Oh, really?
I would look for the the asset owner, the person, the group, the team that has the actual ability to make the change. Mhmm. And they're the ones accountable to you usually, like, think of a a a an infrastructure where you have your sys admins that are supporting the infrastructure, but they're actually supporting pieces that support an application. And then you have an application that has an application owner. And typically those application owners are an IT from that perspective that align to a business owner for the use of that application.
So now what I'm looking for is the security person to facilitate the conversation, but not to to have to take the brunt of things not going well.
So you're saying the risk owner, the owner should own the risk.
The asset owner should own the risk, but not without checks and balances, but the asset owner should own the risk. And so if it's going to impact some department head outside of IT's application that delivers the service that they're responsible for selling, they should have some awareness that there's a vulnerability or a thousand vulnerabilities that affect sure.
I don't think we're disagreeing on What we're talking about is setting the risk. And I think that should own to security. Oh, I'm Now, whether owning the risk and whether you're fixing or not, I would agree would go to end of this session. Then we're talking to some
things. Yeah.
Okay. Because as you're advisors, right? You have to say, Hey, we see no reason that this isn't as bad. We ran a scan. Scan came back, said something's really, really bad. We see no reason not to think it's really, really bad. We did our Here's this thing. We think it's really, really bad. We got to do something about it.
Right. Now security sets a risk. They're responsible to make sure it's getting Resolved.
Right. Yeah. Or accept, mitigate, whatever. Yeah, exactly. Yeah.
I mean, honestly, at that point, the business says like, hey, it's a critical risk. And there might be some internal process like, hey, if it's critical, it needs to go up to the CIO, CTO, you know, for approval or something like that. Like if it's a medium or high, maybe there's some flexibility on the, you know, the IT owner, you know, to do that. Whatever it may be, it's up to the owner at the end of the day to meet the SLAs and or follow a process to, you know, accommodate that, you know.
And I know you're
not suggesting that the business sets the risk, but I have seen organizations that flowed in the opposite direction and what ended up happening was the business went, Yeah, I know the scanner said this is a big deal. We don't think it's a big deal. And then it stops there and then security never becomes aware of, right, or never reviews in the right light.
Never seen that. I've seen
it a couple of places.
Interesting. Because security usually owns the scanner infrastructure, so how would they not be aware of some of the stuff coming back from the assets?
It comes down to hyper lean security teams that maybe have misinterpreted the push the risk onto the business conversation.
Which is being the coding pipelines or you're talking about actual like network assets? Like
infrastructure.
Yeah, like Rapid7 Nessus scans coming back and everything.
Yeah. And you say, Hey, first reviewer is the network team or first reviewer is the business team or this app team or whatever it is.
I could totally see somebody saying, Oh, yeah, that's not really affecting anything critical. And they're not qualified to make that. Exactly. And the security analyst enters it in as accepted. Yeah. And all of a sudden you have an accepted risk in your well, it's not even risk register at that point, but you're just your VON list.
Yeah.
And it's not going anywhere.
I don't wanna suggest it's, I've seen it terribly commonly, but I have seen a couple enterprise grade organizations that maybe didn't think about all the ramifications of how and the order in which they try to I don't wanna say shift risk to the business, but make sure that the business is the decider in terms of remediation, right? Because if they cede their opinion on things, well, all of a sudden, security doesn't really have a seat at the table. They don't really have an opinion and things can get missed because to your point, they're not the experts.
Right. Yeah, but at the end of the day, I think, yeah, you're setting what you think the risk you're evaluating the situations and into your case there, if somebody sets it and they don't even know what an RCE like actually stands for, you know, type of thing, it's like, all right, I don't think they have their own interest because if they rate it as critical, they get more work, you know, type of thing. So that's why I think the separation of duties from security who's trying to appropriately set it, but when they set it, they're not necessarily getting more work, you know, type of thing. Right. Like between high and critical or stuff like technically you shouldn't be the one patching.
Again, the separation of duties to keep that kind of pure,
I always think of it as like the prioritization filter too, right? Right. It's useful for the security team to pass along what they think are real criticals and filter out what they don't think are real criticals to the infrastructure teams or the application teams that need to fix them because, I mean, you only get so many shots, like call them appropriately, right?
Oh, yeah. So from from my experience at a large company where this was happening, we would have tons and tons of volumes come up across all these variety of different criticality level systems. Yeah. And we would, you know, as we were building this process, we early on made mistakes. The mistake was, let's just ship the list of all the stuff to the sysadmins and say, get this done.
Exactly. It would never get done. We found it more effective to do a couple different threads. One is these are the top five I need you to do this week. Gets so much more action than here's the list. Go and fix them. Do stuff. Yeah. Because the that a list that was so big, nothing gets done. It gets like, I have 18,000 things to do this week. Mhmm. And reading 40 pages of this isn't gonna make the cut. Yeah. I'll read the five things, and that's what they would do. Yeah.
So we got much more effect that way.
And these were highly manual fixes, I would assume.
These were yeah. You gotta go patch things.
The one off, two off system that are out Because you'll typically have your operational systems. So your Microsoft patches that come out, you know, they'll go through a filter, but generally they should be on monthly patching cycle, you know?
Yeah. That'll they'll take care of themselves. They'll catch up after
a month.
Yep. But then the other stream that would we'd put in place at the same time was actually run it down, do a threat model of, wow, this is a really bad Vaughn. And even back then, we're like, there no next point now? I, you know, some of our teams have started, KEV, K E V, known exploitable vulnerability. So you take those kinds of things and you weigh that into the situation.
So if you have those, this is a critical and there's a known exploit out there. And well, let's look at what systems this applies to. Now, let's go do the thing. We're going to go talk to the person outside of IT who's responsible for the revenue stream that the service this thing runs on, you know, is there and have that conversation.
Yeah.
But may that that shouldn't be the first time you talk to that person. You probably need to talk to that person and say, some point, I'm gonna come and see you
Yep.
Because this scenario is gonna happen. And when this happens, I wanna know that I don't have to spend a lot of time introducing myself. I wanna make sure you know what this is about.
Yep. And I thought you were gonna go somewhere else too because I think an additional thread that I've seen be really useful in those scenarios is, look, there's a monthly thirty minute standing meeting, right? Because you're doing all the communication on the side, right? Like these are the important things right now. These are the important things this week, right?
And there's just a monthly standing meeting to say, hey, look, we're gonna build this operational cadence to talk with the relevant infrastructure team about the stuff that's going on. And depending on the size of the infrastructure and the enterprise, it might just be this is the standing vulnerability meeting where we talk about what progress has been made, what are the blockers, security need to, you know, help apply some leverage to the business to help make sure this thing gets fixed or not? Because sometimes IT gets stonewalled on trying to fix their things in different ways, or sometimes the business has a great point. They go, well, we need to apply additional information. So or it could be a more general operational and communications cadence being where you go, hey, look, these are the projects we have going.
What's the status? Here's the open vulnerabilities. What's the status? So depending on who you are as an organization, different things work. But I think it's typically important to maintain those lines of communications. And I love what you said, like you shouldn't be intro Whoever's running down these vulnerabilities shouldn't be introducing themselves for the first time, right, during these processes. I think
To the person that needs to make the decision to get this thing
Yeah, yeah.
And so I think from a maintaining relationships perspective and also just from a making sure that there's a line in the sand once a month to talk about, okay, what progress has been made? Is this acceptable or not? If it's unacceptable, well, this is the point at which we escalate.
Yeah.
Right? I've seen those processes yield results even in busy months because people go, Oh crap. Like on the infrastructure, Oh crap. Well, I have the vulnerability meeting in three days from now. I really need to get moving on this thing, and then a couple of things get resolved right now.
So we include I have several customers where we've put this process in place, and it's really I wouldn't say it's like changed the world for them, but it's made continuous improvement over years.
You're talking about the five things? Fix the five things?
No, no. It's slightly different. It's take those Well, it's not just that, but it's on a monthly, is what reminded me. And it's the monthly risk committee meeting.
Yeah. And it's called
several different things. You know, everybody calls it something different.
Right.
Essentially, they're doing the same same general thing. Like you get in a room with the people who all own parts of the infrastructure, whether it's software development, you know, owning the various customer support items. And it's very interesting from customer to customer that does this. The people in the room have this variety from somebody at the C level, whether it be in a on the legal team or a CFO or somebody else, and then several IT different parts. And all the people are there, and they represent it well.
And then when you start going through the Vollons and you're talking about the top Vollons, it's it's it's works great when everybody starts taking their own accountability. So I just watched a meeting this last Nobody
wants to be the worst on the list. No. Yeah. And and That's pretty powerful.
I just watched one this last week where they were going through the list of the the VONs, and people were standing up saying, oh, that system that needs assigned to me. Yep. And we just need to patch that thing or that system, was used for, you know, a test or, oh, I think the Microsoft patches caught this because we had a gold image and it needs updated from what we were deploying. Fantastic. And all these people were jumping up to, like, say it's their turn to take accountability to get this stuff patched.
And it was awesome. And it took years to kind of get to awesome. But if you're not awesome yet, start now.
Right.
I think that is one of the more like superhero moves you can do in a company. If you can get where you're presenting to multiple executives, owners of different areas, business units, everything, it's night and day how it transforms an organization. Yeah. Like, you go from security kind of being isolated, usually underneath IT and everything. And if you can get that kind of audience, you know, into that, all of a sudden you get cooperation like nothing else.
I'll tell you one unique thing about at least two of the places I see this working well, there's some other ones that aren't, but two of them are ISO 27,001 certified. And so they've created a culture of continuous improvement. Trying to figure out when something doesn't work right. I'm gonna hand something off to you because once you find the VOM, why?
Yeah. It was definitely a thing that when we were talking about these topics that I think that a lot of organizations, they patch the vulnerability, but they don't take that next step. They don't go, Well, why was this a vulnerability in the first place? Why was this infrastructure patch late to be applied Yeah,
RCA. What is RCA?
Root cause analysis. You know, why did this config drift from the approved standard? Why, why, why? And look, if it's a zero day, well, the why is pretty easy. Like, no one knew this was about to occur and we responded in this way and now you have a success story.
Or if it didn't go fast enough, then you go, well, why didn't we fix it fast enough? But I think a lot of organizations that aren't as mature at this, they do the patch or the config change or they they fix the phone and they kinda stop. And it's much more powerful. You don't have to do this for every single one, but start doing it at least for a couple, at least for the big ones, at least for some Because what you'll find is when you move upstream with some of that operational diligence, it actually makes your future VON scans less, right? It has this add on effect because you go, Oh yeah, well this patch wasn't applied quickly enough because, well, we didn't have operational coverage and this person took vacation, and this other person was on maternity leave or whatever.
Go, oh, okay. Well, how do we make sure that that doesn't happen in the future? And then it doesn't happen in the future, and then you don't have that problem recur. And as you fix those things, again, a continuous improvement, ISO perspective, your scans start to get cleaner and cleaner. But to your point, it's a process. Right? So if you're not amazing at it now, start now.
Well, yeah. And to your point and everything, I mean, how how often have you guys brought like, because vulnerability management in the day to day is very tactical. You know, very in the weeds, very system oriented, IP oriented, vulnerability oriented. How often do you actually pull everybody out of the weeds and be like, all right, let's talk strategically?
Well, it's the lessons learned for like we talk about lessons learned for IR all the time. Yeah. Well, is kind of just like an IR that an attacker didn't take advantage of, right? Like,
do a lesson five hundred and 11 Hey, we'd like our current deployment of patches aren't working. We need more of a big fix solution.
Right.
Or something like that. Or we have a whole bunch of one offs off of all of our M and A. We haven't standardized. Maybe we need to just do a whole refresh and actually get on the same level. And this will bring down all of our work from vulnerability management.
Like I find a lot of times when you're so busy in the weeds and doing the onesie twosie stuff that you're not thinking like long term, maybe we need to do a whole cloud shift, type of thing and put it into somebody else's problem. There's a whole bunch of conversations that, again, they're not will be done next month, but a multiyear shift would help transition your vulnerability management and then something that's working very well.
And I think it ties into the risk committee thing you were saying in the superhero move you were saying, which is when you can build that sort of coalition of some executives and some tactical people, what I've seen in the past on those similar meetings is you get the executive saying, Well, wait a minute. Why did this thing happen in the first place? Right? It's not enough it's great to take accountability and stuff, but oftentimes it's the executives then saying, Well, how did we even get here? Right?
And they do pull back to that level. But if you don't have those types of meetings, it's harder to get that conversation rolling.
That's what I Go ahead.
Well, was just going bring up We actually I think I brought it up before in one of our talks. It still rings in my head when Equifax or Experian got hacked. Yeah. Yeah. With the struts vulnerability. I remember watching the CEO say, It wasn't my fault. An admin didn't patch.
And they knew and it was on their roadmap that they had this problem and it just didn't get prioritized to get done in time before somebody took advantage
of it. Yeah. And to me, that just shows poor leadership. I mean, like, you don't blame the, like, the admin. Like, no, sorry. We had bad processes.
But your point, why didn't your admin patch?
Exactly. Well, that's actually
one of the reasons I love ISO 27,001 is when you have a nonconformity, which is basically a breakdown in your own requirement or this requirement of the ISO standard, you do your root cause analysis. You cannot blame a person for a breakdown. It is a process failure that is the gotta be the root cause. Right. Now you can have a person error. Bad performance or whatever.
Yeah. Again, there should be checks and balances through all this stuff where that stuff gets flagged. Stuff gets Where
is your safety net? Where is the oversight? Who are the lines?
If that person was responsible for patching and they didn't patch in an appropriate time, they get fired and you get somebody else into that.
Right. You fixed the you had somebody not following the process.
Right.
And then your breakdown was your check and balance.
What's oversight?
Like to me, I always look at the GRC team as the oversight, the three lines of defense model. They're the second line of defense and that there should be a process for them to be checking to see if these things are happening.
But,
you know, I have a like a mental model that's burning in my brain around the way to make this stuff effective. I just had this conversation today with somebody and it's that risk register becomes a prioritization tool of the GRC team, of the security team in order to get things done. When you have a properly logged risk So let's just take the whole macro thing we've been talking about. Lots of vols in an area. Can you figure out like, is there a common thing around all these criticals that are six months old?
What is the thing? And something I see people get wrong all the time. They log a risk and a risk register and they make it a vol. It's like a technical risk. That doesn't help anybody.
Especially at macro level. That's not an enterprise risk.
No, you need to be able to link that to an enterprise risk. And people will always say, Well, how do I do that? Well, there's probably only a finite there's a finite list of types of enterprise risk. Is that going to create a breach? Is that going to create an outage? Is that going to create and you come up with the things that are important to you.
And you you can often not even definitively even answer that. You're just saying it leads to a higher risk of us, you know, like mishandling. You can't say like, we didn't patch this one thing leads to a breach, you know, like
I've always the way that I've always thought about this, my shorthand mentally for it, is who's gonna be angry or who's gonna be fired?
Oh, yeah.
And if it's a C level, that's an enterprise risk, right? And if it's a director, nah. What are they concerned about? Exactly that, right? So who's gonna ultimately gonna need to know about this?
So you take your risk, you get to the risk register.
Yeah.
But actually, if it was a And actually, I'm confusing two different concepts that are very important to separate. It's your nonconformities versus your risk. A risk is just a nonconformity that hasn't yet occurred.
Right.
And your nonconformity is actually the breakdown. So when you have a VOM on your system that's critical and you don't want it there, and you have a policy that you shouldn't even have had it in the first place, and you RCA that, and you find out, Oh, well, now we have a systemic problem, because part of root cause analysis is, or corrective action, the first thing we need to do is isolate the problem and solve this one. Then we need to explore and see, do we have other ones like it? And then what's the underlying? That's where the RCA comes It's after you've stopped the bleeding.
And then you look at that. Now you get that problem logged into a list and the best, the most effective organizations doing this, they track their their nonconformities aren't like rated as high, medium, and low. It's it's either on or off. It's you either violated your own requirement or you didn't. And if you did, that's the nonconformity.
Mhmm. Now when you're looking at nonconformities, which on which nonconformities have action plans, corrective action plans that are in progress and on track? Which ones don't have plans? What nonconformities have ineffective plans? Those bubble up. And then these risk meetings, we cover those first. And and there's a couple of things you can do. And you can have somebody approve an extension to the timeline. Sure. But how many times you wanna do that?
And I just saw a like a chief legal counsel call that out. It's like, well, are we gonna do another another extension? Are we gonna why are we extending this? Why didn't we why can't we fix it?
Yeah. What needs solved here?
If we saw if we extend this another another two weeks, is it actually gonna get done? You know, because now all of a sudden, what's happening, you're creating a lot of liability Mhmm. For knowing about problems Yeah. That you're not solving.
Arguing Oh, yeah. Can down the road.
Yeah. Priority to organization.
Exactly. Yeah.
So all this stuff comes together in the, you know, the risk management framework from NIST.
Yeah.
The ISO process for continuous improvement.
Mhmm.
They all come together to take all this stuff and put it into something they to prioritize it. So we're talking about vulnerability management. And remember when vulnerability management, what was it used to be called something different, like change, change management and patching. It used to be called patching by NIST, and then they changed it to vulnerability. In, the framework.
Yeah. But that incorporate now, like, configurations. Yeah. All this stuff.
And so that's a great improvement. So now we're talking about all these vulnerabilities. And then where does it go to? It's like, well, we gotta fix them. And when we're not, what's the root cause of that? And if you can apply it to getting that into your risk register and using that as a prioritization tool to say, you know, we have a risk this thing could get exploited. Yeah. If it got exploited, then that's a problem. That's no longer a risk. It happened.
Right.
And then take that and move it through. Get an action plan in place and then track the plan. Mhmm. Don't try to track the risk as much as you're tracking the plan to fix the problem. Yeah. And then is that just a project that's on or off track? And get the right people involved so they can help you facilitate escalation.
Yeah. But yeah. And to me, like, you have solving the vulnerability is good. Solving the reason the why behind the vulnerability is better.
Yeah. Yeah. Earlier when we were like talking about this and I walked in and I heard you talking about that, I was like, oh, it's exactly something we're hitting on. We have a fractional GRC program that we offer our customers. And one of the things we do for that is we will Thank you.
We will also throw in like a penetration test. We'll throw in a tabletop exercise as part of VGRC. Yeah. Because it's, you know, it's easy for us to do when we're already in there operating this stuff. So we do a pen test by one of the members of the team, and we now have the whole ability to take the findings from that and actually analyze it and push it right into the risk. It's a
Yeah. It's a validation of all that stuff. I've had that, yeah, back when I was part of a company doing pen testing. It was such a powerful tool when you're doing, like, compliance stuff to say, how well are you really doing? Let's test it out, you know, type of thing. They'd often find holes in patching, configuration management, credentials around, all this
stuff.
Like the whole life cycle of what the security process is supposed to be doing.
Yeah, exactly. I love it. And yeah, once you get that ammo, then your job just becomes a lot easier. It's not a if. It's not go find Yeah. It's not to say like, hey, like, you know, is this an issue? Is it is an issue? You know, look at the report. Now let's talk about solutions, you know, type of thing. So it just greases the conversation so much more when you do a pentest coming into that type of thing.
Yeah. I love that topic. It like it hit that core topic you want to hit, hit all aspects of how to run a security program. Yeah. Oh, that was great. Yeah.
Yeah. And it's amazing. Like, I think I shared with you guys, you know, like I'm dealing with one client and just the fundamentalness of like getting this right. Like, if I'm a new security person, this is one of my first focuses, you know, into this is getting that report gleaming and everybody accountable to it and everybody understanding what their roles are in the organization, including executives, you know, to this entire process and hopefully going strategically into something that we can maintain and be better for the organization ideally at the long term.
And don't just focus on the VONs, focus on the root cause and the processes that you can build out on.
Yeah, how can you optimize it? How can you outsource it? That's a potential with cloud computing or something like that? Yet there's a lot of different ways you can attack it, you know, type of thing. But for you like not to touch it coming in as a security practitioner, I feel like you're neglecting your job.
And you're just asking Super foundational. You mentioned like we haven't talked about responsibilities, but you're asking to get fired. Know, like this is one of your primary roles not to fix it, but to shine light and keep people accountable to it, you And
I think the cool thing too is if you pull those levers and generate meaningful improvements in that space at the right level, right, kind of at the risk level, Well, now you're engaging with different parts of the organization that are going to be equipped to help you with other domains of your job, right, if you are that C level or the person that's ultimately responsible. If you're like a director of vulnerability management or something, okay, that's kind of your scope. But if it's more broad based security, well, when you have an access issue, when the business isn't helping you the way that you want with your BIAs, whatever the thing is, right, you've already built the rhythms and the relationships and the habits by like fixing this thing and talking at the risk level to help streamline those other things. And frankly, those things just become part of these risk Business terms. Yeah.
Yep. It's great. So
Great, gentlemen.
Yeah. So Yeah. We thought we were gonna go short on that.
I know, right? Silly us. Yeah.
Everyone's off.
Cheers. Cheers. So thank you everyone for joining us. Don't forget to like, comment, and subscribe. If you have any interesting topics you want us to dive into, please leave a suggestion on what did we decide? YouTube, LinkedIn, where we decide with that, right? That's the decision. You guys are looking at me. Anyways, thank you, everyone, and stay tuned for Episode 12, One Year, coming up next time. Thank you. Thanks.