Fun Reading on Malware

The most moralistic virus? The most sensationalist virus? The most diligent virus? Fun reading from Panda

On Ugly Stuff

So, Mike Murray brings up this fun point: ' My favorite way of asking it: "What, if your company [...], would be a complete deal-breaker for you? What would make you completely disengage?"'

I'll bite, Mike: one of the truly disgusting things (which would make me reach for my resume in a second) would be for a [security] product company to use a competitor's product to protect its own network. Don't laugh (please cry, in fact!), this stuff actually happens...

I am sure that decent companies run their own stuff and Snorts happily protect Sourcefire's network while Proventias guard ISS (and now IBM) from evil attackers, thus telling the world that their stuff is indeed the best for them as well as their customers. However, what in the whole wide world would make you buy security gear from somebody who prefers some other brand to his very own? And what would make you work for such a company [well, maybe a fat salary will :-), but that is a separate story]?

A milder version would be to simply shy away from using its own product, because it is so "enterprise-grade" that a small company (such as its creator) will not benefit from using it internally. It is a bit less disgusting and credibility-busting, but it smells pretty darn bad as well...

Response to Comments on Predictions

So, I got a few fun comments on my recap of my 2006 security predictions.

Specifically, "Gabriel" said that server attacks have not fallen. Indeed, I would agree that a rise in web application attacks more than covered a drop in server platform software attacks so we are kinda both right (I should have said "server platform software attacks dropped" and not "server-side attacks dropped"). Thanks to "Gabriel" for noticing and clarifying it!

Also, he is just as correct in stating that wireless driver attacks have emerged from the underground. However, I would still claim that wireless attacks have not become anywhere near widespread as worms and virii :-) hits of the 1999-2003 or spyware infestations of 2003-2006.

Also, the next step in my track to highly-awaited 2007 security predictions (I am NOT posting them yet!) would be to pick on somebody else's. Maybe it is just my mood today, but I am very eager to call somebody a dumbass for predicting something truly ridiculous... :-) Stand by for that!

My 2006 Security Predictions Review

So, no, you are not getting my predictions yet, but here is something fun: a review of my last year's predictions. They were:

1. Viruses, worms, bots and spyware will remain the main concern; malware commercialization will continue and thus propel more money-making technologies such as spyware (5,5)

STATUS as of 12/22/2006: Correct (but it was a reeeally easy one)! Recent polls still show that malware tops the charts (even though various forms of regulatory compliance, IP theft [as some has us believe] are challenging that)

2. Data/IP theft and especially ID theft will continue and increase in both severity and occurrence (5,5)

STATUS as of 12/22/2006: Correct (at the very least, the buzz levels about this are skyrocketing); phishing and identity theft - as a type of IP theft - were certainly growing and so was the IP loss in the form of laptop loss.

3. At least one major 0-day compromise story will surface, maybe with Oracle software (5,4)

STATUS as of 12/22/2006: Correct (see recent MS Word 0day stories); Oracle bugs were aplenty, but nobody admitted that they were owned thru one ...

4. Application-level vulnerabilities will grow, service-level ones – shrink (5,4)

STATUS as of 12/22/2006: Correct (see recent SANS Top20 for some illustration); the decrease in network-service level vulns was dramatic, but SQL injection, XSS and other stuff grew like mad.

5. Client (web, mail, chat, etc) attacks will rise and server attacks will fall somewhat (4,5)

STATUS as of 12/22/2006: Correct (see recent SANS Top20 for some illustration), but no credit really - this one was trivial to predict.

6. Major wireless and mobile threats will not come (4,3)

STATUS as of 12/22/2006: Correct (but, again, I see this as an easy one)

7. Endpoint security solutions and NAC-like technologies will experience sharper increase in adoption than other security tools (3,4)

STATUS as of 12/22/2006: Correct; again, if we measure by media buzz levels and [late] company launches, NAC and endpoint security is still heating up

8. Finally, I predict that just as one cannot predict the threats of tomorrow today, one still won’t be able to do in 2006 :-) (5,5)

STATUS as of 12/22/2006: but of course! Indeed, there are many things that I am pretty sure we would all love to predict but just as unanimously missed.

So, I officially upgrade myself to Chief Security Nostradamus :-)

Musings on Logs

Don't you just hate it when you have to parse logs that look like this 'This event contains REPAIR PROCEDURES for the 1084 event which has previously been logged. This message indicates a specific issue with the consistency of the Active Directory database on this replication destination. A database error occurred while applying replicated changes to the following object. The database had unexpected contents, preventing the change from being made."

