Wednesday, December 30, 2009

Fun Reading on Security and Compliance #22

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 #22, dated December 29, 2009 (read past ones here) with which I flush my 2009 “2blog” folder clean :-)

This edition of dedicated to all of us who changed something in their lives in 2009.

  1. First, if you have to read only one thing, read everybody's security predictions for 2010:
  2. BTW, Ivan Arce touches on security in the year 2030 (!) here in this piece: “By 2030 an organization’s or individual’s information security risk posture will be better described as a probable trajectory in an global multi-dimensional risk landscape constantly evolving and the tools used to measure and manage risk will be built using the foundations of modern physics, evolutionary biology, economic modeling and social sciences rather than technology-dependent abstractions.”
  3. What Information System Auditors and Information Security Auditors Do Not Want You To Know” is worth a read and my fave bit is: “…the future of the security profession will be deep and narrow technical knowledge. The generalist that walks around spouting best practices and reviewing documentation only will very quickly become a relic.”
  4. Gunnar promises that 2010 will be the year of “war on risk” in “2010 Goal #1: No more "general risk.” Quote: “Goal 1. Exorcise the word "risk" from the infosec profession, unless its qualified with an adjective.”   This paper is an interesting one to read next as well.
  5. An interesting post that insinuates that Cisco is “exiting security market” (well, not really): “Cisco seems much more passive and confused about its security play then it did a few years ago when it seemed intent on owning all-things security.” While there, read this bit on Life and Death of Cisco MARS, their “once-mighty” (well, not really :-)) SIEM product. The feeding frenzy on the MARS corpse has already begun, with many vendors promising “drop-in MARS replacement” (not hard, given that so many MARS boxes were shelfware …mmm… ”shelf-appliances”)
  6. Fairly intelligent piece on choosing a SIEM from “CSO” magazine. Keep in mind that it is written by a journalist, so it has some inherent hilarity (such as 63,000:1 “compression”). BTW, CSO has another great piece: the first is a must read for all in security: “Lifestyle Hackers” – “The most interesting and ironic aspect of the lifestyle hacker is that he is motivated by the pursuit of productivity, often the very same motivation driving the implementation of various corporate controls”
  7. Melissa Hathaway comes out of the woodwork with her “Five Myths About Cybersecurity” and they are actually a great read, even if sort of obvious to security industry insiders.
  8. Ed Felten on “worst practices”, one of my favorite concepts: “A ‘Worst Practice’ is something that most of us do, even though we know it's a bad idea.[…] There's typically some kind of collective action problem that sustains a Worst Practice, some kind of Gordian Knot that must be cut before we can eliminate the practice.”
  9. And some more log reading, calling to love log analysis. And here as well, but more on the fuzzy size :-)
  10. While we are on the subject, Cisco published a great guide to logging: “Building Scalable Syslog Management Solutions”  (which, BTW, never once mentions MARS – please forget MARS already). It event has a good discussion of “actionable vs. non-actionable syslogs” and some useful architecture bits.
  11. “PoS-gate” (a lawsuit from a merchant against 0wned Point of Sale system dealer and vendor Radiant Systems is covered: here, here, here, here and full suit here [PDF].
  12. Some fun DLP discussion here. In fact, In didn’t even know that DLP stands for “Disturbing Lack of Progress” :-) This seem to follow the same theme of “DLP skepticism” – also check the discussion afterwards.
  13. Very interesting philosophical piece by Rocky DeStefano on FUDSec: “We need to get out of the mindset of applying protection techniques based on physical realms and focus on evolving the entire environment to better suit our needs moving forward.” Some discussion of the above piece also continues here and here. While on FUDSec, check this awesome piece on utilities by Nick Selby; it is very useful if your paranoia is somehow losing its zing at the end of the year :-) (then read his other piece here too)
  14. A good read from Rich Mogul “The Anonymization of Losses: A Market Forces Failure”: “Losses are also anonymized on the corporate side. When an organization suffers a data breach, does the business unit involved suffer any losses? Do they pay for the remediation out of their departmental budget? Not in any company I've ever worked with -- the losses are absorbed by IT/security.” A very useful read to those who like to whine about security not being taken seriously (while compliance is)
  15. I just discovered that SANS is running their annual log management survey. It beats me why they are keeping it secret :-(
  16. Finally, I saved the most though provoking piece for last:  this by Greg Hoglund paints a picture that few people even want to admit: “The decade in review: The most painful thing we learned is that computer security hasn’t worked. […] As we close out the first decade, we must realize we have just entered one of the biggest arms races in the history of warfare.”

PCI DSS section:

  1. A paper “Data Breaches Show PCI DSS Ineffective” can’t be good, can it? Well, this one actually is a good “incite-ful” read: “If PCI is a failure, it is  not because it doesn’t prevent credit card theft; there is no such animal as a perfect set of countermeasures. PCI is a failure because it does not force a business to use it’s common sense and ask these practical, common-sense business questions.” In other words, it does not magically imbue the bearer with common sense :-)
  2. Other people are also thinking about using PCI DSS guidelines for protecting other data. The actual story from McAfee blog mentions some [idiot] organization that lost critical data that was not protected by “PCI-grade” safeguard.
  3. Another useful (=non-rant-ish) PCI DSS piece that I forgot to highlight: “Lessons Learned From PCI Compliance


