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
This archive was generated by hypermail 2b30 : Sat Sep 07 2002 - 12:48:47 PDT