Logblog

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

2008-05-08T22:33:45Z

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:

Time/date
Computer where it happened
User who touched the file
Application he used to access the file
File name + location (directory, share, etc)
Type of access (read, write, create, delete, etc)
Status (i.e. success or failure)

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:

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?

Enable logging (as described above)
Pick events 560 (most useful) and 562, 567 (useful too)
Look for fun filenames that might be touched by the users (have a list of files and users handy)
Figure out what programs were used to access them (this is called "Image File Name" in "WinLogSpeak")
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: security, tips, logging, log management

More 80s: Rubik's Cube for Log Operations

2008-05-06T08:02:26Z

While log management for operations and log management for compliance or security are different applications, they share many of the same foundational requirements so system administrators can benefit from recent advances inspired by security applications:

- Collection

The ability to collect log data from a large variety of sources – with different protocols and different formats, either through an agent-less or agent-based infrastructure. A near-real-time collection is also critical to both security and operations use of logs. Such timely collection enables alerting that warns the users of recent or even impending system failures.

- Normalization

The ability to compare log data from disparate sources. For example, the ability to run a user activity report aggregating all login activity for a particular user, including login to the VPN and the finance server. Or such as the ability to run one report that shows all activity for a particular user, from e-mails sent to websites visited. For operational use, performance measurement across different systems can only be done on normalized data.

- Summarization

The ability to count and summary the log messages collected, by log type, by message type and such. One failed login perhaps isn’t meaningful, but more than five in a row could be significant. The same logic applies to system errors and failures that needs to be reviewed while using logs for maintaining and optimizing system and network operations.

- Statistical analysis

Unusual patterns in log data, an unusual ratio between accepted and denied connections on a firewall for example, can be an indication of a security breach. In the future, statistical algorithms applied to log data may enable failure prediction and other advanced analysis that directly contributes to improved SLAs.

- Alerting

The ability to trigger (near) real-time alerts that are user configurable, either based on manually written rules or automated statistical analysis. Such alerts serve to bring urgent issues to system operator or security analysts attention.

- Search

Search is central to log-based investigations, whether for an operations use (such as system fault investigation) or security use (hacker or insider attack). An ability to go through 100% of logs is key for all three uses for logs: security, compliance and operations. Such searches must be fast and easy – so that users are able to run them while under pressure of a troubleshooting or security incident.

It is also important to note that log management for operations has its own unique requirements:

- Collection revisited

Faults are notoriously singular – this means that they occur once, but never again in quite the same manner. Therefore it is very difficult to predict what log messages are going to be most useful for problem isolation and most practitioners now admit it is best to keep all log data around for post-incident analysis. Therefore, the requirement to collect 100% of all log messages of all log sources is even more important in operations than it is in security.

- Log browsing (data mining)

While for compliance, an auditor may review the same report (say failed logins) every quarter, no two troubleshooting session are quite the same. Problem isolation is an interactive process of trial and error. An administrator may look at the same data from many different angles before understanding the root-cause – like examining a Rubik’s cube. Reports have to be customizable on the fly. Pre- and post-report filtering options are important to allow for dynamic report (re)-configuration. Search is important, but not sufficient and you will likely want to be combine search with access to normalized and cross-correlated information.

- Search (and reporting) speed

Speed truly matters when it comes to fault detection and problem isolation. Whether a forensic investigation takes one hour or one day or one week usually doesn’t really break the bank, but whether a down-time situation persists for minutes or hours can be a matter of many millions of dollars in missed revenues. When troubleshooting a problem, every query must be very fast: whether indexed search or a report against normalized data, every second and every minute counts.

- GUI and Workflow

An external auditor looking at logs to verify that nobody improperly accessed credit card information is going to follow a very different work-flow from an internal investigator examining a potential fraud case and yet completely different from that help-desk person who is trying to tell you why your e-mail isn’t being delivered or your VPN connection is so slow. For optimal functionality and productivity, the best graphical user interfaces and workflows are application specific.

- SOA-based portal or mash-up