Possibly related posts:

Monday, December 28, 2009

Security Predictions 2010

First, if you want to impress friends with your future-seeing powers, just do what Richard Feynman did when he predicted some WWII events: predict “everything will stay the same.” It is known to typically score better than any more “smarty-pants” ways of seeing the future. Granted, you’d be wrong in many cases, but other methods just make you wrong in MORE cases :-)
But how fun is that? What is the value of such passive “predicteering”, apart from winning bets? No new insight will be produced, no new thoughts, no new strategy, etc. I will not follow that approach!

In any case, let’s start from my traditional annual security prediction tracker: There I log what everybody else has been predicting, from fairly insightful to downright dumb and biased. Also, right before preparing the 2010 version, I reviewed my 2008 security predictions and then I realized that I never posted the 2009 version. Shame on me!
The main theme of my 2010 predictions is “nearing the thresholds.”  These thresholds are in many dimensions: interest in information security, security awareness across organizations (mostly due to PCI DSS) as well as threshold of the offensive side lead (offense’s lead cannot grow indefinitely, ya know).
Next, let’s go by themes!

Compliance: as many other observers (Joshua at 451 Group comes to mind) noted, many of the security activities in 2010 will be defined by regulatory mandates such as PCI DSS, HIPAA/HITECH and others.  This will be the case from the smallest (larger extent) to the largest (smaller extent of compliance influence) organizations. I’d love to predict that people will finally get the spirit of PCI DSS (data security) and not just the letter (assessment readiness), but it is a tall one to forecast.
So, PCI DSS will continue its march. In fact, I bet (like I did in 2008) PCI DSS frenzy will further spread down-market - there is so much more Level 3s and Level 4s compared to Level 1 merchants. Now they all take payment cards, they are all insecure - thus, they might all be 0wned! BTW, nowadays nobody is predicting that PCI momentum will fizzle, as some did in 2007-2008.  While some people criticize it for specific requirements or missing things here and there, I still swear that those organizations who paid NO attention to security now do it ONLY because of PCI.
On the other hand, just as it was in 2008, ISO17799 (and its 2700x children), ITIL, COBIT frameworks likely won't be 'hot,' at least not in the US. Ad hoc approach (with some use of ideas from the above frameworks) to security management will still rule. In fact, more will try to base their entire security program on PCI DSS.
All this “comply-mancing” will bring both good and bad, as far as those organization’s ability to defend themselves from “bad shit” is concerned. And while we are on the subject…

