How To Become A Security Blogger?

I know, I know. Some might say that it is a silly question since you rarely seek to become a blogger - you just become one.

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

UPDATE: really good post "Why Blog?" from Richard.

ROI Jokes?

Yes, they ARE possible.

This also remind me of "ROI for compliance" stuff.

Every Time I See It, I Think About Logs

"Hotel chain now says data of just 10 guests was exposed; newspaper claims 8 million" (here)

Can't they look at logs and know for sure? Hmmm...

Do they have logs?

Do they know whether they have logs?

Do they know what are logs?

Ehmmmm...

Fun Reading on Security - 7

Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security." Here is an issue #7, dated August 27th, 2008.

1. Sad, but VERY insightful story of Alan Shimmel getting 0wned (1,2,3,4, others on his blog)
2. A very good essay on security industry/market/community "Evolution is Punctuated Equilibria" ("Right now, Internet security is due for another period of rapid change.")
3. As I like to say, most everybody in out industry is confused about risk (myself included, in fact) - here is some nice reading about the subject: "Quant love", "What is Risk?" ("The probability of a threat overcoming security controls resistance to exploit a vulnerability that results in a loss.") While you are at it, check this blurb about risk and CVSS (BTW, CVSS is about "V" - vulnerability, not "R" for risk!)
4. Solid gold on "running IT as business" (and where it hits the wall) - Richard, the original CIO.com piece ("If you've tried managing an internal IT department as a bona fide business you already know that you can't take that very far, for the obvious reason that your IT department isn't a business.")
5. More fun stuff from Richard on insiders and why NOT look for them (sadly, same logic applies to not looking for owned boxes in your environment...).
6. Analyst firms shocking discovery: wireless MAY have security issues (I guess count it as humor...)
7. Fun read: "Challenges of Enterprise Cloud Computing" ("By moving the data into the cloud, enterprise, for now, will lose some capabilities to govern their own data set.")
8. Raffy on visualization. ("One of the dangerous things is if you don't understand the log file itself, don't assume you'll understand the visualization of it or even generate a visualization that makes sense") Amen to that! BTW, Raffy's book is finally out.
9. Compliance and checkbox mentality: fun pickup from my original "DLP and Compliance" post - Rich and TechTarget. Good stuff! ("Don’t Sell ‘Compliance’ If It Isn’t A Checkbox ")
10. RedHat is nicely 0wned (more info)
11. BGP hole to dwarf the DNS hole?
12. Chris continues the virtualization and PCI DSS theme here. The jury is still out on this one, even though the common sense approach (that virtualization is OK in regards to PCI) will probably win.
13. NEWS FLASH! Privacy dies. The date of death? 1967. While reading it, think just how visionary some folks are...
14. Finally, just for laughs: How to Spin Bad News

Enjoy!

BTW, I am saving some fun reading for dedicated posts soon :-)

Run Through PCI DSS 1.2 Changes

Finally, I found time to read PCI DSS 1.2. change doc. So:

• Good news: router is now officially a firewall (it has been for a while, but many people are still stuck in "security device" vs "network device" cloud) - see Req 1
• From the "WTH dept": anti-virus is a MUST on ALL platforms - Req 5. Please ship me some of the stuff they are smoking; I want it! BTW, I am going to Amsterdam soon :-)
• WAF or code review for web application security is still a stupid "OR" - Req 6.6. OMG, please, software security folks, teach them the truth.
• Can we kill "plain text passwords" once and for all? Req 8 tries to achieve that noble goal (good thing!)
• Visit your offsite data storage - good (if costly) idea - added to Req 9. Requirements to secure electronic AND  paper media  are solid too.
• Love it, love it! Req 10 explains that logs needs to be actually available: 'three months of audit trail history must be “immediately available for analysis” or quickly accessible' (bye-bye, silly log dumps...)
• Some vulnerability stuff clarified in Req 11, mostly about ASVs and pentesting.
• Scope of security policy is expanded to "employee-facing technologies" (what a term!) - Req 12
• All over: more references to wireless  (WEP, access points, hidden SSIDs, etc) - indeed, recent data losses are often due to insecure wireless.

