BlackHat 2009 Day 1 – Laws of Vulnerabilities Panel

Since I am press (got my ridiculous pink  badge tag already), I will write :-) After catching part of the keynote (the Google guy was pretty interesting with his security thinking – however, I suspect when he says “users”, he means much better people than a typical organization), I am at Qualys-led (Wolfgang) panel with GE (Richard), Orbitz CSO (Ed), Heartland Payment Systems CSO (Kris), Goldman Sachs (Paul) and State of CA (Mark).

Wolfgang showed the updated Laws of Vulnerabilities (all details here); some good insights to take away are (if you were not here – there was a lot more of great insights than that!):

• Half-lifes of vulnerabilities (=time in which half of the vulnerable boxes get patched) didn’t change much since 2004 (same as the research revealed at RSA 2009 showed)
• No matter how old, many vulnerabilities stay forever on some systems (or new systems with old vulns are being connected). 8-10% of machines which were vulnerable stay vulnerable for as long as the research covers, but likely forever. This about it! Even old critical – “Insta-0wn”-type – vulnerability stay forever on some – likely compromised – systems.
• If you limit the scope of half-life analysis to core OS vulnerabilities, the half-life drops to 15 days (which means that people patch those quickly!) On the other hand, if you limit it to Adobe and MS Office flaws, the half-life sharply rises to 60 days (which means people just don’t care – and the current dramatic “0wnage” will continue)
• “Speed up patching!” call is still needed, despite it being made for years and years. Looks like people get to pay attention to OS flaws, but not to client issues.

The panel then discussed that doing “single day”  patching (holy grail for many organizations) is doable even in large companies, but that is not the end of it -by far. For example, Ed from Orbitz comments reminded folks that “deploy patch” becomes  “write patches”  for custom apps. The problem thus becomes worse and worse, if you happen to have a “build, not buy” culture: the percentage of systems that you can quickly patch becomes lower and lower.

A lot of interesting comments were made by the Heartland CISO (who, BTW, joined 2 weeks before the now-infamous election breach disclosure) about how a breach motivated a change in their patching process. He said that they used  to focus most resources on payment processing environment, but then their non-CDE corporate network was breached first and analyzed for 7 months (!) by the attacker who then broke thru the developer access to CDE. Patching client flaws on the corporate (non-CDE) side is now a priority as well.

Richard’s comments come from the IR/IH side. For example, in case of a particular Adobe flaw, they saw exploitation activity on the 15th, were informed about the issue on the 21st, and then the patch came on the 28th (timeline approximate). Thus, even if you patch really well, finding 0days becomes key since 0-day 0wnage is rampant if you are the “right target.” In-house research is the only choice in this case, I suspect.

Afterwards, Kris from Heartland made a few one comments on DLP: they use it for discovery and data auditing, not for data leak prevention (which is definitely very reasonable). Another interesting theme (brought up by Ed) was not just awareness of what is going on your network (which is hard), but also on all the supplier networks that connect to it. This is a curious mix of technical security and legal, contractual stuff.

Finally, an interesting insight came to me from listening to this panel: evidence of different focus of security management was clearly heard - some organizations focus on patching the right segment, some on faster patching, some on limiting access, some on network visibility. To me this spells the end of the quest for “security best practices” since your “best” might be doomed to be forever different from others “best” …

Overall, this was a very fun panel to attend!

Now, on to the  “Weaponizing the Web” talk.

Meet at BlackHat and DEFCON?

Just a quick note to folks who are going to BlackHat 2009 and DEFCON 17 (and Security BSides, of course!): see you all there.

Another Claimed "0wned While Compliant" Case ... NOT!

So, another card data theft (only 500,000 cards this time, not a biggy :-)), another chance for some folks to scream "PCI didn't save me!"

In particular, the paper has this quote:

"Wade added that Network Solutions is compliant with the Payment Card Industries (PCI) Data Security Standards, but did not immediately know when the last compliance assessment was conducted."

Stop ... right ... here! This is "delusions of compliance" case, a very clear-cut. Even without ever seeing her environment, I can guess that:

