Wednesday, February 10, 2010

ShmooCon 2010 – Our PCI DSS Panel

It goes without saying that our PCI DSS panel was – for me – the most fun part of ShmooCon 2010. Yes, spectator sports are OK, but the most fun is had when you are playing and kicking the ball – or balls as the case may be in a heated discussion :-) So, Mike Dahn, Jack Daniel, Joshua Corman – over video Skype! he got “snowed out” – and me got to play.

Everybody who’s been to ShmooCon, can easily figure out that the audience there is extremely smart – I sensed there were no “security laggards” in the room. So what happens if you combine PCI and some smart security people? Rage! In fact, we had people from large merchants, QSAs, issuing bank (!) and other organizations. I am amazed that even some non-PCI folks, who can’t tell a QSA from an SAQ found the discussion enjoyable…

It was very interesting to watch that the debate split into two distinct flows: “security vs prescriptive compliance” AND “fuck PCI, they [the brands] must fix the system.” The latter sentiment was very strong, like the Dark Side of the Force (even though there is absolutely nothing dark about it…). It ranged from “why don’t they fix it [the payment system]? they have billions in profit!” (naive) to “if 4 millions of people put the Band-Aids on, is this cure for cancer?” (philosophical). The impression that PCI DSS approach is “too much work” even if good security results from it – which is …how should we put it… not always the case… was also represented. Given the circumstances, it is evident that the view that PCI DSS is many companies’ first encounter with real security management kinda was not very visible…

Also, I always felt it for the issuing bank guys, since they were often left holding the bag for ignorant merchant (TJX anybody?) and unlucky processors or acquirers (Heartland anybody?). But I didn’t expect the present issuers to be so angry at the brands – and not at the merchants! Well, learn something new every day…

The other discussion that even if “checklist security” is offensive to some people, it is the only way to many organization to actually do something. A lot of “risk management stuff” just goes – whooosh! – over their heads. IMHO, this is still an unsolved problem.

Also, somebody very smart in a red blouse :-) said the following: even if we “do everything perfect with PCI DSS”, we will only solve the problem of cardholder data…not any other data (like SSN or key IP) and not any other security issue. Indeed, if PCI DSS magically “just works” and payment card security “becomes 100% secure” , a lot of security work will remain. This is something useful to keep in mind.

I don’t remember signing any NDAs, so I will share some of the reviewer comments that I got from the ShmooCon feedback system (BTW, if you were at the show, please leave the feedback!!)

“Best panel discussion of the con. You could tell there wasn't agreement amongst the panel but the disagreements weren't made personal. Mike and Josh did a great job in explaining their positions and Jack did a super job moderating.”

as well as:

“This dissolved in a religious argument 30 seconds into the talk.”

(in reality, it was maybe 20 minutes into the talk :-))

Overall, the panel was “awesome+” We even took one question from the Internet, something I have not seen at other sessions. Looks like that live video feed was not broadcast in vain… So, watch the video when [correction: it appears that the correct word is “if” here…] it comes out – VERY fun!

BTW, I had an Eureka moment when I spoke to Josh after the panel – deep thought warning! – if we think that the only way to get some merchants to secure their system is to force PCI DSS on them, then how can we expect for them to do a good job with it and not just “check the box”? “Forced standards” and “doing a good job” are hardly compatible.

Finally, thanks to my publisher for providing a copy of the PCI book for the event. I had a chance to wave it at the audience a couple of times :-), but in all the excitement I completely forgot that I wanted to give it out via a contest (FAIL!). In any case, a well-deserving person got the book.

Possibly related posts:

ShmooCon 2010 – Show Notes
Future speaking (just updated!) – including more PCI DSS panels and other fun stuff such as logs and SIEM.

Tuesday, February 09, 2010

ShmooCon 2010 – Show Notes

First things first: ShmooCon was one of the most awesome conferences I attended in quite some time.

If you’d like to see what REALLY was going on as Washington, DC was plunging into a “snow-pocalypse”, go check out #ShmooCon Twitter coverage. Then read other show accounts, such as this one from PaulDotCom.

My note follow below:

First, Bruce’s “intro” was kinda interesting. For example, he made a couple of TSA jokes (the video was hilarious) and noted that “if you think this is funny, then you’d see that network security is actually worse.” What was interesting to me that he also noted that many organizations prefer to “buy new boxes” rather then do something useful, like log “accepts” and “allows” and analyze them.

Then I went to “Social Zombies II: Your Friends Need More Brains.” This was one of those “shit is bad” presentations. Maybe it’s just me, but somehow the idea that some people disclose too much info (Blippy anyone? Anyone sane? Heloooo…) fails to scare me. No shock value really. It can be summarized as "info is out there. done." Then again, I have to admit that their “KanyeWestify” tool was pretty cool and I downloaded the Maltego tool already, so it was pretty useful (Twitter+Facebook+text mining tools = hilarity! :-)). More coverage of it is here and the deck is here.

Now, “GSM: SRSLY?” talk was massive fun. For one, I had no idea that a [relatively simple] piece of hardware can both capture all local cell phone connections (by easily masquarading as AT&T or T-Mobile) AND force them into A5/0 mode that means “no encryption – and you don’t know about it.” So, as I said, I didn't know much about the area, but this talk was very enlightening, useful and overall awesome.

Ah, “Build your own Predator UAV @ 99.95% Discount” talk was fun as well. Think what you can do with an autonomic, mostly quiet robot plane that can fly around (10-12 mile range) and do some wireless hacking and video (via video goggles, of course). No missiles though. What can possibly be more awesome than that? Check out the partial video of it here and many of the UAV building tips are here.

The next presentation was my only disappointment, the “Cyborg Information Security: Defense Against the Dark Arts” talk. Think of this as Dan Kaminsky, but with no issue described in detail and no Dan Kaminsky :-) Yes, some implantable medical devices are a) wireless and b) unencrypted. This is sad. So what? But "This shit is bad! FAIL! Epic fail" summarizes the talk well. Not useful, not really amazing - and, honestly, not really shocking either. And as my opinion of the talk was going down – they misspelled HIPAA. At which point I realized: these guys built the talk based on some googling and no real research at all. FAIL! Epic fail! :-) In some post-show conversation, I actually tried to defend the talk as “raising awareness”, but was beat up by other folks, most of whom labeled is as content-free and aimed only as some posturing.