Overall, a minor change that, sadly, doesn't touch a few KEY areas, such as virtualization, for one.

Anton Security Tip of the Day #16: Virtually There - Journey Into VMWare ESX Log Analysis

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 Security Tip of the Day #16: Virtually Screwed - Journey Into VMWare ESX Log Analysis

CISecurty guide for VMWare (here) and DISA STIG for virtual machines (here) both mandate collection and analysis of VM platform logs; none goes into enough details on what to look for in logs. Let's try to shed some light on security-focused log analysis of VMWare ESX v. 3.x logs.

First, at least until ESXi becomes the default choice, one needs to keep in mind that ESX as "Linux-inside" and thus diving into /var/log will not reveal any "alien technology" (well, not much :-)). However, one of the most useful logs is /var/log/hostd.N which is not a descendant of Linux standard logs. Extensive VM event records are written into this file.

Let's focus on various types of logins to the ESX platform and identify logs that indicate a successful and failed attempts to log in. Here are a few useful examples to analyze:

Successful logins:

• May 30 09:20:42 esx2 su(pam_unix)[9405]: session opened for user root by jhonny(uid=1626)

This is a classic Linux root login message; you can watch for these by searching VMWare ESX logs for "session AND opened AND user AND root."  Notice the user name of the user who switched to root.

• May 30 09:20:34 esx2 sshd(pam_unix)[9364]: session opened for user jhonny by (uid=0)

This is also a classic Linux message for a normal (non-root) user login.

• [2008-05-25 06:57:48.774 'ha-eventmgr' 111639472 info] Event 40645 : User jhonny@1.1.1.1 logged in

This is a VMWare -specific application login to ESX. You can track such events by username, by event ID or by keywords "event AND logged AND user" (if you are using search)

Failed logins:

• May 30 09:20:31 esx2 sshd[9356]: Failed password for jhonny from 1.1.1.1 port 54773 ssh2

Another classic Linux message from the ESX system; a failure to login due to incorrect password.

• May 27 12:06:59 esx2 sshd[4756]: Failed password for illegal user jonny from 1.1.1.1 port 30594 ssh2

A message indicating a failure to login due to incorrect username (note a typo).

• May 25 07:03:48 esx1 sudo:     jhonny : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/var/log ; USER=root ; COMMAND=/bin/bash

This ESX Linux platform message should also be familiar to Linux/Unix admins: it indicates multiple sudo password failures; look for such messages in the logs.

BTW, do you need to be reminded to track NOT only failed, but also successful login events?!

Overall, you must prepare for the future by learning to analyze  VMWare logs, just like you handled "legacy OS", such as Linux/Unix and Windows.

As I said before, 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

RIAA Scum Beaten Back in Court

Wow, this is impressive and kind of "against the tide." It looks like you CAN win against RIAA in court....

eBook on Log Management

Check out this new log-related ebook from TechTarget: "eBook - Log Management: Effective Tools for Compliance Reporting and Security Event Detection"

Went on Vacation - Missed PCI DSS 1.2 :-)

OMG, I go on vacation for 3 days (pretty much offline) - and I miss pre-release of PCI DSS 1.2.
How unfair is that? :-)

In any case, I am baaaaaack!

A Few More Words on DLP and Compliance

Today I was thinking about DLP again :-) (yes, I know that "content monitoring and protection" - CMF - is a better description) Specifically, I was thinking about DLP and compliance. At first, it was truly amazing to me that DLP vendors "under-utilize" compliance in their messaging. In other words, they don't push the "C-word" as strongly as many other security companies. Compliance dog doesn't snarl at you from their front pages and it doesn't bite you in you ass when you read the whitepapers, etc. Sure, it is mentioned there, but, seemingly, as an after-thought.

For example, Reconnex that was recently absorbed by McAfee, touts "information protection" before compliance. Similarly, my friends from nexTier only mention "compliance" on a few pages. Even newly unveiled DLP resource  (DLP In-Depth portal) only contains a little bit  of information on how DLP solutions help with various compliance projects. People tout "data protection", " data security", "data governance" (aka "we know big words - bigger than you") or even "data risk management" (aka "we are confused about what we sell")

