« April 2007 | Main | June 2007 »
G2000 Logjam Continues To Spur Log Management Says SANS Survey
We teamed up with the SANS Institute again this year to survey the G2000 on the trends driving log management and intelligence. You can dowload a copy of the preliminary findings of the 2007 Log Management Survey or sign up to attend a webcast presentation of the results with SANS on June 6th.
Based on last year's findings SANS Institute CEO Stephen Northcutt said:
"In our analysis, we found that G2000 IT leaders are today not only validating the use case for log intelligence, but are signaling the increased need for the market to evolve even further with log services that cost-effectively allow them to exchange information with other solutions."
The 2007 survey saw that trend continue to evolve. Polling more than 650 IT professionals in government, financial services, banking, manufacturing, healthcare, telecommunications, and education sectors from the North American Global 2000 (G2000) - Forbes's comprehensive list of the world's biggest companies, key findings:
· Log data monitoring continues to grow exponentially. Of those surveyed over 61% report using log data to assess IT incidents and minimize downtime (an increase of 24% over 2006 survey results).
· Log data retention is up significantly, but most of the G200 and G2000 are still failing to meet compliance regulations. Despite regulatory recommendations or requirements that logs be maintained for three to five years, 11% say they keep log files between 30 and 90 days, 10% retain data for six months and 5% less than 30 days. Remarkably, a full 14% say are not sure how long they keep log data, relying on the system default as defined by their operating system.
· Security while important is not the prime motivation for log management. More than half of those surveyed reported operations management and monitoring the health of the network as the prime motivation for using log data. 43% indicated compliance with SOX, PCI and other mandates as the top priority.
· The quantity of stored log data is rising. 57% percent of survey respondents store logs from as many as 500 sources.
To receive a preview copy of the 2007 Log Management Survey, sign up here. To attend the webcast, sign up at the SANS Institute.
Posted May 31, 2007 in Compliance , Log Management & Intelligence , Security | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Logging Glossary: Log Rotation
As I mentioned here, I started publishing the LogLogic Logging Glossary. So, here is the sixth term (first second third fourth fifth):
Log Rotation
A log management process where logs are moved, renamed, or over written for system resource management and archival.
Rotation is usually based on time or size. Rotation usually includes some form of log identification. Log identification may take a number of forms, all intended to represent the current log, next current log, and so on up to some number of logs. When reaching a limit to the number of logs, the oldest log is removed before the current log is created.
Posted May 31, 2007 in | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Webcast Today - SIEM Shifts to Log Management
LogLogic roundtable discussion on log management and intelligence is today. The panel will discuss the shift in the Security Information and Event Management (SIEM) paradigm as it moves toward log management. Topics covered in the panel include how leading enterprises use log management, when they use it, and some pragmatic approaches to deploying it enterprise wide and across different geographies.
Who: Dr. Anton Chuvakin, Director of Product Management LogLogic
Mike Rothman, President and Principal Analyst, SecurityIncite,
and author of The Pragmatic CSO
What: Online webinar roundtable discussing log management trends and
best practices.
When: May 31, 2007, 2 PM ET / 11 AM PT
Registration: www.loglogic.com
Posted May 31, 2007 in Log Management & Intelligence , Security | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Anton Logging Tip of the Day #10: Email Tracking Through Logs
Following the new tradition of posting a tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along. One of the bloggers called it "pay it forward" to the community.
So, Anton Logging Tip of the Day #10: Email Tracking Through Logs
Email tracking - oh, need I say more? :-) A nightmare for privacy fans - an "evil" weapon of lawyers and HR. Email tracking raises concerns that vary from a severe inability to do it all the way to having too much ability to do it. In this tip, we will focus on the following scenario: your boss says she just sent you an email; you never received it. What's the story?
First we need to search our Sendmail server logs (this is that case where searching logs is appropriate) for the email address of the sender (unfortunately, we rarely can search the logs of the remote mail server which sent - or didn't send! - the message in question). One thing to note before we start searching is to limit the time frame to the one close to the reported problem (let's say to the same day).
So, we search for messages containing from=boss@examples.com (since we want the sender address) at January 11 (if you just search for boss@examples.com, the volume of unrelated results will be much higher) and find something like this:
Jan 11 11:45:49 ns1 sendmail[28022]: j0BGjkc28022: from=boss@example.com, size=376597, class=0, nrcpts=1, msgid=Pine.LNX.4.61.0501111145450.17081@boss.example.com, proto=SMTP, daemon=MTA, relay=esafe1.example.com[10.211.15.69] (may be forged)
Is this our message (we are not quite sure since we don't see a recipient)? Why isn't it here?! What do we do next? Well, this is where things get a little ugly (for those unfamiliar with Sendmail logs).
Next, we need to search the logs for this "mysterious" string "j0BGjkc28022" from the previous log record and find this:
Jan 11 11:46:00 ns1 sendmail[28025]: j0BGjkc28022: to=employee@example.com, delay=00:00:14, xdelay=00:00:11, mailer=local, pri=405901, dsn=2.0.0, stat=Sent
So, it looks like our mail server have indeed sent the message, but what happened to it afterwards? Where did it go next? Given that "employee" has a mail account on the example.com system, most likely the message went into his mail spool (something like /var/spool/mail folder)
Next? If the employee uses local shell access to a mail server and Pine or other similar mail client to read mail (really unlikely, but possible - mostly at University systems), we need to see whether it exists in user's local mail folders, such his /home/username/Mail folder or something similar.
But what if the employee uses POP3 or IMAP to read mail? In this case, we have more logs to go through ... However, most POP3 server logs will not help us determine the fate of a specific message, but just to confirm that the user checked and/or downloaded mail. We will leave POP3 log fun for the next tip...
So, in today's basic tip we covered one simple scenario of email tracking through logs.
Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.
Posted May 30, 2007 in | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
The Cost of Reputation In Light of a Security Breach
Over the past few months we've talked alot about TJX and their now-infamous security breach. In fact, a few days ago, InformationWeek reported that TJX Companies, Inc. (the parent company of T.J. Maxx and Marshalls, among retailers) continues to be hit hard by their breach -- which is now being known as the largest customer data breach in history.
Posted May 29, 2007 in Compliance , Risk Management , Security | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Logging Glossary: Log External Reference
As I mentioned here, I started publishing the LogLogic Logging Glossary. So, here is the fifth term (first second third fourth):
Log External Reference
A log or message that requires information not contained in the log to understand the description, fields, values, or format.
The best example is all this stuff in Windows Event logs that requires some funky DLLs to map from numbers to strings.
Posted May 24, 2007 in | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
LogLogic 4 Earns Approved for SCLabs Rating from SCMagazine's Las
We have received the distinction of Approved for SCLabs Rating from SCMagazine for LogLogic 4.Second year in a row. How cool is that? The verdict?
The LogLogic LX release 4.0 is a top-flight product and we continue to award it our Approved for SC Labs rating, the highest rating that we award. Over the coming year it will continue to be our log analysis workhorse
Some highlights from the review. Peter Stephenson writes,
"I have used the LX/ST combination for research that involves large log sets and, while I like the product a lot, I have to admit that there have been a few limitations. One of those limitations is the types of logs that it can handle. The other is the way it has handled raw log content. Both of these limitations have been rendered obsolete in release 4.0. ""Implementation is quick and easy. Although users will not need to reinstall the entire system (the new release comes as an upgrade), we opted to do a fresh install. We installed on our legacy (release 3.X) appliance and the entire installation took under a half hour. The results were flawless."
Read the whole thing here.
Posted May 21, 2007 in Compliance , Log Management & Intelligence | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Logging Glossary: Event
As I mentioned here, I started publishing the LogLogic Logging Glossary. So, here is the fourth term (first second third):
Event
Why define an event? Isn't it kinda obvious? Well, with time even this term did grow a bit fuzzy in log management circles... so a quick trip to dictionary.com gives us:
1. Something that happens or is regarded as happening; an occurrence, especially one of some importance.
2. The outcome, issue, or result of anything.
A common confusion is in calling a single Windows Event Log entry an "event."
Posted May 21, 2007 in | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Logging Glossary: Context Information
As I mentioned here, I started publishing the LogLogic Logging Glossary. So, here is the third term (first second):
Log Context Information
The circumstances and conditions which surround a logged event.
It is usually the log time, system the event occurred on, the system that has the log, or some combination. It may contain any set of information the vendor considers relevant. It is usually written at the beginning of a log file or the beginning of a log message.
Context information is most often applied by a system logging API or a log forwarder.
Posted May 18, 2007 in | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Managing Incidents in Age of Compliance
In this ComputerWorld guest column, LogLogic's Anton Chuvakin outlines the basics of incident response and relates them to three major compliance regulations -- FISMA, HIPAA, and PCI DSS -- that directly affect the specifics of setting up incident response capabilities.
" . . . being prepared for incidents via an incident response plan is likely to be one of the most cost-effective security measures an organization takes. Timely and effective incident response is directly responsible for decreasing the incident-induced losses. It can also help to prevent expensive and hard-to-repair reputation damage, which often occurs following a publicly disclosed security incident."
Compliance, too, is one area that Chuvakin points out has repeatable IR capabilities due to some predictability:
" . . . recent government regulations and standards put forth by industry groups have explicitly highlighted the importance of having a repeatable incident response plan to guarantee security of key data; they even mandate specific details on how incident response should be performed. Thus, some aspects of IR planning and procedures have, as a direct result of these regulations, moved from the "should" category to the "must" category. . . "
Posted May 17, 2007 in Compliance , Risk Management , Security | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Innovation Stems SOX Costs
Posted May 16, 2007 in Compliance | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Logging Glossary: Audit Logging
As I mentioned here, I plan to start publishing the LogLogic Logging Glossary. So, here is the second term (first):
Term 2: Audit Logging
Structured logging intended to capture detailed event and activity information in a form suitable for analysis and reporting.
Audit logging is often inserted into a product rather than integrated or developed with the product. The product may have ‘hooks’ that enable auditing. This 'external' monitoring can have differences in semantics and data associations than found for the same event recorded through normal logging. It's logging methods, management, and log construction can be closely tied to performance and the tools used to report and analyze the logs.
See System Audit Logging and User Audit Logging.
Posted May 16, 2007 in | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Keep Those Logs. But Keep Them Right...
One of the important lessons from the AOL log saga was secure your logs (and think twice before letting them out of the building).
Another thing it highlighted was the value of logs outside of the security context - that doesn't mean they aren't really important to security and Information Asset Protection. In fact, Google has been quick to highlight the security value of logs:
"Immediate deletion of IP addresses from our logs would make our systems more vulnerable to security attacks, putting the personal data of our users at greater risk. Historical logs information can also be a useful tool to help us detect and prevent phishing, scripting attacks, and spam, including query click spam and ads click spam," says Fleischer.
Nate Anderson has a great piece on why Google retains log data. Retention laws around the planet differ by country and regulation. Nate makes a good point:
Two months ago, Google announced a plan to anonymize its logs, but only after retaining the data for 18 to 24 months. After that time, user searches will still be stored, but it should be impossible to link search queries up with individual users. Of course, this is what AOL researchers thought when they released their own search logs, but queries often turn out to be highly specific things... the sort of things that can eventually be used to identify individuals.
Fisher also points out that one of the emerging European laws is, well, emerging - complicating things:
"Since these laws do not yet exist, and are only now being proposed and debated," Fleischer says, "it is too early to know the final retention time periods, the jurisdictional impact, and the scope of applicability. It's therefore too early to state whether such laws would apply to particular Google services, and if so, which ones." Even though the laws are not yet in force in Europe and won't apply retroactively, Google still uses the law as an argument to retain data now, and to do so for the longest possible period the law provides for.
One of the challenges is that privacy, telecommunication and labor law differs greatly from one country to another around the world. For instance, in France, log Data can be retained for up to 6 months in the maximum (the penalty is up to 5 years of imprisonment term and a 300,000 euros fine) while in Germany it is recommended that log data should be deleted as soon as it is no longer needed for fulfilling the purpose for which it was are stored - this should typically not exceed 2-3 months.
Compliance mandates also vary in either direct or implied retention requirements:
This is where automating storage, chain of custody and securing of log data can ease much of the pain. Through a log data warehouse regional and regulatory requirements can easily be reconciled and managed. So whether the Government may or not require it today, or, regulations related to your business probably do require it - collecting and storing log data makes good commercial sense and shouldn't be either a pain or a risk.
Posted May 16, 2007 in Compliance | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
PCI Takes A Twist
Computerworld reports that the State of Texas is mulling a bill that would make PCI requirements law - and that retailers that accept credit cards would be financially liable for data breach costs.
The state's House of Representatives last week voted 139-0 in favor of a bill that would formally codify PCI requirements into a state law that merchants would be obliged to comply with if passed. Under HB 3222 a breached entity will have to reimburse banks and credit unions the cost associated with blocking and reissuing cards if the merchant was not PCI compliant at the time of the compromise. It also provides a safe harbor against such liability for companies who are PCI compliant and get breached. The proposal needs to win approval in the state Senate before it becomes law.
Texas is not the only state eyeing such a bill. In Massachusetts, legislation proposed earlier this year by state Rep. Michael Costello would hold retailers financially liable to banks for the costs of a credit card security breach.
Gartner's Avivah Litan comes out swinging though suggesting that banks are shifting too much liability to the merchants. "In every single instance, the retailer already has to pay for the direct costs of the fraud. And now banks are trying to shift the customer service costs to the retailer as well," she said. "Retailers are being pinned against the wall, frankly," Litan said. "If laws like this take affect, it could have serious consequences on a retailer's balance sheets."
While that might be the case the reality is that the retailer (after the consumer) has the most loose - especially reputationally. What shouldn't be confused is the cost of doing business versus the cost of implementing industry mandates. Effective protection of customer data should be viewed as a cost of doing business. PCI is forcing an entire industry to step-up to that responsibility.
I speak to plenty of retailers. Many are already there. Some of them have very small and resourceful IT departments who have automated many of the processes, reports, sampling and alerts that surround PCI. What always amazes me is the number of retailers, some large, that still lack by even basic standards, strong security processes. Who should bear their costs - the banks, or ultimately the consumer? We're here to help.
Posted May 16, 2007 in Compliance | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Logging Glossary: Alert
As I mentioned here, I plan to start publishing the LogLogic Logging Glossary. So, here is the first term:
Alert
A message designed to raise awareness of a particular event or condition.
An alert may be recorded in a system log outside the product normal logging behavior. It may be sent to another system or displayed on a system console for immediate attention, or to communicate to another system that a monitored event has occurred. An alert may be the normal message generated by the product, or it may a message designed to carry additional information not present in the log message. Alerts may have no detail content, intended only for notification that the event occurred.
Posted May 14, 2007 in | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Log In at the Za Za in Dallas
Join LogLogic and Accuvant at the Hotel Za Za in Dallas May 24th for a seminar, as we reveal break through technology that brings new visibility to your Enterprise log data. Followed by a cocktail reception, poolside at the Urban Oasis.
Enhanced capabilities in log management such as Multi-dimensional search, universal log processing, open log services platforms, and log data warehousing are bringing power to IT departments. Make your IT department superheroes by giving them the tools to help mitigate threats to your Enterprise data and comply with mandates with ease.
May 24th, 3pm Seminar; 5-7 Cocktail Reception poolside at the Urban Oasis
Space is Limited, Please RSVP today!
Posted May 10, 2007 in Log Management & Intelligence , LogLogic News | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Log Management Trends
Some time before the recent SANS Log Management Summit in San Jose, CA, somebody asked me: What are the top three trends in the log analysis industry? I figured why not also post my answer for all to see. So, here they are (slightly edited for clarity):
- Rapid increase in the breadth of log sources that people care for (and thus collect data from): it used to be just firewall and IDS logs, then servers, and now it is expanding to all sorts of log sources - databases, applications, etc (see more information on this here)
- This might sound boring, but it is still a major trend: more regulations, governance frameworks and standards will cover logs and logging. Just look at recent PCI, NIST 800-92 and a few others (including my very favorite - CEE where work is just starting up)
- There is also a trend towards auditing more access and more activity through logs; for example, few of the file server, storage or database vendors cared much about logging, but now they do (well, some do and some start to :-)). What used to be just about "access to information" is now evolving into "auditable access info." More discussion of this is here.
Got comments?
Posted May 06, 2007 in | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
SANS Log Management Summit WrapUp & Conference Materials
The SANS Institute has posted the presentations from the 2007 Log Management Summit held in San Jose, CA last month. The complete set of presentations is available as a downlead (zip file) here.
A number of bloggers attended the event and they have had some nice writeups of the event. Blog Infosec Potpourri has a nice discussion of some sessions.
Finally LogLogic's Anton Chuvakin has a few observations on the state of the Log Management Industry ...
I noticed that logging for operational uses was much better represented and more frequently mentioned compared to last year; logging for security and compliance were certainly there in full
force, but logging for operational uses, which is the oldest, classic use for logs, seems to be making a comeback and people really buy (or build - and then suffer :-)) log management tools to deal with the challenge.
On the market side, Summit pretty much proved that there is a log management market now with its own players, requirements, use cases, etc. At the same time, buyers are much more aware of what they are actually signing up for when they call a log management vendor. Still, I saw a share of people who made really bizarre decisions in regards to their logging
...
Posted May 06, 2007 in Compliance , Log Management & Intelligence | Permalink | TrackBack (0)
« April 2007 | Main | June 2007 »
Visa's New PCI List You Don't Want To Be On
Two weeks ago Visa sent out a letter that listed a half dozen vendors whose POS products have been shown to contain stored card data in known data breaches. Digital Transactions News reports that Visa is recommending that merchants stop using these products. In fact Eduardo Perez, vice president for payment system risk and compliance at Visa, told the the news site that the while the list is not publicly available today Visa is considering "posting it on a private page on its Web site that is available to members."
While he says vendors on the list were contacted before the letter went out from Visa, Perez went on to say that not only was:
"a patch or an upgrade that would not store prohibited card data" made available to merchants, but that the update on how to make the names solutions compliant was available in the warning letters. He said, "Obviously, they weren't happy, but in most cases they wanted [the information] out there because it gave them more ammunition as to why merchants should upgrade"
PCI Compliance is not only at the top of merchants agendas this year, but progress towards compliance is mounting as the June 2007 deadline looms. Visa reports that most large merchants have been able to prove they are not storing credit card-verification data, PIN numbers, and other encoded information typically found in magnetic stripes, which is one of the key requirements of PCI.
And in more evidence of PCI Compliance, Visa now says that 35% of Level 1 merchants, as defined by Visa as those processing 6 M or more transactions annually, are now PCI compliant. This is up from 18% a year ago. A full 51% have completed Visa's 'report on compliance' which is recognized as a step toward satisfying PCI requirements that involves a review of systems for security flaws and demonstrate a plan to fix them, often referred to by Visa as remediation.
In less than two months, the PCI DSS standard will be enforced for merchants, making fines a reality for many merchants who accept credit cards. The mandate is the requirement for monitoring and storing credit card data mapped to four levels of security based on a merchant's volume of credit card transactions.
Major breaches at global companies like TJMaxx have not only illustrated the needfor protections, but have also spurred on legislative efforts to deal with securing customer data in the US.
So how are you tracking to meet the PCI deadlines in 2007? Log management and intelligence provides some key strategies now.
Posted May 01, 2007 in Compliance , Log Management & Intelligence , Risk Management , 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