“The Splendiferous Story of Archive Team and the Rapidly Disappearing Digital Heritage” rant was purely that – a rant. But it was 5PM, people were tired and needed a drink – and a rant :-) So it was a perfect fit for the occasion. Apart from reminding everybody about backup (and if there is one thing that everybody always needs a reminder of – that’s backup! I am backing up my laptop as I am typing this :-)), Jason basically talked that some web content just dies – think GeoCities. More details are here.

Even though I am not a web hacker, “Exposed | More: Attacking the Extended Web” aka “owning the APIs” talk was actually very interesting – and useful. I wish he’d speak more about methods to discover undocumented APIs though.

Next – OMFG! – was our “PCI" panel” – but let me first finish with other’s talks and I will write a whole post on that tomorrow.

Also, I went to “Pulling the Plug: Security Risks in the Next Generation of Offline Web Applications” by the zScaler guy and learned about csSQLi and other interesting offline apps stuff. HTML5 will make security fun again – eh.. that is if it is not fun enough for you know :-) That talk – IMHO – was how “a new security issue”-type talk needs to be presented: with details and ideas for solutions. There is enough of fun and epic FAIL in our realm, but the talk was not just whining about it, but actually taking it apart and showing areas of concern.

Finally, as with any great conference, “hallway conversations” are golden. This time I broke the record and probably deserve the Guinness record book inclusion: on the last day of the show I was involved in – srsly! – a 9 hour (!!!) such conversation. It will probably result in a dozen blog posts, a few papers, a few consulting projects and some other interesting implications…

The usage of word “fun” count: 8

Thursday, February 04, 2010

Logging, Log Management and Log Review Maturity

This picture depicts log management and SIEM maturity curve and is taken from a soon-to-be-released [eh..make that when-my-consulting-client-decides-to-release-it] Guide to SIEM and Log Management. It says it all – and if your organizations tries to enter in the middle…well... FAIL happens:

Enjoy!

Wednesday, February 03, 2010

Monthly Blog Round-Up – January 2010

As we all know, blogs are a bit "stateless" and a lot of useful security reading material 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.

As predicted, my security predictions ( “Security Predictions 2010” and “Security Predictions 2020 (!)” - yes, 2020!) took the #1 spot this month. They are fun – but I will also check how well they panned out early next year. Then we will know who is laughing :-)
“How to Stay Compliant? or Ongoing Tasks in PCI DSS,” a repost of my paper published at EthicalHacker.net was next. Indeed, “getting compliant” is only half the fun (actually, getting validated is only 1/3 of it :-))
SIEM is on a lot of people’s minds. That is why ““I Want to Buy Correlation” or How NOT to Pick a SIEM?” is on the hot list. BTW, I am planning more of “how not to buy a SIEM?” posts…
“Top Log FAIL!” is still hot! The post summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.”
“MUST-DO Logging for PCI?” took the next spot. BTW, there is a newer post on the subject of PCI DSS logging requirements: “More on PCI DSS and Logging.” This, BTW, has been the main goal of some of my recent consulting projects. Should I maybe talk about “PCI logging in the cloud” next? :-)
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.” While you are reading up on SIEM , check out the post called “SIEM Bloggables” with key SIEM use cases. BTW, the funny (and new!) part is that I see more queries for “open source log management” as well.

This month I am 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 sent the most visitors to my blog:

Thank you for all the link-love!
See you in February; also see my annual “Top Posts” - 2007, 2008, 2009!
Possibly related posts / past monthly popular blog round-ups:

Obligatory “added everywhere” posts :-)

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

Tuesday, February 02, 2010

Live Test of FUD Value: Pro/Con?

Can you achieve “security goodness” (and common good) by FUD and [possibly] stretching the truth? Let’s debate this one!
The story started here with this letter from an unknown-but-now-infamous PoS (=point of sale aka cash register – for the non-PCI crowd) vendor about using Windows 2000 after Microsoft EOL’s it and no more security updates come. The letter makes an argument that any OS no longer supported by the vendor will be automatically out of compliance. StorefrontBacktalk, that covers retail tech (and payment security), has a good story on this here. They say:

“For your overflowing folder marked “Ludicrous PCI Scare Tactics That Too Many People Believe” comes a renewed effort from some security vendors to say that out-of-date operating systems this year will cause instant PCI non-compliance. ”

So, the statement about “no security patches –> no PCI compliance” clearly does not hold water. It is what is known as “a lie.” Compensating controls can definitely be used in this case and PCI Council even has a FAQ entry about this very subject (quote: “Systems that use operating systems that are no longer supported with new security patches by the vendor, OEM, or developer are not necessarily out of compliance.”)
However!
While embedded and highly “cut down” Windows 2000 can be “made secure” (with whatever definition: secure enough to run while directly connected to the Internet) even in the absence of patches (especially if some whitelisting software is deployed), I personally will trust neither a typical merchant nor a typical PoS vendor to actually do it. If I were a QSA in this case, I’d accept heavy OS changes plus no user access plus host firewalling plus application whitelisting as adequate compensating controls. However, I doubt that this is the case for most of those “W2K holdouts.” So, IMHO, that outdated stuff “must die” since it puts everyone at risk (think: botnets). If their W2K install dies together with the merchant – then so be it.
Overall, many security folks treat merchants resisting PCI DSS as either stupid or malicious and irresponsible (or both). The merchants, on the other hand, are simply trying to survive and run their businesses. However, at what cost to society? Every one of those W2K boxes CAN BE (and, in many cases, probably IS) used to attack other sites (think: SCADA) and spread malware. Still, is lying the right tactic to get them to upgrade?
For me, this is a hard call to make.
What do you think? “Go FUD!” or “Truth and W2K Rulez!”?
Possibly related posts:

“Top PCI DSS Security Marketing Annoyances”
“More On Security Vendors and PCI DSS”
“A Treatise on FUD”

Top Nine Reasons How PCI Is Like APT

UPDATE: this is HUMOR! HUMOR!! HUMOR!!!

It all started from this tweet: “if you read on #PCI and #APT on the same day, you get some pretty darn interesting high.” Some more …mmm…thinking about the subject resulted in this blog post.