• She has absolutely no idea whether they are compliant at this time or at the time of the breach!
• She can hope that they were indeed compliant with all the necessary requirements whenever they were validated (not sure QSA or SAQ)
• She can hope that they were in compliance at the time of the breach, but I bet a bottle of bad vodka that they were in fact NOT!

Please save us from another round of "PCI didn't save us, thus it is bad!" Think for a second before you spout it...

How to Harness the Power of PCI DSS? Tip #3

Inspired by the panels we did on PCI (here, here), I decided to start a series of posts with tips on harnessing the amazing motivating power of PCI DSS for meaningful security improvements. These tips are most useful for those in the trenches who are required to comply with PCI DSS while keeping the systems running and secure but maybe do not know how, and not to those who whine, bitch, blog and twitter their way to infamy…

So, got a nice heavy PCI hammer? Where do you hit for security?

Tip #3 will again focus on something very basic, non-controversial and, again, spelled out relatively clearly in PCI DSS: namely, vulnerability scanning, which is itself part of vulnerability management. Basic? Hell yeah! So then, pray tell me, why is it one of the most common PCI assessment failures (see Branden for evidence)?

First, where does PCI DSS guidance talks about vulnerability scanning? In Req 6 and 11, namely:

“6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks” [and vulnerability scanning is one of the options]

and

“11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).”

So, when you see the above what questions pop up first? My tip will be in answering them!

Q: What systems must I scan for PCI DSS compliance?

A:

• External: “all Internet-facing Internet Protocol (IP) addresses and/or ranges, including all network components and devices that are involved in e-commerce transactions or retail transactions that use IP to transmit data over the Internet” (source: “Technical and Operational Requirements for Approved Scanning Vendors (ASVs)”[PDF] by PCI Council). The answer can be “none” if your business has no connection to the Internet (duh!)
• Internal: all systems which are considered “in-scope” for PCI, which is either those involved with card processing or “directly connected” to them (source: PCI DSS[PDF]). The answer can also “none” if you have no systems insider your perimeter which are in-scope for PCI DSS.

Q: Is there a pass/fail criteria for scans?

A:

• External: Yes, here is an example below from Qualys site:

PCI DSS ASV Scan Criteria

Vulnerabilities with a CVSS v2.0 base score of either 4.0 or higher will cause PCI compliance to fail on the scanned systems (excluding vulnerabilities leading only to denial-of-service issues)

A system will be considered non-compliant if the SSL version installed on it is limited to 2.0 or older.

Vulnerabilities that may lead to SQL injection attacks and cross-site scripting will result in a non-compliant status on the corresponding system.

These are derived from the same “Technical and Operational Requirements for Approved Scanning Vendors (ASVs)”[PDF] document by PCI Council.

• Internal: there is no explicitly spelled-out pass/fail criteria. The decision is thus based on your idea of risk; there is nothing wrong with using the same criteria as above, of course, if you think that it matches your view of risks to card data in your environment. However, most QSAs will not accept a scan report with high-severity vulnerabilities present in the card holder data environment. For example, assuming a 1-5 scale with 5 being the most severe, 3s,4s and 5s are likely to be a "deal-breaker" (this section is UPDATED!)

Q: How do I pass?

A:

• External: you satisfy the above criteria. If you don’t, you need to fix the vulnerabilities that are causing you to fail and the rescan. And then you pass and get a “passing report,” that you can submit to your acquiring bank.
• Internal: there is no pass/fail criteria. You don’t get to to pass – or to fail. You just need to do it to reduce risk to cardholder data, based on your own view of such risk. You can do it right or wrong in that regard, BUT “not doing it” is unambiguously wrong! So, actually, you do get to fail – if you don’t do it at all.

Q: Am I “PCI compliant” if I get a passing scan for my external systems?

A: No. No. No. No. No. You only satisfied one of the PCI DSS requirements; namely, PCI DSS validation via an external Approved Scanning Vendor (ASV) scan. This is NOT the end. Likely, this is the beginning…

Q: If I scan my website using my ASV and get a passing scan, am I also OK in regards to Requirement 6.6 “For public-facing web applications… address new threats and vulnerabilities on an ongoing basis?”

A: No, most definitely not. This is a different story; and the subject of another tip.

Enjoy!

