-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dont forget secure transfer and timestamping/hashing for evidentiary procedures... Chris Kirschke Security Analyst Silicon Valley Bank >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 queryab >le format > >You might want to take a look at Addamark's Log Management Syst >em >(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 securit >y >perspective >not system h/w prob etc troubleshooting purposes...Can u pls he >lp 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 justi >fication >>will be specific to the business you're in and the size of you >r >>environment)... >> >>In an environment which has invested capital in highly availab >le (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 so >me 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 in >vestment. >> >>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 man >y IT >>staffers and can eliminate one by centralizing logging. Perha >ps the >logs >>are not being read today and the investment in HA is in jeapor >dy of not >>being realized. Perhaps centralized logging is the only way y >our >current >>staff can accomplish log monitoring and assurance that HA syst >ems >remain >>available. Regardless of the environment being HA or not, com >ponent >>failures can be headed off so the cost of down-time might be a >n issue >in >>your environment, that could be leveraged to cost justify cent >ralized >>logging. >> >>Another situation involves environments with a large number of > systems >>exposed to worm activity (ie., out in a DMZ). The time to res >pond to >an >>incident is minimized through centralized logging in that you >can >>instantly summarize what hosts are being hit, which are affect >ed, and >how >>successful your remediation efforts are. Time spent respondin >g to >>incidents is time not spent providing core IT services / suppo >rting >>business processes - so minimization of response time = minimi >zation 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 mo >dified. >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 l >ocal log >>entries. Because centralized logs were not available, discove >ring that >>these local logs had been modified a) took a while; and b) mig >ht not >have >>been discovered at all if we were not so meticulous, skilled a >nd lucky. >>Unfortunately, this meant about 4 wasted man-days of pouring t >hrough >>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 respo >nse, >>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 inf >ormation >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 lik >ely be >>"we're not sure but...". >> >>Finally, centralized logging is an essential part of any infor >mation >>security infrastructure. The ROI on preservation of evidence >is >difficult >>to put into numbers however, it is worth noting. A proper inc >ident >>response procedure would involve initial reconnaissance from s >uch 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 lo >gs will >>cause valuable forensic evidence to be lost on that local syst >em. >>Accouting records will be added to the system, file MAC times >will be >>updated/lost, memory will be swapped out, logic bombs may trig >ger, >>"deleted" data may be lost; but worst of all, the logs themsel >ves may >have >>been "cleaned" (modified by the intruder). Lack of a centrali >zed >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 c >entral >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 > -----BEGIN PGP SIGNATURE----- Version: Hush 2.1 Note: This signature can be verified at https://www.hushtools.com wlsEARECABsFAj1/1KQUHGR1cm5pZUBodXNobWFpbC5jb20ACgkQ3UH5NRolsbai9gCg hKCOgmiEI7juwqejJf0ykknZxpMAoJQxcl4DLOR7FlfGEm6bN8qvV0VJ =Zvfc -----END PGP SIGNATURE----- _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Thu Sep 12 2002 - 18:06:17 PDT