vs

BTW, everybody knows what PCI DSS is, what about APT? APT is “Advanced Persistent Threat”, an acronym with a murky past (some say going back to 1876…) that is used to label “some advanced bad shit that just doesn’t go away” – yes, it is that vague. Some fun discussion about it can be found here, here and here and of course here.
So, how is PCI like APT?

“P” in “APT” stands for “persistent”, “P”in PCI stands for … well … PCI is pretty darn persistent.
Both are absolutely a threat, whether of non-compliance or of severe 0wnage…
“Nobody would ever find that we lied on our SAQ” is said sometimes in PCI, and “no APT will want to hack us” is often said about APT.
People under PCI sometimes do not want to update their anti-malware defenses, because they say “it is too hard.” People under APT often also do not update their anti-malware because… hey… what’s the point?
“A” in APT stands for “advanced,” PCI is pretty advanced stuff for some people who have to be compliant with it (think: your neighborhood gas station)
With PCI, you don’t always know what you need to do; with APT you almost never know what to do.
Also, you are never “done” with PCI, you need to maintain compliance and security; you’re absolutely never “done” with APT.
PCI compliance requires logging and monitoring; dealing with APT absolutely requires extensive logging and monitoring.
People refuse to deal with PCI because they do not believe that anything bad will happen to them, similarly people refuse to deal with APT since they don’t know that APT has already happened to them.

Enjoy!

UPDATE: an awesome follow-up "Why PCI and APTs are NOTHING alike" from Cassandra Security.

Possibly related posts:

All posts labeled humor.

Monday, February 01, 2010

ShmooCon!!! or Anton in DC This Week!

Later this week I will be at ShmooCon, doing a very, very, very fun panel on PCI DSS:

“An Existential Threat To Security As We Know It?

Joshua Corman, Michael Dahn, Dr. Anton Chuvakin, and Jack Daniel

Whether you love it, hate it, or are merely "friends with perks"- compliance is significantly changing what we call security. PCI has been accused of being the Spawn of Satan by some, and yet it has also been credited with advancing security by others. This panel of PCI experts, analysts, and victims will discuss and argue the realities of PCI: its origins, goals, and consequences (intentional and otherwise). PCI is having an impact on priorities, budgets, and personnel, which is being felt throughout the security industry. Unfortunately, there have been few informed discussions of PCI and compliance issues in the technical ranks of the security community. This panel will bring PCI subject matter experts with real-world experience to the technical security professional and hacker audience to discuss, engage, enrage, and argue about what may well be an existential threat to information security as we know it. The diverse viewpoints and experiences of panel members will guarantee a lively and often heated discussion, and will provide a broad base for fielding audience comments, questions, and criticisms. Bring plenty of Shmooballs to this session, you will need all you can get.

Joshua Corman is Research Director for Enterprise Security at The 451 Group and was previously Principal Security Strategist at IBM ISS; Michael Dahn is Global PCI QA Manager for a Verizon Business and was previously the subject matter expert in creating PCI DSS training for Visa USA, Europe, Asia-Pacific, LAC; Dr. Anton Chuvakin is a recognized expert in the field of log management and PCI DSS compliance, he is Principal at Security Warrior Consulting and former Director of PCI Compliance at Qualys; Jack Daniel is some guy with a beard and Sock Puppets who drives the ShmooBus.”

This time, BTW, I will have plenty of time to meet with people since I am in DC from Thursday to Monday. Drop me an email/tweet/etc if you want to meet up and talk SIEM, logs, PCI (well, better logs than PCI :-)), etc. In any case, see you all in Washington, DC later this week!

Thursday, January 28, 2010

REAL PCI Compliance Percentages?

Reading "UK Security Breach Investigations Report 2010" [PDF] (source) makes for some truly blood-curdling reading.

Example:

"Prior to having suffered a cardholder data compromise, 26% of the organisations had believed themselves to be PCI DSS compliant upon submission of completed
Self Assessment Questionnaires. The investigations also revealed that none of the organisations met all requirements of the PCI DSS."

This is how it starts. It is all downhill from there:

"Indeed, in just over one quarter of the cases, none of the twelve requirements were met."

and

"7Safe has found that all the merchants who have been subject to a breach and have completed an ASV scan
have believed themselves to be secure based solely on the results of this scan"

I literally cannot read any further, since I am starting to get angry! Can somebody come and kick those merchants in the balls, please? Actually, no. Do not kick them! Stand on their balls. :-) Then have then buy our book!

Tuesday, January 26, 2010

On Log Context

Recently somebody asked me: what do I mean by LOG CONTEXT? And what is “log enrichment correlation?”

This picture explains it clearly:

For each element in the log message shown, you can gather some contextual information. Contextual here simply means that the information is gathered NOT from this particular log entry. For example, a log entry might contain an IP address, but its DNS name needs to be grabbed from the DNS server, which “enriches” the log entry and makes it more useful.

One of the ways SIEM and log management systems performs such enrichment is by gathering and displaying context information. Context information is the additional information required to make the limited details available within the log entry more meaningful. Context information does not come from the logs themselves [not from the entry in question – it might come from other logs], but originates in the surrounding IT environment such as other systems inside or outside the organization.

As I say above, one of the simplest example of context data is name resolution: the DNS names or Windows NetBIOS host names are added to the logs. While the log file may have already provided IP addresses, the added context of a human-readable name makes the log more meaningful. Normally, DNS names are not present in logs, but have to be obtained by queries to a DNS server. The SIEM tool might find context data in a variety sources, including:

Windows name services, DNS and NIS servers: to map IP addresses to names
Defined asset groups: internal or external status of an IP address
Asset management systems: to gather information about systems, their ownership, compliance relevant of each system or group of systems
WHOIS servers: WHOIS information for external addresses shows who owns them and where they are located
Geo-location: show the physical location of the system
Active directory and LDAP servers: to map user names to actual user identities
Attack details and vulnerability information: to gather additional details about the log data and/or the log source.

BTW, back in 2008, I did a poll on what context is the most useful for log analysis. That is what came back – it shows that some useful context is simply documentation on what the log mean (might be pulled from the internal knowledge base of a SIEM product):

poll-context-results

Enjoy!

Thursday, January 21, 2010

