Log Files Do Not Improve Security(devcentral.f5.com)
devcentral.f5.com
Log Files Do Not Improve Security
http://devcentral.f5.com/weblogs/macvittie/archive/2009/09/09/log-files-do-not-improve-security.aspx
8 comments
Monitoring logs may not BE security in the classical sense, but it should be a security enabler. Things like:
* why am I seeing ingress/egress traffic to an IP I thought was firewalled? * why am I seeing triggers to IDS signatures on hosts I thought didn't communicate in/out to the internet? * why am I seeing web traffic bypassing a content filter/proxy I thought everyone had to use? * why am I seeing router/switch VLAN/routing errors that could expose more of my network? * if I continue to buy all of those technologies, how do I monitor them to know that they are functioning/doing their job/reporting any exposure? * how do I know if I've been exploited/exposed?
If you use it right, it isn't just a post-attack/exposure response and investigation system, it can be an early warning system, and an aid in your normal incident response techniques. If you do get exposed (which unfortunately does happen to most organizations - whether it's a simple policy violation or a worm infection or worse), it can help with containment (who is still infected?), patient zero identification (when/where did it start?), and mitigation itself in some cases (though that's not always practical or possible).
For a lot of people/teams, knowing really is half the battle. A lot more are strapped for resources and using a tool to extend the IT team does enable better security in that it enables them to focus their time somewhere other than monitoring.
* why am I seeing ingress/egress traffic to an IP I thought was firewalled? * why am I seeing triggers to IDS signatures on hosts I thought didn't communicate in/out to the internet? * why am I seeing web traffic bypassing a content filter/proxy I thought everyone had to use? * why am I seeing router/switch VLAN/routing errors that could expose more of my network? * if I continue to buy all of those technologies, how do I monitor them to know that they are functioning/doing their job/reporting any exposure? * how do I know if I've been exploited/exposed?
If you use it right, it isn't just a post-attack/exposure response and investigation system, it can be an early warning system, and an aid in your normal incident response techniques. If you do get exposed (which unfortunately does happen to most organizations - whether it's a simple policy violation or a worm infection or worse), it can help with containment (who is still infected?), patient zero identification (when/where did it start?), and mitigation itself in some cases (though that's not always practical or possible).
For a lot of people/teams, knowing really is half the battle. A lot more are strapped for resources and using a tool to extend the IT team does enable better security in that it enables them to focus their time somewhere other than monitoring.
"Monitoring" was not part of the equation and that's part of the problem. The implication in the cited article was that logs IN AND OF THEMSELVES result in better security. That's simply not true. Monitoring logs is better, but analysis and even reactive tools that make use of those logs is better. That improves security, but log files don't..
Absolutely agree that logs are an enabler of security. Either someone needs to look at them (analysis) or they need to be leveraged via third-party tools (if you're looking to do more real-time analysis or catch a breach in progress).
And very good point on the investigation aspect - I was thinking more external facing (breach) but there's also good for internal facing (infection/containment).
Absolutely agree that logs are an enabler of security. Either someone needs to look at them (analysis) or they need to be leveraged via third-party tools (if you're looking to do more real-time analysis or catch a breach in progress).
And very good point on the investigation aspect - I was thinking more external facing (breach) but there's also good for internal facing (infection/containment).
Yes, ma'am, we are on the same page. :)
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.
Use logcheck to filter out benign messages; have everything else emailed to you in real time.
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.
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.
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.
> [...] 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.
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.
They can help in prosecuting offenders, and in that way be part of a deterrent that improves security.
If security is measured in a way such as (average leak size/mean time between leaks)
As a novice at security issues, I find the discussion sounding helpful, but would appreciate HN discussion.
The general issue regarding security and blogs seems obvious: Shouldn't logs be considered one element in security analysis ? - not something I see discussed in my short time here. Anyway, it gives me pause to think, "Where have I implemented log-analysis in my (or my cron's) routine... and planned for follow-up?"
The general issue regarding security and blogs seems obvious: Shouldn't logs be considered one element in security analysis ? - not something I see discussed in my short time here. Anyway, it gives me pause to think, "Where have I implemented log-analysis in my (or my cron's) routine... and planned for follow-up?"
All boils down to the fairly generic statement in the last line:
Logging is an integral part of organizational security policies and best practices and well it should be. But don’t make the mistake of thinking that logging access to records is the same as securing them.
Logging is an integral part of organizational security policies and best practices and well it should be. But don’t make the mistake of thinking that logging access to records is the same as securing them.
I worked at SenSage, a company that creates a log-archiving/querying product (used by NSA/IRS/Dept-of-Treasury/Navy, banks, insurance companies, telcos, etc.). Our customers all had very good reasons for archiving logs:
* Real-time security never gives complete coverage in an evolving electronic infrastructure ... there always are vulnerabilities that are patched, new services introduced whose risks aren't properly understood at first, etc. Having a log archive lets I.T. personnel look at history in case of breaches to find how certain data was leaked, or find what kinds of attacks were attempted. This history informs I.T. personnel how to improve their real-time security. It's an essential part of the feedback system.
* The most dangerous data theft isn't done by those penetrating a network from outside ... it's done by unscrupulous insiders who have some (needed) measure of access to the data. You need to trust someone. But they're not always honest. Trust, but verify. Archived log data is your only recourse here ... and knowledge that every move is recorded keeps insiders (if you choose to let them know) honest.
* Yes, log archives help prosecute bad actors.
Log data archival is a big commitment, will take tons of disk space and some expensive software (for a large corporation), and should be more than simply a data sink. To be effective you need to be able to continually run standard and custom queries to see what's happening in your network.
* Real-time security never gives complete coverage in an evolving electronic infrastructure ... there always are vulnerabilities that are patched, new services introduced whose risks aren't properly understood at first, etc. Having a log archive lets I.T. personnel look at history in case of breaches to find how certain data was leaked, or find what kinds of attacks were attempted. This history informs I.T. personnel how to improve their real-time security. It's an essential part of the feedback system.
* The most dangerous data theft isn't done by those penetrating a network from outside ... it's done by unscrupulous insiders who have some (needed) measure of access to the data. You need to trust someone. But they're not always honest. Trust, but verify. Archived log data is your only recourse here ... and knowledge that every move is recorded keeps insiders (if you choose to let them know) honest.
* Yes, log archives help prosecute bad actors.
Log data archival is a big commitment, will take tons of disk space and some expensive software (for a large corporation), and should be more than simply a data sink. To be effective you need to be able to continually run standard and custom queries to see what's happening in your network.
I've used log files extensively for security.
Aside from the obvious post-incident investigation, I've set up (nearly-) real-time scanning of logs feeding into programs that scan for abuse-like activity, and feed the output of those into alerting mechanisms and blacklists.
Those tools have proven time and again to be extremely valuable from a security perspective (we still log blacklisted attempts and can see what's trying and failing).
Aside from the obvious post-incident investigation, I've set up (nearly-) real-time scanning of logs feeding into programs that scan for abuse-like activity, and feed the output of those into alerting mechanisms and blacklists.
Those tools have proven time and again to be extremely valuable from a security perspective (we still log blacklisted attempts and can see what's trying and failing).
It's actually just a piece so that F5 can pimp the technologies they are selling. See the numbered list towards the bottom of the post.
Here's a weak argument to say that log files can improve security:
IF
* security means reducing risks to the confidentiality, integrity, and availability of information;
* risk is a function of likelihood and impact;
* the longer an attacker has unauthorized access to information, the bigger the impact; and
* if log files are reviewed frequently
THEN
* unauthorized access can be detected;
* corrective actions can be taken;
* unauthorized access can be stopped or limited;
* thus reducing the impact;
* thus reducing the risk; and
* thus improving security.
But, in reality, the corrective action reduced the risk, not the detective control (logs and reviews), so this is a weak argument.
IF
* security means reducing risks to the confidentiality, integrity, and availability of information;
* risk is a function of likelihood and impact;
* the longer an attacker has unauthorized access to information, the bigger the impact; and
* if log files are reviewed frequently
THEN
* unauthorized access can be detected;
* corrective actions can be taken;
* unauthorized access can be stopped or limited;
* thus reducing the impact;
* thus reducing the risk; and
* thus improving security.
But, in reality, the corrective action reduced the risk, not the detective control (logs and reviews), so this is a weak argument.
The title is trollish. As explained in the first sentence of the article, logs don't provide "real-time security", this is very different than "they do not improve security". Sure they do.
One pretty standard way to classify security counter-measures is in the three areas: Protection, Detection and Response/Recovery. Logs play a very important part in the detection area.
One pretty standard way to classify security counter-measures is in the three areas: Protection, Detection and Response/Recovery. Logs play a very important part in the detection area.
Log files have never been about improving security.
Log files have never been intended as a security measure in the same way as a firewall, but it's naive to claim that they don't improve security. The concept the author is missing is that security is a process, not a software feature. Log files address several key parts of the security process:
1. Damage containment: if someone does compromise a system, logs are your way to catch that as early as possible - the difference between, say, someone at your bank getting malware and their authorization credentials being stolen. Identifying failures can be done close to real-time so it's realistic to be able to do things like quarantine desktops which suddenly acting like botnet nodes.
2. Verifying normal functionality: things like security updates being installed and services restarted, whether your admins are following correct policy, etc. This stuff matters a lot in any large-scale environment and while you can get a lot using a security scanner, logging is faster, safer and easier in many situations.
3. Identify anomalous behaviour: the classic example is adding firewall rules to drop traffic from hosts which attempt noisy attacks but this can also apply to things like banks notifying their customers that their browser is outdated, showing signs of being compromised, etc. Having actual data makes many security decisions a LOT easier.