More on Trends and Predictions, New and Old

So, to throw those waiting for my 2007 predictions off the track, I will post my predictions (sort of) for 2004 :-) It is my old SANS presentation on "What is NOT Working in Security 2004;" yes, old it might be, but it is still a fun read.

My Security Predictions for 2007 .... Not Yet

OK, it looks like I just have to respond to this. The claim was made that one has to unleash his or hers (hmmm...) security predictions for 2007 immediately.
But - guess what- I will be a party pooper and will hold on to mine.

Feel free to see what I collected so far: security predictions 2007 tagged at del.icio.us

So, no, I am not posting my predictions just yet. In this prediciton game, you know that whoever waits the longest (preferably to the end of 2007 :-)) wins (i.e. looks like less of an idiot :-))

Isn't Compliance Cool? :-)

At least, PCI compliance is: where else you can win a large bonus cash prize for doing something that is mandatory (and you'd be fined if you don't do it)

"Earlier this week, the company announced that it has created a new $20 million incentive program under which it will monetarily reward "acquiring" financial institutions if their members are fully compliant with PCI requirements by Aug. 31, 2007. At the same time, acquiring banks that fail to ensure compliance by Sept. 30, 2007, will be assessed fines starting at $5,000 a month for each noncompliant merchant. The fines increase to $25,000 per month for each noncompliant merchant after Dec. 31, 2007."

Database Security ... Not

Isn't embarrassing when someone posts a guide on how to secure a database and doesn't even mention logging and audit logs? It sure it, but at the same time it shows something pretty pervasive and unfortunate: many folks who run database have no idea who does what with the data (and, to a lesser extent, with a database itself) since no logging is enabled, with the possible exception of logging major failures with the database software itself.

DBAs who don't care about data in "their" databases is a sad phenomenon indeed. But then again - somebody got to help the incident response consultants to get rich! And the media needs constant flow of hotter and hotter breaches and data thefts! Go ahead, help these folks, continue to ignore logging on your database and reap generous rewards, such as seeing yourself on CNN (right before you "see yourself" on a pink slip! :-) )

Wireless Network Get More Secure ... Duh

So, this ancient blog post stated that "80% of wifi networks [are] insecure" ( and points to a Slashdot interview with the author of Kismet). The date on the post is 08/20/2004; more than 2 years ago. And a funny thing happened - wireless networks actually gotten more secure! Nowadays one can't be certain that he would see an open wireless network whenever one sees a bunch of wireless networks somewhere...

As similar things happen in other areas of IT, the specter of security being done is being raised once again. But - guess what? - the answer is still NO.

Is Humanity Getting Dumber?

This sure makes one think so, what happened to common sense and basic kindergarten physics ...

“Imagine a plane is sitting on a massive conveyor belt, as wide and as long as a runway. The conveyor belt is designed to exactly match the speed of the wheels, moving in the opposite direction. Can the plane take off?"

Now, how many of you would NOT be able to answer this within, say, 30 seconds (I am being generous here)? Such people should please read Darwin and then try to remove their genes from the humanity gene pool in whatever manner desirable and ASAP!

One piece even called this "a brain-teaser" - yeah, maybe, if you lack the very organ mentioned above :-)

Another Old Presentation: On Log Centralization

Another Old Presentation of Mine: On Log Centralization. My old preso on data ... centralization; note that I might not agree with everything I said back then (more on that in the near future ... )

More Proof that CA = No Brain

As you, my dear readers know, I sometimes like to point at really, really stupid things that I see in our domain. Here is one: "Vista will force need for network forensics."

This security VP from CA (you can start laughing now, but please wait for a punchline) claims that "Encryption by default means that without user credentials it will no longer be possible to investigate user behaviour at a disk level." thus "The result? Network forensics is rapidly becoming the next big thing in IT security."

So, who can name more reasons why this pathetic attempt to sell "CA Network Forensics" product is laughable?

Here is one reason to rule them all: network encryption is here NOW, disk encryption is coming in the FUTURE. Thus, if disk encryption will break disk forensics, than network forensics is broken already...

BTW, looking at logs for forensics will always be useful - but that is another story altogether :-)

On Annoyances, Major and Minor

Arrrgh, I just want to kick whoever redesigned the UI look and feel of Google Desktop: from the most useful and neat tool to a hateful annoyance in one quick automated update ;-)