“I Want to Buy Correlation” or How NOT to Pick a SIEM?

Somebody showed up at my door the other day and said “I want to buy some correlation!” Don’t get me wrong – I love correlation; I developed correlation rules for a living some time ago. Correlation is totally fun. That’s why I wrote a couple dozen papers defining and explaining security event correlation (example here, here, here).

Despite all that, I am still shocked when I see people who define their requirements for an expensive security product (such as Security Information and Event Management – SIEM) in that form: I want to buy correlation. BTW, I ridiculed this as one of the “worst practices” here in this fun presentation – see slide 11.

First, correlation engine is … well… an engine. What can you do with an engine? Unless you are an engine mechanic and think that it is fun to just tinker with it, you probably prefer this engine to be embedded in a car. And car is that thing that allows you to get from A to B faster [than walking … unless you drive up RT101 in the morning]. So, you are buying “transportation” and not “correlation.” Or, in our security realm, you are buying [a chance for] automated near-real-time detection of incidents. Or a tool to simplify your security monitoring.

Second, engine needs oil and gas to operate. What is correlation “oil and gas”? Content! This jargon term simply means correlation rules, alert/notification templates, views, workflows and reports that define how correlation will actually solve your particular problem. That is not everything that allows the engine to contribute to solving “the transportation problem,” but it is pretty darn important. Even engine mechanics drive their cars using oil and gas, even after they build that extra turbocharger on the side :-)

Third, the above two points should tell you that you need to know what problem you are trying to solve with correlation before you go “shop for correlation.” And here is something magical: don’t pick a problem of “improving food quality in a buffet on a ‘Titanic'.” Pick ship survivability instead! (BTW, “Titanic” was compliant!) What I mean here is that if you are not ready to handle real-time notification of incidents, then focus on investigations first with log aggregation, indexing and searching. This paper should jolt your brain in this useful direction.

Now, if your organization is looking for some help defining the requirements for a SIEM or log management product, choosing the right tool etc, figuring out how to operationalize it, I can definitely help.

BTW, this is posted by the scheduler. I am away attending to a family emergency; response to comments will be slow.

Possibly related posts:

All blogs posts on SIEM
“Titanic Was Compliant”

Tuesday, January 19, 2010

Some Fun Reading and Listening

As I am preparing to attend to a family emergency and thus go “offline” for a while, here is something fun stuff for my dear readers:

“PCI War” rages one in this “CSO Online” podcast “The Great PCI Security Debate of 2010: Part 1” [MP3] with such fun people as Joshua Corman, Mike Dahn, Jack Daniel, Ben Rothke, Martin McKeay, etc. It is a bit chaotic at times, but fun and enlightening. It was also fun to participate in, despite the fact that it was recorded at 7AM. This piece provides some background for the debate.
The second part of the PCI debate was just posted here.
Those with interest in SIEM must read Rocky’s “The 2010 SIEM Winter Olympics Preview”

Enjoy! More fun posts coming when I am back. For now, buy The PCI Book :-)
BTW, see you all at ShmooCon and then at RSA 2010.

Wednesday, January 13, 2010

More on PCI DSS and Logging

Despite my older post on this (“MUST-DO Logging for PCI?”), people continue to harass me to create an “authoritative” guide on logging for PCI DSS: what events to log? what details to log? what logs to retain? what logs to review? how to review? etc, etc. BTW, the quotation signs above are there since only your QSA holds an authoritative view on the subject; the rest have to settle on “defensible” view, such as the one from my very self :-)

So, OK, I will [eventually] share my entire defensible guide on logging for PCI DSS, even thought it doesn’t sound anywhere near as glam as an authoritative guide would :-). In this guide, I analyze all the PCI DSS logging requirements (in Requirement 1, 5,10,12 and all others too) and translate them info a logging policy and more-or-less-actionable tasks and operational procedures, while making few assumptions here and there about your organization. What it more important, I cover both PCI logging requirements that you need to achieve PCI DSS compliance, stay compliant with these requirements and what you need to [most likely - see the comment about QSAs above] get validated. It goes without saying that such logging will be actually useful, following the traditional "compliance+" model.

Still, no externally-created guide will ever be fully effective in defining logs and logging for your organization, for your applications, for your in-scope PCI environment. Indeed, the only way to get it right is to hire a consultant and have him customize and “operationalize” the document by replacing the assumptions with actual facts about your organization [oh-nos, I started to sound like a consultant already :-)]
The document will be shared later this year (unless I roll it into my upcoming book on log management..oops!.. that was a secret :-)) If you want it sooner, you can hire me to do this for you organization as some other people just did. Here are some examples of what I built for this F1000 consulting client:

Logging Policy
In light of the above, a PCI-derived logging policy must at least contain the following:

Adequate logging, that covers both logged event types and details
Central log aggregation
Log retention (1 year)
Log protection and security
Daily log review

[…]
Let’s now focus on log review in depth. PCI DSS states that “Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).“ It then adds that “Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6”
PCI DSS testing and validation procedures for log review mandate that a QSA should “obtain and examine security policies and procedures to verify that they include procedures to review security logs at least daily and that follow-up to exceptions is required.” QSA must also ”through observation and interviews, verify that regular log reviews are performed for all system components.”
Below [in the full document, not here – A.C.] we document PCI Application Log Review Procedures and workflows that cover:

Log review practices, patterns and tasks
Exception investigation and analysis
Validation of these procedures and management reporting.

The procedures will be provided for using automated log management tools as well as manually when tools are not available or not compatible with log formats produced by the application.”

Possibly related posts:

MUST-DO Logging for PCI?

Monday, January 11, 2010

How to Stay Compliant? or Ongoing Tasks in PCI DSS

This post and, of course, the paper included below, are inspired by some work I’ve been doing on so-called “ongoing compliance,” in particular as it applies to PCI DSS. The table in the paper below is the result of my going through the text of the Data Security Standard and extracting all the requirements which are NOT “one point in time”, but periodic in nature. I did it just to prove to some buffoon that PCI actually mandates security things to be done periodically and NOT just before the assessment were to start or SAQ was due. No deep thinking here, but a useful reminder about the fact that …

Validation is “point-in-time”
Compliance is “over time.”