I decide to explore this curious phenomenon.

Initially, I thought that it was reverse compliance at work? People not wanting to know what content packs up and leaves their network. Then I thought that maybe DLP vendors just aren't "the bandwagon jumping kind" (yeah, right!) Then I thought that they are "beyond compliance" already :-)

But you know what? I actually think that it is something different, much more sinister. It is the ominous checklist mentality (here too)!  You know, DLP is newer than  most regulations (PCI DSS, HIPAA, FISMA, etc) and - what a shock! - the documentation for these mandates just doesn't mention DLP (or CMF) by name. Sure, they talk about data protection (e.g. PCI DSS Requirements 3 and 4), but mostly in terms of encryption, access control, logging (of course!).

Also, PCI DSS directly and explicitly says "get a firewall", "deploy log management", "get scanned", "install and update AV" - but where is DLP? Ain't there...

Yes, Virginia, folks who "go by the book" and just "do the minimum" are missing out on the chance to procure DLP while their compliance budgets are still flowing. To me that means that many still don't get the "compliance+" model - buy for compliance -> use for security, operations, having fun, etc. Think what a good DLP solution  will do for you in discovering regulated data across the entire organization, blocking those pesky email with SSNs, PHI (hi, HIPAA) and CCs (hi, PCI) as well as solving plenty of other problems ...

On Idiots and Logs

How on Earth can someone even utter the phrases "scalable log management" and "Microsoft Access for data storage" in one sentence? OMG, OMG, OMG...

MS Access, for God's sake! I wonder if they tried storing logs in Excel spreadsheets?

Yeeeeesh.

On Stratfor

I love Stratfor. I am addicted. They have a unique way of saying things, an elegant mix of insight, cynicism and humor. How about this one, for instance:

"But in Georgia’s twilight hour, Stratfor’s gaze is not particularly riveted on Tbilisi. Georgia’s fate is more or less sealed. At dawn either the bombs will fall and the tanks will advance and depose the Georgian government by force, or a siege will begin that will depose it in time. Either way, the government of what is currently known as Georgia will evolve into a form that slavishly respects Russian wishes. The only reason Russian officials have not said they will enforce “regime change” is because they feel the term is too American. Whatever the nomenclature, the details of how this change happens pale in comparison to what such a change represents."

Again, On Laptops and US Borders

"According to the U.S. Department of Homeland Security (DHS), Customs and Border Protection (CBP) officers can confiscate and detain travelers' laptops at the U.S. border without suspicion of wrongdoing. Laptops can be taken to an off-site location for an undisclosed period of time, during which officials may examine the computer's contents and share copies of files with other agencies. This policy applies to any other form of digital or analog storage device, including iPods, cell phones, flash drives, hard drives, and tapes." (source)

"The key to the above paragraph, of course, is "without suspicion of wrongdoing." Indeed, in the policy (PDF), DHS says (emphasis mine), "In the course of a border search, and absent individualized suspicion, officers can review and analyze the information transported by any individual attempting to enter, reenter, depart, pass through, or reside in the United States."" (source)

Fun question that was brought by someone on a security mailing list: if your employer-owned laptop is "captured" by DHS, TSA or Customs AND it has regulated information on it (CCs, SSNs, PHUI, etc), do you have to report it as "data loss"? The chances of that info being lost are definitely much, much higher now AND the control over such data is clearly not in your hands anymore... Niiiiice.

On TV Warfare

It is simply amazing that all the countries now "get it" that war happens primarily on TV (this vs this; many other examples are around). It is also amazing that there is NO way to know where "media reporting" ends and "psyops" begin. So, a burning tank with no clear markings that you see on TV might be:

1. Tank belonging to warring side A
2. Tank belonging to warring side B
3. Just a tank that was passing by and got hit by mistake :-)
4. Something that looks like a burning tank
5. An archive shot that reporter added for visual impact

Same applies to the "primary weapon" of a modern TV war: "evidence of atrocities of the opposing side."

What's the truth? Who knows... progress brought us "TV wars," is this the first "YouTube war"? But if we cannot believe the media coverage, how can we believe a random video online? Well ... maybe the same way we often believe Wikipedia over Britannica.

