LogBlog

A Five-Star Week

We’ve been at RSA San Francisco all week talking to customers, prospects, competitors and the great unwashed. Now as we gracefully slide into the weekend to recover, as I look around the office, all I see are smiling but tired faces.

During the long dark winter months it’s often easy to lose your gleam, to start to question your place in the world. This season has been no exception. I’ve heard sales people grumble about missing features, or an occasional bug, the lack of marketing support, or just the plain fact that a prospect got a 90% discount from a competitor eager to win a deal.

And then suddenly RSA bursts onto the scene like sunlight through a storm cloud – and all is made better. This year we saw competitors literally giving cash away to win attention. We heard from customers who virtually, and in one case, physically hugged us. We spoke to IT guys that are running the competitors’ products, but now want to switch to us, having learnt the hard lesson that sometimes things are free for a reason.

We laughed at/with our CEO and CMO as they made fools of themselves in our new quirky videos. We enjoyed fine food, beer and conversation with our customers and sat humbled and amazed at their stories of how we’ve helped them out of legal, moral, and just plain sticky situations. Another nice feather for our cap: the cool new Borderless Security ecosystem from Cisco now includes us as the log management go-to people of choice.

And finally, when we thought there could be no more joy in the week, we were awarded 5 out of 5 stars for our database management product, and chosen as one of the products of the week over at NetworkWorld.

Happy Friday people. We’re going home to sleep the sleep of the victorious.

Sign up for our LogLogic Newsletter and join in the continuing fun.

Posted by Andy Morris on March 05, 2010 in LogEd | Permalink | Comments (0)

Logging Poll #8 Context for Log Analysis

So, my next poll is up - and it is fun (but more technical): what information is most useful when trying to make sense of a log entry?
Vote here! Analysis will be posted here in a few weeks.