BTW, a good QSA can check for signs that an organization is actually “equipped” for ongoing compliance and not simply “cooking evidence” to impress him…
===================================
“What do I really need to do to STAY compliant?” paper was originally published here. BTW, check out this fun PCI DSS poll that accompanies the paper (results, vote).
Lately, a lot of security industry discussions have been focused on PCI DSS- Payment Card Industry Data Security Standard. The conversation ranges from practical advice on “how to get compliant” all the way to branding PCI as a devilish invention (Google for “PCI is the devil”) Fiery debates aside, PCI DSS guidance helped countless organizations to see the light of security where there was none before. It goes without saying that it didn’t magically make them “become secure” – no external document can.
One of the frequent criticisms of PCI DSS focuses on the misguided view that “PCI is all about passing an ‘audit’.” Many people would be surprised to find out that PCI DSS lists specific tasks that you have to be doing all the time – NOT just before the assessment. This paper focuses on the exact steps organizations must take to actually stay compliant and not just pass validation via scanning, on-site assessment by QSA or self-assessment questionnaire ( SAQ)
Indeed, very few experts will actually tell you how to STAY compliant and not just how to GET compliant. Recent cases of massive card data breaches at companies that were at one point validated as PCI DSS compliant show that staying compliant is much harder than getting compliant. Security benefits of PCI DSS are not realized just because an assessor in a fancy suit tells you that are “validated as compliant.” Such benefits are there if you are “doing PCI” and “doing security” every day (yes, PCI does included daily tasks for you to do!) By the way, if you are trying to use PCI DSS to launch your security program, this resource would be a useful guide.
Despite the above focus on “getting compliant,” some security vendors preach the theme of “ongoing compliance.” In fact, they’ve been doing literally for years. Of course, the “ongoing compliance” theme is awesome. Sadly, a majority of the same vendor customers don’t do it like this (to their own loss – this why it is sad). They still have assessment-time rush, “pleasing the QSA” approach and “checklist-oh-we-are-DONE” mentality. We can conclude that before one wants to “sell” continuous compliance concept, one need to educate the audience first.
To top it off, achieving 100% PCI compliance for validation gets much more resources at corporations, compared to maintain 100% PCI compliance.
In light of the above discussion, a lot of people are surprised that PCI DSS document itself contains a list of tasks to perform to maintain compliance between assessment. The table below shows these periodic tasks:

	PCI DSS Requirements Version 1.2.1	Period
3	3.6.4 Periodic cryptographic key changes § As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically § At least annually	1/year
6	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 by either of the following methods: § Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes § Installing a web-application firewall in front of public-facing web applications	1/year
9	9.5 Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location’s security at least annually.	1/year
9	9.9.1 Properly maintain inventory logs of all media and conduct media inventories at least annually.	1/year
12	12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment	1/year
12	12.1.3 Includes a [security policy] review at least once a year and updates when the environment changes	1/year
12	12.6.1 Educate employees upon hire at least annually	1/year
12	12.6.2 Require employees to acknowledge at least annually that they have read and understood the company’s security policy and procedures.	1/year
X	On-site QSA assessment (Visa L1, Amex L1, MC L1-2, etc) or self-assessment (Visa L2-L4, Amex L2-3, MC L3-4, etc)	1/year
1	1.1.6 Requirement to review firewall and router rule sets at least every six months	1/6 months
11	11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use	1/quarter
11	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).	1/quarter
11	11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files or content files; and configure the software to perform critical file comparisons at least weekly.	1/week
10	10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).	1/day
12	12.2 Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures).	1/day
	A lot of other processes require to “maintain”, “ensure”, etc - as well as procedures mentioned in item 12.2	As needed

(Source: PCI Data Security Standard, v. 1.2.1)
What do we learn from the above on how to stay compliant? Based on the above, we can come up with the following lists of periodic tasks, which are directly mentioned in the DSS (many more, of course, are implied…):
Every year
o Review security of web application
o Review security policy
o Perform security awareness training
o etc
Every six months
o Review firewall and router configurations
Every quarter
o Perform external and internal vulnerability scanning
Every week
o Run integrity checking on critical files
Every day
o Review logs from the systems in scope for PCI
o Perform other daily operational procedures defined in security policy

To conclude, while getting compliant gets more attention, staying compliant is where a lot of mistakes and faults (leading to data breaches) are made. As you are working on PCI DSS compliance related initiatives, make sure that staying compliant” is taken just as seriously as getting to that first validation…
Finally, there are still 2 days left to get THE “PCI Compliance” book at 30% off launch discount.
Possibly related posts:

All PCI DSS blogging on my blog.

Thursday, January 07, 2010

Annual Blog Round-Up – 2009

If monthly, why not annual blog round-up? These are my top popular "Security Warrior" blog posts for 2009. This list covers the posts most popular in 2009, not necessarily only those written in 2009. Enjoy!

The quest for open source SIEM continues! In fact, the TWO top posts on my blog in 2009 resulted from search queries for “open source SIEM.” They are: “Why No Open Source SIEM, EVER?” and “On Open Source in SIEM and Log Management.” BTW, all SIEM posts are tagged here.
Next, we got scientific (eh..statistical :-)) proof that Heartland Payment Systems mega-breach was The Security Event of 2009. My coverage of the Heartland saga is next on the top list: “On Heartland”, “On Heartland II”, “On Heartland III”, “On Heartland IV”, “On Heartland V”, “On Heartland VI.” BTW, what is the overall security lesson of the “HPS-gate”? Sorry, but it is “it’s OK to have a massive card data breach!”
I suspect a lot of security folks do a lot of career soul searching nowadays. That is why “A Myth of An Expert Generalist” is so HOT. I suspect you already read it, but if not – go do it!
It is interesting that Windows log collection is still very much an issue with many folks. That is why “Windows Log Collection Poll Analysis” is in the top for the year.
“Thoughts and Notes from PCI DSS Hearing in US House of Representatives” needs no introduction or explanation why it is on the top list for 2009 :-)
“Top Log FAIL!” summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.” Log management at its worst!
I am not really “a rant-master”, but some of the more philosophical posts (“Smart vs Stupid: But Not Why You Think So!”) end up being very popular – this one definitely struck a cord with many people.
““Compliant” + 0wned = ?” … this posts seeks to answer this “eternal” question.
A champion of multiple months – AND last year!- “MUST-DO Logging for PCI?” is also on the list the second time; the world does need more specific PCI DSS guidance. PCI DSS guidance is not “too prescriptive,” it is more often not prescriptive enough! BTW, you can hire me to help you with your logging, log architecture, log management/SIEM product selection or related product development.
“Five Reasons to Dislike PCI DSS – And Why They Are WRONG!” is a fun little piece which fights the war in defense of PCI DSS.