Bad shit: what we have here is an intersection of two opposite trends: rampant, professional cybercrime and low occurrence of card fraud (as a percentage of card transaction volume). I explain this conundrum by predicting a scary picture of huge criminal opportunity, which still exists unchanged.
So, there will be more of rampant, professional cybercrime: from RBN to its descendants, from individual criminal entrepreneurs to emerging criminal enterprises, all signs point to dramatic rise of cybercrime. This is not some kinda FUD – this is simply logical consequence of today’s situation with the use of information systems: Insecure computers + lots of money + no punishment = go do it! (in the past, I made fun of people who predicted that “hackers will hack” – this item is different)
Still, I predict that low card fraud rates will continue: despite the above crime picture, many in the payment security industry know that fraud as a percentage of transaction volume is relatively low (I’ve seen estimates from 1% to 5% - in dollar volume this is till huge, by the way). Why is that? I explain it by the fact that criminal enterprises have limited bandwidth -you simply cannot pump ten billion dollars through a garage-style operation. My guess is that most if not all credit card numbers in circulation have already been stolen; the bad guys just didn’t have a chance to monetize most of them due to their limited bandwidth. This is exactly why selling card dumps is seen as a better [criminal] business than actually using stolen cards to buy goods – a counter-intuitive situation to many outside the industry.
In other words, there has not been a better time to go into a cybercrime business. The strategy is pretty much the “blue ocean” one: a lot of unexplored opportunity with low barrier to entry. You don’t want to wait until emerging “market leaders” will run the black business. Today, those folks have a unique opportunity to focus on “easy AND rich targets”, not “easy OR rich targets.” The best analogy is robbing a large bank with no security instead of large bank with security or small bank with no reliable security.

Intrusion tolerance is another trend (and its continues existence is in fact my prediction for 2010) which helps the “bad guys”: it is highly likely that most organizations have bots on their networks. What are they doing about it? Nothing much that actually helps. It is too hard; and many businesses just aren’t equipped – both skill-wise and technology wise – to combat a well-managed criminal operation which also happens to not be very disruptive to the operation of their own business. Your systems run OK and bots don’t bother you, what’s 5% of CPU and 10% of bandwidth between friends for sending penis enlargement spam? This view is admittedly cynical, but fairly realistic and results in a weird symbiosis that I call “intrusion tolerance.”
BTW, the Heartland guy said ( “a breach is usually detected when the processing payer is notified of fraudulent use of cards.” This simply negates the existence of the entire security industry! Why is that? ‘Cause it is not doing enough to stop the tide. For example, it was very insightful to learn  that it took us on average 30 days in 2004 to patch a vulnerability, while in 2009 is takes 29 (!) days. See a huge improvement in security management practices here? 2010 will not change this trend: more bugs (such as all the Adobe stuff) moved the stats back to the Stone Age even as we improved our handling of platform patches.
Still, I doubt that “fully automated crime”, predicted back in the 90s by Donn Parker is fully possible today. If it were, the fraud rates and losses will probably grow – yes, you guessed right! – exponentially. So, I vote “no”, at least not in 2010. If that happens, the threshold will surely be crossed…

Cloud security: I predict much more noise and a bit more clarity (due to CSA work) in regards to information security requirements as more and more IT migrates to the cloud. The Holy Grail of “cloud security” – a credible cloud provider assessment guide/checklist – will emerge during 2010.

Finally, I am going to drag some of the 2008 predictions which are still valid and dust them off for 2010:

Platform security: just like Vista didn’t in 2007, Windows 7 won’t “make us secure.” The volume of W7 hacking  will increase as the year progresses.  Also, in 2008, I predicted an increase in Mac hacking. I’d like to repeat it as there is still room there :-)
And, only the truly lazy won’t predict more web application attacks. Of course! It is a true no-brainer, if there ever were one. Web application hacking is “a remote network service overflow” of the 2000s….

Incidents: just like in 2008, I predict no major utility/SCADA intrusion and thus no true “cyber-terrorism”  (not yet). Everybody predicts this one forever (as Rich mentions), but I am guessing we would need to wait at least few years for this one (see my upcoming predictions for 2020!) Sure, it makes for interesting thinking about why it did not happen; surely there is a massive fun factor in sending some sewage towards your enemies.  I'm happy to be correct here and have no such incidents happen, but I was predicting that something major and world changing would NOT happen so Feynman paradox is on my side.
A massive data theft to dwarf Heartland will probably be on the books. And it will include not some silly credit card number (really, who cares? :-)), but full identity - SSN and all.

Malware: sorry guys, but this year won’t be the Year of Mobile Malware either. As I discussed here, mobile malware is "a good idea" (for attackers) provided there is something valuable to steal – but it is just not the case yet in the US. There will be more PoC malware for iPhone, BlackBerry, maybe the Droid, but there will be no rampage. On the fun side, maybe we will finally see that Facebook malware/malicious application (that I predicted and consequently missed in 2008). This one will be fun to watch (others agree), and current malware defenses will definitely not stop this "bad boy," at least not before it does damage.

