5 ms·

I disagree. Log files greatly improve security if you read them. When you spot problems early, you fix them early. Would you rather spot a burglar as he lockpic

by shykes 17y ago

I disagree. Log files greatly improve security if you read them. When you spot problems early, you fix them early. Would you rather spot a burglar as he lockpicks your door, or as he's jumping out the window with all the jewelry? Use logcheck to filter out benign messages; have everything else emailed to you in real time.

lmacvittie 17y ago
You have a good point, although the log file is merely enabling better security, not the cause of it. ;-) Subtle difference that needs to be pointed out so people remember that simply turning on logging isn't - by itself - doing anything to improve security. You have to actually leverage the log file - either by reading it, as you point out, or using other tools to act on what's in the log file.
pasbesoin 17y ago
A while back, someone (here, I think) cited an article / blog entry wherein the author describes his log reading process as first filtering out all the... I'll use the word "typical" entries. He identified patterns for these and lets a script strip these out. As he continues to identify those types of entries, he adds patterns for them to the script. He then focuses on what remains. At least as described, it sounded like an effective way to focus attention on the needles in the haystack. Note that this doesn't mean shrinking your logs. It means an automated process for extracting an interesting subset. You still have the complete logs for other work. I'd also regularly audit the extract process both for sufficiency and as a reminder that its output is not the only thing you should be paying attention to. It's not my idea, and I'm probably not doing it justice. Maybe someone else recalls the article / blog entry and has a link. It's also not something I need to do; perhaps if I did, I'd see shortcomings in the methodology.
- shykes 17y ago
  > [...] first filtering out all the... > I'll use the word "typical" entries. > He identified patterns for these and > lets a script strip these out. As he continues > to identify those types of entries, he adds > patterns for them to the script. > He then focuses on what remains. That's exactly what logcheck does. http://logcheck.org http://logcheck.org
intel_chris 17y ago
The problem with log files is that many people don't read them, particularly not proactively. Moreover, certain automated tools reading logs promote complacency--I;ve got tools checking for abnormalacy, I'm safe. Same thing happens with virus scanners that aren't kept up-to-date. However, if your business is running a hospital, how intrinsicly motivated are you to be secure? That isn't a core competency. It isn't even a profit center, at best it's meeting a mandate. Thus, most will do the least allowed to save cost. Mandating log files isn't mandating security.

by shykes 17y ago

lmacvittie 17y ago

You have a good point, although the log file is merely enabling better security, not the cause of it. ;-) Subtle difference that needs to be pointed out so people remember that simply turning on logging isn't - by itself - doing anything to improve security. You have to actually leverage the log file - either by reading it, as you point out, or using other tools to act on what's in the log file.

pasbesoin 17y ago

A while back, someone (here, I think) cited an article / blog entry wherein the author describes his log reading process as first filtering out all the... I'll use the word "typical" entries. He identified patterns for these and lets a script strip these out. As he continues to identify those types of entries, he adds patterns for them to the script. He then focuses on what remains. At least as described, it sounded like an effective way to focus attention on the needles in the haystack. Note that this doesn't mean shrinking your logs. It means an automated process for extracting an interesting subset. You still have the complete logs for other work. I'd also regularly audit the extract process both for sufficiency and as a reminder that its output is not the only thing you should be paying attention to. It's not my idea, and I'm probably not doing it justice. Maybe someone else recalls the article / blog entry and has a link. It's also not something I need to do; perhaps if I did, I'd see shortcomings in the methodology.

shykes 17y ago
> [...] first filtering out all the... > I'll use the word "typical" entries. > He identified patterns for these and > lets a script strip these out. As he continues > to identify those types of entries, he adds > patterns for them to the script. > He then focuses on what remains. That's exactly what logcheck does. http://logcheck.org http://logcheck.org

intel_chris 17y ago

The problem with log files is that many people don't read them, particularly not proactively. Moreover, certain automated tools reading logs promote complacency--I;ve got tools checking for abnormalacy, I'm safe. Same thing happens with virus scanners that aren't kept up-to-date. However, if your business is running a hospital, how intrinsicly motivated are you to be secure? That isn't a core competency. It isn't even a profit center, at best it's meeting a mandate. Thus, most will do the least allowed to save cost. Mandating log files isn't mandating security.