See you in December 2010 when I will post the next annual blog round-up (see my previous annual “Top Posts” - 2007, 2008)
Possibly related posts / past monthly popular blog round-ups:

Obligatory “added everywhere” posts :-)

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

Tuesday, January 05, 2010

Monthly Blog Round-Up – December 2009

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

It sure seems like most SIEM vendors and log management vendors have again camped at my blog :-) How else can I explain that “Log Management + SIEM = ?” takes #1 spot in December? This topic is getting really, really hot – it is also the subject of my recent consulting projects.
Completely unsurprisingly, my “Security Predictions 2010” post takes a much deserved #2 spot. Why #2? ‘Cause my 2020 information security predictions went up on 1/1/2010 only and didn’t make it into December top roster :-)
“Top Log FAIL!” is still hot! The post summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.”
Again this month, “Smart vs Stupid: But Not Why You Think So!” stays on the most popular post list. You need to go read it to know why it is so awesome :-)
“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.”
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.” While you are reading up on SIEM , check out the post called “SIEM Bloggables” with key SIEM use cases.

Thanks for all the link-love! And now back to carving powder at Heavenly :-)

See you in January; also see my annual “Top Posts” - 2007, 2008 and the coming 2009!

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

Obligatory “added everywhere” posts :-)

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

Friday, January 01, 2010

Security Predictions 2020 (!)

How impossible is it to predict anything in the field of information security? 10 years? Into the future? Still the purpose of this endeavor is not necessarily to “have everything right”, but to have fun in the process and to get people to think beyond the immediate tactical horizon in information security.

Let's start from the overriding trend that will define the rest of the discussion:

That trend is that the walls between the computer world (aka the Internet, cyber-anything, online, virtual, cloud, etc) and the “real” world (aka meatspace, Earth, “outside”, “reality”, offline, etc) will break down beyond a certain interesting point, both on the perceptual level and in reality. With – duh! – huge implications to our profession and practice of information security.

What do I mean by this?

Whether perception is reality on not, studies I’ve seen (examples, more, more, more) point that most people behave differently in an online world and in the so-called “real” world. People can also point at many factual differences between online world (that happens inside the human created medium – networked devices) and the outside. I believe that this difference explains at least some of the current information security problems – on some deep level people just don’t see computer intrusions and other issues as “real enough” for them. Even the simple fact that we have “crime” and “cybercrime,” points that this difference.

So here is the punch line: I think that in the next 10 years these two worlds will be much closer to each other, in both perception and “real” reality. HUGE implications to information security will result.

Where's the evidence? Here are all the things that I bundle in that “ultimate convergence”

Everything geo-related: GPS in phones, location- aware services, and even integrated Internet in cars. When you start to “google for coffee,” you straddle both worlds.
Augmented reality, conspicuous high-speed video uploads (in 2020) and video analytics capture the real world and ”map” it onto the online world. And as computing devices first become wearable (needed for AR), and then implantable (best for AR), the convergence between both worlds will become even more intense.
Everything computing embedded in objects: embedded computers in an ever-increasing percentage of the things we use in the real world; these will go a long way from the first Internet-connected refrigerator. Yes, clothes and shoes, not just sunglasses, are not far behind – and with bluetooth or whatever future incarnation, such wearable “PAN” becomes within reach. BTW, trains and planes run on computers too… And I am not even touching SCADA.
Everything robotics: robots, from Roomba to military hardware, is one more way for a computer realm to “act out” in reality. If you are confused about this argument, think about the following: a crashed computer will destroy only a computer and information inside. A crashed computer in a vacuum cleaning robot can potentially destroy … your carpet. A crashed computer in a robotic high-speed cannon… you get the picture.
On a perceptual level, some studies have noted that younger generations (and here) do not draw the line between their Facebook friends and their real-world friends. This is an example of the same trend, but occurring in the mighty realm of perception. If you are born and then grow up with (and on) the computer, you views of “computer world” will be different from those who still see computers as something “not really real.”
On top of this, advances in bio-sciences will obviously rely on computers and algorithms. I predict this would be another way for the computer realm to impact the “meatspace” and not only through the implantable computers.
Finally, the Ultimate Proof that such convergence has in fact taken place will be - you guessed it right! – cyber-terrorism. Smart folks today object to the concept of cyber-terrorism by [correctly!] stating that “real world” terrorism is more impactful. Today – it sure seems like it. In 10 years, when “real world” is so much closer to the “computer world” – I am just not going to bet on it…

All of the above will make information security and computer security (as well as a dying art of network security) PAINFULLY more relevant for people’s lives. If an attacker from a remote location can crash the computer and steal your data, this is bad. If that same attacker can impact what you perceive to be your “real world,” the game changes. And change it will - probably even before 2020. What will stand between such attacker and others? That’d be you and me, my dear reader :-)

The above convergence will also be combined with these “side trends”, all with big impact to security:

In 2020, a lot of tasks can only be done with computers - or not at all. Now we can still buy a book in a bookstore, you can pay with a credit card when computers are down. Forget that – in 2020! Such irreplaceability of computers and Internet will make security sharply more relevant. Your business will not simply switch to an old, inefficient mode, when Internet is not an available. It will STOP.
To quote Alvin Toffler, there will also be a lot more information and thus a lot more computers to process it. These are added to the above mentioned embedded computing devices. The result is not just an increased target set, but also more businesses being completely reliant on computers for their operation.
I also predict a much larger use of non-deterministic algorithms, such as those based on statistical methods. This will imbue the phrase “computer did it” (and we don't know why and how) with a whole new meaning…
Complete local and network scope convergence due to cloud computing and ubiquitous connectivity. They will be no such thing as a device asking “can I connect to the Internet?” As a result, Internet becomes a fabric of distributed applications, not client/server push/pull model we still largely have today. Security implications? You bet! BTW, this will also kill the whole “but why did they connect that to the Internet in the first place?!” thinking.
As a result of the last point, the whole control over data will have to be done in a completely new way - or not at all. And if you think web hacking is fun today, just wait until 2020 :-)