In any case, if there was a better time to turn off the TV (and tune off the web news...), it would be now. Also, time to get the dust off my copy of Toffler?

Rant mode off :-)

UPDATE: fun article on that very subject (media vs psyops) - "Debating Domestic Proganda: Part I"

UPDATE: "A column of Russian military vehicles, including tanks and armored vehicles, was reported to be moving toward Tbilisi with a journalist from U.S. media giant CNN riding along and reporting live for U.S. television. [...] The fact that Russia now has U.S. journalists embedded with its military to report every move being made is key. " (source)

Fun Reading on Security - 6

Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security." Here is an issue #6, dated August 7th, 2008.

1. DNS + Karma = Boom! Enuf said. Also, hear Pete Linstrom squeal.
2. Fun essay on "blocking" and risk. Is it our job to stop'em from using Facebook?
3. MS Exploitability Index. Smart ... or misguidedly focused on "vulnerability release" (and not creation)
4. Chip-n-PIN, a PCI killer? I don't think so!
5. Mike R revisits "good enough security" - read it, then review your IR plans (...for you will be 0wned)
6. Very fun RSA survey here; data leakage beats malware again, people still not report incidents (to whom???)
7. More and more and more people point at idiocies of academic security research... Read the whole w00t 08 thread here. Weep. Laugh.
8. Neosploit has a bad quarter... breaks support "contracts" ... shuts down? Ah, the economy :-)
9. Awesome stuff from  Richard Bejtlich: CAER.
10. "The Network Firewall is a Consensual Hallucination" :-)
11. More GRC-ball-kicking: here, here ("IT-GRC "vendors" are not IT-GRC vendors") - both are pretty insightful for GRC-lovers and GRC-haters)
12. More SIEM-ball-kicking: here ("underwhelming","ridiculous", "missing the point"), here ("dead ...unless","cripple")
13. Fun DLP portal launches.
14. Final word (?) on TerryChilds-gate here. "When management starts controlling the actions of admins, things start to fall apart." Huh? When management loses control of the business, it dies. Folks, IT vs IT security gap IS real. I never quite believed it, but this taught me a lesson. Some common security sense for a change (also here).

Enjoy.

Even More Logging Questions - Answered

I did this fun webcast on logging for accountability (here) and people asked a lot of good questions. Here are some of the answers for them and all my blog readers.

 

Q1: How do you handle variety of log sources? There are so many, almost beyond my capability.

A1: Sorry to ponder the meaning of "is" here, but what is meant by "handle"? It is really not that hard to collect logs from a large number of diverse sources (as long as the logs can be delivered via syslog or exist as files and can be collected). Now, there will certainly be challenges  when the volume of logs gets large, but if by "handle" you mean "collect + store", it is really not that hard, given the right tools. Now, if "handle" means "make sense of what all those logs are trying to tell you," it is a different story altogether.

 

Q2: You talked about the importance of logging; however for an intermediate or novice admin what are the starting steps .. what are the minimal logs they should start at once?

A2: Answered in "Log Management - Day 1" If you want a simple list of things to "enable today,"  I cannot really answer it since I know neither your needs, nor your environment. In other words, this is the "what is the meaning of life question?" :-)

 

Q3: What regulations, rules or guidance exist regarding sharing or visibility of logs to users?

A3: PCI DSS says in Requirement 10.5:  "Secure audit trails so they cannot be altered.
10.5.1 Limit viewing of audit trails to those with a job-related need
10.5.2 Protect audit trail files from unauthorized modifications
10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to
alter"

NIST guidance for FISMA also says something similar (for example, look in NIST 800-92 doc). Overall, log protection and security are mentioned in many other regulations as well.

 

Q4: Privileged groups membership monitoring in AD one of the most important from my point of view. However I did not find effective way to monitor/report on changes in those groups. Any recommendations?

A4: This is indeed a tricky one which might take more space to answer than I have here; it might also take you 'beyond logs.' One good source of information is Randy Smith's site and, specifically, his webinar on 'Active Directory "Logging Gap"' (here somewhere) - which covers how to audit things of that sort when then native logging is not sufficient.

 

