one of the most important pieces in relation to responding to incidents is reviewing your logs. The whole purpose for us having logs is so that we can weaken research, an event that's happened. It doesn't have to be a security incident. I mean, you know, we have performance logs,
We have access logs, we have firewall walks. We have all of these logs that track information.
If we don't review those logs, uh, then we're we're losing a very good resource.
You know, if you think about when most people want to go back and look at logs is after a breach. We're after an incident or after a problem.
set of procedures on how we review those laws.
Uh, I hate to go back and pick on Target because it's so, but because it is something that's in the news right now. And we're still hearing about the ramifications of that attack again. The loss of 70 million credit cards. There was a whole study on the attack, and I mentioned just a little bit ago.
The biggest cause for the attack was they didn't properly isolate out their networks.
They didn't have a guest network that was limited just for contractors. They had that merged with their production network. Sure, that was a big problem, but what I found was interesting is an independent third party that went through and reviewed theater Tak
in trees in audit logs that indicated ex filtration of data. When we talk about ex filtration, that's me removing data off your network Now, really think about this. 70 million credit card numbers were moved from Target's network
to another source or tow a specific destination. They were moved off the network.
Don't you think there should be something in place that says, Hey,
there are 200 gigabytes of data leaving my network, and that doesn't normally happen. Perhaps we should look at this. Well, of course, that should happen. And Target had the logs configured properly. They created triggers and alerts for network administrators. But what was so interesting
was the company that did this third party analysis
found that even though the logs were even though the entries were tracked in logs, the logs had over 10
1000 security related events. On a week by week basis, 10,000 new security events generated.
How in the world are you going to sift through 10,000 audit entries to find something meaningful?
Well, we've got a problem. If that's the case, and I can't tell you how. How frequently that happens is because of regulations, Whether we're payment card coming to accept payment cards or hip or this requirement of that requirement, we're required to keep audit logs that track all these different types of events.
Well, if you're tracking so many events that you can't review them meaningful,
So what do we have to do? We gotta do something.
And frequently, what we'll do is we'll bring in tools like audit reduction tools, uh, seven system incident in event monitoring tools, uh, or information event monitoring tools that can go in and pull out just specific types of events
that can make these logs more meaningful. The answer isn't audit less stuff. We may have to offer those events and what we have taught it may generate 10,000 entries, but we have to find a way of taking those entries, breaking them up, categorizing them,
having different team members evaluate different portions of logs.
Nobody is gonna be able to go through on a weekly basis, 10,000 entries and make sense of them. It's too cumbersome. It's too bulky. So we use thes monitoring tools, audit reduction tools, and there are a lot of them that are out there. We use those toe limit what we have to review.
So you know auditing is just a piece of it. Review your logs, but find a way to make those entries meaningful and reviewable.