So, I don’t know what features your log management system will have in 2020 or what the label “firewall” will mean in 2020, but I know is that it'll matter much, much more than now. Despite all the harping about information being “critical for business”, we only protect information today. Sorry for a bit of grandstanding here, but we will literally protect the world in 2020…

Enjoy!

BTW, other fun views of the year 2020 technology are here (created in 1994), here (created in 2005), here and in many other places.

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.

First, if you have to read only one thing, read everybody's security predictions for 2010: http://delicious.com/anton18/security+predictions+2010
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.”
“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.”
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.
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”)
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”
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.
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.”
And some more log reading, calling to love log analysis. And here as well, but more on the fuzzy size :-)
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.
“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].
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.
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)
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)
I just discovered that SANS is running their annual log management survey. It beats me why they are keeping it secret :-(
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:

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 :-)
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.
Another useful (=non-rant-ish) PCI DSS piece that I forgot to highlight: “Lessons Learned From PCI Compliance”

Enjoy!

Possibly related posts:

All other security reading posts.
All security predictions.

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 del.ici.us annual security prediction tracker: http://delicious.com/anton18/security+predictions+2010. 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 (http://www.govinfosecurity.com/articles.php?art_id=1774&rf=091509eg) “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:

“Implementing and Running SIEM: Approaches and Lessons” (HOT!), given in St Andrews in Scotland in November 2009. All SIEM/SEM/SIM/log management people, check it out. You can get most of it here with voice… but there is a catch :-)
“PCI 2010: Trends and Technologies”, given at “PCI 2010: Trends and Technologies” by BankInfoSecurity. You can get it here with voice and some fun subsequent discussion. It is about PCI DSS and contains the nor-infamous floor-and-ceiling picture…
“PCI DSS Myths 2009: Fiction and Reality” (a slightly updated version of my PCI DSS myths), given at a recent ISC(2) webinar called “PCI 360: Multiple Perspectives”. You can get it here with voice.

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: www.pcicompliancebook.info

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….

Enjoy!

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:

Breach Report 2009 Day …

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:

“PCI Compliance” Book 30% Discount code

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:

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.
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.
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.
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.
“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. 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:

On SIEM Complexity
All posts on SIEM.

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:

Book website (check out a couple of free PCI DSS sample policies there!)
Official page of “PCI Compliance” at Amazon
Book page at Syngress website (has full book Table of Contents); for the above discount code, you have to buy it from here.
My co-author’s Branden Williams website and blog.

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.

Enjoy!

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.

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 :-)
“Top Log FAIL!” is still hot! The post summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.”
“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.”
“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.”
“SIEM Bloggables” post covers key SIEM use cases – it is part of the presentation which is yet to be posted.
“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:

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.

Monday, November 30, 2009

“Leaving Vendorland” or Consulting Full-Throttle

I have a horrible confession to make: I was “vendor scum” for most of my security career. All good things come to an end – replaced by better things, of course.

Since departure from my last job, I discovered the world full of exciting projects where I can be incredibly useful. For some logging projects, I can be more useful than anybody else in the world (and, no, this is not my ego talking). At the same time, I discovered many jobs at “wonderful” large companies, where everything developed two years after the market is considered “innovation.” Maybe this is why I don’t really believe in security market consolidation: BigCo=slow while threat=fast leads to some nice EPIC FAIL of “consolidation.” In any case, I’ve seen a lot of fun projects, and not enough fun jobs. Thus I decided to start developing my own consulting practice.

With this post, I am “officially” announcing my switch to consulting (even though I’ve been busy consulting for a couple of months already). Here is a quick summary of my services, also posted at Security Warrior Consulting site:

Technology vendor services: compliance strategy for a security product, security and compliance content development, “thought leadership” webinars, training and writing, etc.
End-user organization services: development of logging strategy, logging policy, log review procedures, planning of log management architecture, etc.

Go see more details on my new consulting site or look at the full services menu [PDF]. At this time, I am working on a couple of very fun projects, but will look for more work along the above lines in the future. If you have anything of that sort for me, please get in touch (email, other methods)!

Finally, if I discover new fun security things to build and evangelize, I will once again join the noble ranks of vendor scum…

BTW, our “PCI Compliance” book should be out any day now and our book website is “ready for business.” Time to get back to work on that logging book…

Possibly related posts:

Not at Qualys Anymore

Tuesday, November 24, 2009

Two Fun PCI Appearances

FYI, this week I spoke at these two fun PCI DSS events (both virtual):

PCI 2010: Trends and Technologies by BankInfoSecurity.com
PCI 360: Multiple Perspectives by ISC(2)/BrightTalk

If you are into that sort of thing, check them out.

BTW, the PCI book is about to be printed – and our official PCI book website is almost ready!

Fun Reading on Security and Compliance #21

This edition of dedicated to all the folks who write blogs, but never read blogs. Shame on you :-)

