Archive

100 Log Management Uses #27 Printer logs

Back from my vacation and back to logs and log use cases! Here is a fairly obvious one — using logs to manage printers. IN this video, we look at the various events generated on Windows and what you can do with them.

-Ananth

Logs and forensics, a lesson in compliance and more

How logs support data forensics investigations

Novak and his team have been involved in hundreds of investigations employing data forensics.  He says log data is a vital resource in discovering the existence, extent and source of any security breach.  “Computer logs are central and pivotal components to any forensic investigation,” according to Novak.  “They are a ‘fingerprint’ that provides a record of computer and system activities that may demonstrate a data leak or security breach.”  The incriminating activities might include failed login attempts, user and system access, file uploads/downloads, database access or manipulation, access privilege modification, application system transactions, transmission of email messages or attachments, and many other common activities.

In many cases, when logs are setup and configured properly, they can tell the story of the tactics a hacker used during a breach.  They can give insight as to how advanced (or not) the hacker is, and provide an understanding of the extent of a breach by showing how long a hacker was inside the confines of the firewall.  “You can see if the unauthorized person has been in your system for five minutes or five months,” explains Novak.

Given the security insight that logs can provide, it’s no surprise that data protection regulations such as the Payment Card Industry Data Security Standard (PCI DSS), the Federal Rules of Civil Procedure (FRCP),  the Sarbanes-Oxley Act (SOX), and the Health Insurance Portability and Accountability Act (HIPAA) all mandate the requirement for logs and log management.  The information captured by logs can be used to help protect sensitive data and to support incident response and forensic analysis in the event of a suspected data breach.

Often it’s these regulations that are driving organizations to become better at log management and event correlation.  In Novak’s experience, however, many organizations do need to improve in their log monitoring and management practices.  “It’s not uncommon to find that companies collect the logs but don’t review them as closely as they should,” says Novak.  “The monitoring of logs in many instances is hampered due to the extensive amounts of good data being captured and the lack of means to properly manage or analyze that data.  As a result, if there is a breach or questionable activity, it may take weeks or months to actually detect it – if it’s detected at all.”  Novak says the lack of logs or log management can increase the cost and length of an investigation substantially.

The dimension of data correlation is critically important in the support of a forensic investigation.  Correlating data from multiple sources provides the means to substantiate other evidence sources, and logs are a good way to do that.  “We use logs to corroborate what is seen in a forensic image or, vice versa, what we see in a forensic image to what we see in logs,” says Novak.

In investigations, it’s common to use logs to play off one another to validate each other.  For example, an environment has firewall, intrusion detection system (IDS), system and application logs.  If they are properly configured, an investigator can go through all the logs and “show” that a hacker got into the network or application at a specific time.  If all the logs aren’t in agreement about the illicit activity, this could be an indication the hacker manipulated one or more of the logs to make it difficult to follow his actions.  By correlating the log data, it’s possible to determine this manipulation.

Log data should be viewed and treated like a primary evidence source.  Hopefully it will never be needed to investigate or validate a data breach or hacking incident.  In any event, here are some best practices that can help ensure that log data and log management practices properly support forensic investigations.

  • Have a clear corporate policy for managing logs across the entire organization.
  • Have centralized storage and retention of all logs, with everything in one place and in one format.
  • Ensure the time synchronization of logs to facilitate correlating the data and retrieving data over specific timeframes.
  • Ensure the separation of duties over logs and log management systems to protect from potential internal threats such as a super user or administrator turning off or modifying logs to conceal illicit activity.
  • Always maintain backup copies of logs.
  • Document what is being logged and why, and how the log data is captured, stored and analyzed.  Ensure that 100 percent of log-able devices and applications are captured and the data is unfiltered.
  • Have a defined retention policy that specifies the retention period across the organization for all log data.  Organizations should work with counsel to determine the best time frames and have log data incorporated into an overall data retention policy.
  • Have a defined procedure to follow after an incident.
  • Test the incident response plan, including the retrieval of backup log data from off-site storage.

If an incident or data breach is suspected, there are several steps to take right away:

  • Increase the logging capability to the maximum and consider adding a network sniffer to capture additional detail from network traffic.  In an incident, it’s better to have more data rather than less.
  • Freeze the rotation or destruction of existing logs to prevent the loss of potential evidence.
  • Get backup copies of the logs and make sure they are secure.
  • Deploy a qualified investigations team to determine the situation.

With the right care and feeding, data logs can provide solid forensic evidence in the event of a security breach or data loss.  Analyzing the logs may not make for an exciting TV drama, but it can be rewarding nonetheless.