Past polls:

  • Poll #7 "What tools do you use for Windows Event Log collection?" (analysis)
  • Poll #6 "Which logs do you LOOK at?" (analysis)
  • Poll #5 "What are your top challenges with logs?" (analysis)
  • Poll #4 "Who looks at logs in your organization?" (analysis)
  • Poll #3 "What do you do with logs?" (analysis)
  • Poll #2 "Why collect logs?" (analysis)
  • Poll #1 "Which logs do you collect?" (analysis)

     

    Technorati tags: , ,

    • Posted by on May 05, 2008 in Innovation , Log Management & Intelligence , LogEd | Permalink | Comments (0)

    Critical Log Management Questions - Answered!

    Here are some interesting log management questions I got asked some time ago; reposting here for our blog readers.

    Q1: For those companies that have successfully implemented enterprise-wide logging, what were the big nasty surprises that they encountered?

    A1: Here are a few:

    Q2: For those companies that have successfully implemented enterprise-wide logging, what was their implementation approach?

    A2: Typically, 2-3 vendor PoC or pilot first. Then with the chosen vendor: phased approach based on location + type of log source (e.g. firewalls, then routers, then OS, then proxies, etc) + network topology (e.g. DMZ, then internal) + log source criticality (e.g. critical servers first; the rest next). This might be handy to look at.

    Q3: What kind of storage requirements have been experienced by those organizations who have successfully implemented enterprise-wide logging?

    A3: Massive? :-)

    Here is a simple example: PCI DSS is a bit more aggressive than NERC since it mandates 1 year of log retention vs NERC 90 days, so: 1 year worth of logs is = 365 days x 24 hours x 3600 seconds x 1 (one!!!) busy firewall with 100 log messages each second x 200 bytes per message average (e.g. valid for PIX and ASA devices) = 588 gigabytes / year of raw log data uncompressed (assuming 10x compression you'd get about 60GB of compressed log data per year)

    Store it in RDBMS? Multiple it by 2-3. Have an index? Add about 30%.

    The bottom line is: terabyte is the unit to measure logs.

    Q4: At the organizations that have successfully implemented enterprise-wide logging, how logging impacted network and system performance?

    A4: Too broad a question, so here are a few pointers:

    Q5: What were some successful strategies for obtaining buy-in from system owners and operators in regards to turning logging on?

    A5: OK, also too broad a question, but here are some pointers:

    Q6: How the organizations that have successfully implemented enterprise-wide logging dealt with unusual devices (=log sources) that have no log management vendor support?

    A6: They were in massive pain - if they choose a log management vendor wrong. You need to look for vendors that have "universal log source support" with NO requirement for a custom rules or custom collector/connector/agent development. LogLogic have generic text log collectors that can grab and analyze unknown logs. Typically this is done via some form of text indexing that works across all logs, including those from unknown, vertical, esoteric or custom-developed log sources

    Hope it was useful!

    Technorati tags: ,

    Posted by on April 24, 2008 in Compliance , Innovation , Log Management & Intelligence , LogEd | Permalink | Comments (0)

    Quick and Fun Poll on Behavior Change

    While I am analyzing my previous poll, here is a quick and fun one: do we change our behavior when monitored? Vote away!

     

    Technorati tags: , , ,

    Posted by on March 27, 2008 in Compliance , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

    Logging Poll #4 "Who Looks at Logs?" Analysis

    Time to analyze my final 2007 poll on logs. In it, I asked who actually looks at logs at the organization. Here is what came up: results are here and also included below.

     pollwholooks_thumb

    What can we conclude from this?

    First, an obvious conclusion is in order! No matter how many times one can utter the word "compliance," logs are still most useful for mundane (one would hope!) system administration. Yes, indeed, sysadmins are the primary consumers of logs - yesterday, today, and - likely! - tomorrow as well.

    Second, I am saddened by the fact that application developers have not warmed up to logs, at least not en masse (and not according to this limited poll...). I am guessing when they start thinking of logging when creating their applications, they will be more aware of the fact that you can troubleshoot the applications using logs ...

    Third, incident response team showing that low is some kind of fluke, I am sure. Everybody knows that logs are indispensable during incident response. Yes, even if only a little logging was enabled or even logging defaults left in place, logs often reveal answers unobtainable via any other mechanisms.

    Next poll coming soon!

    Technorati tags: , ,

    Posted by on January 08, 2008 in Innovation , Log Management & Intelligence , LogEd , LogLogic News | Permalink | Comments (0)

    Logging Glossary: Operational Log Message

    As I mentioned here,  I started publishing the LogLogic Logging Glossary. So, here is the twelfth term (first second third fourth fifth sixth seventh eighth ninth tenth eleventh):

    Operational Log Message

    A log message about the state of a product, the product's operation or support of its application, or the interaction of the product with its environment.

    Operational messages are one of the three basic message types. They can be summarized as:

    Example of operational messages are: backup succeeded, update applied, memory is running low, system load high, etc.

    Future Glossary entries will cover Administrative Log Messages and Operational Log Messages

    Technorati tags: , , ,

    Posted by on December 20, 2007 in Log Management & Intelligence , LogEd | Permalink | Comments (0)

    Logging Poll #3 "What Do You Do With Logs?" Analysis

    So, the results of my 3rd poll are ready: live results are here, picture is also in this post.

    poll3whatdone_thumb

    First, this poll way more popular than my previous "why" poll. It seems like people do dislike to wonder "why."

    Second, what are  the two choices, that are by far the most popular? They are:

    Yes, this is the "state of the art" of logging:   collection of raw logs and "as needed" grep aka "slow and painful" search. In fact, the above answers might not even be given by the same people: some might be grepping logs on the individual servers, while others collect them on syslog servers and never touch them. That is why being in log management business is such a great thing: you have nearly the whole world to evangelize about the value of logs and log management tools.

    Third, what's the next most popular idea of analyzing logs? It is "Run my own log analysis tool" at 10% of the respondents. Indeed, this movement still lives and thrives: people choose the Build->Suffer approach to log management often enough ...

    Fourth, next come my somewhat self-inflicted surprise: apart from commercial log management (at 4%) and rolling one's own (discussed above at 10%), I added the option of "Use other log analysis tools"   which captured 7% of the vote. But what does that mean? I have no idea!

    Fifth, I am NOT surprised by the lack of popularity of the rule-based correlation tools, such as SIEM (at 2%). When I made my decision to join LogLogic, I had to ponder this one really, really hard. My conclusion at the time (which is also valid now, even more than back in 2006) was that "SIEM is for some, log management is for everybody." This poll confirms this further.

    Finally, all my logging polls and analysis are here. Next one is coming up!

    Technorati tags: , ,

    Posted by on December 08, 2007 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

    Anton Logging Tip of the Day #13: Into the Darkness ... or The Ominous World of Unix Binary Audit Logs

    Following the new "tradition" of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative.

    So, Anton Security Tip of the Day #13: Into the Darkness ... or The Ominous World of Unix Binary Audit Logs

    In this tip, we will take a peek at one of the most esoteric areas of logging: Unix binary audit logs. Solaris BSM and Trusted Solaris auditing is the least unknown :-) example of it, even though other Unix vendors have similar auditing capabilities - see this for HP-UX Audit and this for IBM AIX audit. Linux kernel audit is also pretty much the same thing. If you look for information on 'Solaris BSM audit logs' , you'd find plenty of tips on how to enable such logging, a little on how to manage/rotate the log files, a bit on how to survive the resulting data deluge and ALMOST NOTHING on what to do with the log data, which is kinda sad :-) After looking at BSM logs for a while, I developed an opinion that nobody has ever looked at them on a regular basis :-)

    So, let's assume you enabled Solaris BSM kernel audit for user "root" and few other "interesting" users (there is no per-object logging in Solaris; other Unix variants do have it) via the following commonly recommended per-user configuration in /etc/security/audit_user:

    root:lo,ad,fw:no

    anton:all,-all:no

    jsmith:all,-all:no

    This configuration file pretty much leads to logging of everything that the above listed users do. Now, you have audit files growing like mushrooms in your /var/audit. What good does it give us?  First, we need to convert the binary audit files into text - something along the lines of

    # auditreduce -A  /var/audit/20071127193515.not_terminated.SunUltra10 | praudit -l > /tmp/sol_box_11272007

    will do. Now what? In this tip we will pick one thing to use these logs for: how use them to see who is trying to copy sensitive files off the system.

    First, who is connecting out - lets's search the logs for 'connect' calls (if you are using LogLogic for it, use Index Search for this task; if not, grep will have to do, but be prepared to wait, possibly a looooooooooooong time :-)). A few recommended searches:

    Here is an example found (with connect, IP and user in bold):

    header,103,2,connect(2),,Tue Nov 27 11:36:46 PST 2007, + 193 msec,argument,1,0x4,so,socket,0x0002,0x0002,0x80d6,SunUltra10,0x0016,10.1.1.41,subject,root,anton,other,anton,other,29902,29720,0 1611 172.16.0.173,return,success,0

    At this point we already know the user name of the user who run that connecting process since it will be in the results (you can also the user to search as I showed above).

    Next, what are those connections - let's try to uncover which programs actually connected (BSM logs don't make that easy!). Let's search for process starts in the same time frame (within a few seconds):

    Example found:

    header,124,2,execve(2),,Tue Nov 27 11:36:46 PST 2007, + 115 msec,path,/usr/bin/scp,attribute,100555,root,bin,136,1573,0,subject,root,anton,other,anton,other,29901,29720,0 1611 172.16.0.173,return,success,0

    OK, so somebody is trying to connect via SSH/SCP. Notice that both records - connect and execve -  have the same timestamp, up to a second. Sadly, time and parent process ID ( which is in our case 29720) is all that correlates them together.

    Finally, what file was affected (i.e. copied off the system via scp in this case) - more digging is in order; we again use the process ID and time. The easiest is to search for a file name or browse all records around the same time frame (might be A LOT!):

    For example:

    header,135,2,open(2) - read,,Tue Nov 27 11:36:47 PST 2007, + 900 msec,path,/tmp/not-so-secret.zip.gz,attribute,100600,anton,other,0,32743959,18446744073709551615,subject,root,anton,other,anton,other,29901,29720,0 1611 172.16.0.173,return,success,4

    What do we know now? This user connected to this system and MAYBE copied this file via, MAYBE via scp. How cool is that? (A: not cool at all, since we are not sure, but that is all we can do with such logs)

    To conclude, if you can avoid dealing with Solaris BSM logs, please do so :-) On a more serious note, you now know why these logs were called "the ugliest logs ever."  Even more seriously (but still pretty humorously), these logs are a classic example of trees that make every effort to obscure the forest, because these logs record system calls and not processes or user actions (and connect, execve and read are all logged separately). There are also many, many more idiosyncrasies where these come from :-)

    Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Tips of the Day.
    Technorati tags: , , ,

     


    Posted by on November 30, 2007 in Compliance , Log Management & Intelligence , LogEd , Security | Permalink | Comments (0)

    Poll: Which Logs Do You Collect?

    I figured I'd do a poll a week since people really like it. So, my first poll-a-week: Which Logs Do You Collect?
    Vote away! I will post and comment on results here after a few weeks.

    Technorati tags: ,

    Posted by on October 17, 2007 in Log Management & Intelligence , LogEd | Permalink | Comments (0)

    Simple Log-based User Profiling for Activity Monitoring

    Recently I've been looking into detecting stolen/shared access account credentials. Now, how can you detect that? No NIDS will trigger, NIPS will let is pass, no unusual types of log records might ever by  produced (especially if only limited logging is enabled). And what raises the stakes is that this type of activity is not  only about "hacked" accounts, but also about insider abuse of accounts.

    However, there will likely be changes in how normal log records are produced.

    Let's summarize some known methods for using a simple user "profile" to detect account theft aka account sharing aka user impersonation aka access with stolen/shared credentials. It implies that we've been collecting the logs before the incident and have a solid trail of normal users and legitimate account owners.

    1. Unusual login source IP (e.g. normal user always comes from 10.0.X.Y or 10.1.X.Y, but now we see a login from 172.16.0.Z) - will work in some cases, but not for the free-for-all servers such as at a University
    2. Unusual login time (e.g. normal user always comes from 9AM to 5PM, now we see 3AM) - will work in most cases, but will fail if the attacker happens to be in the same time zone
    3. Unusual login session length  (e.g. normal user always stays logged in for 5-20 minutes, now we see a 10 hour-long session) - works only if logout is logged; might not catch a lot of realistic but malicious connections
    4. Unusual login frequency (e.g. legitimate user logs in once a day in the morning, now we see dozens of connections) - will work for some cases, but others will be missed
    5. Unusual login failure/success ratio before a successful login (e.g. normal user always types the password right the first time, now we see failures than successes) - not too reliable, obviously
    6. Unusual list of user actions performed (normal user only reads these files, but now we see writes to a very different set of files) - will work most frequently, but needs more granular logging of file access, object changes, etc (audit logging) [more on this in the near future!]

    So, if you have logs of user activities, at the very least, logins and logouts ( but having records of more user activities is always better!),  for the last few weeks or months, one can compute the above profiles using historical data and then compare them with current numbers (very similar to some of the methods from my classic log mining presentation).

    The final missing bit is for how long to collect your normal user behaviors: I discovered that 1 week to 1 month works pretty well. Less time yields unstable results and more time necessitates much more data crunching without much gain.

    Technorati tags: ,

    Posted by on October 12, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

    Just What is Enterprise Class? Part IV

    Here is the next enlightening post from Dimitri McKay, our super-brilliant network and systems engineer from the East Coast, where he continues to discuss the meaning of the phrase "enterprise-class," which is certainly MUCH more than a marketing buzzword! Part I is here, Part II is here, Part III is here. 

    "10. Serviceability/Manageability: The scale of deployment of a LogLogic solution, whether it be managed remotely or locally, requires features which allow the solution to be managed effectively. FCAPS is an acronym which is often used to remember the following guidelines of  security log appliance management:

    Fault, Configuration, Accounting, Performance, and Security

    The users of LogLogic must be able to monitor what is happening on the system itself, as well as the network around it and applications on it, and to have the ability to diagnose faults when they occur.

    Fault diagnosis requires the ability to collect sufficient information about the fault when it occurs, preferably without having to reproduce the fault. We log our own appliance, and anything else on the network, and then alerts can be handled via SNMP traps sent to an SNMP trap receiver such as HP Open View or IBM Tivoli. The other option is an alert sent to a remote pager or mobile device, or even an email to the NOC/SOC personnel.

    11.  Customizability/Flexibility/Integrability: LogLogic is used to solve complex business problems on a large scale. For some it’s used for various compliance needs, such as PCI or SOX. To others, it’s an alerting or filtering tool, while forwarding a few of the log records on to a SEIM (typically, as much as it can handle, which is usually not as much as needed ...) or a specific other security tool. To others, LogLogic is used for general reporting, incident investigations or forensics. Regardless of how it’s used, LogLogic a different tool to different people.

    LogLogic appliances are rarely rolled out as a single unit in an environment. Generally they are rolled out by location, by message per second (MPS) requirements... or by long term storage requirements, but any way you shake it, LogLogic architecture is designed to meet the needs of the Enterprise (and this is not to say that SMBs won't benefit from log management!).

    Usually you’ll see several LX reporting/alerting appliances feeding back to a single long term storage ST appliance, but that’s not written in stone. Sometimes customers send all of their log data direct to the ST storage appliance (which handles a massive 75,000 messages per second) in order to take advantage of a single IP address destination. This, in my own humble opinion, is a good data center solution.

    My point is, the architecture of the LogLogic appliances is a variable (but still easy!) which gives you total control. There is no firm “config” that is required for boxes to be placed in. Instead, the architecture is flexible, and allows for multiple configurations depending on the environment they reside in. This is the ability to remain agile.

    Living in an enterprise world, we must adopt to new technologies as they become standards. Often some of the features on the LogLogic appliances overlap with other technologies already in use. Because of that, we have engaged the ability to utilize those technologies in those situations. One example is that LogLogic has but doesn’t always provide its own identity management functions. Typically there is another authentication management that the enterprise is already using, such as TACACS+ or RADIUS. The enterprise may have adopted particular standards to manage user databases and access control. For this LogLogic needs to be flexible in it’s architecture, allow customizability within the enterprise, and integrate well within the framework of the already existing environment.           

    12. Support: With any mission critical software deployment, the enterprise must have a reliable way of getting support for diagnosing problems and getting fixes and advanced replacements. This includes 24x7 availability for support personnel and an organization with the experience and expertise to understand how the appliances are used in enterprises. Our support is not only top-notch, but is also praised by our customers!

    Thank you for tuning in to part lV of “Enterprise Class” where I’ve laid down WHAT enterprise-class really is, and how LogLogic has tackled it. I’d also like to thank our competitors who have been visiting my blog. You can imitate, but you’ll never duplicate us, boys!

    Next piece will conclude the series ... stand by!"

    Technorati tags: ,

    Posted by on October 11, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

    PoS Logs out of PCI Scope? Surely You Are Joking...

    ... well, turns out they were dead serious. As I expressed my puzzlement to our resident PCI auditor, he explained that PoS logs and overall security of PoS devices are often "in-scope for PCI, but out of scope for a typical PCI audit."  How bizarre is that?  But let's start from the beginning.

    First, what on Earth is a PoS? PoS, or Point-of-Sale terminal, is a machine that stores (or whoever else who takes credit cards) use to process credit card transactions: scan cards, communicate with verification server, print receipts, etc. It might be standalone or combined with a cash register. It might very very simple - just card reader + transaction unit in a single hardware unit - or as complex as a Windows PC with a cash drawer and no software updates (a scary thing indeed!)

    So, in the latter case, there are certainly logs involved. In fact, there are also PoS-specific application logs, such as this example below, coming from an IBM SurePoS device:

    --------------------------------------------------------------------------------------------------------------------------------

    01/11 09:11 CC     5 W518 PROGRAM ADDDDDXUXDL HAS ENDED                           
                       B3/S111/E007 REASON=2 TYPE=3 RC=00000000            
    SOURCE: OCF                                                                     
    REASON: Application ended            PROGRAM TYPE: Background               
    RC: No error      
    --------------------------------------------------------------------------------

    PoS devices might be configured to store credit card numbers locally (for backup) and also to offload them to a "branch server" (a store server or both a store server and a regional server). Are there logs of who accessed them on the local PoS system? Unlikely. Are they looked at? Probably not.  Maybe the logging is done better on the branch or store central server, but even this is not a certainty.

    Overall, I am willing to bet a bottle of decent champagne that very few people, if anybody, in the whole world are regularly looking at PoS logs. At some happy point in the future, I predict they will start since the Beast of PCI will make them :-) When this happens, we will talk about PoS log analysis.

    As of today, you would do comparatively well if you will collect and save them and thus will have a chance to review them for incident response for your next data theft case (or show them to an unusually nosey PCI auditor...)

    More fun PoS security reading is here [PDF].

    Technorati tags: , ,

     


    Posted by on October 05, 2007 in Compliance , Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

    Just What is Enterprise Class? Part III

    Here is the next enlightening post from Dimitri McKay, our brilliant network and systems engineer from the East Coast, where he continues to discuss the meaning of the phrase "enterprise-class," which is certainly MUCH more than a marketing buzzword! Part I is here, go read it first. Part II is here, go read it next.

    "This is the third piece in the five part series titled “Enterprise Class”. Here we’ve gone through what IS enterprise class and how that corresponds to the LogLogic solution. Feel free to post your comments.

     7.Performance: Performance is a broad topic. We’re not just talking local log collection performance, but also the ability to perform efficiently while in a distributed environment is critical to enterprise class hardware and software.

    While the ability to add more LogLogic appliances allows more devices to be logged and application data to be collected, if the software does not perform with a high level of efficiency, the cost to deploy a system for the required number of devices will be prohibitive.

    LogLogic’s top end reporting appliances handle 4000 messages per second sustained. That is a HUGE amount of traffic. if you’ve ever had to sift through it, you’d agree. Think about it. That’s 240,000 messages per minute. 14.4 million messages per hour. That’s 345.6 million messages per day. Grep that with your syslog server. Parse that with your SIEM. It’s not going to happen (not without an ENORMOUS price tag). And our log collection appliance do even more, way more: 75,000 messages  per second sustained. Wow!

    Performance on a LogLogic appliance is measured based on several factors: CPU usage, messages per second, and disk usage which are important not only for the main functions of the system such as receiving and parsing logs, but also for the ability to run reports and searches on those messages.

    8.Security: Because LogLogic is used for mission critical functions, security is essential. LogLogic must ensure that users who are authenticated to the appliances only have access to the functions they need and access to the log sources that are determined by their job role. LogLogic must also offer the ability to encrypt data as it moves between appliances (which we do via LogLogic TCP) and to also offer the ability to use WORM or data at rest encryption (which is handled by the EMC Centera or NetApp for WORM and Decru for data" at-rest" encryption).

    LogLogic also covers security with the ability to verify that the system is secure through audit trails, general protection of the appliance through a secure linux kernel locked down in the default install, perform self logging, and then hashing the raw logs which are kept in an immutable format. At LogLogic we take security serious, and the box is put through a variety of vulnerability assessments on a regular basis.

    9.Documentation: Because LogLogic handles device support through a specialized group of folks we call “LogLabs” we are able to add devices at an expeditious rate. With each of those new devices comes the required measures to configure each of those devices for logging, and with that knowledge transfer that to documentation. Over time our Documentation Group has continued to grow. Knowledge management is essential to managing the enterprise class solution while alleviating the strain on any of the support or field engineering staff.

    Check back soon, to see more about how LogLogic does Enterprise right. In the next episode I will run off on a tangent about usability and flexibility/interoperability/customizability and support! We are boldly going where no other LMI vendor has gone before!"

    Technorati tags: ,

    Posted by on October 04, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

    Log Trustworthiness Hierarchy

    This post is inspired by the old TaoSecurity post Enterprise Trust Pyramid where he explains that he trusts some security, system and network evidence data more than other. For example, dedicated NSM sensor records are trusted more than vanilla server logs. With this post, I am looking to establish a log trustworthiness hierarchy so that people start thinking about trusting log data as a kind of a spectrum, from "probably trash" to "guaranteed to be an accurate record of activities."

    So, do you trust your logs to accurately depict what happened on the system or network? Which logs do you trust the most? How do we increase this trust?

    My first draft of such trust hierarchy follows below (from low trust to high trust):

    1. Compromised system logs (mostly trash, but might contain bits that attacker missed/ignored)
    2. Desktop / laptop OS and application logs (possibly changed by users, legitimate systems owners, etc)
    3. All logs from others systems where 'root'/Administrator access is not controlled (e.g. test servers, etc)
    4. Unix application logs  (file-based)
    5. Local Windows application logs
    6. Local Unix OS syslogs
    7. Unix kernel audit logs, process accounting records
    8. Local Windows server OS (a little harder to change)
    9. Database logs (more trusted since DBA cannot touch them, while 'root' can)
    10. Other security appliance logs (located on security appliances)
    11. Various systems logs centralized to a syslog server
    12. Network device and firewall logs (centralized to syslog server)
    13. Logs centralized to a log management system via a real-time feed (obviously, transport encryption adds even more trust)

    Admittedly, the differences between some of them are minor or even non-existent ...

    To conclude, some logs DO in fact provide reliable evidence in case of an incident; you just need to know which ones to trust and which ones to only consider to be "hints" (or possibly even a misdirection). But of course, you need to first have logs and then look at them.

    Posted by on September 27, 2007 in Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

    Just What is Enterprise Class? Part II

    Here is the next enlightening post from Dimitri McKay, our network and systems engineer from the East Coast, where he continues to discuss the meaning of the phrase "enterprise-class," which is certainly MUCH more than a marketing buzzword! Part I is here, go read it first.

    "4.Scalability: To support a large number of devices in growing enterprises, SIEM and log management products differ a great deal in how they scale. Some of the SIEM products require you to add as many as three new appliances, (which all carry a hefty price tag) just for a slight increase in throughput. Others require you to forklift out your existing hardware to bring in new, bigger (and more expensive) equipment. In my own humble opinion these options are completely ridiculous.

    The LogLogic scalability approach is uniquely simple. “Add log-traffic to your LogLogic appliances until you reach capacity on that box. Then add another box. Rinse and repeat. Each box does it’s own collection, does its own parsing, reporting and searching, and does its own storage. No special other boxes required. All encompassing solution.

    Of course, with “Scalability” comes other requirements of how to add capacity not only vertically, but what of horizontal scalability? Such features would include the ability to report across all LogLogic appliances, manage users and their access rights across a global environment, and use some form of remote authentication such as TACACS+ or RADIUS. This distribution should be an asset, and not a limitation of the overall system scalability. All of these are addressed and in the current LogLogic 4.x.

    5.High Availability: Due to the number of corporations and government agencies depending on LogLogic for regulatory compliance, system security and forensics, as well as heartbeat monitoring and troubleshooting, it’s safe to say that LogLogic is “Mission Critical”.

    Because LogLogic is a “Mission Critical” system, it must support the internal and external capacity for zero downtime via high availability. This is accomplished via bonded NIC’s, hot-swap drives in various RAID arrays and Mirrored sets, hot swap redundant power supplies and most importantly... the ability to link the boxes together in an active pair. Should there be a failure in a LogLogic pair, both appliances are exact clones of each other, and the passive appliance jumps right into gear as the primary. In milliseconds. It’s genius.

    In a perfect world, there would be zero downtime on “Mission Critical” systems. Here at LogLogic, we try to minimize that to as little as possible through the use of various forms of HA, and it shows. Have you seen our new hardware?

    6.Reliability: Although high availability plays a part here, I prefer to think of reliability as the quality of the code-base, the product design itself, and the forward motion of feature sets and additional device support in a timely fashion.

    LogLogic is built on a stripped down lean, mean hardened Linux platform. From there we didn’t go the route of a proprietary datastore which can start as a good idea and then turn into a huge hulking mess with nothing but frustrations stemming from using, maintaining and increasing the capabilities of, but rather we went with a solid database solution for storing meta-data. Industry standard. Well known. Easy to use. Robust.

    Then we built in some brilliant parsers and a very straight forward GUI. Sprinkle that with some great features and a little bit of magic and you have a LogLogic appliance. Our upgrade plans and implementation are fast and furious. We release new device support monthly. Monthly additions. Monthly updates.

    At the end of the day, however, extenuating circumstances happen. Should there be a hardware or software problem, LogLogic support is there to help. With 24/7 support and advanced replacement available to our platinum level enterprise class customers, all the bases are covered.

    Build the appliance on a solid kernel, with a well known and well tuned database. Add HA, some of the finest engineering talent in the world, and a great support team, and LogLogic does enterprise right.

    Stay tuned for the 3rd installment of “Enterprise Class”. LogLogic is going where no LMI vendor has gone before."

    Technorati tags:

    Posted by on September 27, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

    More Web Proxy Log Tips

    After publishing my proxy log tip (here), I figured I'd post a few more mini-tips on web proxy logging as well as a link to my full presentation (webcast with voice, slides only) on web proxy log management.

    First, why look at proxy logs? Apart from my overall answer that applies to all logs, proxy-specific reasons are the following:

    1. Review users’ activities on the web (not just surfing!)
    2. Monitor applications' HTTP activity
    3. Detect Web-enabled malware traffic
    4. Study proxy performance metrics

    Most people just focus on #1 above and kind of forget #2-#4. Also, the focus of #1 is often narrow - what do they surf at work?- and not broad - what do they do on the web? - which is much more useful. While there is no direct mention of proxy logs in recent regulations, monitoring what users do with YOUR data is clearly part of the compliance mandates (and, obviously, a good idea in general!) Indirect references to proxy logging can be seen in the following:

    So, please treat proxy logs with the respect they deserve!  Here is my full presentation (webcast with voice, slides only), on analyzing and managing web proxy logs.

    Related posts:

    Technorati tags: , ,

    Posted by on September 24, 2007 in Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

    Just What is Enterprise Class? Part I

    Here is another enlightening post from Dimitri McKay, our network and systems engineer from the East Coast, where he discusses the meaning of the phrase "enterprise-class" (which is sometimes known to be abused in marketing literature...)

    "The Enterprise is generally a huge task, and this post itself is quite large. Due to the mass of both this post and the average Enterprise roll-out, I will break this down into 5 parts. Here is part 1 in the 5 part series.

    I hear the term “Enterprise Class” as a buzz word to define hardware and software. Sometimes it’s used to describe a feature set, and to some it’s a scalability reference. Here’s what “Enterprise Class” means to me, and how it pertains to LogLogic solutions as a whole.

    1. Multi-user: LogLogic handles the Multi-user process in a two prong attack. First, we offer the basic granular local account system which gives users the rights needed to do the job on only the devices they require. Now, on the enterprise side, we have added the ability to connect to TACACS+, RADIUS and soon LDAP/AD servers in order to alleviate the task of managing users on the LogLogic Appliances. Multi-user is a must for anything that is to be considered “Enterprise Class”. I’m hoping to see some additional authentication methods in the future, however, as for now the TACACS+ and RADIUS option certainly covers the majority of our enterprise customers.

    2. Accessibility: In 1998, Congress amended the Rehabilitation Act to require Federal agencies to make their electronic and information technology accessible to people with disabilities. Inaccessible technology interferes with an individual's ability to obtain and use information quickly and easily.  Section 508 was enacted to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. Most of the specifications for software pertain to usability for people with vision impairments. For example, one provision requires alternative keyboard navigation, which is essential for people with vision impairments who cannot rely on pointing devices, such as a mouse. Other provisions address animated displays, color and contrast settings, flash rate, and electronic forms, among others (see more at Section508.gov).   Now, at LogLogic, we try to make our GUI as straight forward and easy as possible. We adhere our GUI to the standards and framework put forth by the web browser itself, which thereby adheres itself to the accessibility options within both that browser and also the Operating System.

    3. Localization: As with any business solution, our world isn’t set in one language or specific dialect. As a whole, LogLogic offers language options not only in English but also in languages relevant to foreign countries that are bound by the same requirements that LogLogic can address such as JCobit and J-Sox, which are the Japanese versions of COBIT and Sarbanes-Oxley (SOX) compliance. As we move forward LogLogic continues to add alternative language support such as Korean and Chinese.

    Stay tuned for the next episode of “Enterprise Class” where I will run off on a tangent about HA, reliability and scalability."

    Technorati tags: ,

    Posted by on September 24, 2007 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

    More Project LASSO Updates

    Dimitri McKay, our network and systems engineer from the East Coast contributes this fun story: "When I first started at Loglogic, the only option for retrieving Windows logs was via an open source product called Snare. Snare was a simple concept. It would basically tail a Windows event viewer and whenever a new event was written, Snare would convert that to syslog, and send it over the wire (UDP or TCP) to its destination. Basic concept, basic execution. 

        Now, all of this was well and good, however, I couldn’t help but feel like an agent was not the greatest of solutions. As a former Windows Engineer, I was sort of put off with the idea of agents as a whole. It seemed like everyone was offering agents, and those agents were never happy on my systems in some form or another. So began Project Lasso. 

        Over some Thai food, Matt Foley, Andrew Morris and myself had a conversation about an agent-less Windows solution, and later that day I found myself writing a PRD for the “Windows Remote Event Collector” which was code named Project Lasso. 

        The name stuck, and with our 4.0 release I’m really happy with the ongoing development of the product. The concept is simple... Lasso is installed either as an agent to monitor itself, or on a “Project Lasso Server” where it uses WMI connections to connect to the other hosts it will be pulling logs from. There it pulls the string dll’s to a local repository, and then pulls the windows events themselves. Both the string dll’s and the events are then sent to the receiving syslog or Loglogic appliance where they are parsed and indexed. [Anton: they can also be sent to any other syslog receiver, such as a syslog-ng server]

        In 4.0 we added a few features I’m very excited about. 

    The ability to use custom shares. In version 3.x we needed a Domain Admin account to pull the full Windows events. The Domain Admin account was the only account which had access to:

    In Project Lasso 3 if you set some Active Directory policies, you could eliminate the need for a Domain Admin for the registry and event viewer, but not the C$ admin share. The only other account that had access to that was the Backup Administrator. Now, in Project Lasso 4 we don’t have that issue any longer because we can configure just a standard Lasso User account to have access to the registry, the event viewer, and a local drive via a custom share.

    The ability to change the Hostlist.ini on the fly: In Project Lasso version 3.x when you added hosts to be monitored, you had to restart the Lasso service. Well, this process became somewhat onerous in that every time an Administrator needed to add new servers/clients to be monitored by Project Lasso he had to re-start the service which would take quite a bit of time to check those string .dll’s for changes or additions and then start pushing logs to the destination server. This could sometimes take more than a few minutes depending on the number of hosts. So much for real-time alerting or reporting. None of this is a problem anymore as the Project Lasso service will now grab the new hosts on the next pass.

    Shared DLL Repository: Prior to Project Lasso version 4, when a dll Repository was created on the Lasso Server, it downloaded all .dll’s for all monitored hosts. This means there was a ton of the same .dll’s in the repository as each machine would most likely have the same .dll’s. These folders were about 120MB large in Lasso 3 times the number of hosts you were monitoring. That can be a big storage problem in a short amount of time. In Lasso 4, the dll’s are shared among hosts so it has a much smaller disk space requirement.

    In closing, if you’re interested in routing Windows Events to a syslog or Loglogic appliance, you can do so via Project Lasso either in agent mode or in agent-less / remote collector mode.

    Feel free to check out the always free Lasso 4 on Logforge"

    Indeed, Project Lasso  is in wide use among LogLogic customers as well as in the broader world. Deal with Windows logs? Grab Project Lasso!

    Posted by on September 17, 2007 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

    Read "PCI Compliance" book chapter on logging!

    As you know, the "PCI Compliance" book is out. Syngress/Elsevier publisher released one chapter from the book for free: and it is my chapter on log management and logging in PCI! Enjoy it here! [PDF] The book (and, in fact my logging chapter!) already got some glowing reviews.

    While people still argue whether PCI is simple or overly complex, PCI DSS is certainly motivating a lot of people to take a long hard look at their IT security ... For example, more people are starting to look at database logs as a result of PCI. While some vendors are still lagging behind, you can get your database logs into LogLogic today!

    Posted by on August 24, 2007 in Compliance , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

    Logging Glossary: Log Preprocessing

    As I mentioned here,  I started publishing the LogLogic Logging Glossary. So, here is the eleventh term (first second third fourth fifth sixth seventh eighth ninth tenth):

    Log Preprocessing

    1. The process of modifying or transforming a message as preparation for later stage processing.

    Preprocessing can include multi-line message handling, encoding conversion, and special character substitution.

    2. The prerequisite analysis of headers or other information in a log that define the formats or values present in the log messages.

    The preprocessing assures correct parsing and identification of values. 

    Technorati tags: , , ,

    Posted by on August 20, 2007 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

    Anton Logging Tip of the Day #12: Proxy Log Fun - Proxy Log Analysis for Possible Information Leakage Detection

    Following the new tradition of posting a tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative. One of the bloggers called it "pay it forward" to the community.

    So, Anton Logging Tip of the Day #12: Proxy Log Fun - Proxy Log Analysis for Possible Information Leakage Detection

    You probably know that web proxies (such as Squid, BlueCoat SG and others) produce a lot of detailed logs, that record all web traffic flowing through the proxy as well as pass/block decisions made by the proxy's content filters and possibly embedded anti-malware tools. Proxy logs can be used for a whole range of things, from routine monitoring for Acceptable Use Policy (AUP) compliance to malware detection as well as possibly looking for security scourge of 2007 - web browser attacks by malicious or compromised web servers.

    Specifically, in this tip we will learn how proxy logs can be used for detection of file uploads and other outbound information transfers vie the web. First, think what is the legitimate use of file upload functionality in your environment. For example, if using web-based mail services is allowed, then sending an attachment will include an upload. What else? The rest will be considered at least suspicious...

    In addition to file uploads, some malicious or commonly unauthorized applications will use similar methods to steal or transfer data, that will be reflected in proxy logs. Looking for HTTP methods (such as POST) and content-type in combination with either known suspicious URL  or user-agent (i.e. web client type) can often reveal spyware infections, actively collecting data. Admittedly, a well-written spyware can certainly fake the user-agent field so it is clearly not reliable, but still useful to add to our query above. 

    So, here are some of the criteria we will use to look for information uploads in Squid and BlueCoat SG proxy logs:

    (if you feel adventurous, other interesting content-types to try are "application/x-javascript" and "text/javascript")

    Here are the examples found in proxy logs using the above query, including some "classics" (while spyware specimen are a bit dated, this method of  detecting them via logs is still relevant and useful):

    1. 1124376766.026 RELEASE -1 FFFFFFFF 4734C557F9315105CA6BE0FA56B94D55 200 1124276674 -1 -1 unknown -1/0 POST http://reports.hotbar.com/reports/hotbar/4.0/HbRpt.dll
    2. 1124392388.975 RELEASE -1 FFFFFFFF 810FFBF233584C330353CF0A8C31F5D2 503 -1 -1 -1 unknown -1/813 POST http://log.cc.cometsystems.com/dss/cc.2_0_0.report_u
    3. 2007-05-19 03:55:12 160 10.1.1.3 - - - OBSERVED "Spyware/Malware Sources;Spyware Effects;Web Advertisements" - 200 TCP_NC_MISS POST text/html;%20charset=utf-8 http bis.180solutions.com 80 /versionconfig.aspx ?did=5342&ver=1.0 aspx - 10.1.1.2 273 175 - - none - -
    4. 2007-05-21 03:10:40 4 10.1.1.3 Joanna- authentication_redirect_to_virtual_host PROXIED "Search Engines/Portals" - 307 TCP_AUTH_REDIRECT POST - http storage.msn.com 80 /storageservice/schematizedstore.asmx - asmx "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; MSN Messenger 7.5.0324)" 10.1.1.2 791 2566 - - none - -
    5. 2007-05-22 21:35:09 215 10.1.2.237 200 TCP_NC_MISS 217 8122 POST http kenobi.example.com /exchange/john.smith/Drafts1/RE:%2520CustomerList.xls-2.EML - - DIRECT kenobi.example.com - "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" PROXIED none - 10.1.170.42 SG-HTTP-Service - none –

    The first three are traces of spyware (one was even identified by a BlueCoat content filter as "Spyware/Malware", the fourth is MSN Messenger-based activity while the fifth is emailing the Excel file via web mail.

    Here are some other signs that will make the above log entry extra-suspicious is:

    Overall, this log analysis method is good for casting a broad net to catch not just spyware-infected systems, but also unauthorized applications (e.g. method=POST and user-agent=iTunes), instant messaging (e.g. method=POST  and then by user-agent, content or URL), simple forms of data theft and document handling policy violations (emailing files to self via web mail: method=POST and sensitive file name present in the entry; also content-type set to popular Office file types) as well as other abuses of web access. As a result, proxy logs provide an extremely rich AND readily available source of data about threats that users face!

    To top it off, one promising direction of future research is using web proxy logs to detect client-side exploits by malicious web servers (more on this in the near future!)

    Possibly related posts:

    Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Tips of the Day.

    Posted by on August 07, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

    Musings on 100% Log Collection

    One of the most exciting, complicated and, at the same time, very common questions from the field of log management is the "what logs to collect?" question. This comes up during compliance-driven log management projects (in the form of "what to collect for PCI DSS compliance?") as well as operationally-driven (in the form of "what logs from this application do I need to detect faults and errors?") or security-driven log management projects (in the form of "which logs will help me during the incident response?")

    What are the answers that one sometimes hear? Otherwise awesome log management guidance NIST 800-92 "Guide to Computer Security Log Management" confuses the reader with this fascinating blurb: "generally, organizations should only require logging and analyzing the data that is of greatest importance." And how do people to know which logs are of importance? (I did have a bit of a debate with NIST folks on that...)

    Other answers are situation-specific and thus limited in their usefulness ("need IDS alerts + server logs to detect intrusions via correlation", "need all logs that show access to PHI").  I spoke about the pitfalls of "prioritizing before collection" in my presentation "Six Mistakes of Log Management" and its companion paper.  In some cases, such as the incident response scenario, you might be naturally leaning towards grabbing as much as possible, since you never know which bit will help you answer that dreaded "WHAT happened?!" question ...

    On the other hand, there is a simple answer that doesn't suffer from the above issues: collect everything. However, many folks go into a state of shock upon hearing it :-) "Everything!?! HOW can you collect 'everything''? What about storage, bandwidth, hardware, etc?"

    But you know what? It really isn't as bad as you think! Just think that:

    1. Logs compress really well (1:10 to 1:15 compression ratios are not unheard of), so bandwidth and storage are less of an issue that initially estimated
    2. Disk storage is cheap (and tape is cheaper still); holding a billion of log records might well cost  under $200 (!) in disk drive cost
    3. Figuring out what you need, might need, can be "told to need", will need, etc is genuinely hard. You will never get it right!
    4. Many logs don't need to get collected the next second after generation, thus allowing you to save some bandwidth by moving them when network is less busy.
    5. Technologies exist to make sense of "everything", not just "hand-picked" and parsed logs. More on the "making sense" part later

    Convinced yet? So, if you are pondering "what logs to collect?", try to switch your mindset into thinking "what will it take for me to collect everything?" You probably won't regret this decision!  At the same time, one can try to reverse this question and ask "why collect everything?" - in this case, the answer will be "because any other collection strategy is worse."

    Related posts:

    Technorati tags: ,

    Posted by on July 19, 2007 in Compliance , Log Management & Intelligence , LogEd , Security | Permalink | Comments (0)

    Logging Glossary: Log Header

    As I mentioned here,  I started publishing the LogLogic Logging Glossary. So, here is the tenth term (first second third fourth fifth sixth seventh eighth ninth):

    Log Header

    A set of information at the beginning of a log file or the start of a log message.

    The information usually consists of context information, or meta data.

    It may have a fixed or variable format. Fixed formats and some variable formats are usually well defined in vendor documentation. Some variable formats, such as with Syslog are subject to vendor discretion.

    Posted by on July 17, 2007 in Log Management & Intelligence , LogEd | Permalink | Comments (0)

    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 by on December 15, 2006 in LogEd , LogMatters , Security | Permalink | Comments (0)

    How Log Intelligence is Transforming IT

    Compliance, information protection, audits, user monitoring and risk mitigation are driving a new set of practices and policies in IT -- all around managing log data. In fact, recent research points to the Global 2000's continued investment in Log Management and Intelligence (LMI), projecting double-digit growth in 2006 to $380M.

    And log data continues to grow at an unprecedented rate -- which just further compounds the issue of how to manage it!

    We are hosting a webcast with the SANS Institute on August 9 to discuss the trends and solutions. LogLogic's Andy Lark will be joined by SANS Institute CEO Stephen Northcutt. Register here.

    Posted by on August 03, 2006 in Log Management & Intelligence , LogEd | Permalink | Comments (0)

    At the SANS Log Management Summit

    Anton, Jill and myself are here in DC at the inaugural SANS Log Management Summit. Alan Paller opened the morning session to a packed room - over 200 people are attending - stating that Log Management is the sweet spot that bridges compliance and security.

    Ben Wright took the stage after him speaking on Logs & The Law. A couple of the highlights from my rough notes:

    1. Have a written policy... it is better to speak in general terms rather than hard language. And, a written policy, not followed = a negligence case.
    2. Keep logs of log management - records about what was reviewed. Ben saw lots of value in this saying that "logs of log management are more valuable than logs themselves".
    3. Bias to keeping more logs - general trend in law which rewards organizations that keep more information than they did in the past. More expectations for records/archives.
    4. Only full audit committee should have power to know all logs... Maintaining custody of your log data is something we constantly emphasize and is a key feature of LogLogic.

    Watch for our SANS Webinar on Logs & The Law - with Ben - later this month.

    A great customer panel followed featuring a very large financial institution - and LogLogic customer, NetApp and others. NetApp are collecting some 40 million log messages a day - and emphasized that you can't use people exclusively to do log data mining when processing these kinds of volumes. You need a great tool. They made some other great points that we often look at when architecting solutions. You can't just collect logs from one set of devices and they shouldn't be dispersed. Get them centralized for rapid review and forensics. There was a definite preference on the panel for agentless log management systems.

    - Andy

    Posted by on July 12, 2006 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

    The Case for Universal Log Processing

    Andreas Antonopoulos revealed some more wisdom from his interviews with 82 IT managers:

    “The average enterprise has more than 1,200 applications, but even that number is increasing every year”.

    I have always known that enterprises have many applications because a typical log management and intelligence RFP has requests for about 200 discrete log sources. The bigger point is that 70% of enterprise software applications are homegrown or highly customized. This means there are a lot of “one-off requests”.

    Therefore, it doesn’t matter anymore how long your list is of “supported applications”. What really matters is how quickly you can support “unknown log types”. Nothing is better than instant gratification and so at LogLogic have opted for out-of-the-box support for unknown log types. We use natural language processing and machine learning algorithms to provide baseline support for any application that writes ASCII.

    - Dominique

    Posted by on May 31, 2006 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

    LogLogic and the SANS Institute Sponsor Industry’s First Log Management Summit

    As the proven industry leader in transforming log data into critical intelligence for compliance, operations and security, we're thrilled to announce that with the SANS Institute we have created the only major conference on what works in log management, to be held in Washington, D.C. on July 12-14.

    This promises to be a great event with more than 20 speakers - mostly users - speaking to best practices and leading-edge approaches. Moreover, it will go beyond security and network intelligence to look at more complete approaches to LMI spanning operations, IT controls, compliance and SLAs. Here's what Anton has to say:

    It's time for log management to move beyond network intelligence and security event management, said Anton Chuvakin, director of product management, LogLogic, and member of the SANS Organizing Committee. Log management and intelligence has established itself as a critical discipline in medium to large enterprises. Activities such as compliance, information protection, audit, availability and user monitoring and risk mitigation are driving a new set of practices and policies. Our commitment to and participation in this event is further evidence of our support for the global log management and intelligence market. We look forward to sharing this event with our customers and partners.

    If you are a LogLogic customer or partner and interested in attending, be sure to use the promo code to get a discount: LOGLOGIC10.

    Posted by on May 30, 2006 in Log Management & Intelligence , LogEd , LogLogic News | Permalink | Comments (0)

    Attend Log-ED ~ Go Home Earlier

    Last week we announced the arrival of Log-ED, a new series of training programs that will take your log management and intelligence expertise to new levels.

    Our first offering, Log Management and Intelligence Analyst, teaches best practices for collecting and storing log data; implementing log standards; and, provides an overview on how companies can validate IT controls and mitigate risk using logs.

    It's time to mark your calendars! Public courses are available:

    Enroll today!

    Learn how to:

    If you aren't using LogLogic, that's fine. You'll still learn lots. If you are, this is the perfect opportunity to use your log management and intelligence platform to its fullest potential. Let us show you what it can do for you to make you better at your job, while lessening your workload. With these new skills, it's likely you'll be going home much earlier!

    Posted by on May 12, 2006 in LogEd | Permalink | Comments (0)

    Visit loglogic.com

    I ♥ Logs

    Subscribe to this blog’s feed RSS

    March 2010
    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 31      
    Categories
    Archives
    Blogroll
    Blogroll
    Compliance
    Good Reading
    LogLogic
    LogLogic Partners
    Sites We Watch