The “60-minute-gate”: start here, then comments here and here.
Hilarious SIEM/log management video (“I need an outlet for my detective instincts”).
Did somebody finally beat “the Levin record” (which seems not really his now) from 1994? Stealing $9m purely through computers is kinda cool :-)
This shit is deep: data breaches cause data abuse (fraud, etc), says recent research. Captn Obvious award does not go unclaimed :-)
Detecting Malice eBook is out. Get it!
NIST SCAP Conference presentations are finally posted (including mine). Check them out here.
Privacy and future shock discussion: read this (“Forget Privacy, It Is Just An illusion”), then this (“Gartner Gets Privacy Dead Wrong”), then this (“Bob Blakley Gets Future Shock Dead Wrong”). Fun to read and think about.
“HIPAA teeth” and HITECH act, very interesting. Also, this says that “57% of the survey respondents said they would make additional investments in security tools or technologies” [due to HIPAA/HITECH]. Is this for real?
Various smart people beat up risk assessment: here (“The practice of risk analysis is one of the root causes of our failure to match security countermeasures to the emerging threats. It depends on too many unrealistic assumptions”) and here (“I think one of the “hot” areas that I care about is being able to quantify risk. I personally don’t think this can be done because I’ve had too many customers show me their risk measuring systems and I’ve found fault with them.”) And then some other people defend it.
Gunnar’s cloud wisdom: Part 1,2,3a, 3b. Did I mention it is awesome?
Dave for the n00bs. Useful read, and not just for the n00bs: “Please please please please PLEASE do not come out of school with a degree in “Information Assurance” or some other bullshit and tell me you are a security professional.”
As I think more about SIEM, I find this old Decurity post very insightful, even though its enlightened creator has been absorbed by the EMC machine :-)
“The Art and Science of Infosec” is surprisingly insightful. Key quote: ”too many security folk, especially consultants and auditors, seem to fall into the trap of having the science drive their work more than the art.”
I read this (“Is Your Response Time Less Than 120 Days?” that talks about a security monitoring tool which was “mistakenly turned off for a four month period.”) and it reminded me of my old paper on "the fallacy of real-time” (here). Why obsess about sub-second correlation on your SIEM, if your “process” is to respond to events months after they happen? I like to call it “Is CNN your IDS?” syndrome. :-)
“Change the game” or “raise the bar”?

PCI DSS section:

I can’t think why I haven’t highlighted it earlier: “Will PCI Mandate The Use Of Data Discovery Tools?” It is from Branden “Awesome” Williams, now of EMC.

Enjoy!

Possibly related posts:

All other security reading posts.

Friday, November 20, 2009

Smart vs Stupid: But Not Why You Think So!

This slightly rambling post was born out of some fun conference discussions and well as pondering the “PCI is the Devil” theme. So, some interesting dichotomy was born as a result. Let’s temporarily call it “smart” vs “stupid” security, but if offensive labels … well.. offend you, you can pick something else instead :-)

The table below shows some concepts loosely associated with each security paradigm (of course, this whole thing is a gross oversimplification, but useful for our purposes nonetheless):

“Smart” Security	“Stupid” Security
Incident response	Badness prevention
Risk (to the extent understood … which is often not much)	Compliance, “doing the minimum checklist”
C of C-I-A, moving to I	A of C-I-A
Monitoring for attacks	“Nobody wants to hack us”
Logging + log analysis	No logging
Application security	Network security
System perimeter, application perimeter, network perimeter, “data perimeter”	Network perimeter
Firewalls, SSL, AV, IDS/IPS, WAF, SIEM, DLP, DAM, SDLC, VM, etc	Firewalls, SSL, AV
People	Boxes
Visibility (striving for it) – know control is impossible	Control (failing with it) - afraid of visibility
Metrics (striving for it)	FUD
Want to know how secure they are	Afraid to know – but want to just “be secure”
0wned (know it, care to have less of it)	0wned (don’t know and don’t care)

Now, forget my “offensive” column labels that I added to purposefully confuse you :-) Even though security literati prefer to call the left column “smart”, “correct”, “good”, “risk-based”, “new school”, etc while label the right column “stupid”, “wrong”, “evil”, “checklist-based”, etc, it is more useful to think of the left as “RARE” and of the right as “TYPICAL” if you consider the organizations of all sizes.

However, things are actually a bit worse, even “TYPICAL” security from the right column is more than some smaller organizations have. And this is where PCI DSS comes in, an angel with a flaming sword :-) In this context, PCI is a noble attempt to bring many organizations to somewhere better than the above “typical” level. And this is why I think it is awesome.

P.S. If you were expecting a post on why PCI sometimes IS the devil, that will come later :-)

Possibly related posts:

Tuesday, November 17, 2009

SANS Log Management Class in Sacramento

FYI, I will be teaching my SANS class SEC434 called “Log Management In-Depth: Compliance, Security, Forensics, and Troubleshooting” on December 2nd in Sacramento.

Details: “This first-ever dedicated log management class for IT and security managers will cover system, network, and security logs and their management at an organization. We will start with the basics, like making sure that logs exist, and then go on to touch upon everything from managing log storage, to analysis techniques, to log forensics and regulatory issues related to logging.

In the beginning, we will cover various log types and provide configuration guidance, describe a phased approach to implementing a company-wide log management program, and go into specific tasks that IT and security managers need to be focusing on a daily, weekly, and monthly basis in regards to log monitoring.

A unique and comprehensive section that covers the hot topic of using logs for regulatory compliance, such as PCI DSS, will also be presented. Everybody knows that logs are essential for resolving compliance challenges; this class will teach you what you need to concentrate on and how to make your log management compliance-friendly.

The class will also touch upon various uses of logs for incident response, forensics, and operational monitoring. Common logging mistakes, learned from many years of working with logs, will also be explained.”

Sadly, the class is NOT public, but open to employees of the State of CA only (this time). The next time the class will be taught at SANS CDI 2009 (sign up!)

Anton Chuvakin Blog - "Security Warrior"

Wednesday, February 10, 2010

Tuesday, February 09, 2010

Thursday, February 04, 2010

Wednesday, February 03, 2010

Tuesday, February 02, 2010

vs

Monday, February 01, 2010

“An Existential Threat To Security As We Know It?

Thursday, January 28, 2010

Tuesday, January 26, 2010

Thursday, January 21, 2010

Tuesday, January 19, 2010

Wednesday, January 13, 2010

Monday, January 11, 2010

Thursday, January 07, 2010

Tuesday, January 05, 2010

Friday, January 01, 2010

Wednesday, December 30, 2009

Monday, December 28, 2009

Thursday, December 24, 2009

Tuesday, December 22, 2009

Thursday, December 17, 2009

Friday, December 11, 2009

Wednesday, December 09, 2009

Tuesday, December 08, 2009

Monday, December 07, 2009

Friday, December 04, 2009

Wednesday, December 02, 2009

Monday, November 30, 2009

Tuesday, November 24, 2009

Friday, November 20, 2009

Tuesday, November 17, 2009

Dr Anton Chuvakin

RSS Feed

THE "PCI Compliance" book

My Links

Twitter

Twitter

My del.icio.us Feed

Topics

Followers

Blogroll

Labels and Tags

Lijit Search Wijit

Blog Archive

About Me

Lijit SBN Search