Earlier in my career, I was the IT director for a medium sized enterprise and had responsibility for information security, in addition to networking, server ops, help desk, etc. I was fortunate to be able to start with a mostly clean slate and had the help of many talented and energetic thinkers. The company was a manufacturer of network security software and our flagship product was an intrusion prevention (IPS) application, which meant cost wasn’t an option with determining how many IPS engines to place throughout the network. One of the debates we had was what to do with and how to respond to attacks coming from the Internet. We had implemented a very robust and restrictive firewall infrastructure that was very effective at keeping out attackers. The IPS engines on the Internet side of the firewalls reported a constant barrage of scans, malware propagation attempts and nearly every other type of attack the engine could detect.
Full of good intentions, we prioritized attacks and tried informing abuse contacts for assistance with stopping them. There were far too many to handle manually, and we quickly found that ISP’s and network owners were either overwhelmed with complaints, didn’t care or were complicit in the attacks. Our well intentioned efforts did absolutely nothing. I found that the volume of Internet-based attacks is directly proportional to the number of IP addresses the organization has, and nothing was going to change that. The only one who cared about what happened to our network was us, and we needed to focus on only things we need to care about. And we decided that we could only care about attacks that were successful. The firewalls were effective in their jobs, after all. We could roughly monitor successful attacks by looking at IPS engine traffic on the inside of the firewalls.
As our budding IT shop matured, we entered the age of metrics. We relied heavily on technology to keep us safe, and so didn’t have a lot of process related metrics. To show the value of the security program, we began reporting the number of attack attempts and the number of intrusions. Being a technology company, and a security-oriented one at that, these numbers were very interesting to the management team at first. We would show reports with millions of attacks each month, and always zero successful intrusions. At some point it occurred to me – I don’t, nor was I expected to, do anything different if the number of attack attempts was 100,000 or 100,000,000,000 in a month. It was a truly useless metric. The very few times there were security incidents, the management team was made aware and kept up-to-date real time, so even the successful intrusion metric was pretty useless.
I learned a lot as I matured alongside that IT organization, and one important lesson was only monitor things that will cause you to take action based on the resulting data. Anything else is simply trivia and probably not contributing anything useful to the organization. Syslog is very similar. There is generally good value in archiving logs for reference in the future, but for active monitoring, an assessment should be made about whether the types of things being monitored would cause an action based on a specific event being detected.
RSS Error: A feed could not be found at http://www.syslog.org/forum/.xml/?type=rss. A feed with an invalid mime type may fall victim to this error, or SimplePie was unable to auto-discover it.. Use force_feed() if you are certain this URL is a real feed.