Risk management: more confusion. Enough said. In 2008, I said “Will we know what risk management actually is in the context of IT security? No!It sounds like we know no more now.

Various security technologies (refreshed from 2008):
  • Full disk encryption will not (yet?) become ubiquitous.
  • NAC will be largely forgotten by the end of 2010.
  • More whitelisting for host and network security will happen (but combined with blacklisting, which is certainly not going away!) As malware landscape becomes even more diverse, application whitelisting for security will start to shine even more. Collaborative filtering for malware will also become more noticeable.
  • Secure coding does not (yet?) becomes mainstream (definitely, 'not yet' on this one) It pains me to say that that I think that while this ball definitely started rolling (e.g. SANS is pushing it hard now) it won't be hurtling down the highway at full speed. 2011? Sure, maybe! :-)
  • More vendors will release SaaS versions of their security technologies and new SaaS security vendors will be launched.
  • Few people will be on the market for “just the network firewall.”
  • WAFs will finally boast near-mainstream adoption.
  • A sizable percentage of log management users will feed application logs into their systems. Not just payment application (for PCI DSS), but various enterprise application logs as well (and, of course, web application logs)
  • End-user organization will start talking (and buying) technologies specifically aimed at protecting virtual machines and other virtualization technology (the first year of “virt sec” tools will be 2010)
Overall, we will be approaching those thresholds – with unpredictable and interesting events likely during the course of the year!
Decade predictions will follow next!!! Go “security 2020”!
Possibly related posts:

Thursday, December 24, 2009

Three More Fun Presentations Set Free

As it is traditional, I am setting free three more of my recent security presentations:

Happy holidays! What better way to celebrate the season is there then to read up on security? :-)

Possibly related posts:

Tuesday, December 22, 2009

PCI Compliance Book at 50% TODAY

It looks like fine folks at Syngress / Elsevier  have given everyone a BIG holiday gift: our "PCI Compliance" book at 50% off with code 97561 (not sure for how long the discount code will work ...maybe just today). To use the code, buy the book direct from the publisher here.  

This is awesome, pretty much! Even if you hate PCI :-)

And if you came here too late, but still in December, use this old code for 30% off. If the above also doesn't work, feel free to use the Amazon icon on the left.

BTW, while you are at it, check out the book website:

Think about! PCI DSS, massive holiday shopping ... what can possibly go wrong? :-)

Thursday, December 17, 2009

Cloud Security Alliance Guide 2.0 (well, 2.1 Actually) is OUT!

Cloud Security Alliance (CSA) Guide next major release is OUT today: press release, full document [PDF].

It's full name is now "Security Guidance for Critical Areas of Focus in Cloud Computing." I did contribute to the compliance domain (what is more fun than PCI in the cloud, he-he? :-)), full domain documents will be released soon here.

Friday, December 11, 2009

Unintended PCI DSS Consequences IS The Devil!

No, sir, PCI DSS is STILL not the devil. However, the devil is in the details ;-) This post attempts to analyze some of the details and is inspired by a really insightful conversation I had with Joshua Corman of 451 Group. In particular, this post is about the devilish nature of some unintended consequences of PCI DSS.

Let’s start from something truly despicable (WARNING: vomit alert!)

the purpose of security measures is to minimize legal damage

after complete loss of all critical data (or after other EPIC security FAIL)

by claiming that “adequate protections were in place”

If this line does not cause you (assuming you work in security) to go into seizures, I am not sure what will (maybe a lightning strike will?) I can barely type it, in fact, it is so disgusting :-) This is the evil side of otherwise benign phenomenon called “diligence.”

What it has to do with PCI DSS and the devil? Let’s explore it.

Security programs built and run ONLY as “a post-hack lawsuit defense” are indeed despicable. And so are compliance programs that are “mistakenly” labeled “security program.” And I’ve long claimed that organizations that “magically” arrive at “all we need to ‘be secure’ is to deceive a QSA” have only themselves to blame for their intrusion losses. Despite that, we all agree that there are plenty of organizations like this; in the past they were just negligent and now they are “fake PCI negligent.”

