LogBlog

Anton Logging Tip of the Day #15: Fear and Loathing in Event 560 (and 562 and 567)

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. One of the bloggers called it "pay it forward" to the community.

So, Anton Logging Tip of the Day #15: Fear and Loathing in Event 560 (and 562 and 567)

This tip digs into a seemingly simple, but really VERY esoteric subject: monitoring file access and modification via a Windows event log. Now, some people - who never studied this subject - tend to have a very simplistic view of this: just enable Object Access auditing, then right-click on a file or directory, click Security->Advanced->Auditing and then pick what types of events will be logged and by what accessing entities (i.e. users or computers). OK, so this will produce some logs, that is for sure. But are they useful?

First, why are we doing this? We typically need to know the following when we audit file access in Windows (or any other OS for that matter) for security (monitoring and investigation) or compliance:

Can we get this from the above logs? No.

What? No!?! Really?

Yes, really. We can get some of the above, some of the time, not all of the above, all of the time. Here is an example, we are looking at event ID 560 (picture) and then at an extract from its description field.

Event:

event_log560_1_thumb

Description (selected field):

Object Server: Security

Object Type: File

Object Name: C:\0\TestBed\simple_text_file.txt

Image File Name: C:\WINDOWS\system32\notepad.exe

Primary User Name: Anton

Primary Domain: XXXXXX

Accesses: READ_CONTROL

SYNCHRONIZE

ReadData (or ListDirectory)

WriteData (or AddFile)

AppendData (or AddSubdirectory or CreatePipeInstance)

ReadEA

WriteEA

ReadAttributes

WriteAttributes

 

WTH is that? Well, we know that the user  'Anton' has successfully read? wrote? changed attributes? did something? with a file named "C:\0\TestBed\simple_text_file.txt" using a program named "C:\WINDOWS\system32\notepad.exe." That's the best we can get, in this case! We may try to look at event IDs 562 and 567, but this missing information (i.e. the exact action performed) will not be added.

BTW, there will be  a few more dozen (sometime hundreds!) of the 560s, 562s and 567s  produced - all from just opening the text file in a notepad. The above event is notable for having BOTH "notepad" and "simple_text_file.txt" in the same event; others will have either of the two.

Anything else gets in the way? Yes, lots! MS Office will write to all files, even just opened for reading (with no user modifications to the content whatsoever), which will screw up your log monitoring efforts. If the file is on a share, more information will be missing (e.g. username might be).

So, how to use Windows event logs for file access tracking?

  1. Enable logging (as described above)
  2. Pick events 560 (most useful) and 562, 567 (useful too)
  3. Look for fun filenames that might be touched by the users (have a list of files and users handy)
  4. Figure out what programs were used to access them (this is called "Image File Name" in "WinLogSpeak")
  5. Ponder the 'Accesses' section of each event until your brain turns blue :-) or until you decide whether such access is authorized or not...

Overall, this is still very useful for file access monitoring, but the process is somewhat painful.

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

Technorati tags: , , ,