So, maybe Google Desktop is spyware after all?

Oh, What the World Came to: Blocking Word Docs at the Gateway

So, this has been making rounds for a few days already after yet another (and then two more...) 0day in MS Office was discovered, but it got me thinking. The issue is that some orgs (NASA is mentioned here) chose to "block the receipt of Microsoft Word documents coming in to the space agency's core computer network as e-mail attachments" this time.

Would you do this? Or will your business units eat you for lunch and have nothing left for dinner? Now, almost everybody blocks EXE and COM as well as VBS on their gateways and it is seen as a reasonable practice. But DOCs?

So, Are Agents Evil?

I admit I am late to this agent-slamming party started by Matasano folks, but I want to play "kick an agent" as well :-)

So, I've yet to see a person who willingly says "yep, I wonna go and deploy agents on all of my 23,000 servers and desktops" even if he KNOWS that he will get a sizable benefit as a result of doing it (and, sometimes even when said benefit is not achievable without all those agents)

Unfair? And so is life...

Anton Security Tip of the Day #6: The Other Web Log

Following the new "tradition" of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to go along and join the initiative. One of the bloggers called it "pay it forward" to the community.

So, Anton Security Tip of the Day #6: The Other Web Log

We all know that Apache web server has its access_log log files while IIS has its w3c logs. When people think about web log analysis, they think about the above and only about the above logs, often calling them "the web server logs." However, the other web log - error_log (in case of Apache) - contain a lot of fun and useful info as well. Today's tip is to encourage the review and analysis of this treasure trough - pardon the idiom - of insight.

So, what goes into the error_log? Well, errors, duh! Why errors matter? 'Cause errors often present the only indication that a) you are being 0wned or, worse, that b) you've been 0wned by the attackers. Additionally, apart from the obvious security usage mentioned above, errors matter since they - or rather, some of them - require actions by the user and thus knowing about them is of huge importance. What is even more striking is that many error messages present an interesting tradeoff - do only a little now to correct the reasons (or, "the root cause" as network management people would say) for the error, or do a whole lot later when the system crashes, gets hacked or "misbehaves" in some other truly spectacular way. Now, a grizzled BOFH would surely say "heh, but who would want to do that! surely, dealing with a dramatic world-ending catastrophe later is more fun that making a minor config fix now." Well, I sincerely hope not all of my readers are such people :-)

Now, back to the Apache errors; we are going to show a few examples from a live phishing site, run by the attackers on a compromised server. We will start from the obvious - server restart, which actually happened as a result of an attack, in our case.

[Sun Mar 12 04:02:05 2006] [notice] SIGHUP received. Attempting to restart

Did YOU restart the server? No? Two choices then - someone else did (likely without permission!) or the server got restarted automatically for whatever strange reason. You certainly need to be at least somewhat concerned in both cases - thus: look for the above messages.

Here are a few more fun examples - the relevance of those for your business is left as an exercise for the readers, but all of the messages below

[Mon Mar 13 14:54:11 2006] [error] [client 10.10.10.10] Premature end of script headers: index.htm

Does "index.htm" sound like a script to you? It sure should not; and this error message indicates that somebody is trying to run it as a script - a clear indication of malicious behavior. The next message is also similar in this regard:

[Mon Mar 13 14:54:26 2006] [error] [client 10.10.10.10] attempt to invoke directory as script: /var/www/cgi-bin/tcpsupport/

and so is this one:

[Mon Mar 13 14:54:23 2006] [error] [client 10.10.10.10] (8)Exec format error: exec of '/var/www/cgi-bin/tcpsupport/main.htm' failed

Other interesting things spotted on the same server -this one looks like an overflow attack attempt (and, no, the NIDS did not make a squeak about it)

[Thu Mar 19 07:16:11 2006] [error] [client 10.10.10.10] request failed: URI too long (longer than 8190)

So, to conclude, the tips is: when doing web server log analysis, make sure you look at the error logs as well as the access logs.

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

Does the Word "Content-Free" Rings a Bell? :-) More on Logging

This piece, even though it borders on being content-free at times :-), has a few fun insights on logging and audits (some painfully obvious to us logging people :-))

For example: "Does the fact that audit logging is enabled satisfy all the different regulatory compliance requirements? [...] In all but the most generic cases, the clear answer to this is no." But of course! Having logs is great, but looking at them is awesome (and sometimes required - see PCI Requirement 10)!

