NCSAM: Logs as a means of defense
by Steve Ragan - Oct 4 2010, 09:30The topic of logging is a complex subject. Inside a typical business, there are countless things to monitor, such as webservers, employee access, and applications just to name a few. For this installment of National Cyber Security Awareness Month coverage, we look at logs from a defense perspective.
Logs are wonderful and terrible things at the same time. Anyone who has ever had to sit for hours and sort through server logs, only to never find the data they need, will happily explain how awful they are. Yet, anyone who has ever found the source of a mission critical application failure or proof of an attack will gleefully tell you of their greatness.
For the basics, logs are recordings of events that have taken place on an organization’s systems and networks. An organization needs logs as part of an audit trail, and the auditing process is a must if an organization needs to address the needs of regulations such as SOX, GLBA, HIPAA, FISMA, and PCI DSS.
Year after year, more and more logs and log types appear on the network, which according to the NIST is why log management tools have grown in popularity. While the popularity is growing, the log management solution needs to fit snuggly into the organization’s operations. If it doesn’t, then it is a wasted resource.
You also have issues related to storage, as the more logged data you collect, the more space you need to store it. Another problem with logging is the actual examination. Sure the logs are there, but no one looks at them, and that is a damning mistake.
“It cannot be a pleasant experience to learn that the six months of log data you’ve been collecting contained all the necessary indicators of a breach. It is, however, a common experience. We consistently find that nearly 90% of the time logs are available but discovery via log analysis remains under 5%,” the 2010 Verizon Data Breach Investigations Report (VDBIR) explains.
The VDBIR listed three tip-offs when using log data for defense. The first is when there is a larger than normal increase in log data. Second, there are longer lines than normal in the logs themselves, and finally, the absence of logging.
“We’ve seen log entries increase by 500% following a breach. We’ve seen them completely disappear for months after the attacker turned off logging. We’ve noticed SQL injection and other attacks leave much longer lines within logs than standard activity,” the report added.
The VDBIR uses Enterprise operations in its data, but Enterprise operations, such as the Fortune 500 or 100, are well aware of logs, how to manage them, and how to gather serious business intelligence from them. The SMB segment, another key part to the VDBIR, is not.
We spoke with LogLogic’s CMO, Bill Roth, about logging and its role in security. When asked his advice for things an SMB administrator should be looking for when dealing with an attack on Apache or IIS webservers, he offered up some gems.
First, administrators should look for unknown bots scanning their pages. “They can expect bots like Google, MSN, and Baidu, but [administrators] should also keep an eye out for unfamiliar ones.”
Other things to scan logs for are consistent 404 errors, specifically 404 errors on long URLs, as this might be a sign of a probe for overflow errors. Excessive traffic, from a wide range of IP addresses, could be a sign of a DDoS, Roth added.
Traffic such as this could signal bot activity that is searching for ways to inject traffic into a database, as well as spam forums or comments. In addition, scan the logs for odd user-agent strings, as this could be another sign of probing, especially if those strings occur at the same time as the traffic spike from a wide range of IP addresses.
“It is useful to scan for strange URLs that are getting 200s,” Roth explained, adding that the code for successful request could be a sign of a successful attack or compromise if the URL earning the 200 code is unknown or unexpected.
Depending of your firewall rules, Roth’s list of items can also detail internal attacks that come from Malware, and if you monitor for policy violations, you can catch rogue employees. Still, log management isn’t easy. So we asked Roth, what are the top things that should be logged?
He recommends Network Device logs and Flow Data - like Cisco equipment, key server logs in Syslog format, with authentication data as well (for policy monitoring and compliance), database access logs, and server/ftp logs.
Lastly, when it comes to preserving the logs, an important part in the auditing process, Roth said to first, make sure you have enough storage. After that, use compression, going so far as to ask if your vendor can do at least 10:1 compression.
Also useful is the ability to assign the data a checksum, “…something like MD5 hash tags that show that the data has not been changed. This is useful if your data is ever used in the ‘Discovery’ portion of a legal trial,” he added.
There are some notable vendors in the log management space. ArcSight, GFI, LogLogic, LogRythm, Nitro Security, and Trustwave are just a few. It’s worth the effort to test their solutions to see if they would fit in your environment.
Roger A. Grimes, a reporter for InfoWorld, recently published a review of the aforementioned log management and compliance vendors. It’s an informative read. Check it out here.
Comment on this Story