However, I got a few emails from my readers asking me something along these line, thus this post. For example, I got asked "Should I focus more on targeting security professionals or general IT users?", "Any pitfalls I should be aware of?" as well as general questions about how to start, what content is best, etc all the way to "How did I profit from my blog?"

Q: Who should I blog to?

A: Blog to colleagues first i.e. infosecurity pros. Blogging to IT or general public is - in some sense - harder or - gasp! - will turn you into a journalist (someone who knows nothing about everything BUT writes about it as an "expert" :-)) Maybe you can broaden it later. Even better, write for YOU (!)

Q: What area of security I should focus my blogging on?

A: Focus on the area of security that you like the most or know them most: IDS? Patching? PIX administration? Linux? AD esoterica? Logs, maybe? :-) Then broaden if you feel like it or as you learn new areas

Q: Any advice on site design, themes, etc?

A: Site design, themes, etc will all come later; just pick something basic and FOCUS on content, not on SEO, design, etc. MUST have RSS feed; make it highly visible (HTML is out, RSS is IN :-))

Q: Any security blogging pitfalls that I should avoid? Any other tips?

A:

• Don't stick to only long, deep posts? Unbelievably, people often prefer shorter posts or a mix of short/shallow and longer/deep posts (that came as a shock to me early on!)
• Tips on how to do whatever useful work well; comments on hot issues (that you understand) works too for a shorter post.
• Definitely comment on other bloggers posts (more often early on, later - as you wish...)
• Avoid long breaks in blogging (>7 days); it will  lead to reader loss (you should only care about it later - focus on fun content first!)
• Join Security Bloggers Network (drop an email to Alan Shimel for it)

Q:  Has blogging in this niche generated any income for you? If so, how much?

A: Exactly $0. The reason is that I never wanted to "monetize" my blog;  I don't have banners, etc. This is by design.

Q: How did it help your professional career in a significant way?

Yes, I think it helped my career and connected me to a lot of fun people! I sure hope I am not "known only as as blogger", but blog can definitely make one much more known professionally, especially if you create fun and/or useful content.

Overall, blog is a time commitment, but it is also a passion. It does help your career, but "forcing " yourself to do it just for "career benefits" is,  IMHO, a wrong approach.

Yo, my fellow bloggers; help the newbies out, will ya?! Let's start a series of posts on "how to be a good security blogger!"

Somebody asked me: "That's great that you have such a clear  vision of a future log management technology - but tell me first what future business problems will such 'ideal tool of the future' solve?"

First, I laughed and said: "Dude, look around, will ya? :-) There are plenty of log-related problems today which we are not even close to solving. We need to solve the problems of today first, before we can get to solving the future problems..."

So, what I consider to be the biggest log-related problems of today?

1. Not knowing what to log - whether  for compliance, tracking attackers or troubleshooting system problems. Remember all the comedy about "Tell me EXACTLY what to log for PCI?" If not, reread it!
2. Log volume  - there is too darn many log messages (seriously, 100,000 each second is a lot of log - but there is more at large companies!), and, which is worse, a lot of them are of unknown value to the users (might be useful, might not - but you never know in advance); thus, log clutter networks, systems and brains of security/system analysts.
3. Log diversity - logs all look different (at least while standards are being developed) and no single person have the skill set to understand  more than a few types. PIX admin groking SAP logs? No way!
4. In light of the above, just pure bad logs are also a major challenge - logs that miss a key piece of info (like the infamous "login failed" without the username...) or are useless in some other way are sadly common.
5. How about getting the logs from all the nooks and crannies where they are stuck  (think application logs here) - it is a problem if you want to achieve  (expand, rather) your operational awareness of applications.
6. Finally (not really, the list can go on and on), making sense of logs in  an automated fashion is still a #1 challenge  (IMHO) - we are getting better creating tools for humans to go thru logs (via reports and search), but log->conclusion process still requires a human, and a darn smart one.

Now, when you read the above think "end user", not "log management  vendor" challenges (I plan to post about these later). My idea of an ideal tool will seek to solve these and others.

Along the same line, this picture from 4th SANS Log Management Survey shows how people perceive the logging challenges:

as well as my logging challenges poll (analysis here):

Now, let's think of logging problems of the near future, say in 2 years.

But you'd have to wait for the next post for this :-)

However, there are rare situations where you can choose device-specific log management approach (and still not look like a money- and time-wasting and idiot :-)). For example, you might be motivated by the fact that tools that can handle one specific type of log data (e.g. Windows-only, web server-only or Cisco PIX-only) are usually many times less expensive than cross-device log management tools. The table below clarifies it:

Also, while looking at logging tools, one needs to make a distinction between tools that can collect all sorts of logs but only allow you to analyze one log type at a time (e.g. sawmill) vs tools that can collect all sorts of logs AND allow you to analyze all of them together (e.g. LogLogic). The former tools still fall under "device-specific log management" despite their ability to gather hundreds of different log types.

The bottom line: in most cases, cross-device, uniform log management provides huge value, especially if your motivation for log management is compliance or incident response.

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 subjects): 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. Some vendors 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!

I actually read this earlier this week but did not have a chance to comment. ComputerWorld had this article today that details that Cisco will stop selling its line of PIX firewalls on July 28th of this year.  I don't think this announcement came as a shock to anyone.  They had discontinued their VPN 3000 concentrators a year ago and it was only a matter of time that the PIX boxes went the same way. For me personally the PIX firewalls just seemed to always be there. Yes Checkpoint was the "cool" firewall when I first got into security, but PIX was from Cisco and it seemed like the cornerstone of their security business.  Their IDS was not so good for a long time.  Cisco's other security products were never considered back then (or now for that matter) to be best-of-breed, but PIX was a product that was not a bad product in its class.

What is more important though is what is taking the PIX place. It is the ASA line of UTMs.  This presents living proof that the market is moving away from stand alone appliances like firewalls and IPS and towards UTM type of devices that also offer anti-virus, antispam, etc.  I personally had perplexing experience this week on this very subject. One large analyst firm claims that by 2011, 50% of all network security will be spent on UTM.  Then in speaking to an analyst from an even larger analyst firm, he said their position is that UTM will never catch on in the enterprise.  Even if they buy a UTM box, they will not turn on the other features.  So ASA boxes will just be used for firewall and VPN and perhaps IPS. 

Here is the Shimel analysis for what it is worth. I think the larger analyst firm is wrong. I think they have only thought this half way through. I think what the facts are is that people buy the UTM for just one or two functions.  I think that is true for both the mid-market and the enterprise market.  What happens is after they buy the UTM and set up either the firewall or IPS or what have you, geek nature takes over.  They can't help themselves but to experiment and tinker and see what the other functions can do and how they work.  If these other functions work reasonably well without choking the box, they will slowly but surely use the other functions as well.  So before you know it, that UTM that you bought as a firewall is doing UTM duty.

Anyway, any of you PIX owners out there don't throw out the old boxes just yet, Cisco will support them until 2013.  In the meantime I am sure there will be no shortage of vendors looking to give you a deal to upgrade to the latest box. In the meantime if all you are interested in is a good firewall, don't pay anything.  Go to http://cobia.stillsecure.com and use our community sourced firewall for free and upgrade to UTM down the road.

I actually read this earlier this week but did not have a chance to comment. ComputerWorld had this article today that details that Cisco will stop selling its line of PIX firewalls on July 28th of this year.  I don't think this announcement came as a shock to anyone.  They had discontinued their VPN 3000 concentrators a year ago and it was only a matter of time that the PIX boxes went the same way. For me personally the PIX firewalls just seemed to always be there. Yes Checkpoint was the "cool" firewall when I first got into security, but PIX was from Cisco and it seemed like the cornerstone of their security business.  Their IDS was not so good for a long time.  Cisco's other security products were never considered back then (or now for that matter) to be best-of-breed, but PIX was a product that was not a bad product in its class.

What is more important though is what is taking the PIX place. It is the ASA line of UTMs.  This presents living proof that the market is moving away from stand alone appliances like firewalls and IPS and towards UTM type of devices that also offer anti-virus, antispam, etc.  I personally had perplexing experience this week on this very subject. One large analyst firm claims that by 2011, 50% of all network security will be spent on UTM.  Then in speaking to an analyst from an even larger analyst firm, he said their position is that UTM will never catch on in the enterprise.  Even if they buy a UTM box, they will not turn on the other features.  So ASA boxes will just be used for firewall and VPN and perhaps IPS. 

Here is the Shimel analysis for what it is worth. I think the larger analyst firm is wrong. I think they have only thought this half way through. I think what the facts are is that people buy the UTM for just one or two functions.  I think that is true for both the mid-market and the enterprise market.  What happens is after they buy the UTM and set up either the firewall or IPS or what have you, geek nature takes over.  They can't help themselves but to experiment and tinker and see what the other functions can do and how they work.  If these other functions work reasonably well without choking the box, they will slowly but surely use the other functions as well.  So before you know it, that UTM that you bought as a firewall is doing UTM duty.

Anyway, any of you PIX owners out there don't throw out the old boxes just yet, Cisco will support them until 2013.  In the meantime I am sure there will be no shortage of vendors looking to give you a deal to upgrade to the latest box. In the meantime if all you are interested in is a good firewall, don't pay anything.  Go to http://cobia.stillsecure.com and use our community sourced firewall for free and upgrade to UTM down the road.