Or this "gem" - "The problem is no one looks at these logs unless something bad happens" which goes straight back to my famous (and old) "Five Mistakes of Log Analysis" paper (an update, called "Six Mistakes of Log Management" is to be published soon) Having a log management solution solves this one nicely.

Or this one: "Audit logging is not just for compliance reasons." Guess what, every sysadmin worth his salt have known this for, say, 20 years :-)

Overall, the piece is much better at asking questions than giving answers. Seriously, is this true: "What do you log? Do you look at successes and failures? How vulnerable are your logs once they've been written? How long do you keep your logs? Only you can answer those questions." No, there are pretty good answers already given to the questions above. Such answers are given in various regulations (some mentioned in the article) as well as "best practice" and IT governance frameworks, such as COBIT, ITIL and various ISO docs.

Mike Rothman kicks it as well by saying "Kevin Beaver beats the horse a bit too much about why you should log (providing the regulatory context) and not enough perspective on how you should do it."

In any case, I liked the blurb since it helps to bring awareness of log management to those still hiding from it under their desks...

Today is My Birthday ...

... feel free to send gifts NOW!

UPDATE (based on a comment below) - my Amazon wishlist

Yet Another Not So Old Presentation on Linux Intrusion Discovery

Here is one more of my old gems: a presentation on Linux Intrusion Discovery.... This presentation from a couple of years ago covers how to discover the common signs that your Linux system is compromised by attackers (yes, it has stuff on logs as well, of course, but not as much as I wanted - maybe I will create something separate in the future)

ISP Have to Preserve and Destroy Logs, Both at the Same Time

Here is a bizarre story, related to log management. "The highest appeal court in Germany has decided that T-Online, one of the largest German ISPs has to delete all IP logs to guarantee the privacy of their customers."

Obviously, all I know is the press story, but it sounds weird enough to mention. Moreover, here is how it works, reportedly.

"The decision (German) does not mean that T-Online is now obliged to delete all their IP-logs, the customers first need to complain. "

So, lemme understand, the logic is "surf to an illegal website -> complain to an ISP -> have the proof of that removed." Neato! The only thing that mitigates it is the fact that many ISPs would not have retained the logs anyway ...

And it ends with: "After the district court and the regional court, now the federal appeal court decided that T-Online has no right to store the IP-logs without a legal reason." [whatever such reason might be]

It also seems directly related to this piece of mine on "Access vs Access + Audit." I also wonder what happens if some regulations call for log retentions while others for log destruction and you are subject to both. Aaaah, compliance is so much fun!

On Cyberterrorism and ROI, Kind Of

"What would the ROI be for a terrorist organization wanting to take advantage of cyberterrorism, and how would they measure it?"

Read it; I won't spoil the conclusion for you here, but it is pretty much what you'd think :-)

Not New, But Interesting: Anti-Virus is "Dead"

Just a fun read - here is quote: "Bottom Line: By the end of 2007 stand-alone AV will be dead, d-e-a-d, dead! Organizations need to evolve their client security programs or expect to see increased costs as the number of agents continues to rise."

Another Fun Old Preso: "FTP Server Intrusion Investigation"

Here is another fun old preso of mine: "FTP Server Intrusion Investigation." Now famous FTP server intrusion investigation, including log analysis, disk forensics as well as lessons learned; all still fun and useful, but circa 2002.

Somehow, This Caught My Attention :-)

A very fun read: "A Hard Lesson in Privacy" that somehow caught my interest. I wonder why... need to psychoanalyze ;-) It all starts from "My brother-in-law just bought a used Intel 20" iMac. The seller was a nice looking blonde, who didn't wipe the disk."

Old (But Still Fun) Presentation on Honeynets and Honeypots

Another classic :-) presentation uploaded (in addition to this one on Unix rootkit analysis): my old (circa 2002) presentation about my experience planning, building and running honeypots and honeynets.

On Oracle 0days

I just love this quote from a DailyDave post:  'releasing Oracle 0day is like "picking on a retarded kid with no legs and arms"'

It also reminds me of this; the day of reckoning is near :-)

And What if the Logs WEREN'T There?

So, Andy plays off my bit on ignoring logs and relates a story where logs proved crucial. Great! However, what is the pink elephant in the room and where is the fat bastard hiding? :-)

[dramatic pause] :-)

Well, Andy discovered the mischief by looking at the logs, but what if the logs weren't there (happily rotated away or erased by the attacker)? Doesn't it just fill you with dread and make you run, not walk to all your systems and cranking the logging up, way up? And then, of course, buying some log management to handle the resulting volume ... :-)