The initial fault alarm will likely land with a help-desk employee; in the form of an HP Software (or equivalent) alert, a log alert or a phone call from an unhappy user. Either way, the first-level support person will attempt to perform some analysis. In many cases, truly understanding the problem requires access to log data. Without log automation, it could require a phone call to a third-level support person and a long wait-time until the escalation managers returns his log analysis. However, in the new brave world of log analysis, the help-desk employee could access log data remotely with a single mouse-click assuming the task is made easy enough. It probably means further customizing the workflow and GUI to a particular customer’s situation. This is easy to do with today’s web 2.0 technologies and open web services APIs: a custom portal or mash-up can be created in days.

- SOA based integration

Unlike with log management for security, for fault analysis very mature consoles and dashboards exist. These event management systems even have correlation and alerting capabilities. Rather than replacing these systems with yet another console, most companies are going to look for the ability to integrate a new information source, log data in this case, into the existing fault management console. Web services likely will be the mechanism of choice.

- (Lack of) archiving

Keeping log data around for long periods of time is not a requirement. Data quickly loses its value after the fact. However, mining historical data patterns to predict future failures before they occur can be very valuable. This field is still in its infancy, but shows a lot of promise. Given enough data, both error data and fault data, predictive analysis is not far in the future.

It appears to me that the ideal technical architecture for log management recognizes both similarities and differences of the various log management use cases (and there are many more than just security and operations). Would the ideal solution perhaps be a common log data platform that can collect, aggregate, summarize, normalize, index and apply basic analytics to log data once, while allowing for a many different user experiences depending on the use case?

Technorati Tags: logs,log management,problem isolation,SOA

Logging Poll #8 Context for Log Analysis

2008-05-05T22:01:08Z

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: logging, log analysis, polls

The best of the 80s: log management for operations!

2008-05-02T07:15:18Z

Log management has been around for a loooong time. In the 80s log file management was the primary mechanism for fault analysis and management of computer systems. Also in the 80s, Eric Allman at the University of Berkeley developed a logging standard called syslog as part of the Sendmail project. While adopted by quite a few applications, many other protocols and formats persist until today.

The sheer success of log data nearly killed it. The cacophony of log formats and the sheer volume of messages generated – up to 40 terabytes a month for a mid-sized organization or, shall we say 100,000 log messages every second (!) , it is impossible for any human being to keep track of all that logs have to say. Based on SNMP alerts and other event data, including selected error log messages, large-scale event management systems such as HP OpenView emerged as the new kings of fault detection.

If it was not for compliance and security concerns, log management might not have made it back. But out of a need to track user activity and to identity potential insider and outsider intrusions and transgressions of corporate networks emerged a new form of log file analysis. Log data featured prominently in Paul Proctor’s Practical Intrusion Detection Handbook in the late 90s for example and tens of companies emerged to perfect the art of security event management based on log data.

Now, in part due to virtualization and the ever increasing cost of downtime in our networked economy, system and network administrators have re-discovered log data. In surveys, 70%+ of organizations confess their primary budget for log management still comes from compliance. However, this same group admits for years now that 70% of their use of log data is driven by operational needs such as fault detection and problem isolation. This is no surprise, because operations use cases can drive true log management ROI. One minute of down-time could cost millions so if automating log management can help to accelerate problem isolation, then companies are willing to pay big bucks. If giving help-desk employees access to normalized log data can off-load expensive third-level support personnel that is even better.

So, as the sun is setting on HP OpenView (the name was changed to HP Software in 2007), a new dawn has broken for log management in operations! Hoorah!

Technorati Tags: log management,fault management,problem isolation,operations

Critical Log Management Questions - Answered!

2008-04-24T16:38:53Z

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:

political boundaries within the organization: "these are our logs, and you are not getting them"
privacy laws: some logs cannot be collected in some countries; some cannot cross the border, some cannot be seen by some people, etc. This is true mostly in EU, less in US.
legal blocks: work with legal before deploying any org-wide log management; legal might try to prevent certain data from ever being created (for fear of being legally discovered later)
log volume: underestimating log volume is common and pretty nasty
related to the last one: vendors being "optimistic" about their tool scalability
time synchronization (of course!), specifically, lack thereof.

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:

logging affects performance much more on some types of systems compared to other types: most painful examples are databases where some people (can't find a link...sorry) report performance loss of up to 40% if logging all SELECT statements and other data retrieval commands (you need to log selectively on these); in other cases (e.g. web servers) there is no performance loss and logging is "always on"
log collection: agents impact system performance (long post on this subject): a little when they run (everybody knows this) and A LOT when they crash (few people think about it - agent software memory leaks are not uncommon); unlike agents, remote agentless log collection barely affects system performance (unless you have one of the few esoteric cases)
log transfer and network performance: look for compressed (logs compress really well), TCP-based transfers; syslogging over UDP uncompressed has a chance of doing a pipe saturation DoS on your network. Yes, people say "use a dedicated LAN," but this is definitely wishful thinking for many. Also, raw UDP syslog in large quantities over WAN = insanity :-)

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:

provide them a useful service based on their logs (e.g. performance measurement, availability monitoring, compromise detection :-), or other security metrics, etc)
help them with their compliance mandates (e.g. create reports that they can show to the auditors that "bug" them)
give them tools to better solve their problems (e.g. allow access to a log management tool so that can investigate issues better, search the logs, check on their users, etc)

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: logging, log management

From Log Apathy to Log Enlightenment

2008-04-22T22:29:03Z

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:

Deep log ignorance: "Logs? What are those?"
Shallow log ignorance: "Later...later...later... #37 on the TODO list."
Log collection: "We gather and store dead log data...cold."
Log searching: "We will dig into the pile when we have to ... hopefully never!"
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: logging, log management, loglogic

RSA 2008 Summary

2008-04-16T23:31:28Z

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: security, RSA, conference, 2008

Security Mash-Ups in the Cloud

2008-04-16T06:52:13Z

In the past 90 days, Savvis, Verizon Business Services and SecureWorks launched hosted or cloud-based log management services. Customers do not pay for owning any log management infrastructure, but rather for using it and typically pay monthly on a per-device basis. Security in general and log management specifically lend itself well for a cloud-based model since compliance mandates and new threats continue to evolve and require continuous updating of reports and alerts, in addition to a high level of expertise, often not found in-house. Stephen Northcutt from SANS has made the case for outsourcing Log Analysis here.

But there is one more significant advantage to Security in the Cloud … Security service providers can be (and are) light-years ahead of product vendors when it comes to putting together integrated compliance offerings. Customers typically access cloud-based offerings through a web portal. Using web services, service providers can quickly and easily create compliance mash-ups, for example combining reports from vulnerability scanning services with log management-based user activity reports. Very cool!

Technorati Tags: Log management,cloud-computing,SaaS,security,mash-ups

On Trusting Log Timestamps

2008-04-04T23:35:23Z

It is about time: specifically, timing logs. As I said in my Log Trust and Protecting Logs from Admins posts, the issue of trust is critical in the logging world. After all, logs = accountability; and the latter in unthinkable without trust. If we are to at least pretend that logs objectively record events and user actions, we need to unambiguously establish WHAT happened and WHEN. This post deals with the 'WHEN' issue.

So, can we trust that the time stamp in the log file or the one added by the log management system correctly describes when the recorded event actually happened?

We will start from locating the timestamps in logs. Most of the log formats, such as file-based logs (web servers and proxies, various application, some security gear, etc) and syslog, Windows event logs, database audit tables, etc contain a timestamp. Here are a few examples:

Mar 20 10:03:47
19/Mar/2006:04:27:33 -0800
Sun Mar 19 04:45:19 2006

In fact, once I saw somebody use a timestamp to define logs as "timed records of IT activity." So, time is critical for logs being, well, logs :-) At this point it is worthwhile to note that file-based logs will contain a timestamp IN the file, while syslog records arriving over the UDP or TCP port 514 connection are usually timestamped upon arrival BY the syslog daemon (using its own "knowledge" of time) - and then it shows up in the syslog files in /var/log.

Let's assess whether this "in-log timestamp" provides an adequate way of timing the actual events that are being logged. Answering this question is important for investigations and troubleshooting, but becomes nearly a matter of life and death in case of log forensics. Here are some fun cases and issues to consider:

First, what are the chances of a completely false timestamp in logs (BTW, today is Jan 1, 1970!) When might that happen? Typically when a logging system own clock is reset or not set correctly. This timestamp clearly should NOT be trusted. How do you then time this event? This is a separate story that will be discussed some other time...

Second, it’s always 5PM somewhere: in other words, what time zone are your logs in? EST? PDT? GMT? UTC? Or any of more than 24 other possibilities. If you have no idea, you should not trust the timestamp.

Third, are you in drift? Is your system clock? Those pesky drift seconds turn into minutes that then work to undermine the accuracy of timing the records (and thus your certainly and trust in evidence quality)

Fourth, syslog forwarder mysteries are plenty: some of the syslog messages will be delayed in transit and then be timestamped by the final recipient daemon, thus completely losing when the event was originally logged. Admittedly, this delayed syslog messages are rare, but as more people employ buffering syslog daemons (e.g. syslog-ng), it might happen more often.

Fifth, more esoteric, but still real (and really annoying!): some system logs will contain two timestamps. If you don't possess in-depth knowledge of this specific log, confusion has a chance to undermine the trust as well (so, which timestamp should I use?)

Sixth, most people will not think that they will fall to something that stupid: 24 vs 12 hour time. However, when facing an unknown (and poorly designed!) log format, beware that 5:17 might well be 17:17...

Finally, if you know that something got logged at 5:17AM, then when did it happen? Beware of "Log lag!" This issue is actually too tricky to give it justice here... The simplest example is when the process leaves a log record when it exits, not when it starts, which might happen days earlier (thus creating a log lag).

As we dive into more issues with timing logs, we also need to think about sequence timing and absolute timing. Sequence of logged events is a critical fact! Miss the sequence and the whole “house of cards” goes … But! Absolute time is also important! Can we be assured of both being correct all the time? (hint: no)

So, when you look at logs next time and you see a timestamp there - start thinking about all of this :-)

Technorati tags: logging, logs, log management

Is your digital shadow protected?

2008-04-03T06:14:59Z

Many UK retailers handling credit card transactions have no visibility of who has been accessing data within the company network, as reported by Computing Magazine based on research by Vanson Bourne on our behalf. Almost half (45 per cent) of the 60 medium-to-large UK retailers polled – which include supermarket chains, department stores and clothing retailers – are unable to track and trace data access. Even at those retailers who do track data access, security breaches can go unnoticed for an entire day in most implementations.

The responsibility for protecting and maintaining 85 per cent of your ‘digital shadow’ including financial records, web surfing histories, historical credit card transactions and such lies with businesses such as retailers, according to a study commissioned by EMC.

Is it surprising anybody that fraud is at an all-time high? This too has been reported on by our UK friends at Computing Magazine, based on research by KPMG. It sure seems like across the pond they have all the numbers to backup why user tracking should be a priority. So why isn't it? Problems cited by the IT directors in our survey include budget restrictions (24 per cent), time (14 per cent) and other priorities (41 per cent).

What Log Data can (not) do for Hannaford

2008-04-02T05:56:06Z

Indications are that the recent, massive, breach at Hannaford Bros. Co.'s supermarkets was an inside job leveraging a sophisticated malware deployment. We were asked today whether malware will generate logs that we could have picked up in the Hannaford case and the answer in general is "no". These types of software are very evasive and try not to leave any type of trail while running.

However, what could help investigation in this case is logs generated by the systems on a day-to-day basis. These logs can be used for forensic analysis, e.g., potentially identifying who did the installation and where they came from. In this case, logs from the POS systems, servers that manage the data, databases that store the data, firewalls that protect these systems, can all be used for forensic analysis.

Of course this case is getting national attention because the number of customers affected (4.2 million) and the large number of fraud cases (1,800) already linked to the data breach. However, there are a ton of breaches that happen on a daily basis. A good place to track them is The Breach Blog.

Compliance or risk? Install cameras first.

2008-03-28T20:36:17Z

