« November 2006 | Main | January 2007 »
Wishing You A Year of Log Bliss...
Best wishes from all the loggies for a brilliant holiday season and a 2007 full of log bliss!
We're thankful for another year of record growth made possible by the incredible support and insight of hundreds of customers and the LogLogic community.
Posted December 21, 2006 in Blinks | Permalink | TrackBack (0)
« November 2006 | Main | January 2007 »
Anton's Security Tip of the Day #6: The Other Web Log
We all know that Apache web server has its access_log log files while IIS has its w3c logs. When people think about web log analysis, they think about the above and only about the above logs, often calling them "the web server logs." However, the other web log - error_log (in case of Apache) - contains a lot of fun and useful info as well.
Today's tip is to encourage the review and analysis of this treasure trough - pardon the idiom - of insight.
So, what goes into the error_log? Well, errors, duh! Why errors matter? 'Cause errors often present the only indication that a) you are being 0wned or, worse, that b) you've been 0wned by the attackers.
Additionally, apart from the obvious security usage mentioned above, errors matter since they - or rather, some of them - require actions by the user and thus knowing about them is of huge importance. What is even more striking is that many error messages present an interesting tradeoff - do only a little now to correct the reasons (or, "the root cause" as network management people would say) for the error, or do a whole lot later when the system crashes, gets hacked or "misbehaves" in some other truly spectacular way. Now, a grizzled BOFH would surely say "heh, but who would want to do that! surely, dealing with a dramatic world-ending catastrophe later is more fun that making a minor config fix now."
Now, back to the Apache errors; we are going to show a few examples from a live phishing site, run by the attackers on a compromised server. We will start from the obvious - server restart, which actually happened as a result of an attack, in our case.
[Sun Mar 12 04:02:05 2006] [notice] SIGHUP received. Attempting to restart
Did YOU restart the server? No? Two choices then - someone else did (likely without permission!) or the server got restarted automatically for whatever strange reason. You certainly need to be at least somewhat concerned in both cases - thus: look for the above messages.
Here are a few more fun examples - the relevance of those for your business is left as an exercise for the readers, but all of the messages below:
[Mon Mar 13 14:54:11 2006] [error] [client 10.10.10.10] Premature end of script headers: index.htm
Does "index.htm" sound like a script to you? It sure should not; and this error message indicates that somebody is trying to run it as a script - a clear indication of malicious behavior. The next message is also similar in this regard:
[Mon Mar 13 14:54:26 2006] [error] [client 10.10.10.10] attempt to invoke directory as script: /var/www/cgi-bin/tcpsupport/
and so is this one:
[Mon Mar 13 14:54:23 2006] [error] [client 10.10.10.10] (8)Exec format error: exec of '/var/www/cgi-bin/tcpsupport/main.htm' failed
Other interesting things spotted on the same server -this one looks like an overflow attack attempt (and, no, the NIDS did not make a squeak about it)
[Thu Mar 19 07:16:11 2006] [error] [client 10.10.10.10] request failed: URI too long (longer than 8190)
So, to conclude, the tips is: when doing web server log analysis, make sure you look at the error logs as well as the access logs.
- Anton
Posted December 15, 2006 in LogEd , LogMatters , Security | Permalink | TrackBack (0)
« November 2006 | Main | January 2007 »
User Activity Monitoring. It All Starts With A Log
User activity monitoring starts with effective logging. Logs provide the fingerprint of a users activity across the network. InformationWeek illustrates this well.
Managers must not only monitor system access, but also let employees know their system changes can be tracked. Employers should be wary of people unwilling to share their knowledge about systems or uncomfortable with the fact that their activities accessing systems or data can be tracked.
Mike picks-up on this over at Security Insights (subscribe to his daily email - worth the read):
But that's far from the only place insiders can cause damage. It ain't easy, but there are a couple of tips to help deter the behavior and then detect it. First is logging. You should be logging all administrative changes. Duh! But here's the nuance. Store the logs somewhere else and do not provide access to the administrators. Thus, they can't tamper with the logs to cover their tracks. They'll need to think twice before setting backdoors and the like.
Both Mike and InformationWeek get at one of the key tenets of an effective LMI solution - chain of custody. Even administrators shouldn't have access to your set of immutable log data. And you also want controls over some reports and alerts. All this can be managed very easily with the right solution.
You LMI policies should also incorporate two other elements. Who is "watching the watchers" (often IT Audit takes on this role in larger enterprises) and, who is auditing the policy - do you, for instance, have automated reports and alerts as to the status of logging?
Posted December 14, 2006 in Compliance | Permalink | TrackBack (0)
« November 2006 | Main | January 2007 »
Visa PCI Fines On The Rise...
From Visa... Fines for PCI Compliance and Data Storage Visa's PCI CAP will build on the company's current enforcement efforts, which include acquirer fines for data compromises involving merchants of any size. Fines are also assessed on acquirers that have failed to confirm that full track data is not retained or that did not provide a PCI compliance plan for their Level 1 merchants by September 30, 2006. In 2006, Visa levied $4.6 million in fines, up from a 2005 total of $3.4 million.
This new program sets an enforcement date for acquirers to validate PCI compliance for Level 1 and Level 2 merchants. Additionally, Visa is adding new fines to acquirers whose Level 2 merchant customers retain full-track data, CVV2 or PIN data after the transaction authorization.
Specifically for PCI compliance, acquirers will be fined between $5,000 and $25,000 a month for each of its Level 1 and 2 merchants who have not validated by September 30, 2007 and December 31, 2007 respectively. For prohibited data storage, acquirers failing to provide confirmation that their Level 1 and 2 merchants are not storing full track data, CVV2 or PIN data by March 31, 2007 will be eligible for fines up to $10,000 a month per merchant, subject to escalation in the event material progress toward compliance is not made in a timely manner.
Posted December 14, 2006 in LogMatters | Permalink | TrackBack (0)
« November 2006 | Main | January 2007 »
See Log Management Services Live!
Verisign have put together a cool video showing off their LogLogic-powered Log management service. Its worth a look.
One of the cool things about Verisign's service is the ability to capture 100% of your log data for long term retention, forensics, and reporting. That's all made possible by our services oriented and distributed architecture.
Another key feature is LogLogic's Universal Log Processing which enables 100% of log data to be collected and indexed (think "Google-like") from syslog and non-syslog sources.
Unlike expensive and limited software-based log tools, this scaleable approach gives you the flexibility to engage your MSS throughout the entire "Log Lifecycle" and can be managed on or off-site. No need to configure complex log tools - its all done for you out of the box.
Posted December 07, 2006 in Security | Permalink | TrackBack (0)
« November 2006 | Main | January 2007 »
Telco Rings Up Log Management and Intelligence Platform
Recently a large telecommunications carrier came to us because their extenal auditors required log management as part of their Sabanes-Oxley compliance strategy. The auditors, of course, created an urgency to get the telco to meet a business goal and report data that is readily accessible through log files. Compliance was central in creating the demand for LMI, but it didn't take long for other departments to support the project and extend log management across the enterprise -- something a product just can't do.
As we began rolling out LMI, the problem management department stepped forward. They had been looking to improve on log-based root-cause analysis for years. Historically, wehen they encountered a performance problem in the corporate network that could not be explained by the initial systems management alert alone, they were performing a manual search to find relevant log data -- and taking days to find an answer. Automating the process with log management and intelligence sped up this process with a simple log search and through agile, ad-hoc reporting with a single mouse-click.
Next, the help-desk group stepped up. They were seeking to integrate log data directly into their trouble-ticketing system. Now, a second-phase implementation was born. Now, when an operator opens up a trouble-ticket it includes a link that can retrieve the most recent log messages generated by the failing system and cross-correlate that with other log messages for the same IP address or user. This integration was easily achieved using open log services based on web-services standards.
This customer is just one of many LogLogic customers that point to a single need for log management, but quickly realize that a LMI platform addresses multiple needs across their enterprise. A point product can't begin to deliver the same level of support, or recoup the same ROI. Time and time again we see our customers validating LMI's role in supporting a multiple stakeholders simultaneously. Only an open, services-oriented architecture is able to achieve the ease-of-integration and multiple views into log data without incurring exorbitant professional services costs.
What is your organization dialing up in the new year to solve complex IT?
Posted December 05, 2006 in Compliance , Log Management & Intelligence , Risk Management | Permalink | TrackBack (0)
« November 2006 | Main | January 2007 »
Descending Into Log Policy Hell
Different countries have very different approaches to Log Management. Across Europe policies vary widely as some specify log destruction within short timeframes while others mandate long-term storage. These same pieces of country legislation often conflict with global industry mandates such as PCI and SOX.
Anton points to the latest out of Germany where "The highest appeal court in Germany has decided that T-Online, one of the largest German ISPs has to delete all IP logs to guarantee the privacy of their customers."
"The decision (German) does not mean that T-Online is now obliged to delete all their IP-logs, the customers first need to complain. "
Anton highlights how bizarre this is: "So, lemme understand, the logic is "surf to an illegal website -> complain to an ISP -> have the proof of that removed."
The decision ends with: "After the district court and the regional court, now the federal appeal court decided that T-Online has no right to store the IP-logs without a legal reason."
Enterprises are increasingly subject to multiple compliance mandates and industry regulations. Not all are in sync and as this highlights, not all are particularly logical. What is certain is that navigating log policy is going to increasingly become a nightmare for global enterprises without automated log management and intelligence.
Posted December 05, 2006 in LogMatters | Permalink | TrackBack (0)
« November 2006 | Main | January 2007 »
Lies, Damn Lies & Log Messages Per Second
As more SIEM vendors make their first forays into log management, price/performance claims are muddying reality - and more importantly miss what customers care about altogether.
First lets set the record straight, vendor to vendor. Whether it's 75,000 messages per second (MPS) or more, you're not talking leadership, you're talking entry point. We're proven by independent analysts and customers at sustained rates exceeding that so we'll leave it at that. What ultimately matters is not MPS but time-to-information. If you're working an incident, troubleshooting a datacenter or working an audit you care less about MPS and more about time to critical data, reports and insight. LogLogic is the only vendor to combine Agile Reporting (much broader than SIEM) with Google-like indexing and search. (Watch for more on this topic over the next day).
Second, price. SIEM's have a reputation for being expensive. Their proprietary logging appliances appear to be priced from the same playbook. In the case of the most recent, starting at $75,000 (and that excludes the proprietary SIEM you'll need to also purchase for reporting) you are looking at unvalidated performance at about 30% more than more feature-rich Log Management solutions.
And what do proprietary LMI solutions do - they lock you in to proprietary SIEM. Through our Open Log Services, we are able to open the log data - and intelligence, to be easily shared with other applications, including SIEM. And, our Services Oriented Architecture enables new applications to be easily developed and reused. LogLogic's Open Log Services have been developed based on the principles of SOA and conforms to all major standards (Java, SOAP, XML, PERL, PHP and .NET). We have the complete details here.
What newcomers to the log management and intelligence market really mean is more market validation. Spurious claims aside, they are recognizing what we saw four years ago - a distinct and growing customer requirement. But we also hope to hear more about openness and support for all customers in this vastly growing space and hopeful that we are not seeing another extension of SIEM that will promote yet another vendor lock-in strategy, a strategy to trap them into yet another high-priced solution. And a vision that goes beyond SIEM. The vision we see -solutions for IT performance, compliance and information asset protection - all architected for the Enterprise to an SOA - is very different to one rooted in a SIEM legacy.
Posted December 04, 2006 in Log Management & Intelligence , Security | Permalink | TrackBack (0)
November 2007
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 |
Categories
Archives
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005