A Passing Comment on ROI of Security

So, a colleague sent me this link ("3 Metrics To Gauge Security Spending") and I was meaning to think and blog about it (yes, in that order :-)). But then Mike Rothman opined that this guy is a dumbass in his blurb "3 ways not to gauge security spending". So, what's the story?

First, bear with me since I am still trying to build a coherent picture of security ROI for myself from all the diverse sources of info, some as smart as Pete Lindstrom :-) In general, I am leaning towards "there is no ROI for security; there are only cost savings" (which, as my in-house Ph.D. economist stated, are neither the same nor equivalent)

So, let's see, what is this guy suggesting: "If security spending exceeds 10%, your business architecture is probably poorly designed to cope with attackers." Huh? What's up with the magic number? So, 9.5% certifies you as OK? Sounds like an application of "all hard problems of the Universe have easy, clear and simple INCORRECT solutions" :-)

Further, "If the cost of your security investment is 200% or more of the value of employee downtime, you may be spending too much on security." Same problem - see above, bro.

Going down, "If you are experiencing a loss of 1% or more in productivity, review how you are protecting your information." No comment, really. Wait, one, actually: bullshit.

And, on top of the above, I just hate it when people proclaim something truly obvious as if it were some kind of news, so this guy definitely commits this crime: "The goal of total security is not achievable in complex systems that have millions of hardware and software vulnerability points." Wow, that's deep, good thinking here... NOT! :-)

So, I am with Mike on this one and he said it best: "These "metrics' will do nothing but waste your time, except maybe the gauging the cost of downtime one. I can only hope your CIO didn't read this drivel, because then you'll start to see this crap on your 2007 MBO's."

Security in the Age of Web 3.0

Just think about - how would information security look in this world

Are YOU Ignoring Logs?

So, as I said, DarkReading published this fun list of commonly overlooked aspects of security and one of them is - surprise, surprise! - related to logging. The specific item is "Analyzing trends in security log files," but it applies in general to ignoring logs, at significant peril to your organization.

As usual the log volume is called out as the primary reason for behaving stupidly ("In fact, most IT and security pros have so much log data that they typically only skim it, or ignore it altogether.") BTW, I am preparing a longer post to illustrate just how much data that can be...

At the same time, it is certainly nice that DarkReading chose to quote the experts in their piece :-) Even though their obsession with NBAD (in this context) is puzzling... They also seem genuinely confused about the relationship between SIEM/SIM, NBAD and log management.

On Most Overlooked Aspects of Security

As my loyal readers know, I sometimes have an unfortunate tendency to enjoy reading and writing about mistakes. Well, if no mistakes are in sight :-) an "overlooked aspect" will have to do :-) So, here is a list from DarkReading:

1. "Physical security
2. Proper disposal of devices, storage media, and sensitive documents
3. Background checks
4. Getting control of the at-home user
5. Taking advantage of built-in security functions
6. Analyzing trends in security log files
7. Training
8. Outsourcing of security functions
9. Encryption
10. Integration of security with software development"

Enjoy! And, of course, the #6 (Analyzing trends in security log files) deserves a separate post (stand by for it :-))

Old (But Still Fun) Presentation: Illogic Rootkit Analysis

I started uploading some of my olde :-) presentations on Slideshare, enjoy the first one: on Unix rootkits and Illogic Kit Analysis (from 2002)

Revisiting 80% Mystery

So, everybody heard that "80% of something bad is due to insiders;" moreover, many just hate this mystery statistic. Here are a few common and different versions:

1. "80% of security attacks are due to insiders."
2. "80% of security loss is due to insiders."
3. "80% of statistics are made up." :-)

Should we completely scrap this 80% beasty or is there any truth in it, after all? Recently I've seen a discussion on one mailing list where some pretty darn smart folks swore that they can personally attest that one or the other version of the above is "absolutely true."

So, any defenders/attackers of the above?

On "What Will Future Anthropologists Deduce from Firewall Logs?"

Now, apparently on a semi-humorous note, Dave Piscitello writes this fun blog post "What Will Future Anthropologists Deduce from Firewall Logs?"

Here is how it starts: "Imagine that several centuries hence, anthropologists uncover a hoard of archived tapes containing terabytes of firewall log files recording events from the last decade of the 20^th century and into our present day (2006). Now imagine that they discover how to read the media and open the log files."

Read on for laughs, but not only for those. There is enough sad truth in the conclusion ...