P.S. There are some of you who would read this and say “Give us sexy security stuff! Give us clouds! Give us bleeding edge! Or at least give us the results of your CVSS vector factor analysis..” To those I say, all in due course :-)

Possibly related posts:

• How to Harness the Power of PCI DSS? Tip #1
• How to Harness the Power of PCI DSS? Tip #2
• On Scanning
• All tips on everything

More On KindleGate

SANS just repored that the KindleGate is worse than just "1984":

"COPYRIGHT, PIRACY & DIGITAL RIGHTS MANAGEMENT
--Amazon Deletes Purchased Books From Kindle Users' Devices (July 17, 2009)
Kindle owners who had purchased [emphasis by Anton, explained below] electronic copies of George Orwell's Animal Farm and 1984 were no doubt surprised to find the books deleted from their devices last week. Apparently the company that added the editions of the books to the Kindle catalog did not have the rights to do so. Amazon credited affected users' accounts for the cost of the books. Amazon says that if it faces similar circumstances in the future, it will not delete books from users' devices. Comments in customer web forms indicate that certain editions of Harry Potter books and works by Ayn Rand had similarly disappeared. The Kindle terms-of-service agreement nowhere states that Amazon has the right to delete purchased content from users' devices. The irony of Orwell's books being deleted has not been lost on the public.
http://www.techweb.com/article/showArticle?articleID=218501227&section=News
http://www.nytimes.com/2009/07/18/technology/companies/18amazon.html"

But this teaches us something truly deeply funny and sad about the world we live in! Even SANS thinks that the readers "PURCHASED" ebooks; I am sure that said readers thought so too. That was their honest perception.

In reality, they never did purchase anything - they licensed it.

As a result, I suspect that the more stuff like "KindleGate" happens, the more the following perception (whether true or not!) will grow, strengthen and develop:

When you "BUY" digital content, you don't really BUY it - it is not really a PURCHASE.

THEREFORE

When you STEAL digital content, you don't really STEAL it - it is not really a CRIME.

Please, folks who enforce the rules the way Amazon just did, watch for that monster you are helping to create. It will destroy you!

UPDATE: fun discussion about clouds, DRM and the KindleGate here (read the comments too)

UPDATE: Kindlegate truly ends; "Amazon Settles Kindle Deletion Lawsuit For $150,000" ("Amazon.com has agreed to pay $150,000 to the student who sued the company for deleting his digitalcopy of George Orwell's 1984 from his Kindle e-book reading device.")

On Scanning

This post is about PCI DSS and vulnerability scanning.  What can be simpler than that? :-)

Well, the illustrious Branden Williams reminds us that even the simplest, clearest, most painstakingly defined part of PCI DSS can cause .. you know … trouble. Since his post is so good, I’d quote more and comment less.

First, a quick and useful reminder:

“Requirement 11.2 mandates quarterly scans for all hosts in scope for PCI, both internal and external”

External scans are well-defined, internal scans are left to the discretion of merchant’s security team. The latter does NOT make them any less mandatory though.

Then Branden asks a perfectly reasonable question:

“In more than half of the PCI assessments we [=his team at VeriSign] did in 2008, Requirement 11.2 came up as an initial gap. If it's just scanning, why can't we get it right?”

And, yes, he has an answer. The first part of the answer makes me embarrassed to even mention it here; in fact, I feel ashamed of being part of the same humanity with folks who do it… Namely:

“Reason the First: You scanned, but you forgot to obtain CLEAN scans for every quarter. Remember, the testing procedure for Requirement 11.2 states that QSAs must "Verify that the scan process includes rescans until passing results are obtained." Just scanning is not enough, you have to scan, patch, and re-scan until you have a clean scan”

No, neither Branden nor I are joking; stuff like that really happens: “It mandates scanning? So, we are going to scan! Is there anything else?” He then explains it further, with YouTube video illustrations, of course :-) And now the second part:

“Reason the Second: You scanned externally, but forgot to scan INTERNALLY.”

So, please call me the f*cking broken record (modern version: a corrupted MP3 file? :-)), but:

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Did I mention … oh, never mind! In any case, read his whole post here.

