[logs] centralized logging

abhinav_tiwariat_private

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