Posted by Anton Chuvakin on May 08, 2008 in Compliance , Innovation , Log Management & Intelligence , Security | Permalink | TrackBack (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 Anton Chuvakin on April 24, 2008 in Compliance , Innovation , Log Management & Intelligence , LogEd | Permalink | TrackBack (0)

From Log Apathy to Log Enlightenment

So, I was talking to this small log management vendor the other day and he confided to me that his product faces fierce competition in his target market (which is, important to note, small to medium companies with 10-100 systems): and this competition is apathy.

More specifically, his prospects either just blow him off by saying "pah, who needs logging!" or they profess their undying love of all things logging - and then still don't buy his product (which is priced, shall we say, "to go")

Admittedly - and somewhat tongue-in-cheek, these are the same companies that form the core of today's botnets (due to various reasons including their scarce resources) and enable RBN to deliver high-quality malicious services to criminal enterprises worldwide. Still, if you happen to have thoughts along the line of "who needs logs?" or "ah, logging? it will come later!", you really deserve a nice fat check from RBN and other malicious "hacking" syndicates since it is extremely likely that your overall attitude towards security is just as misguided...

But how to progress from such ... what was before the Stone Age? ... Sharpened Stick Age? to modernity? Most companies go through the following stages in regards  to their logging:

  1. Deep log ignorance: "Logs? What are those?"
  2. Shallow log ignorance: "Later...later...later... #37 on the TODO list."
  3. Log collection: "We gather and store dead log data...cold."
  4. Log searching: "We will dig into the pile when we have to ... hopefully never!"
  5. Log analysis and reporting: "We know our logs - and what they mean"

(also see my post "Natural Flow of Log Management" for some specifics)

Of course, compliance (PCI DSS and others) helped move people from 1. and 2. to 3., but, sadly,  people often get stuck at 3. (just collection) or 4. (collection  + maybe search) and never progress to Logging Enlightenment of 5.

Yes, PCI DSS and other regulations mandate not just log collection, not just dead cold log storage, but also log review (daily, in case of PCI DSS Requirement 10), but "review" happens to be the item that gets overlooked  all too often.

Why is that?

I think the reason is that log analysis is still too hard and still not automated enough for an average organization. Yes, I did see some corporations that built their own log analysis systems that - surprise! - exceeded the best available from the vendors [at the time]. However, a typical company IT department would not have Ph.D. poring through hardcore text mining research papers in order to improve their home-grown log analysis AI. They expect the vendors to  eat the logs, chew on them for a bit - and then spit out the answers.

Are we there yet? No, but we will be!!!

Technorati tags: , ,

Posted by Anton Chuvakin on April 22, 2008 in Compliance , Innovation , Log Management & Intelligence , Security | Permalink | TrackBack (0)

RSA 2008 Summary

So, RSA 2008 has come and gone.  Now that everybody has recovered from the information overflow, it is time for summaries and reflections. Before we begin, go read my RSA Impressions (Part 1,2,3,4). Next, read what others said about RSA 2008 (via my del.icio.us feed). Then reflect on past RSA shows (2006, 2007).

Ready now?

First, what was the theme? Unlike in the past, I personally couldn't pick any. The candidates were GRC (and compliance + risk management) , DLP (and other data-leak/-theft technologies), IAM (and identity enablement), but none quite measured up to being a show "theme."

What I saw too much off? Even though their numbers have shrunk, I still saw too many NAC vendors there (Lockdown, here we come!). One of my friends joked that there were more "GRC vendors" than NAC vendors, but both were in low enough numbers to make it a trend. As far as loud noises back from RSA 2007, "identity-driven this or that for security" was still very visible. What is also bizarre is that people still start log management companies. I saw a couple of new ones - amazing, isn't it? Yes, it is a hot space, but come on! Accept that LogLogic is the leader and be done with it :-)

Overblown messages? "Information-centricity." It was cool and hot :-) and new when Hoff said it.  But when it trickled down to keynotes of some "trailing edge" vendor executive, it became boring and stale. And, while we talk about "information centricity" people must still worry about "A" (availability) first (see this discussion).

What I didn't see enough of? VOIP security. Somehow this previously hot trend is quieted down. Also, I saw a lot of web application security vendors, but I think that is still not enough as this is an area with a raging fire, not just "some hotness." Also, I expected to see more vendors messaging around (and, actually helping with!) fraud. Dan Geer's Verdasys kinda mentioned that, but pretty much in passing. Is fraud handled outside of security (and thus out of RSA)? I am not sure.

What I didn't see at all? I didn't see much "market consolidation" - no huge deals, no vendors of note "taken out", etc. Still a huge number of security companies around ... some with products that seem deeply out of touch with today's threat landscape.  One of the speakers said that nowadays "no single security pure-play expected to change the world", but it sure seems like many will try!   Along the same line, Mike R said that such shows are 18-24 months ahead of what "normal" people deploy. This might explain the VOIP and other missing items.

As I said before, "consumerization" of IT - i.e. IT infrastructure, servers, laptops, storage, services, computing resources, applications, etc provisioned outside of IT departments was an elephant in the room. It is not simply "unmanaged IT" or "consumer-grade IT for business", it is the whole "not-IT-department IT" phenomenon. Yes, via mashups it even includes "non-IT application development" (read this fun 451Group report on that). Security implications of this are nothing short of ginormous.

In light of this, I liked how one presenter said this: "we lost the desktop" - meaning "1/3 is managed by users [not IT], 1/3 is unmanaged and 1/3 is compromised/ "managed" by hackers."  Sad but true... Dave Aitel used to joke how in the future banks will have to "re-compromise" your PC so that some temporary security can be established for you to transact business with them. Are such horrifying times upon us already? Maybe desktop virtualization will help with this ...