Our Chief Logging Evangelist, Anton Chuvakin, recently published an article in SC Magazine on an integrated approach to Governance, Risk and Compliance (GRC). He argues that eventually a piecemeal response to compliance won’t do. Rather, why not define some security goals up front, such as “who should have access to what”, then enforce those policies through technologies such as identity management, configuration management and segregation of duties analysis. Of course I agree. Who doesn't? The key word being ‘eventually’.

Let me give you an example from the physical world. LogLogic’s offices are set away a block or two from the main road. In recent months, a number of cars in our parking lot were violated - scratched, windows smashed and GPS devices stolen. What to do? Using the GRC analogy, we might restrict access to enter or exit our parking lot. We could build a fence and install a guard post. While effective, this is a costly and time-consuming approach. What really happened? We installed security cameras. Will this guarantee there are no more incidents? Of course it will not. However, it was quick and cheap and reduced our risk. So far it has helped.

This brings us to the fourth corner of the GRC puzzle – log management. Why not start your GRC initiative with basic user tracking? It is quick and cheap, but it goes a long way. Just by watching you reduce your risk. Having studied user activity for a while, it also becomes easier to take the next step. In our parking lot analogy, by watching the security tapes we might see a lot of strangers entering and exiting our lot at certain times a day and decide that we want to hire an external security firm to patrol the lot at those hours. More about that in a later post. It is no different in cyberspace. Using historical user activity data, I can now target an identity, configuration management or segregation of duties roll-out to start with the most frequently used information assets. And yes, eventually, I will reach GRC nirvana.

Technorati Tags: log management,GRC,compliance,identity

Quick and Fun Poll on Behavior Change

2008-03-27T08:39:07Z

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: chuvakin, logging, log management, polls

Imprudent Curiosity?

2008-03-24T08:42:58Z

In the past week, two high profile cases of improper viewing of personal information hit the wires. Ironically, there is much good news in both incidents. Note that these were cases of imprudent curiosity not of information leakage or theft. Workers were caught snooping around and disciplined or fired. The good news is that companies are increasingly tracking user activity, in particular user access to sensitive information. One way to track user activity is by collecting and analyzing log data. Remember to also protect archived log data as legal evidence if you want to use the data to substantiate employee dismissals.

UCLA Health System employees reportedly accessed Britney Spears' medical records without authorization. The Los Angeles Times reported about a week ago that 25 staff members, including six physicians, could be disciplined or fired. UCLA's medical center immediately launched investigations and the UCLA chief compliance officer revealed that the hospital has "people dedicated to looking at records to monitor access". When employees look at a patient's records electronically, they leave an electronic trail. "The systems track which screens they view and for how long".

Days later, news broke about a similar case of 'imprudent curiosity'. The State Department confirmed that that some of its workers had improperly rummaged through the passport files of all three presidential candidates, Obama, Clinton, and McCain. Two contract employees were fired and a third was disciplined for accessing Obama's passport data. A department spokesman said: ``Our initial view is this was imprudent curiosity on the part of these three individuals,'' Still, the State Department was taking steps ``to assure ourselves that it is nothing more than that.''

Protecting customer data in mid-market companies

2008-03-18T18:27:04Z

Today we announced our new product line for mid-market companies. These are all-in-one appliances that combine embedded compliance content with real-time analytics and long-term forensic archival. Some customers have compared our new products to the Mercedes C-Class. They never thought they could afford a Mercedes, but now are driving their favorite car.

My conversations with reporters such as Alex Woodie, Paul Korzeniowski, and Zach Church have been thought-provoking and have forced me to articulate what is different about meeting compliance mandates such as PCI and HIPAA in the mid-market as compared to large Fortune 500 organizations.

The bottom line appears that the same compliance and information protection mandates apply in full force to large and small companies. As a consumer, I expect my credit union, local retailer and regional hospital to be equally vigilant about protectiing my personal information, as Britney Spears painfully experienced.

The difference is that small companies have fewer resources, expertise and budgets. The primary competition in the large enterprise is a homegrown solution, whereas our primary competition in the mid-market appears to be 'doing nothing'. It is not apathy or ignorance, because mid-market customers deeply care but they need to do more with less. Unless the solution is highly automated they simply don't have the resources to act.