Brian Musthaler, CISA – is a Principal Consultant with Essential Solutions Corp. A former audit and information systems manager, he directs the firm’s evaluations and analysis of enterprise applications, with a particular interest in security and compliance tools.

Industry News

Conficker worm arms itself to steal and spam
The Conficker/Downadup worm is on the move again. After a relatively uneventful April 1, on which the worm began widening the number of Web sites that it scanned for instructions, a new Conficker variant has emerged and appears to be preparing to spam and steal information.

 Did you know? EventTracker is the only SIEM solution that comes integrated with a powerful change and configuration monitoring solution that detects zero-day attacks and helps prevent costly damage from new, emerging threats.

A lesson in compliance from the chemical industry
Events occurring in the U.S. chemical-manufacturing industry, specifically those relating to security guidelines being enforced by the federal government, are likely foreshadowing what’s next in line for other industries.

 Did you know? EventTracker provides support for the broadest set of compliance requirements among SIEM/Log Management vendors. Customizable reports and active defense in depth ensure that companies are able to comply with constantly evolving and new regulations.

In poor economy, more IT pros could turn to e-crime
In an annual security survey, Sixty-six percent of respondents felt that out-of-work IT workers would be tempted to join the criminal underground, driven in part by threats to bonuses, job losses, and worthless stock options

Did you know?  EventTracker detects in real-time suspicious activity that often precedes a security breach, and enables instant remediation before costly data theft occurs.

Some thoughts on SAAS

A few months ago I wrote some thoughts on cloud security and compliance.The other day I came across this interesting article in Network World about SaaS security and it got me thinking on the subject again. The Burton analyst quoted, Eric Maiwald, made some interesting and salient points about the challenges of SaaS security but he stopped short of explicitly addressing compliance issues. If you have a SaaS service and you are subject to any one of the myriad compliance regulations how will you demonstrate compliance if the SaaS app is processing critical data subject to the standard? And is the vendor passing a SAS-70 audit going to satisfy your auditors and free you of any compliance requirement?

Mr. Maiwald makes a valid point that you have to take care in thinking through the security requirements and put it in the contract with the SaaS vendor. The same can also be held true for any compliance requirement, but he raises an even more critical point where he states that SaaS vendors want to offer a one size fits all offering (rightly so, or else I would put forward we would see a lot of belly-up SaaS vendors). My question then becomes how can an SME that is generally subject to compliance mandates but lacks the purchasing power to negotiate a cost effective agreement with a SaaS vendor take advantage of the benefits such services provide? Are we looking at one of these chicken and egg situations where the SaaS vendors don’t see the demand because the very customers they would serve are unable to use their service without this enabling technology? At the very least I would think that SaaS vendors would benefit from putting in the same audit capability that the other enterprise application vendors are, and making that available (maybe for a small additional fee) to their customers. Perhaps it could be as simple as user and admin activity auditing, but it seems to me a no brainer – if a prospect is going to let critical data and services go outside their control they are going to want the same visibility as they had when it resided internally, or else it becomes a non-starter until the price is driven so far down that reward trumps risk. Considering we will likely see more regulation, not less, in the future that price may well be pretty close to zero.

– Steve Lafferty

Log Monitoring – real time or bust?

As a vendor of a log management solution, we come across prospects with a variety of requirements — consistent with a variety of needs and views of approaching problems.

Recently, one prospect was very insistent on “real-time” processing. This is perfectly reasonable but as with anything, when taken to an extreme, can be meaningless. In this instance, the “typical” use case (indeed the defining one) for the log management implementation was “a virus is making its way across the enterprise; I don’t have time to search or refine or indeed any user (slow) action; I need instant notification and ability to sort data on a variety of indexes instantly”.

As vendors we are conditioned to think “the customer is always right” but I wonder if the requirement is reasonable or even possible. Given specifics of a scenario, I am sure many vendors can meet the requirement — but in general? Not knowing which OS, which attack pattern, how logs are generated/transmitted?

I was reminded again by this blog by Bejtlich in which he explains that “If you only rely on your security products to produce alerts of any type, or blocks of any type, you will consistently be “protected” from only the most basic threats.”

While real-time processing of logs is a perfectly reasonable requirement, retrospective security analysis is the only way to get a clue as to attack patterns and therefore a defense.

 Ananth

100 Log Management uses #26 MS debug logs-Part II

Today is a continuation of our earlier look at Microsoft debug logs. Today we are going to look at logs from the Time and Task Scheduler services.

-By Ananth