Roddy Bergeron [00:00:06]:
You don't want to say your baby's ugly, but like, sometimes you have to have somebody else tell you, right? And that's part of it, right? That's part of the process, the audit process. I think that's what scares a lot of people about hearing the word auditor. Tax auditing is a different thing, but like the auditing that we do, it's coming in. Just make sure you have the proper things in place. And that's scary sometimes for people because they don't want to have to face the fact that they may be doing things right, or maybe they feel like their job's on the line and that comes from company culture and everything else. Making sure that we're doing this from a passion of making the company better.
Chris Lindsey [00:00:40]:
Hello and welcome to Secrets of Appsec Champions. My name is Chris Lindsey and today we are speaking with Roddy Bergeron. Today's conversation is going to be around auditing. Roddy is the cybersecurity fellow at SherWeb. Roddy, please introduce yourself.
Roddy Bergeron [00:00:55]:
Hi, thanks for having me. Like you said, my name is Roddy Bergeron. I am the cybersecurity fellow at SherWeb. So my responsibilities are driving cybersecurity initiatives with the company and for our like managed service provider partners in the MSP space. In the past, I've done government auditing, so I did government facilities, also hospitals and banks and other clients that had financial responsibilities and then went into the nonprofit space. I worked with a nonprofit doing some public private partnerships with department and hospitals in Louisiana. So taking some of my it background and then taking some of my auditing background and helping turn around facilities for people with intellectual and developmental disabilities, helping turn some of those facilities around with state of Louisiana, got into the managed service provider space, worked at an MSP as director of operations, and then later as their CISO, helping turn around and can create their managed service division, streamlining operations, creating their V CISO services, their compliance as a service package, implementing EOS, entrepreneur operating system with them and some of our clients we had at the time. And then I got snatched up by SherWeb, where I'm at today.
Roddy Bergeron [00:02:04]:
So taking a lot of my expertise in cybersecurity, in the managed service provider space, and some of the work I did doing incident response and compliance and helping MSP's build out their practice for the most part.
Chris Lindsey [00:02:14]:
Awesome. That's a lot.
Roddy Bergeron [00:02:17]:
It's been a varied career over the years and it's taken me all over the place, but I'm taking a lot of that, that knowledge which is crazy because we were talking about the financial regulations of 20 years ago and how now that's like starting to become the standard for business now. And it's like, you know, seeing the regulations we had to put in place and the controls we had to put in place with banks, you know, and to make sure that they had the right controls in place over financial transactions and just the integrity of the financial data they had. And now seeing that become common in the MSP space we're talking about it is like wild to me because I was like, yeah, we were doing that 20 years ago. Yeah, I'm glad you guys are doing it now. It's good to see it. But like, I always say that, like, the financial industry tends to have you watch what the financial industry is doing with regards to, like, security controls. And then we'll probably see that pop up in ten to 15 years for the rest of people because they have a very highly regulated space and it's very tightly controlled and it's cool to see. It's cool to see it happen, you.
Chris Lindsey [00:03:09]:
Know, so it only took 20 years.
Roddy Bergeron [00:03:11]:
For it to catch 20 years in the grand scheme of time. It's a small amount of time, but it's good. It's progress and that's good.
Chris Lindsey [00:03:22]:
Yeah, well, you know, one of the things you were talking about, you know, you're talking about the financial and you're talking about how things have changed and where things are going, really that kind of falls into auditing. And there's a lot of aspects to auditing. Can you share some of what you've done with auditing?
Roddy Bergeron [00:03:38]:
With, yeah, so like I said, when I started, I was 21 or 22 years old. I just got out of college with an IT degree and I went work for a CPA firm and they were like, hey, you know, we're starting to get more and more it controls in our financial audits. Right after a little thing called I think it was Enron. I don't know if you've heard of.
Chris Lindsey [00:03:58]:
It, but after just a small company, I hear from the east coast.
Roddy Bergeron [00:04:02]:
So there was a lot of tightening of financial controls and that also revolved around, like, controls for electronic systems. So mostly servers and IT infrastructure. So that was becoming more and more crucial and they needed somebody who understood it. So I was like, yeah, I can go help. So that helped me start to understand audit methodology. And so you go into banks and you would help them audit their systems. They had a lot of as 400 systems, a lot of banking system, cardinal systems, things like that. And so I kind of cut my teeth there.
Roddy Bergeron [00:04:32]:
And we do everything from audit the types of patching systems they had to, whether or not they had correct controls in place for system access. So, like, we would audit things like who has access to accounts receivable and who has access to accounts payable so that you don't have crossover in the ability to do things like create invoices and then turn around and pay them. And that's how we busted, say busted. That's how we caught a lot of. What's the word? I want to look at? Financial shenanigans sometimes in businesses was lack of proper controls and delegation of duties and stuff like that. So going into a technical background, right, and the technical world, like, I took all these ideas of, like, it's not just technical controls, but it's also administrative controls in place that you need to put in place. Coming into the IT managed service space and seeing a lack of it was like, I see an opportunity here for us to mature our practice goes, because then we don't have to be so tool focused in how we do things, but we also have to make sure that we have proper people, policies and process in place. So that auditing background helped drive for me the ability to understand the full scope of, like, cybersecurity.
Roddy Bergeron [00:05:34]:
So going in and making sure not only that people were doing the right thing, but they could prove they were doing the right thing too. And making sure you had the ability to report port and attest to those controls became a really important piece of me when I started building out our cybersecurity program, our managed service provider, and then starting to connect with other it providers in the space who are then saying, like, yeah, I'm doing this too. But there's no general consensus. There's no good practices out there. We started banding together and helping each other out help better understand how do we take this idea and how do we make it easier to access for small businesses. Like, we all have risk, and we have to make sure that you're putting the proper controls in place to manage that risk. And understanding, like, where your risk is at.
Chris Lindsey [00:06:12]:
Right. And the risk can come from anywhere. It can come from the hardware that you're on. It can come from the software that you're running. It could come from the software you've written and put on, you know, this environment and it's running. And the people you do business with too, right?
Roddy Bergeron [00:06:27]:
Like, those people are your vendors and your partners and the people who have access to your system. So whether or not you're mixing and matching on prem with cloud services, understanding the risks of there that you can't control, that's part of it as well.
Chris Lindsey [00:06:40]:
Right? And so it all comes together as one big ecosystem. And just like Roddy was saying, when you've got the cloud, you've got your on prem, you've got the different environments, they're all connected, they're all interconnected. And so anything that you do on one can affect the other. And that's where auditing is important, because if you don't have the auditing in place, this really could bite you because you don't know what you don't know.
Roddy Bergeron [00:07:04]:
Yeah, that was supported. Do an incident response. One of the things that I ran across was I ran into an environment where they had a lot of API access and we asked them, hey, when was the last time, like, you did some basic hygiene there, like maybe some rate limiting or even reviewing your audit logs? Or was the last time you changed your API keys? Right. They were just like seven years, eight years, I don't know. Whenever we put that API in place, we set an API key and we've never changed it. And we've never done anything like, it's just out there. I mean, they have vendors who access it, right? They had no idea if any of that use was legitimate or how much data they were scraping or how often they were doing API calls. So that's a potential issue there.
Roddy Bergeron [00:07:43]:
Now, it wasn't being abused, but then it opened my idea of like, hey, how interconnected are all of our systems? So, like, I sat down at our MSP and I was like, all right, let me, let me do a data flow diagram. So I was like, how do all of our systems interconnect? And that became a spider web of man. Like, our systems are super interconnected, and it could be anything from API to maybe some database connectivity or maybe some RPC connectivity between all these different systems, disparate systems. And it became clear to me, like, if I had an incident with one system, it could affect all these downstream systems, and there's potential liability there. That's part of the process. You identify not only just those systems that you need to protect, but how do they communicate to one another? How do they connect to one another? Make sure you understand, like, all the different components that go into it as well, because just like all our systems are connected together, and that is that those are components in a much bigger environment, like your individual pieces of your software packages too. Like, it's no longer this monolithic code that you write yourself. It's composed of different libraries.
Roddy Bergeron [00:08:47]:
Some are open source, maybe some are licensed that you bring in. And keeping track of that, too, can become its own job, right? Its own full time job.
Chris Lindsey [00:08:57]:
You bring up a good point with APIs and the fact that you have keys that are seven, eight years old, you have dependencies that you're plugging in. The auditing is absolutely key to know, what do you have? When was the last time it was modified? And you're right, an API key that is seven years old. How many times has that thing been compromised?
Roddy Bergeron [00:09:17]:
How do you know it's been compromised? That's one thing. You can't just say, oh, it hasn't been compromised, because if you don't have the proper audit logs, you're not reviewing those logs. And you don't know, again, who's supposed to be accessing this and in what parameters are they supposed to be accessing it? You don't even know if you've had an incident. I hate to use the word breach all the time. Like, in one of my previous jobs, we'd say, did you have a lowercase incident, or did you have an uppercase incident? Is it small or is it big? I tried to stay away from, like the breach word, right? That's always, that's like a legal term, but like, the incident. How can you even know you had an incident if you're not doing the proper auditing of your own systems?
Chris Lindsey [00:09:52]:
Right? Well, an auditing can take multiple facets, right? You can have your own application auditing, where you're logging the inbound requests. All the details are being written to a database file or somewhere. It's rarely done. And we can hit on that here in a minute to other applications that the firewall is looking at the requests. And the cool part is, with today's technology, it's easy to really aggregate everything together through different systems, like a SIM or an ASP EM or some other methods to consolidate all the data together. So then you can actually look at it and try to identify is something going on like a splunk? I mean, you know, there's so many options out there.
Roddy Bergeron [00:10:32]:
It's. You should be definitely, yeah, that's the thing. You can collect all this data, but is this data useful to you? And how are you correlating all this data together? Because if you're collecting 13 different audit logs or 13 different logs of security events, can you tie that all back together to make it cohesive? You can have all the data, you have all the big data in the world. Right. But like, if you're not specifically tailoring that data, not specifically looking for those certain actions, you're just collecting data for the sake of collecting data, and then that becomes a liability in of itself, right? Because now you have all this data and what do you do with it? And the more data you collect, the more liability there is. So tailoring that data and making sure you're not just collecting data for the sake of collecting data, in this instance, security logs or whatever, that's an important thing to think of as well. If that data becomes a part of an incident, then what systems have you exposed? Have you potentially exposed client data or other client systems that are interacting with your systems? The web that happens from that can be quite huge and quite costly for businesses as well. Like, in the event of an incident, right?
Chris Lindsey [00:11:35]:
Something that I was reading on LinkedIn this morning, there was a big conversation about SQL. And with different systems, you have query languages where you can query against it. And you're right, it's a two sided coin. You want to collect enough information to be able to identify. Has something happened? On the flip side, collecting too much data? Now the question becomes, you have so much in front of you, trying to find what you're looking for becomes more of a needle in a haystack type scenario where you query against the system, hey, I want this information. And instead of having, here's 300 things to go through, now I have 30,000. And if you have 30,000 and they're almost identical, what do you do there? Right?
Roddy Bergeron [00:12:18]:
I always say this like talking to people who have run soc, the security teams. You know, the big thing is like, hey, I need visibility. The more visibility the better. But again, always tell them, like, coming from someone who worked a lot with legal teams over the years, that can also become a liability for you as well. So what you have to do, though, is try to figure out and start small. Don't ingest as much data as you can, and then say, okay, I'm going to figure out exactly what I need, because then now I have the data to know what I need. Think of those things that those better security practices you could be doing now, and then say, okay, what do I now need to make sure I can meet those? Or if I put controls in place to limit those potential issues, I might see what data do I need to collect to make sure I'm aware of these issues. I mean, there's tons of pre made integration, especially for sims.
Roddy Bergeron [00:13:03]:
Like if you're doing sim ingestion, like, cool, now I can go write one. I can go find one for maybe like my Azure environment. So you're pulling in azure logs and you're only pulling specific ones that you need. Or maybe you have AWS environments, or maybe you have some kind of other platform or service that you're using. Like there's, people have written integrations for them to help you curtail exactly what you're pulling in so you're not pulling in too much data. And that's important to do too. So there's experts out there always say, like, if you don't know, ask an expert or try to get someone in there to help you contextualize exactly what you need and then scope that down so that you know exactly what you need to pull in. Because again, pulling in too much is just as bad in my opinion.
Roddy Bergeron [00:13:40]:
If you had to like put me in a corner and say, do you want to put in too much data or too little data? I'd say pull in too much data. But then that's also, as we discussed earlier, that's also an issue as well.
Chris Lindsey [00:13:49]:
Well, in clean up the data you're pulling in, I have a friend of mine, they're ingesting data. Their ingestion rate is four times the size that they estimated. And that was because they were looking at condensed data and data that was basically prepared to go into an ingestion system. And what happened for them is they were just sending the raw data in and they're like, turn it on, turn it on, and all of a sudden all this data just flowed in and it's costing them a lot more. And so they're looking at it going, well, how do we scale this back? How do we pull it back? And so when you're bringing data into a system, a sim or other system, like a splunk, you can clean the data, trim the data, do a little bit of, hey, this is what I need, and then send it in, and then you have more of the meat and potatoes of what you're looking for.
Roddy Bergeron [00:14:39]:
Yeah, and that's true, like, especially if you are using, like, cloud storage, because cloud storage costs can get outrageous real quick. And if you're doing threat hunting right against this data, you don't want to put it in, like, cold storage because you're going to potentially parse a whole lot of data real quick so that fast storage gets real expensive real quick. One of the things too, right, is when talking even to small businesses about data retention. And so how long is the data good for, and how relevant could it be? Do you really need a threat hunt against three year old data. Like, potentially, yes. Right? Like, there's always a gotcha. There's a non zero chance that looking at three year old data might be useful. But, like, do you need to keep 90 days? Is it a year? Do you have regulatory needs? Or maybe you need to keep it for five years? Like, it's important to contextualize that.
Chris Lindsey [00:15:26]:
Right?
Roddy Bergeron [00:15:26]:
Again, like, I've walked into businesses of all size out of their incident and just say, like, how long have you been keeping data? How much data do you have? We never got rid of anything. And some of this data is clients they no longer do business with, that they now have to report as, like, part of their incident. And it's like, now you're digging up, I like to say, digging up old bodies here. Now you got to go have a conversation with a client, doesn't do business with you to say your information's been part of an incident. So making sure you understand, not only how much data do I need, that's just enough data for me to have enough information to contextualize an event. But then how long do I need to keep that data for? Is threat running for 90 days enough, or do I have to go back further? That's an important question to ask. When you start collecting data as well. You go through the data lifecycle policy, everything from how do I request data? How do I create data? Where's the data stored? All the way.
Roddy Bergeron [00:16:14]:
Then to, like, the last step, which a lot of people fail to do, is like, how do I get rid of the data? Because, you know, we kind of become these data pack rats where we're just like, oh, I just got to keep it. There's no issue with me keeping it, especially if it's on old or cold storage. Sorry, cold storage, right. That's super cheap. It's not costing me that much to keep an extra terabyte here or there until an incident happens. And then that's the true cost of that. That decision comes into play.
Chris Lindsey [00:16:38]:
Right. So in the past, what I looked at was what's important to me and have a rotating basis at that point. And then I looked at from a legal standpoint, and that's for anybody watching this, consult your legal team. As far as you know, what do you need to hold? Because every state's different. And for those who are listening to this overseas, you know, your country have different. So look at that and talk to them.
Roddy Bergeron [00:17:00]:
When we talk about the amount of log data or whatever that we collect, is the format in which we put it in too. Matters like are we ingesting it and putting into a SIM format? Are we putting it into a SQL database? And the ability of your vendors to meet those formats is also important as well, because not everyone supports every single format out there. Hopefully they can contextualize everything to a syslog format or whatever. But that's all part of the vendor management and vendor risk discussions you have. Can they meet my needs as well?
Chris Lindsey [00:17:32]:
When you're storing data, especially logs, you need to make sure they're tamper proof. There's a lot of tools and things that you can do out there to ensure that they're not tampered with. You know, if you're dealing with a database, the backup method, you know, methodologies, the three, two, one, you know, make sure that you have that.
Roddy Bergeron [00:17:49]:
Yeah, film, right.
Chris Lindsey [00:17:50]:
You know, and the other thing, there's.
Roddy Bergeron [00:17:50]:
Film fall integrity monitoring. Right? Like making sure that things that shouldn't be touched or are touched or tampered with. We go back to, I call it the altar at which cybersecurity professionals worship, like the CIA triad, where it's the confidentiality, integrity and availability. All three must be in balance. And when you're talking about things like audit log, they have to be available and they also have to be, I'd say confidential, but also you do have to make sure that whenever you write something to it and you touched on backups. And I remember my first job at this, at the CPA firm, we did tape backup, and we had LTO and Dapp tapes. We had a thing called worm Media, which is right once read many. And now that everything's all device based or cloud based backups, you don't hear about worm media that much anymore, but it's still a concept.
Roddy Bergeron [00:18:40]:
Can I write to it? And then it's tamper proof, and then I can only read from it for restore. That's important because we hear so many cases of that backup data not being properly segmented, air gapped or whatever you want to call it. Right. And it being cleared out. There was a case recently, I don't want to name the company, but it made the news because it was a humongous ransomware incident. And they same thing happened. They had backups, but they weren't segmented from the network. There was a device like sitting right next or in the same rack on the same network as the servers.
Roddy Bergeron [00:19:09]:
And that got hosed as well. During the ransomware incident.
Chris Lindsey [00:19:12]:
We don't have to name them, but.
Roddy Bergeron [00:19:13]:
We all know who it is as.
Chris Lindsey [00:19:17]:
A matter of fact, actually the downfall, kind of like an Enron, there's going to be some legislation that comes out of this.
Roddy Bergeron [00:19:23]:
So, yeah, you know, the legislation piece has been coming for a long time, I think. And I think it's starting to get some teeth now in the US. Like if we're going to, we're going to take us focus, right? In the US, it's coming, right. You know, Europe has GDPR and other privacy laws, but the US, we see what the White House has put out with regards to some of their cybersecurity pillars and programs that they want to put in place and everything from accountability, like who's accountable whenever there's a vulnerability in a piece of software? Who's accountable when a piece of software isn't secured by default? If you don't have a secure by default mantra, or maybe you install a piece of software and every single feature is turned on and exposed to the outside world, or allowed to be exposed to the outside world, can you curtail that through having a smaller feature set turned on the beginning? Can you turn off any accessible services besides a setup page? And then once that's done going through all these basic setup, can then those other services be turned on? Those types of conversations are going on in the regulatory space. And like, you can see it's coming, right? Especially you see like what happened with dfars and then that turned kind of into like CMMC. So CMMC is starting to become a reality for Department of Defense contractors. It's only a matter of time before that trickles to other federal agencies. And then it'll become probably common practice in those spaces to adhere to those standards.
Roddy Bergeron [00:20:40]:
Right. And that includes piece that we hadn't seen in a long time in regulatory spaces. That's the idea that a third party auditor is going to come in and certify you before you can get access to government contracts, which wasn't going on before with d four s. It was self attestation. So you basically say you give a thumbs up and say, yeah, yeah, we're doing that. And we wouldn't know you're good. Yeah, that's all it was. It was like you would sign a piece of paper, figuratively speaking, you'd sign a piece of paper that said, I'm doing this, and then we wouldn't know you weren't doing it until there was an incident and then kind of find out you weren't doing nearly anything.
Roddy Bergeron [00:21:12]:
Right. And the d far space. Right. The scoring system you had was your spurs score and you start off with 110, and then as you fail to meet a control, it goes down and you can get to the negatives. Like, you know, I've gone to partners or clients, whatever you want to call them, and, you know, we would do an actual, like d four s audit and your spur score is like a negative 32 or negative 40 or whatever right now. And they would gasp, like, it's not bad. It means just we have a lot of things to fix. And then to hear people say things like, yeah, yeah, all my clients have 110 spur score and I'm like, impossible.
Roddy Bergeron [00:21:44]:
There's no way. There's no deficiencies at all. I find that hard to believe. And come to find out that was true, right? Like, people were signing off and saying they had perfect spur scores and that wasn't happening at all. So now you see that the regulatory teeth come into play with CMMC, where it's like you're gonna have a third party independent auditor come in and verify that you're doing what you're doing or else there's going to be some pain there, which I go back to my original conversation about the financial industry that was going on 20 years ago. In the financial industry, you had to have a third party auditor come in and assess your controls, right? Because there were some issues. There were like, if a bank folded, FDIC insurance comes in, they pay, but like, that's federal dollars and they want, they don't want to have to spend that money. So they were like, if you want the FDIC to cover you, then you have to.
Roddy Bergeron [00:22:29]:
And you want your banking license or whatever the other got. The proper term for it was, but like, you have to have someone come in and audit your controls. It has to happen. So there was a lot of teeth there. I'm glad to see that we're starting to get some enforcement. I don't like the fact that it's forced. Right? Like, you have to do this always like to think that people should do what's best ethically and morally, but again, it has to, it has to be some teeth to that thing, people to act.
Chris Lindsey [00:22:50]:
Well, it's being forced because, you know, it's like a sign. A sign is created because it happened. The problem is when you're self auditing, you know, that's just problematic. And so having an outside vendor come in to validate your stuff, and it's not a bad thing, because when you have somebody that can come in and look at your environment from an outside perspective, who has no skin in the game, other than the fact that they're there just to make sure that you're doing what you are saying that you're doing and you're doing it right. Because back to what you were saying earlier, you may not know what you need to audit, and laws change. And some of these auditors, they're up to date with what requirements are out there. And so what, 1015 years ago, what was standard is not today. And companies get into a habit of, hey, it's like dependency management.
Chris Lindsey [00:23:40]:
It's up, it's running. Why would I modify it if everything's working correctly? Oh, I'm collecting all the data. Well, the problem is, what you're collecting is still the old stuff in the software, but software has been updated. It's not logging the same way, but you're not collecting it because you haven't changed.
Roddy Bergeron [00:23:56]:
It's also good to have a third party come in. You get a little nose blind to your own problems, right? Like, you live in it day in, day out. Like I always like to use. I don't know if you remember Donald Rumsfeld. He served under the. It was a George W. Bush presidency, right?
Chris Lindsey [00:24:11]:
Yes.
Roddy Bergeron [00:24:11]:
He had a famous quote. Right. That. I understand the logic behind it. But he said, you know, there's known knowns, which are things we know. There's known unknowns, which are things we know we don't know. And then there's unknown unknowns, things we don't know. We don't know which.
Roddy Bergeron [00:24:23]:
It's the same thing, right? Like, if you are in that environment constantly, whatever it is, your dev environment, your it infrastructure, whatever, I. You will become blind to your own issues because you don't know what you don't know. So having a third party come in, either an auditor or red team, penetration testing team or whatever, to come in and help you, it's not to point out the fact that you're doing something wrong or bad. It's to make sure that you're bettering your position and bettering your risk posture. That's how it should be viewed. I see so many people take it as an offense because I've worked with red teams before, and they get so much resistance going into an organization, and they get, like, scoped down so bad where it doesn't help the organization because they just don't want it to look bad. And I'm like, look, it does not make your company look bad. Like, what's going to look bad is whenever you check a bunch of boxes off on a compliance checklist that, oh, yeah, I had a red team at a pen test, etc.
Roddy Bergeron [00:25:13]:
Etcetera. And you still have an incident because you weren't doing those properly. Like, that's what makes your company look bad, not doing what's best and making sure that you have, you know, like, what was one robot? You say, you know, whether or not your baby's ugly or not. Like, you don't want to say your baby's ugly, but, like, sometimes you have to have somebody else tell you, right? And that's. And that's part. That's part of it, right? That's part of the process, the audit process. I think that's what scares a lot of people about hearing the word auditor. Tax auditing is a different thing.
Roddy Bergeron [00:25:41]:
But, like, the auditing that we do, it's coming in. Just make sure you have the proper things in place. And that's scary sometimes for people because they don't want to have to face the fact that they may be doing things right or maybe they feel like their jobs on the line and that that comes from company culture and everything else. Making sure that we're doing this from a passion of making the company better. And that's what needs to be discussed. Whenever you decide to bring in an audit team, especially if you're in management and you have to break the news to your it team, that's how it should go about. It's not about punishing anybody or making them look bad. It's about funding, where our deficiencies are at making the company stronger.
Chris Lindsey [00:26:13]:
So, Roddy, let me ask you this question. What's the best advice that somebody has ever given you regarding security?
Roddy Bergeron [00:26:19]:
Don't be overconfident in your abilities. There's always going to be someone either in the white hat space or the black hat space that can outsmart you. So always be open to learning from your faults and gesting new information and being open ingesting new information. Because regardless of where you stand in the cybersecurity space, there's always somebody out there who's better than you at a certain thing. And don't become overconfident in your ability to singularly protect anything, because you will need consultants and you will need new education, and you will need new standards and new practices. So never stop learning. I wrote a post about it the other day on LinkedIn, but it was a conversation I had with a partner while I was out doing a roadshow, and they were like, I can't wait to pass my cissp so I can stop learning. And I was like, oh, buddy, like, hey.
Roddy Bergeron [00:27:06]:
I was like, hey, you're gonna have to keep doing cle. Like, that's a requirement with the certification would be, like, stuff you're gonna learn as part of that. Some of its evergreen. Right. It'll stick around.
Chris Lindsey [00:27:16]:
Right.
Roddy Bergeron [00:27:16]:
But for the most part, like, that only skims the surface of what you're gonna be doing. You're gonna continuously evolve, and you're gonna pick a path.
Chris Lindsey [00:27:23]:
Only the beginning.
Roddy Bergeron [00:27:23]:
Only the beginning.
Chris Lindsey [00:27:24]:
Only the beginning.
Roddy Bergeron [00:27:25]:
And, like, if you look at that, if you take any certification and you say, like, well, I'm a master, unless you're taking some very high level certification. But for the most part, if you think you have mastered a skilled by passing a certification, don't do anything for five years and come back and tell me if your skills are still as sharp as they used to be, like arn sharpened iron. You have to continue to improve upon that. So don't be overconfident in your abilities, especially in this cybersecurity world, because that's stuff we did five years ago.
Chris Lindsey [00:27:53]:
I mean, completely changed five years ago. We didn't have AI, we didn't have the LLMs. We didn't have what we have today. And it's been an absolute game changer since. Really, it really became more mainstream, which was somewhere between January and February this year. So let me ask you another question. What's the hardest lesson that you've learned?
Roddy Bergeron [00:28:10]:
Hardest lesson I learned was doing incident response, the human side of incidents, right. Because you, like a. You have to be a therapist first in incident response and a technical person, especially if you're leading the incident response, right. Because you're dealing with some pretty people were pretty much having their worst day ever. And you have to contextualize that in the way you discuss items with them and next steps, and really understanding the fact that, like, besides just the business on the line, you've got people who work at this business whose careers and jobs are on the line, who have had no say in the security controls and security posture of the company, who now have to deal with the repercussions of that changed me in the way I approach cybersecurity, because when I go have a discussion with a client, I would stop talking about, oh, we're going to put in this EDR product. We're going to put in this new firewall. We're going to put in this and that and start saying, like, all right, here's how it operates. Here's how your business is going to hurt.
Roddy Bergeron [00:29:10]:
Here's how the people that, if you care about your employees, the way you say you care, like, let me tell you a story. And I tell them a story of the incident response where they had to lay off 25 employees. There's 25 people who were trying to then struggle to figure out how they can pay their bills, how they can put a food on their table, how are they going to pay their mortgage? And I was like, that is the real issue of an incident response that we normally don't talk about. But it's really one of the driving factors for me and the passion behind me doing what I do is that I know that human beings come first and that the human element of an incident response and the emotions that run along with it or something we don't teach. And it's hard to teach, it's hard to talk about, but it's something that I think is everyone needs to be cognizant of. Sounds a hard lesson for me because being a technical person, I'd walk in there and be like, cool, we're going to be down for two weeks while we restore everything. And I hope everything works out for you guys. Like, we're going to start our work.
Roddy Bergeron [00:29:58]:
And then I would just update a ticket and I'd just be like, all right. And I'd maybe call them, just be like, here's what we did today. But driving home that human peace and letting them understand. All right, first off, yes, this is going to be bad, but we can work through it. And here's what we're going to do. And just making sure that you understand there's a human on the other side of this incident. We may have caused our own problem, but again, at the end of the day, they're still human and they're still dealing with a lot of stuff. And you have to have that, I guess, that emotional intelligence to work with them through it, alongside with the technical knowledge to get them out of the hole.
Chris Lindsey [00:30:27]:
Yeah. Nice. Well, Roddy, I appreciate your time today. Thank you for coming on our show, and I look forward to seeing the amazing things you're going to continue to do.
Roddy Bergeron [00:30:38]:
Thank you. I appreciate it.
Chris Lindsey [00:30:39]:
Thank you. Thank you so much for joining me on this episode of Secrets of Appsec Champions. If you found this valuable, hit that subscribe button on Apple Podcasts, Spotify, or wherever you get your podcast. And hey, ratings and reviews are like gold force. So if you're feeling generous, please leave a kind word. It helps others discover our show. Until next time, take care.