P.S. Today was the day I really didn’t want to write about PCI since I realized that even though PCI DSS is definitely NOT the reason for scams, there are PCI-related scams out there nonetheless. And that makes me sad. Whether it is about “free PCI compliancy” or “guaranteed PCI compliance for $4.75/month”, such things are NOT the whole story – they are the exceptions and not the rule. I still believe that PCI DSS is a strong positive force for security; maybe the strongest we ever had so far.

Logging and Web Services

This post about the paper we wrote earlier this year (“Logging in the Age of Web Services” by Gunnar Petersen and Anton Chuvakin, published in “IEEE Security and Privacy”) will just prove how behind I am on blogging :-) Fortunately,  Gunnar announced this paper a long time ago; I just added it to “2blog” folder :-) The paper will be a useful read to those into either logging or web services or both. I do suspect that web services audit logging will be one of the unresolved mysteries when SaaS/PaaS/IaaS/cloud everything will enjoy further adoption…

Fun Reading on Security and Compliance #17

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 AND Compliance." Here is an issue #17, dated July11, 2009 (read past ones here).

This edition of dedicated to people who send articles for me to read a few months after they are published:  hopefully folks were busy with something worthwhile…

1. If you think that data breach disclosure laws made people immune to breach new, I bet the new medical breach law will suffer from it. Medical info loss is much scarier than card data loss, for sure. BTW, want smth even scarier? How about this, “DNA Database Breach?”
2. Also, a good insider “hack” story. $9m – gone. BTW, here is another.
3. A few gems from Gunnar, as usual: “Enterprise Security Priorities” and “But I Don't Want To Trust the Cloud.”  Just read’em, no need to comment.
4. Moderately fun read “Avoid Security Suffering With These 3 Questions.” Quote: “"What product should I start with?" is a very common first question, but it has about as much use as approaching a doctor and asking, "What medicine should I take?"”
5. Drazen has a good selection of links debating what drives security: ”Regulation vs. Market Forces – A collection of recent posts….” TODAY, market force to drive security = idealism.
6. “Calabrese’s Razor” post covers an interesting approach to risk and security metrics; quote: “I’ve long held the opinion that the community of “Information Security Experts” agree with each other 90% of the time, but waste 90% of their time arguing to the death with other InfoSec Experts about the remaining 10%.”
7. Fun OWASP survey [PDF] is out, via “OWASP Security Spending Benchmarks Project Report for Q2 Published” post on Boaz blog. There is a lot of interesting SaaS and cloud stuff there. Mike also writes about it here.
8. This fun read explores the relationship between cloud security and mobile warfare. It is a bit theoretical, but still worth a read: “With cloud computing, IT security can now use maneuver concepts for enhance defense. By leveraging virtualization, high speed wide area networks and broad industry standardization, new and enhanced security strategies can now be implemented.”
9. Rich @ Securosis has his awesome “The State of Web Application and Data Security—Mid 2009” post. Fave: “When it comes to web application and data security, if there isn't a compliance requirement, there isn't budget.” Ah, and obviously this: “PCI is the single biggest compliance driver for web application and data security.” Overall, a must read!
10. Web app is in such a horrible state, it isn’t funny. OK, sometimes it is funny. Also, this (see comments too) and this (with a good classifications of reasons…) cover  a lot of idiotic reasons why web application vulnerabilities are not fixed. My fave: “That application is behind 3 [!] firewalls!”
11. Some fun SIEM FAIL and also here. More on SIEM from Securosis here.
12. BusinessWeek prints ”Lessons from the Data Breach at Heartland.” Good insight on how business press views “this whole security thing.”
13. “Honeypots aren’t dead” or “Goldman Sachs Code Torrent” story.
14. Here is some SCAP fun: “Hot or not: SCAP is heating up”, “How SCAP Brought Sanity to Vulnerability Management” by Ed Bellis (also note the comments to both pieces. BTW, MITRE just did SCAP Developer days which I woefully missed. Here are the slides from the event which, sadly, don’t unzip for me ;-(
15. Finally, Branden’s blog, as always, exudes pure awesomeness; here are some highlights:  “Do Data Breach Laws Push Compliance?” (quote: “My experience tells me that fines are a much bigger motivator to pushing compliance to a particular standard versus data breach laws.”), “Guest Post: The DNA of Compliance”, “The Top 8 Requirements Your Assessor Misses” (including “Requirement 11.2.a - QSA only documents the external ASV scan and internal scans are not addressed”), “More on NRF's Letter to PCI SSC, and the Wireless Network that Could” (and this post on NRF letter as well) and ”Guest Post: Is it better to be secure, or appear secure?” (scary shit, which reminds me of “Compliance First!” horrors – longer version)

As has become a tradition recently, a dedicated PCI DSS section, a bit short today:

1. Also, Boaz has some fun discussion on “PCI and Nevada” here and here
2. Mike Dahn is back into action, and he as a lot of fun blog posts: “The Good, Bad, and Ugly of PCI”, “How Banks and Merchants manage their risk with PCI DSS”  No comment needed – just read’em.
3. Another awesome list of 10 PCI Misconceptions, courtesy of Rich. BTW, Mike has his own: “10 Fallacies in PCI Conversations.”
4. Walt has a sadly humorous post about PCI and service providers: “PCI and Your Third-Party Service Providers – First, the Bad News.” Fave quote: “My favorite is when the vendor [=service provider] replies that they are compliant as a Level 3 (or 2 or whatever) merchant. That response is completely irrelevant and inexcusably misleading.”

Enjoy!

Possibly related posts:

• All other security reading posts.

Trick Question: Can PCI DSS Apply If …

a merchant does NOT store, process, or transmit any cardholder data on merchant premises?

The answer is “Of course!”

Simply if you accept cards, but process them somewhere else. SAQ A (doc) is small, but decidedly not empty.

Just a thought inspired by Trey here.

Nobody Is That Dumb ... Oh, Wait XII

Many, many moons ago I had this brilliant series "Nobody Is That Dumb ... Oh, Wait" (the last one was back in March) where I made fun of people making dumb security claims with apparent - and often scary! - seriousness. Somehow I neglected this series, but a few days ago I was shown a super-shining example of sheer stupidity of immense proportions.

It all started in a remote country of Norway where one particular journalist discovered a horrible evil (mmm… Evil!) that threatens all life in the Universe (mmmm… Multiverse!): honeypots.  Specifically, the English translation of the printed original from their “Aftenposten” newspaper starts like this:

“Unethical and unacceptable, says computer experts.”

Reeeeally? OMFG, thanks for enlightening me that an idiot in Norwegian is spelled “c-o-m-p-u-t-e-r e-x-p-e-r-t” :-)

“We have to trick the hacker to visit our home, without the him knowing. This sounds like a difficult task, but this is some of what honeynets are about. Tricking a hacker into our systems, allowing us to monitor him without his knowledge.”

Exactly: we “trick” them by using the secret honeypot “teknik” called “existence.” If a honeypot exists, somebody will hack into it. Deep, eh?

More fun quotes, hopefully with the correct translation:

“This is the same as if the cops would do private stakeouts in their spare time. No police department would have accepted that, says Professor of Law, Jon Bing.”

and

“This is far more serious than to set up a surveillance camera. It is more like building a new street and seting up surveillance cameras in the whole area, without the visitors knowing that the information is stored and analyzed, says Professor of Law Jon Bing.”

No comment; it is already pretty funny and pretty dumb. But it gets better:

“There is no doubt that the majority of data users who are monitored in honeypots, have not necessarily done anything criminal.”

Oh, so everything this guy learned about honeypots just went out of some hole in his head, interesting…

At this point a shadow figure emerges, which is behind all this: some Lance Spitzner, supreme commander of cybertank troops :-)