However, now there is definitely a market for “fake PCI security”, “get compliant and think you are secure”, “free PCI compliancy”, “guaranteed secure web site seals” and other scams. All these shops were not in business a few years ago. In addition, given such market, other security vendors have dedicated efforts to compliance-focused tools – obviously at the expense of thereat-focused tools and functionality. “All we need for web app security is PCI DSS Req 6.6” is one example of it (“only 6.6” is clearly better than no web application security whatsoever, of course!) – and if most customers “only want PCI”, this is what will get built at vendor shops.

And “anti-assessor” features might not work as well against attackers.


As a result, it is hard to find a niche within a security market which is not affected by regulatory compliance. DLP (see discussion here)? DAM? It affects even those technologies which are not even when not mentioned/

That is not PCI’s fault, of course – but this unintended consequence of PCI is quite devilish. PCI certainly plays a huge role in improving security; however, through the above mechanism it does seem to play for the opposite team as well…

Now, some of these compliance-focused efforts are actually quite beneficial for security. If we treat compliance as “validated security” (see discussion after this post away for details), then evidence of security measures being deployed and being effective does not just make the assessor happy. It actually helps you run you security program better – and help prove its value to senior management. For example, PCI push for more logging clearly helped both compliance and security.

As Adrian said in his recent post, “They need to have WAF to comply with PCI, so they bought one, but no one mandated they use it effectively. Security professionals really care about security, but the executive management cares precisely as much as legal and finance tells them to.”

In other words, some of PCI consequences is The Devil – they make people focus on things that might be suboptimal from the security point of view. And they make some think that there are easy solutions for very, very hard problems….



P.S. This is posted by a bot, all comments will be responded to when I am back.

P.P.S More on this in the future (treat this as Part I of the ongoing debate)

Possibly related posts:

Wednesday, December 09, 2009

More VzDBIR Awesomeness!

“2009 Data Breach Investigations - Supplemental Report: Anatomy of a Data Breach” is OUT! Grab it here or here at their blog.

Some highlights follow below:

  • This covers the use of keyloggers in investigated breach cases – note a high percentage of stolen records:


BTW, read the case study after this table – very insightful

  • This tells the same sad story, but about backdoors and bots – note a high percentage of records and the use of SQL injection:


Also, read the case study after this; it has gems like “as to how the assailants first gained access, investigators found a non-sanctioned commercial remote
desktop program on one of the R&D workstations [that handled super-secret ‘business-buster’ data].”

  • The attack entry on SQL injection is event more fun – note the reference to database logs (“Routine log monitoring (especially web server and database)”):


  • Other fun bits (the whole thing is one big bundle of fun though!) are: “Striving for perfection in any one control is inefficient and introduces single-point of failure dependencies” and “loose-grained access control applied to routers, firewalls, and other network devices are extremely efficient due to the large number of known and unknown problems they mitigate.” [please shove it to folks who proclaim ‘firewall is dead’] I also liked the VzBIR vs DataLossDB comparison in the appendix.
  • Conclusion: Verizon report series exude pure awesomeness!

Do read the full supplemental report!

Possibly related posts:

Tuesday, December 08, 2009

"PCI Compliance" Book Is Here!

Finally, the PCI book is here in the flesh. I decided to use this opportunity to try video on my blog. Here it is:


Possibly related posts:

Monday, December 07, 2009

Log Management + SIEM = ?

Lately, something made me think of using log management WITH security information and event management (SIEM) - I suspect it was either this or maybe this zombie here. I did spent some time in my career building SIEM tools and then spent some building log management. Nowadays, their “separate identities” are pretty much widely accepted; even “Big G” combines them in the same document, but calls them out by name separately (this, BTW, took about 2 years of fierce arguments back in 2005-2007 :-))

In any case, my recent bout of thinking revealed four scenarios, crudely depicted on the image to the right:

