When it comes to building a centralized logging infrastructure you'll want a system that: 1. lets you load data from all your devices 2. supports any format of log data 3. provides SQL interface for querying the data 4. lets you query across all data sources simultaneously 5. scales to handle your volume of data 6. allows you to retain months/years of raw log data in queryable format You might want to take a look at Addamark's Log Management System (www.addamark.com) if you're dealing with high volumes of data from disparate systems (full disclosure: I work for Addamark). Dan -----Original Message----- From: loganalysis-adminat_private [mailto:loganalysis-adminat_private] On Behalf Of abhinav tiwari Sent: Sunday, September 08, 2002 11:48 PM To: loganalysisat_private Cc: TBWalterat_private-erc.com Subject: [logs] centralized logging Thomas u have greatly put up the centralized logging logics....thanks. Going further..i need some help towards how to centralize in a best known way -- for bsdi unix related system logs. And only from security perspective not system h/w prob etc troubleshooting purposes...Can u pls help me out. Regds abhinav >> >Today's Topics: > > 1. Re: Business Case for log centralization (Been Reading Your Logs >Lately?) > >--__--__-- > >Message: 1 >Date: Fri, 6 Sep 2002 18:51:14 -0400 (EDT) >From: Been Reading Your Logs Lately? <tanat_private> >To: "Walters, Thomas B" <TBWalterat_private-erc.com> >Cc: <loganalysisat_private> >Subject: Re: [logs] Business Case for log centralization > >A couple thoughts on centralized logging (since business justification >will be specific to the business you're in and the size of your >environment)... > >In an environment which has invested capital in highly available (HA) >systems, redundant component failures go unnoticed unless logs are read. >Therefore, reading logs is a required activity to realize the benefits of >HA systems. That said, a number of man-hours may be spent by one or more >admins moving from system to system reading these logs. At some point >(number of systems) it becomes necessary to add another admin. The >ongoing costs of another admin make the costs of establishing a >centralized logging mechanism look as if it has a return on investment. > >How you want to position this savings is, again, dependent on your >particulars. Perhaps there are not enough staff to handle all the >projects and centralized logging would instead enable your IT dept. to do >more with the same number of people. Perhaps you have too many IT >staffers and can eliminate one by centralizing logging. Perhaps the logs >are not being read today and the investment in HA is in jeapordy of not >being realized. Perhaps centralized logging is the only way your current >staff can accomplish log monitoring and assurance that HA systems remain >available. Regardless of the environment being HA or not, component >failures can be headed off so the cost of down-time might be an issue in >your environment, that could be leveraged to cost justify centralized >logging. > >Another situation involves environments with a large number of systems >exposed to worm activity (ie., out in a DMZ). The time to respond to an >incident is minimized through centralized logging in that you can >instantly summarize what hosts are being hit, which are affected, and how >successful your remediation efforts are. Time spent responding to >incidents is time not spent providing core IT services / supporting >business processes - so minimization of response time = minimization of >the cost of responding to an incident. Even if you're paying time and >materials (T&M) to a vendor to respond, the faster they can do it, the >cheaper you get off. > >Incident responses also may be extended when local logs are modified. I >can recall at least one situation where logs had been modified locally on >a system that I was performing a forensic identification of. The first >version of the findings document was structured around these local log >entries. Because centralized logs were not available, discovering that >these local logs had been modified a) took a while; and b) might not have >been discovered at all if we were not so meticulous, skilled and lucky. >Unfortunately, this meant about 4 wasted man-days of pouring through >modified logs before getting around to conducting the type of >investigation best suited for such a situation. > >In addition to wasting valuable time during the incident response, >management's decision making inputs are skewed by modification of >vulnerable local logs. Having a centralized logging mechanism greatly >increases (assuming its been secured) the integrity of the information on >which management will base its decisions on how to respond to the >incident. Without centralized logging, the initial input for these >decisions may very well be "we don't know" and should most likely be >"we're not sure but...". > >Finally, centralized logging is an essential part of any information >security infrastructure. The ROI on preservation of evidence is difficult >to put into numbers however, it is worth noting. A proper incident >response procedure would involve initial reconnaissance from such a >centralized log server. This reconnaissance would drive which systems >were candidates for forensic acquisition. Having to do such >reconnaissance by logging into each local system to collect logs will >cause valuable forensic evidence to be lost on that local system. >Accouting records will be added to the system, file MAC times will be >updated/lost, memory will be swapped out, logic bombs may trigger, >"deleted" data may be lost; but worst of all, the logs themselves may have >been "cleaned" (modified by the intruder). Lack of a centralized logging >mechanism is one sign that an organization has a lax security posture and >is at risk. > > >On Thu, 5 Sep 2002, Walters, Thomas B wrote: > > > > > > > Hey all log surfers! > > > > Has anyone has to present a business case for centralizing all of their > > logs? For example justify to management the purchasing a central log > > server? > > > > _______________________________________________ > > LogAnalysis mailing list > > LogAnalysisat_private > > http://lists.shmoo.com/mailman/listinfo/loganalysis > > > > > >--__--__-- > >_______________________________________________ >LogAnalysis mailing list >LogAnalysisat_private >http://lists.shmoo.com/mailman/listinfo/loganalysis > > >End of LogAnalysis Digest _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Sep 11 2002 - 11:07:09 PDT