So, You Think That Security Is ...

.. about
a) fighting nefarious hackers
OR
b) protecting information

Now, if you ask as many of our colleagues about this, do you think you'd have more of "a)"-people or "b)"-people? Any bets on the percentages?

Just a random thought of the day...

Humor ... or NOT?

Quotes says all: "an anonymous security professional trying to block field employees from bringing a virus into the office by delivering to all their machines a copy of the virus named as “I_AM_THE_VIRUS-DO_NOT_RUN_ME.doc”. What happened?"

So, is humanity incurable? :-)

On Technology Advances ...

I love both quote and the concept : "Feel like you've lived a wee bit too long? Looking for a spectacular way out -- one that'll keep your family crying in disgust for years on end?"

Yeah??!! Try this new means of transportation: a personal helicopter.










Image borrowed from: http://www.defensetech.org/archives/002980.html

SANS Top20 Controversy

Hmm, I didn't realize that SANS Top20 project has gathered so much controversy lately. So, it all started from these two posts (1 and 2) and the main flash point is this:

"As far as the nature of the [SANS Top20] list goes, it's important to realize that it's based on a bunch of people's opinions."

For whatever reason, some people took offense in this (e.g. here), but why? As a SANS Top20 contributor since 2003, I can tell you that the list is certainly based on opinions and I am happy that my expert opinion was counted among others.

But guess what? When you go to a doctor, what he tells you is his expert opinion, not necessarily raw facts. He used facts, hopefully, to form an opinion. In case of SANS, the list was even called "The Experts’ Consensus", which unambiguously implies expert opinions.

Now, there is another, more serious concern being raised: that the list is not as actionable now as it was a few years ago when it contained individual vulns and CVEs. Well, this one is not true: every item still has sections called "How to Determine If You Are at Risk" and "How to Protect." So, you read the first one and act; then, if exposed, read the second one and act. Done!

On Security Mistakes

I love talking about mistakes :-) In fact, I wrote a few fun papers summarizing common mistakes in intrusion detection, incident response and log analysis. But Richard Bejtlich did a one up, summarizing "Common Security Mistakes."

Those are (quoted from his blog post):

1. "Failure to maintain a complete physical asset inventory
   
2. Failure to maintain a complete logical connectivity and data flow diagram
   
3. Failure to maintain a complete digital asset/intellectual property inventory
   
4. Failure to maintain digital situational awareness
   
5. Failure to prepare for incidents"

What I like about them is that most revolve around not knowing what you got ... Indeed, before you mire yourself in prevention-detection-response, you need to think for a few seconds :-) about what are you trying to protect....

On Obvious X

Now, we know that there are some dumb people out there. Thus, there would be some dumb people doing market research in security. Today the enlightened Mike Rothman attacks one batch of such people, who, after apparently months of research came up with this amazing deep (NOT!) insight: "Blocking viruses is the number-one reason companies purchase new network security products and services." Wow, that is sooo new, circa 1987. In fact, I am willing to be that compliance beat malware as a security motivator some time last year, at least as far as large orgs are concerned.

To add insult to injury, the Infonetics opus contains a few other humorous bits: 50% of companies have deployed NAC, while the other 50% haven't cause they don't know what NAC is. Seriously!

Conclusions on my Security Conference Poll

Here are the results of my security conference poll, as of today (11/16/2006). Which information security conference do you like the most?
		FIRST (46%)
		DEFCON (12%)
		BlackHat (10%)
		SANS (all) (7%)
		Other (7%)
		CanSecWest (5%)
		RSA (4%)
		Gartner IT Security Summit (1%)
		ISACA (0%)
		Security Decisions (ISD) (0%)
		CSI (all) (0%)
		MISTI (all) (0%)
		ISSA (0%)
		TechnoSecurity (0%)
		226 total votes

What are the conclusions:

1. The link to a poll was posted on a FIRST web site. I will let the reader decide the causality here :-)
2. DEFCON/Blackhat still rock!
3. SANS is great as well, presenting a close adjusted (see item 1. above) second after DEFCON/Blackhat
4. Some shows where we usually notice an abundance of fake experts presenting their rants are rated low, as they should be
5. Some Gartner folks blessed the poll with their votes :-) (Hi, Rich!)
6. Looks like I totally failed to spell out some of the popular shows, since Other category is so big (please, please, dear readers, post comments and enlighten me on this)

Obviously, the results reflect the bias of my readership selection, but, at the same time, they are not entirely unexpected...