Those are:


  1. Log management as a foundation and SIEM as [one of the] applications: this is what I call “a common sense scenarios” since it is so …well… common sense. It can also be called “grow up to SIEM.” By some strictly unscientific estimates (=random guessing), it accounts for maybe up to 50% of SIEM deployments. This is the case where an organization gets a log management tool and slowly realizes the need for correlation, visualization, monitoring workflows, etc.
  2. SIEM and log management deployed together alongside and at the same time: this is what I call “emerging scenario” since more people now get both at the same time (from same or different “best” vendors). I have no idea about the percentage of adoption here, but likely vendors who offer SIEM and LM can attest to the growth of this scenario. Indeed, if you somehow realized the need for correlation, you better save all the logs and have an ability to perform efficient search and raw data analytics.
  3. SIEM=LM: this scenario means that either you are small (and use the same tool that can handle simple SIEM and log management functions) or, if you are large, you’ve been duped by the vendor who said “they are the same thing” [today they are still not and a smart vendor won’t tell you this – eventually maybe they will be…]. Admittedly, “one box with SIEM+LM functionality” can work in principle and for smaller environments, but typically there are too many things competing for CPU, RAM, network and disk (e.g. correlation and indexing are both resource hogs…). Still, this might well be the #1 by the number of deployments due to its applicability to smaller (and thus more numerous) environments.
  4. SIEM deployment with LM as an archive: this scenario arises when somebody buys a big fat SIEM – and then, over time, realizes that something is missing. As a result, a log management tool is deployed to "dump” all logs into and (sometimes) perform analysis of the raw logs that SIEM “rejects” (i.e. doesn’t know how to parse, normalize, categorize, etc). Specifically, incident response and PCI DSS come to mind here.
  5. “SIEM Shield” [UPDATED!]: the final 5th scenario is so obvious, I completely forgot about it :-). While it is similar to both #2 (simultaneous SIEM and log management deployment) and #4 (log management as an archive for a SIEM), it is also distinctly different – and VERY common. LM SIEM_special5 In this case, an inherently more scalable log management tool is deployed in front of SIEM (typically after SIEM is first implemented, which is similar to scenario #4) to serve as a shield and filter to protect a less scalable SIEM tool from extreme log flows. It is not uncommon to only send every 10th event received by the “log shield” to a SIEM, hiding behind it. At the same time, all received events are archived, just like in case #4.

Obviously, it goes without saying there are lots of “log management only” (still growing) situations and some “SIEM only” (likely shrinking) deployment scenarios. But their are not the subject of today’s note here.

BTW, today is my birthday :-) … and I am writing about SIEM. How cool is that?

Possibly related posts:

Friday, December 04, 2009

“PCI Compliance” Book 30% Discount code

I have not yet received my copy of “PCI Compliance” book, but I was told it is OUT in the flesh.

During the entire “launch month” – December 2009 – you can get the book at 30% off using discount code: SYNGRESS30 

Here is some more info:

BTW, we worked really hard on the book (and then the editors worked on us :-)) - despite this, some typos are unavoidable. Please report them and we will add them errata pages.


Wednesday, December 02, 2009

Monthly Blog Round-Up - November 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,” at least read these.

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

  1. Top spot this month (by far!) is deservedly taken by “Smart vs Stupid: But Not Why You Think So!” You need to go read it to know why it is so awesome :-)
  2. Top Log FAIL!” is still hot! The post summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.”
  3. On SIEM Complexity” is next – it is a piece about Security Information and Event Management (SIEM) and why it is / is perceived as “very complex.”
  4. “Open source SIEM theme continues to drive a lot of traffic – it looks like folks are still desperately googling for it. “Why No Open Source SIEM, EVER?” post takes the spot in Top5 this month again. The older inspiration for this post is “On Open Source in SIEM and Log Management.”
  5. SIEM Bloggables” post covers key SIEM use cases – it is part of the presentation which is yet to be posted.
  6. More PCI Devil Defense” is the next iteration in the ongoing industry discussion of the value of PCI DSS for information security.

This month I am also continuing a new tradition: I am going to thank my top 5 referrers this month (those that are actual humans, that is). So, thanks a lot to the following people whose blogs/resources sent most visitors to my blog:

  1. Gunnar Peterson
  2. Dancho Danchev blog
  3. Richard’s TaoSecurity blog
  4. Dmitry Evteev blog
  5. Adam O’Donnell blog

Thanks for all the link-love!

See you in December when I will post both monthly and annual blog round-ups (see my previous annual “Top Posts” - 2007, 2008)

BTW, somebody said that this year is a good year to post not only next year’s annual security predictions, but also next decade security predictions. Now, that is what I would call super-fun! :-)

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

Obligatory “added everywhere” posts :-)

  • I might be available for fun consulting projects related to PCI DSS, log management, SIEM, etc. Please see the services list at my consulting site.

Dr Anton Chuvakin