Q5: How I can learn what exactly I need to log?

A5: OMG, this is a $1,000,000 question :-) Let me answer "how can I learn" part and not the "what exactly I need to log part,"  (also see discussion on "MUST-DO Logging for PCI?") as it is actually answerable. To learn what you need to log, first ask "Why?" (and then see this) - basically establish what you want to accomplish with logs, catalogue your systems, figure how to tweak the logging knobs - and then do it!

 

Q6: How granular should logging be? What is your recommendation for enterprise servers like domain servers and Windows servers?

A6: Again, too long to answer here in details (it will become a subject of a longer blog post later), but some pointers follow: here for Windows (MS site also have a few recommendations on audit policies)

 

Q7: What is "more control" and what is "less control" that you mention in the webcast? Can you give an example?

A7: OK, I did say that "sometimes when you implement more controls, you actually have less control." What do I mean? If you buy a firewall (a network security control) and then - over time, of course - configure it with 7800 rules (!) that are supposed to give you control over who can and cannot access your network, you will not gain control over your environment. You will actually be less in control of who is touching your network, compared to, say, having only 20 rules.

 

Q8: What about mandated NIST controls for government systems? Auditing is a specific control for Moderate and High risk systems. What list of events do you recommend for auditing?

A8: This is too long to answer here, but NIST 800-92 Guide is a really good source of such info ("Guide to Computer Security Log Management [PDF]") Also, see my presentation on NIST 800-92 Guide in the Real World.

 

Q9: The issue that many organizations get stuck on, is the monitoring process, and defining what exceptions to monitor for? Is there guidance / framework for this? How much of it is system specific and how much is applicable generally to all systems?

A9: I outlined some general ideas back in 2004 via this presentation (note to self - update that to be more 2008-relevant); it is mostly general, but also has pointers to specific system. Keep in mind that it is focused on security, not operational monitoring (which is often no less important - in fact, often MORE important)

 

Enjoy! Sorry for being brief with some of the answers - I am woefully late with this even as they are...

Other questions that I answered in the past:

• More Log Management Questions - Answered!
• Some Burning Logging Questions - Answered!

Poll #9 How Much Log Security Do You Need?

Yes! YES! Y-E-S! :-)

My next logging poll is out - with it I set out to figure out the old mystery of mine, why people don't protect their log data (e.g. see this lamentation "Top 11 Reasons to Secure and Protect Your Logs")

Vote away! As always, results will be posted.

Past polls and analysis are all here. Enjoy!

Ideal Tool to Solve Real Problems ... of the Near Future? - II

I would like to continue the discussion I started in my previous post called "Ideal Tool to Solve Real Problems ... of the Near Future?" Specifically, upon outlining some problems with logging, I will now forecast what will happen with them in 18-24 months.

• Which problems will be solved and forgotten?
• Which ones will simply go away?
• Which ones will persist and in fact increase?
• Finally, which new ones might emerge?

First, let me bet my ass that "Not knowing what to log" problem will be licked in 18-24 months; at least as far as major regulations go, people will have a pretty good idea a) what  the auditors want them to log (and review!) b) what they need to log for solving their problems. Now, for esoteric log sources (and custom applications) might still present a challenge from that point of view, but for basic "staples" (firewall, network gear, major OS) the mystery will be over (again, see "Tell me EXACTLY what to log for PCI?"  for reference)

Next, the problem of "Log volume" will  definitely get worse, much worse.  One might think that 100,000 each second is a lot of log - but there WILL BE more at many companies! Big application log explosion is coming, fueled by the need to address logging in areas where such motivation was lacking before (basically, custom and vertical applications) as well as harness the power of "uncommon" logs for such tasks as fraud analysis or SOA monitoring. Keep in mind that even though in some areas logging is NOT a preferred way of monitoring and auditing activities (see this discussion on database logs here), application logging will still explode on us...

The problem of "Log diversity" (the fact that most logs all look different in format and meaning) will get worse before it will get better - and better it WILL (!!!) get since standards are being developed. We will see people struggling with all sorts bizarro log data in the coming years. Virtualization, web services and SOA, various ERP applications and even cloud services will increase the diversity of logging in the coming years.