“The international organization was started by former US Army tank driver Lance Spitzner, in 1999, to take on the battle against attackers on the internet.
Bush advisor. Spitzner has been a computer security advisor for the  American defence and former president George W. Bush.”

Apart from being 100% false in regards to Bush, it is also pretty darn funny.  Please, dear journalist,  promote me to the Cyber-Apocalypses Supreme Commander for the  Priory of Zion :-)

Overall, let’s use this scale to put his article in proper proportion:

<---awareness ------ ignorance ----- stupidity ----- idiocy -------------------------------------  a particular piece of Norwegian journalistic excellence-|

In any case, if you are looking for a serious response to this from the Project, look here (“Comments on the Aftenposten article”) and here from Lance.

Workshop on the Analysis of System Logs (WASL) 2009 CFP EXTENDED

Just FYI, the CFP deadline for Workshop on the Analysis of System Logs (WASL) 2009 has been extended to next Monday, July 6th.

BTW, the above date is a proposal submission date; the full paper is only due in Sep 2009.

Submit something loggy now!

Relation of PCI DSS to Security

Is Paris Hilton a slut? This is the age of universal Internet connectivity, web 2.0 or even “web 2.0+”, massive search engines and also atheism: this leads us to believe that “The Truth 2.0”  (OMFG!) is undoubtedly possessed by Google. If we can ask Google and then analyze its answer to determine with scientific rigor whether Paris Hilton is a slut, like was done here, why not ask the same source of “Google-given truth” about whether “PCI DSS” is related to “security.” Now, I always hear a lot of high-pitched whining from hardcore security folks that  “all those people just want to be compliant, not secure,” and so I wanted to call upon the higher power of Google to figure it out.

 

 