Overall, RSA 2008 show was an enjoyable, enlightening and thought-provoking experience, as usual. I've heard it was the same even for people who didn't attend a single presentation - indeed, RSA is about people, not slides...

See you next year at RSA 2009!

Technorati tags: , , ,

Posted by Anton Chuvakin on April 16, 2008 in Compliance , Innovation , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (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 Anton Chuvakin on March 27, 2008 in Compliance , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | TrackBack (0)

NERC CIP Rules Out - Logs In!

NERC security rules [PDF], that were updated and became mandatory last week, might well become "a new PCI DSS" and trigger "a golden age" of security in the energy industry: the rules are mandatory, they are specific (more specific than a lot of other regulatory security guidance) and there is an enforcement body (NERC) that can make life miserable for those not complying. 

Here are some log-related examples from the guidance:

"R5.1.2. The Responsible Entity shall establish methods, processes, and procedures that generate logs of sufficient detail to create historical audit trails of individual user account access activity for a minimum of ninety days. "

"R6.4. The Responsible Entity shall retain all logs specified in Requirement R6 for ninety calendar days."


"R6.5. The Responsible Entity shall review logs of system events related to cyber security
and maintain records documenting review of logs. "

So, again: have logs, retain them ("Top 11 Reasons to Collect and Preserve Computer Logs") and review them ("Top 11 Reasons to Look at Your Logs"). Or, better, have a log management tool do it for you!

 

Technorati tags: , ,

Posted by Anton Chuvakin on January 24, 2008 in Compliance , Log Management & Intelligence , LogMatters | Permalink | TrackBack (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 Anton Chuvakin on November 30, 2007 in Compliance , Log Management & Intelligence , LogEd , Security | Permalink | TrackBack (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 Anton Chuvakin on October 05, 2007 in Compliance , Log Management & Intelligence , LogEd , LogMatters | Permalink | TrackBack (0)

Breaches Rise - PCI DSS Enforcement Lags

The Computing Technology Industry Association (CompTIA) recently commissioned a survey of IT organizations regarding the severity of security breaches within their IT environments. Given all the publicity surrounding compromised systems over the past year, the results are hardly surprising - the severity level is on the rise. Timothy Prickett Morgan of IT Jungle provides a good survey synopsis here ( http://www.itjungle.com/tlb/tlb092507-story08.html).

Here's a stat that should grab your attention -- Across all companies, the average cost of dealing with a security breach was $369,388, with a number of large companies with breaches that cost more than $10 million each thus skewing the average. That's a hefty price stemming from various kinds of malware and human mistakes.

Now that the Payment Card Industry Data Security Standard (PCI DSS) deadline has passed (see story here - http://www.scmagazineus.com/Visa-PCI-deadline-looms-for-tier-one-merchants/article/35880/) and a significant amount of large companies still haven't completed PCI compliance work, you can expect a fair amount of finger pointing in the near future as organizations fail external audits.

LogLogic's Anton Chuvakin posed some great questions sure to fan the coming PCI DSS blame game flame ...

1) Who is ultimately responsible for data loss: merchants, banks, customers  or ...?

2) Is Visa/MC PCI DSS too onerous, not enough or just "common sense" security?

No simple answers are expected, unfortunately. Penny (or perhaps $10 milion dollars in PCI fines?) for your thoughts?

Technorati tags: , ,

Posted by Anton Chuvakin on October 03, 2007 in Compliance | Permalink | TrackBack (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 Anton Chuvakin on August 24, 2007 in Compliance , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | TrackBack (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 Anton Chuvakin on July 19, 2007 in Compliance , Log Management & Intelligence , LogEd , Security | Permalink | TrackBack (0)

Log management in the age of compliance

ComputerWorld features a story by Anton on Log management in the age of compliance. Here are a few highlights:

There are a variety of other regulations that call for log management capabilities, although less explicitly than the aforementioned three. California Bill 1386 and its upcoming federal equivalent, for example, require a state agency, person or business that owns or licenses computerized data that includes personal information to disclose any breach of the security of the data to any California resident whose unencrypted personal information was acquired by an unauthorized person.

Logs, which by nature allow for tracking IT infrastructure activity, are the best way to assess if, how, when and where a data breach has occurred. Management of these logs is therefore the best way to assess what data has been accessed or stolen and, thus, who needs to be notified.

The major effect the age of compliance has had on log management is to turn it into a requirement rather than just a recommendation, and this change is certainly to the advantage of any organization subject to these regulations. It is easy to see why log collection and management is important, and the explicit inclusion of log management activities in major regulations like FISMA, HIPAA and PCI-DSS highlights how key it truly is to enterprise security as well as broader risk management needs.

Posted by Andrew Lark on July 18, 2007 in Compliance | Permalink | TrackBack (0)

Our Very First Customer

Recently our first customer -- a financial company -- participated in a case study on Log Management as part of the SANS Institute's What Works series. The customer (sorry, we can't share their name) deployed our very first evaluation unit and was our initial beta site. It was facinating to hear Victor Hsiang reminisce about the early days of LogLogic from the customer's perspective -- and how we've evolved as a company, technology -- and now industry since then.

He talked about those first products. What we do well. What we could do better. He says we are mature (shh, don't tell anyone) and responsive. But most of all he says that we have evolved into a product that "helped us move forward in standardizing on one log management solution for "this large financial firm" globally." (Yes, we are blushing.)

Victor also talks about how he uses log management for Compliance (SOX) use case and discusses how the product is being used in live troubleshooting with the company's own customers. Staff's time is being spent on custom reporting, but he also explains that once they had a template and process, is simple. Our software team is particularly pleased he said the interface was "intuitive" and did not require training. (They liked it so much the GUI team is even are trying to use it as an excuse to get an extra day off next week :-)

Our favorite quote?

"It was literally bring the box in, or the appliance, install it in the rack, provide power, IP address it, give it a DNS and a gateway. Then exit the data center and go back to your desk and start to configure your devices to send logs to it. "

Oh and yes Victor, we'll look into that feature request. Check out the case study and 40 minute replay at SANS.

Technorati : , ,

Posted by Jill Ratkevic on June 28, 2007 in Compliance , Log Management & Intelligence , Risk Management | Permalink | TrackBack (0)

Webcast: Protecting Information Assets

Most enterprises are worried about protecting critical confidential information and customer data. How are you doing it? What are industry best practices for securing infomation assets?

Join us during a daylong event on securing your data at SCMagazine -- along with our partners NetApp and Websense -- on a webcast on June 20, 2007 from 10:30 am PST / 1:30 pm EST. The event will cover such log management topics as:

Aggregating and storing a "fingerprint" of all systems and user activity.
Learn best practices and mandates for log data retention.
Monitoring access to information stored in your enterprise.
Understand how to alert and report on the flow of information across multiple systems and platforms.
How does log data work together with information leakage solutions to prevent privacy violations?
How can you protect chain of custody and ensure that the information will stand up as evidence in the court of law?
How quickly should you be able to produce and share reports?
What are common reports and alerts being used for information asset and compliance enforcement?

Log data is the digital equivalent of a surveillance camera. It functions a deterrent and also provides legal evidence to prosecute those who leak or steal information. In this special Webcast, subject-matter experts from LogLogic, WebSense and NetApp will discuss how organizations can ensure IT Governance, Compliance and mitigate risk with multiple mandates using next generation Log Management and Intelligence, Data Leakage Prevention and high performance and high-security records retention.

Register here.

Technorati : , ,

Posted by Jill Ratkevic on June 19, 2007 in Compliance , Risk Management , Security | Permalink | TrackBack (0)

National Data Security Laws Evolving

Only about two-thirds of existing state data breach notification laws apply to state agencies according to Bruce Brody, vice president of information assurance at CACI in an article at Federal Computing Week.

FCW asks the question -- Would a federal breach notification law bring greater security and sanity to those who find their personal data has been lost or stolen?

The impact of emerging state laws targeting data security and how government agencies factor into being governed by those laws is quite an interesting read. And joining these local initiatives are a host of proposed national bills. The implications of these laws as well as the impact they could have on non-government organizations is going to be a hot debate. Even we got into the discussion, as our resident expert Anton Chuvakin (also LogLogic's Director of Product Management ) weighs in on the topic in the FCW piece.

Chuvakin notes that while existing state laws are already working to protect consumers, he cautions on the realities a national law could bring with it:

"Because many existing state laws are effectively working to protect consumers affected by data breaches, federal legislators must be careful not to pass a national law that is less rigorous than the laws many states have passed, said Anton Chuvakin, director of product management at LogLogic, a risk mitigation company. Were that to happen, he added, "some citizens could lose the protections they enjoy now."

As we noted earlier this year, ignoring data security mandates could cost plenty. Thanks to very high profile breaches like TJMaxx are not only making headlines, but some consumers are nervous about their data and privacy. And US Congress to the European Commission (EC), along with state initiatives in Minnesota, Texas, and California are popping up to deal with the issue.

Technorati : , , , ,

Posted by Jill Ratkevic on June 12, 2007 in Compliance , Log Management & Intelligence | Permalink | TrackBack (0)

2007 Log Management Survey Detailed

Yesterday, we held a webcast with The SANS Institute to announce the complete findings of the 2007 Log Management Survey. The survey, sponsored by LogLogic for the third year in a row, polled 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.

The verdict? The G2000 continues to adopt log management and intelligence to end the 'logjam.' Turns out that despite its importance, security 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. And, 43% indicated compliance with SOX, PCI and other mandates as the top priority. Download the Executive summary here or check out the Webcast findings here.


Technorati : , , , ,

Posted by Jill Ratkevic on June 07, 2007 in Compliance , Log Management & Intelligence , Risk Management | Permalink | TrackBack (0)

California Considers Making PCI DSS Law

This week California is considering a bill that would require organizations that accept credit and debit cards to follow the Payment Card Industry (PCI) Data Security Standard. Noncompliance could mean banks would have to cover the costs associated with notifying customers that their credit card numbers may have been stolen and the cost of replacing credit cards, at a cost that could run upwards of $1 million per breach, according to estimates in a California State Senate report in May that provided details on the bill. The California law would apply to anyone who wanted to do business with a California resident, according to this article at Government Executive blog.

The public backlash after the January disclosure of a major security breach by Massachusetts based retailer TJX has acted as a stimulus for attention and consumer protection mandates. Just last week Minnesota enacted the Plastic Card Security Act, based on the PCI Standard. And other states like Massachusetts and Texas are also considering laws. The Lone Star state's House voted unianimously to approve the PCI-related bill, but the state Senate closed its session before it could vote on the issue.

Log management can help out with complying with the PCI DSS regulations quickly, plugging into your existing IT infrastructure. For some tips, check out 7 Habits of Highly Effective PCI Compliance- a Forrester Webcast with analyst Khalid Kark, sponsored by LogLogic. A PCI book is on the way from LogLogic's Anton Chuvakin later this year.

Technorati : , ,

Posted by Jill Ratkevic on June 07, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)

ITIL Gets An Update

ITIL is getting an update after 7 long years. The UK's Office of Government Commerce (OGC) is updating their comprehensive documentation of best practices for IT Service Management. As part of the launch of the new ITIL V3, the organization is hosting a series of roadshows throughout the world beginning today in London -- with stops in San Jose, CA and Chicago, IL here in the US in June.

New ITIL V3 is to consist of 5 central books and an official introduction book, according to the OGC. These incorporate the best of ITIL V1, V2 and tested current best practice for ITSM. The 5 central books are made up of Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement.

CIO.com is featuring a good overview of ITIL with some pros and cons of using the framework. The short version is that ITIL is the industry's most widely accepted approach to IT service management, provides a cohesive set of best practices, drawn from the public and private sectors globally and is supported by field-tested implementation methodologies and assessment tools, certification and accredited training organizations.

LogLogic offers an ITIL Pocket Guide a pragmatic approach to ITIL implementations. There are 50 reports and 45 alerts in the LogLogic ITIL package to get you started with ITIL and Log Management and Intelligence. To obtain a copy of the guide, go here.

Technorati : , ,

Posted by Jill Ratkevic on June 05, 2007 in Compliance , Log Management & Intelligence | Permalink | TrackBack (0)

Why Banks Are Moving to Log Management

Banking Information Security magazine is covering the emerging trend in log management as it makes it way through the banking sector. They profile LogLogic cusomer, Citizens & Northern Bank, a $1.2B bank out of Pennsylvania, that has made log management a requirement for meeting compliance mandates with Gramm-Leach-Bliley and Sarbanes-Oxley. Using log management, the bank's auditors now have a way to easily track and monitor log data and get compliant fast.

Citizen's Bank learned early on what other G2000 companies are now realizing -- log management is inceasingly becoming the weapon of choice in the quest for compliance. Banking, an industry known for security and scrutiny of IT products is joining a growing trend of deploying log management for security, forensics, loss prevention and compliance. Why? As the article explains, the Industry's Federal Financial Institutions Examination Council (FFIEC) says that "without real log management, organizations are out of compliance and at risk" and calls on companies to monitor their log data. From the article,

"As administrators responsible for various network devices and operating systems, we need to know what typical behavior is," says Pete Boergermann, head of MIS at Citizens & Northern. "When we look at events, we are more apt to know what we are looking at and respond."

Read more about Citizen and Northern Bank's log management deployment in this SANS What Works case study from last year. Log Management and Intelligence is on the IT and business agenda. Industry trends are available in the just-released market survey on log management adoption. The LogLogic-sponsored research study with the SANS Institute is available for preview here or join us with SANS for a presentation of the trend at a joint webcast.

The complete article is at Banking Information Security, please note that registration may be required.

Posted by Jill Ratkevic on June 04, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)

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.

Technorati : , , , , , , ,

Posted by Jill Ratkevic on May 31, 2007 in Compliance , Log Management & Intelligence , Security | Permalink | TrackBack (0)

The Cost of Reputation In Light of a Security Breach

What is the cost to reputation from a security breach? Well it depends . . .

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.

In fact, the company announced in its first quarterly earnings statement that it took a $12 million hit (or 3 cents per share), owing the loss to the over 45 million credit and debit card numbers that were stolen from its IT systems over an 18-month period. During their earnings call, TJX went elaborated that they incurred an after-tax charge of $12 million for technical and legal fees related to the investigation and containment of the breach. Part of the costs, too, are for measures that they are taking in reponse to the breach to improve computer security and systems. This is $12M in addition to the $5M for similar efforts that the company reported at the end of the fourth-quarter. This means only one quarter into the new fiscal year, the company has already lost $17 million.

Between the above and a pending class-action lawsuit being filed by the Massachusetts Bankers Association, it stands to reason that the price of reputation is pretty high in response to a security breach. The ROI on proactively preventing breaches is far more tolerable -- and less costly -- for most companies.

Ignoring PCI Compliance could be bad for your business, and risky to boot.


Technorati : , ,

Posted by Jill Ratkevic on May 29, 2007 in Compliance , Risk Management , Security | Permalink | TrackBack (0)

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.



Technorati : , , ,

Posted by Jill Ratkevic on May 21, 2007 in Compliance , Log Management & Intelligence | Permalink | TrackBack (0)

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. . . "





Technorati : , , , , ,

Posted by Jill Ratkevic on May 17, 2007 in Compliance , Risk Management , Security | Permalink | TrackBack (0)

Innovation Stems SOX Costs

Today, Financial Executives International (FEI) announced the results of their sixth Sarbanes-Oxley compliance survey, which found that Section 404 compliance costs were down this year than in each of the first two years. Section 404 requires corporate annual reports to contain both a statement of management's responsibility for establishing and maintaining an adequate internal control structure and procedures for financial reporting and management's assessment, from the end of company's more recent fiscal year, of the effectiveness of the company's internal control structure and procedures for financial reporting. Section 404 also requires the company's auditor to attest to and report on management's assessment of the effectiveness of the company's internal controls and procedures for financial reporting.

They FEI surveyed 200 companies about their compliance experiences with Section 404 and based on the results, they concluded that the total average cost for Section 404 compliance was $2.9 million during fiscal year 2006, a 23 percent decrease from 2005 totals. The data also shows reductions in internal and external costs of compliance, with internal staff time decreasing by 10 percent. Additionally, total compliance costs have dropped about 35 percent since year one, attributed to companies' increased efficiencies in Section 404 compliance.

What is the root cause of this new found efficiency? FEI President and CEO Michael P. Cangemi attributes it, in part, to technological advancements in the field of compliance.

We've seen this trend of mature of approaches to SOX in spades. Log management solutions go well beyond SEM or SIM - they reach deep into supporting critical operational processes; automating and monitoring controls.

As compliance continues to be a priority in the boardroom, it will continue to drive software innovation through the coming years and software innovation will continue to make compliance efforts more efficient. And Log Mangagement is increasingly playing a key role in that transformation -- and costs savings in enterprises.

Technorati : , ,

Posted by Jill Ratkevic on May 16, 2007 in Compliance | Permalink | TrackBack (0)

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 by Andrew Lark on May 16, 2007 in Compliance | Permalink | TrackBack (0)

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 by Andrew Lark on May 16, 2007 in Compliance | Permalink | TrackBack (0)

SANS Log Management Summit WrapUp & Conference Materials

The