Similar to the above, a problem of "Bad logs" (ones that are subjective, miss key information, require groping for a crystal ball to understand, turn log analysis into dark voodooistic experience or are useless in some other way) will also follow the pattern of the above log diversity problems - it will get worse before it gets better (via the CEE standard effort that now covers the OpenXDAS effort as well!) I noticed that people started asked me questions about "how to do application logging right?" and "what to tell application developers about logging?" which almost never happened in the past. BTW, watch my blog for some uber-fun info on that!

"Getting the logs"  has gotten much easier in recent years; agentless collectors like Project Lasso (which, BTW, just got updated) and grabbing  files remotely via secure protocols made application log collection easier (syslog-NG with TCP transfer and buffering also helped). Next, Windows 2008 will make it MUCH easier for the whole Windows kingdom due to their use of web services (thanks Eric!). However, in the future it might resurface as we try to collect logs from "weird" places, again, clouds come to mind as well as virtual environments (e.g. how do you get logs off a dormant VM?). What's the next frontier in this area? Log discovery - automatic finding and identifying log files on systems in order to analyze and retain them (Yo, my t-shirt-making colleagues... :-))

All this, however, pales in comparison with my favorite "uber-challenge", "Making sense of logs in  an automated fashion" - this baby is definitely not going away in 2-3 years. Much more research is needed to make that "log->conclusion" jump automatically without head-scratching, invoking ancient deities and cursing under ones's breath. Only then we can attempt to reliable handle "proactive logging" (i.e. analyzing various failure or compromise precursors in logs and then predicting the future based on them), another Holy Grail of logging domain.

Anything new will emerge? Yes, I think awareness of the "Logging Gap" problem will grow. "Logging gap" happens when you combine "a need to log" with utter "inability to do so."  For example, this will happen when people will know that they HAVE TO log, say, for compliance, but will have no way of doing it due to application or platform limitations. This will become one of the challenges and special "logging add-ons" will appear to close the logging gap and create additional logs where activity audit is desperately needed, but native logging is not helping to achieve it.

Also, I think people will finally wake up to "Log security" challenges - i.e. producing for use as evidence, compliance attestations, etc. Log security is not getting the attention it deserves, but I think this challenge will finally emerge in full force in the next 2-3 years. My next poll will address that :-)

Anything else I missed? Share away!

Related posts:

• Ideal Tool to Solve Real Problems ... of the Near Future?

• Ideal Log Management Tool?

Monthly Blog Round-Up - July 2008

I saw this idea of a monthly blog round-up and I liked it. In general, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today. This is an attempt to remind people of useful content!

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.

1. As you can easily, easily guess, the  #1 spot this month is taken by my irreverent comments on a Terry Childs saga. Namely, "On Doomsaying (Terry Childs case)", "So ... Am I? Maybe I Am!" and "Admins , Good Guys or "I am NOT an Idiot!""
2. Obviously, my earlier post/rant called "You Are "A Security Idiot" If ..." takes the #2 spot. Yes, we all like to point out other people's problems, especially when they are epically huge :-)
3. Next up is my post "11 Signs That Your SIEM Is A Dog or "Raffy, You Killed SIM!"". It is both humorous and sadly true (and backed up by other sources)
4. Also popular is my post "Log Management - Day 1," which talks about the very first thing you do when embarking on a journey to log management.
5. Finally, again this month, my logging polls took the #1 spot!  Poll #8 that covered context data for log analysis is analyzed here. Other popular polls include a controversial Windows Log Collection Poll (which is a poll #7)  and poll #6 about logs that people actually look and poll #5 about logging challenges.
6. Strangely, a lot of people wanted to "Which Blogs Do I Read?" - so my brief post on that made it to the top.

See you in August, unless you are all on vacations, that is :-)

Possibly related posts / past monthly popular blog round-ups:

• Monthly Blog Round-Up - June 2008
• Monthly Blog Round-Up - May 2008  
• Monthly Blog Round-Up - April 2008  
• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

 

Technorati Tags: blog,security,loggings,monthly