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)

More 80s: Rubik's Cube for Log Operations

clip_image001

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?

Posted by Dominique Levin on May 06, 2008 in | Permalink | | TrackBack (0)

Logging Poll #8 Context for Log Analysis

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

Past polls:

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

     

    Technorati tags: , ,

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

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

    clip_image002

    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!

    Posted by Dominique Levin on May 01, 2008 in | 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)

    Security Mash-Ups in the Cloud

    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!

    Posted by Dominique Levin on April 15, 2008 in | Permalink | | TrackBack (0)

    On Trusting Log Timestamps

    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:

    1. Mar 20 10:03:47
    2. 19/Mar/2006:04:27:33 -0800
    3. 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: , ,

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

    Is your digital shadow protected?

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

    Posted by Dominique Levin on April 02, 2008 in | Permalink | | TrackBack (0)

    Visit loglogic.com

    I ♥ Logs

    Subscribe to this blog’s feed RSS

    May 2008
    Sun Mon Tue Wed Thu Fri Sat
            1 2 3
    4 5 6 7 8 9 10
    11 12 13 14 15 16 17
    18 19 20 21 22 23 24
    25 26 27 28 29 30 31
    Categories
    Archives
    Blogroll
    Blogroll
    Compliance
    Good Reading
    LogLogic
    LogLogic Partners
    Sites We Watch
    Powered by
    Movable Type 3.2