So, I ran these queries for “pci compliance” and “pci dss” in Google Insights for Search. Apart from some sexy visuals (no, not of Paris Hilton :-)), the interface shows you other searches related to your original query and also compares their relative volume. Here is what happened:

Search for “PCI DSS”:

Search for “PCI compliance”:

It is interesting to note that Google clearly thinks that “security” is related to “PCI DSS” as top related queries (after the synonym queries “PCI DSS”, “PCI compliance”, “PCI DSS compliance”, etc) are about "security. BTW, the relation algorithm is explained here: the key part is that “Our system [=Google] determines relativity by examining searches that have been conducted by a large group of users preceding the search term you've entered, as well as after.” Moreover, note than nothing else shows up in either list of related queries; pretty much just PCI terms (“visa”, ”credit card”, “requirements”, “dss”) and the word “security.”

Case closed? PCI DSS IS all about security!

BTW, on an unrelated note, did you also know that Paris Hilton qualifies as a platform? Well, you do now.

Monthly Blog Round-Up – June 2009

As we all know, 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. These monthly round-ups is my attempt to remind people of useful content from the past month! If you are “too busy to read the blogs” (eh…cause you spent all your time on Twitter? :-)), at least read these.

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

1. Top this month is taken by my recent post “Why No Open Source SIEM, EVER?” as well as its older inspiration “On Open Source in SIEM and Log Management.” Looks like all the commercial SIEM vendors came over and marveled at its beauty :-)
2. My quick analysis of the infamous merchant associations’ letter to the PCI Council in the post “On “PCI Letter” takes the next spot. BTW, Bob Russo already responded to this via this podcast and this interview.
3. They say that personal stories are always fun to read and so my personal story on switching away from Mozilla Firefox towards Google Chrome (“On Switching Away from Firefox”) is in the top too. Is Firefox really the IE of 2009?
4. My review and coverage of the book “Beautiful Security” (“Best Chapter From “Beautiful Security” Downloadable!” and “Book Review “Beautiful Security””) is popular due to a lot of linking to it.
5. My little log sharing initiative (“Free Log Data For Research – Update”) took off like a rocket. Here is the log sharing site and here is the mailing list/Google Group.
6. Finally as #6, my PCI DSS Q&A from the Qualys webcast “PCI DSS Myths” are still hot: “PCI Myths Webcast Recording and Q&A.” Also, our latest webcast slides and Q&A are here ("PCI DSS Prioritized Webcast Slides and Q&A")

See you in July. Also see my annual “Top Posts” (2007, 2008)

P.S. Stand by for the post on Paris Hilton tomorrow… :-)

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

• Monthly Blog Round-Up – May 2009
• Monthly Blog Round-Up – April 2009
• Monthly Blog Round-Up – March 2009
• Monthly Blog Round-Up – February 2009
• Monthly Blog Round-Up - January 2009
• Monthly Blog Round-Up - December 2008
• Monthly Blog Round-Up - November 2008
• Monthly Blog Round-Up - October 2008
• Monthly Blog Round-Up - September 2008
• Monthly Blog Round-Up - August 2008
• Monthly Blog Round-Up - July 2008
• 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: chuvakin,monthly,blog,security