Bottom 11 Log Management "Worst Practices"

FYI, this piece has been especially created for LogManagementCentral (original post). It is reposted here for posterity.

 

Many organizations talk about “best practices” for security, log management, SIEM, etc. The definition of such practice is often fuzzy (and overrun by marketing influences…) but can be loosely related to what leaders in the field are doing today and what practices generally lead to great results. Following the same model, we can create a definition of a “worst practice”:

· What the losers in the field are doing today

· A practice that generally leads to disastrous results, despite its popularity

Here are some of the “worst practices” in the area of SIEM and log management that I have observed over the years:

1. Skipping the requirement definition stage of SIEM purchase is one of the worst, albeit common, practices one can take. It almost always leads to failed SIEM projects, unmet needs for customers as well as unjustified anger aimed at technology providers. “John said that we need a correlation engine” is not the way to define your requirements, by the way.

2. Postponing the environment sizing until the purchase is another generally disastrous practice. Even if you plan to eventually collect “everything”, the initial implementation will only have a specific smaller set of data. Careful sizing of that initial phase by watching your logs for a week or two is very important.

3. Choosing by price alone has led to many wrong purchases – and not only in the realm of SIEM. SIEM and log management products are priced from $0 to a few hundred to millions – and there is usually a difference in both capability and scalability between tools with dramatically different prices. Remember that tool can be 30% cheaper, but be “only” twice as bad…

4. “Saving time” by not checking references is another common bad practice at purchase stage. Your environment might be unique, but references is one of the few ways to know that the tool you’re planning to purchase has the will of somebody else. Skipping Proof-of-concept is even worse- that is your way to test a complex new tool in your environment!

5. Expecting the vendor to tell you what you need to log happens more frequently than you might think. Sadly, the only person who knows your needs and requirement for logging, log management and log monitoring is you – not the vendor. If you don’t know – then nobody does.

6. SIEM implementation is often a very “political” affair and thinking you can do it alone without involving others from you organization is definitely the worst practices. SIEM touches systems, network devices, possibly IdM systems and many other components – each with their own business owners and administrators. These people and teams have to be involved in SIEM implementation; and there is no way around it. Preparing the infrastructure is key for the deployment, even if you simply need to make sure that all log source systems has their time synchronized.

7. Ignoring your legal team is a quick way to FAIL with SIEM, especially if your project covers log data from multiple countries. Log data is covered by a conflicting laws and regulations and only your organization legal counsel can figure it out.

8. Deploying everywhere at once and not in phases is a way to run out of budget, management patience and other resources. Phased approach – both in terms of log source scope and SIEM capabilities (from simple to more advanced) – is the only way to go. Focus on “quick wins” in each phase.

9. The interface is “intuitive” so who needs training? Avoiding training is not the way to save money on a SIEM tool. SIEM and log management tools connect to many pieces of the infrastructure and applications. The vendor or consultants might teach you how to resolve many of these challenges, based on their experience with other customers

10. Not checking for changed needs as your SIEM implementation expands is another way to fail. Even though your SIEM may have a few problems, it does not necessarily mean that it can solve every problem you have. Notice how some organization deployed log management tools and then had to expand their deployments to full SIEM due to evolving needs. “We made the decision years ago – why fuss over it?” does not work for integration-heavy technologies like SIEM.

11. Finally, expecting immediate reduction in work after deploying a SIEM is unreasonable. Unless you deploy, customize and tune your system, it is likely that you will not see massive resource savings. SIEM is a great example of “to get value you have to work on it” rather than a magic box that “tells you what is wrong”…

What good or bad practices with SIEM and log management can you share?

Nobody Is That Dumb ... Oh, Wait XIII

Perhaps surprisingly, but “Information Security” magazine allowed me to restart my long-forgotten “Nobody Is That Dumb ... Oh, Wait” series. The last post in the series was a long time ago, so thanks to them we now have the  #13. Hurrah!

So, their latest issue has this brilliant piece of sheer idiocy:

Do you really need me to comment? Just laugh… TrendMicro gets a Silver Prize in SIEM category … WITHOUT EVEN HAVING A SIEM PRODUCT. And “reported dead a few times” Symantec SIM gets a Gold Prize, but that just gets filed under “insult to injury” category…

So, even though my subscription has expired, I just updated my address with them so that they can send me some of the stuff they are smoking.

Possibly related posts:

• Everything else labeled “stupidity”

Nobody Is That Dumb ... Oh, Wait XII

RSA is that time of the year when a lot of otherwise hidden hilarity is suddenly exposed – thru the work of noble PR folks. For example, below is a pre-RSA press email I received the other day – it made a perfect candidate for my “Nobody Is That Dumb ... Oh, Wait” series. The last post in the series was a while ago, so this was a perfect opportunity to revive the series.

“I know your time at RSA is filling up, but I wanted to tell you about “Embarrass Security” [company name sanitized – A.C.], a company that is changing the way companies protect their web properties. “Embarrass Security” is going to be at booth No. XXX [sanitized – A.C.] during RSA and will be:

• Announcing a new ‘counter-hacking appliance’ for enterprises
• Demonstrating a ‘live hacking & sting operation’  demonstration in the “Embarrass Security” booth (with the disclaimer that no animals will be harmed in the production of the demo)

With the counter-hacking appliance, “Embarrass Security” will demonstrate the ability to alert companies when hackers are knocking at the door, and can also show how they thwart evil intentions by making sure the hackers don’t actually see what they think they’re seeing. “Embarrass Security” enables enterprises to protect their web properties at a deeper level that even the bad guys can’t touch.”

Nothing to add really.. let’s all go buy the “counter-hacking appliances,” thwart some evil intentions and be done with it :-)  I can’t help but wonder what kinda people work for their product management / marketing team…

Possibly related posts:

• Everything else labeled “stupidity”

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?

1. “P” in “APT” stands for “persistent”, “P”in PCI stands for … well … PCI is pretty darn persistent.
2. Both are absolutely a threat, whether of non-compliance or of severe 0wnage…
3. “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.
4. 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?
5. “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)
6. With PCI, you don’t always know what you need to do; with APT you almost never know what to do.
7. Also, you are never “done” with PCI, you need to maintain compliance and security; you’re absolutely never “done” with APT.
8. PCI compliance requires logging and monitoring; dealing with APT absolutely requires extensive logging and monitoring.
9. 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.

Praying to PCI Gods

Obviously, inspired by Amrit’s “Exorcising the PCI demons” and, in fact, morphed right from it.

“… But let’s get back to Josh’s demonological metaphor and consider some of the ways that PCI resembles ...” the Benign Deity (specific deity is up to the reader…)

The God holds promise. PCI DSS offers its adherents access to the spiritual riches — and not only those attainable through debit and credit cards—so long as they know and respect (and validate!) PCI’s 12 commandments. While delivering its spiritual riches, it also makes its adherents BETTER in the process: better security, better businesses, better awareness of the threats.

The God is honest. PCI does not promise falsities such as “to make retailers secure against hackers.” It promises to raise them out of the ignorance and “0wnage” to finally having a modicum of much-needed security technology and process.

The sorry history of breaches, blowouts, and damaged reputations attests that there is a long and sometimes difficult road ahead of us and that both faith and hard work will be needed along the way.

The great thing is that PCI is likely the best that many organizations can use to protect a transaction technology based on account numbers, magnetic stripes, fixed user identities, and passwords.

The God is an inspiration for goodness. PCI has led countless companies and organizations to improve security and reduce their operational risks – as well as instill customer confidence.

Security professionals often find themselves assisted by the PCI God when they win an argument with management which then allows them to start taking actions to block threats and keep the business running and out of the negative press. PCI both inspires them to build a solid security program and helps them as a powerful force for good security.

The God loves humanity, even its haters. As at least one commentator has pointed out, the PCI standard is a brilliant way to shift responsibility for IT security from card issuers to retailers.

It is indeed brilliant since many merchants are negligent and lose card data in massive amounts as a result of their own ignorance, but issuing banks have to “eat” all of the card replacement costs which are due to no fault of their own.

Card issuing banks did not invent and institute the technologies that have proven so vulnerable to moderately skilled hackers. When a breach occurs, merchants shrug and talk about their devotion to promulgating security measures, knowing that the issuers will be left with all of the card replacement costs and some of the fraud costs.

The God is sometimes a sacrificial lamb. There are two groups that will vehemently attack the virtues of PCI by completely lacking any insight into it. One group are organizations who refuse to implement any security measures and prefer to be negligent and breach the social contract with their customers by losing their data left and right. The other group are idiotic perfectionists who want all the data to be protected all the time, no matter what the business impact. The latter group also wants somebody (but, obviously, not them!) to pay for an overhaul of the world’s electronic payment processing systems.

Vendors that provide security solutions and those that provide PCI assessment services, also known as qualified security assessors (QSA), will always position PCI as necessary and useful for security. Indeed, PCI God guides the willing – by providing the Data Security Standard – and motivates those still in the darkness – by providing the validation regime and His army of God’s Angels aka QSAs.

At this point, readers may ask, with all of the God’s awesomeness and track record in doing good even to those who prefer to remain ignorant, why do people criticize it? Well, remember the old saying: "I see..."

UPDATE: link for the "I see..." updated; the previous link had some bad language in comments. Thanks for one of my readers for pointing it out.

Amrit, sorry for all the quoting! :-) Enjoy!

Possibly related posts:

• Five Reasons to Dislike PCI DSS – And Why They Are WRONG!

Book Review “Practical Intrusion Analysis: Prevention and Detection for the Twenty-First Century”

“There is no spoon.”

“Practical Intrusion Analysis: Prevention and Detection for the Twenty-First Century”  by Ryan Trost–but-not-really (it is claimed to contain contributions by five other folks, but exact chapters they wrote are unknown) is not a book: it is a collection of papers about security and intrusion detection. The book bears unfortunate, but noticeable signs of being written by multiple people who didn't talk to each other much.

I just finished reading the book and I can say I enjoyed it. It does have interesting ideas peppered in some places. Overall presentation consistency, however, is not lacking – it is absent. Also, the book is not terribly practical if you define practice as “protection of systems and networks from attacks.”  Many chapters are shallow and make the impression of being added to get the book to 450 pages threshold.

So, some chapters are fun and insightful (“Geospatial ID”, “Physical IDS”, the sections on signature tuning), some are funny (example: one chapter talks about SIEM, SIM and SEM, but errs about what “M” in those stands for… seriously!) and some are sad (example: the one that mentions IDMEF), while others are very shallow (“Wireless IDS/IPS”). The chapter on ROI made me fall under my desk; I experience an actual literal ROFL – more on this below.

Here are some of the highlights. Ch3 has a lot of useful Bro NIDS tips; if you have never used Bro in production, give it a try. In Ch4, I liked vulnerability-based signature definition worklfow, which takes into account sig performance tuning. Ch5 was written by an academic, who doesn’t get out much; if works great if you want to really know what the word “befuddled” means (it also mentioned IDMEF for extra punch :-))  Ch6 is fine if you never dealt with network flows; not a bad intro. Ch7 is a very shallow intro to web application firewalls, while ch8 is the same for wireless IDS/IPS.  Ch9 deals with physical security and I loved; such information rarely shows in IT books and it was great to learn it. Ch10  that deals with geospatial intrusion detection is another good one; the approach looks a bit weird (example: all events with the sources address close to a company facility are considered “false positives”…). Ch 11 on visualization mentions all the right books on the subject, but then chooses to makes itself a bad comparison to them.

Now, ch12 (“Return on Investment: Business Justification”) is pure freakshow; I have not laughed that hard for a few months a least. After I had a chance to think about, I realized that maybe it was intended for humorous relief since it is the last chapter. Also, I am proud to be mentioned there (on page 404 – is this numerologically significant? :-)) In any case, the work computes the precise ROI for any IDS system, like that:

Gain  [IDS] from investment = ALE = SBE x ARO = $517,580

SBE comes from 2007 (!) CSI survey data, SBE = $345,005. ARO comes from risk  probability x expected number of incidents  = 0.46 x 3.2 = 1.5.  IDS is assumed to prevent all breaches (!), for computational simplicity, I am sure.  … Anyhow, you get the drift.

Overall, if you want a moderately interesting security read with some good ideas, get it. If you are looking for information on practical intrusion analysis in whatever century, skip it.

Finally, Addison-Wesley provided me with a review copy.

Possibly related posts:

• All book reviews on this blog
• My older book reviews
• My Amazon reviews

Bad Humor: Funny Security Roles

Beer + long train ride + academic papers on security (!) = this piece of bizarre humor.

Funny, hopefully fictitious, security roles [any matches with reality are mere coincidences]:

• Experienced cloud security veteran
• Innovative SOX auditor
• Fork bomb prevention expert [A.C. – inspired by a security “research” paper from 2009 about a new method to detect and prevent fork() bombs on Unix]
• Massive DoS detection specialist
• Open source Windows security expert
• DOS security architect
• Professional sniffer sniffer [A.C. – inspired by a security “research” paper from 2009 which invents new method to detect sniffers, BUT only those that emit (!) packets]
• Syslog psychic reader
• Legendary NAC security guru [A.C. – inspired by Unicorns, of course]
• Executive security reverse engineer

Care to continue this meme? Get some beer and then read a random paper on security written by somebody from a University who never dealt with a single real security problem in his life…

UPDATE: I am copying what was suggested by my esteemed readers from comments to the main post. Enjoy!

Suggested by toxa:

• Metasploit Certified Security Auditor
• Advanced Wireshark Network Analyst
• PCI DSS Clause 11.3 Guru [A.C. - loved this one!]
• Experienced Layer2 Attacks Specialist
• Famous Oracle App XSS Researcher
• Professional Web Applications Written In PHP Pentester

Suggested by Christophe:

• Experienced Password Policy Compliance Manager [A.C. - this one is awesome!!]
• Armed Layer 1 Attacks Specialist
• Veteran ITIL Conformity Observer
• User's Stupidity Documentation Writer
• Senior Unplugged Cables Auditor [A.C. - senior, no less! :-)]
• 2000 Bug Reappearance Sentry

Nobody Is That Dumb ... Oh, Wait XIII

For a while, I was looking for the next entry to my award-winning (eh..maybe) series “Nobody Is That Dumb ... Oh, Wait.” However, I didn’t expect this:

“in August a customer of the Rocky Mountain Bank asked a bank employee to send certain loan statements to a representative of the customer. The employee, however, inadvertently sent the e-mail to the wrong Gmail address. “

it gets better:

“Additionally, the employee had attached a sensitive file to the e-mail that should not have been sent at all.”

better still:

“The attachment contained confidential information on 1,325 individual and business customers that included their names, addresses, tax identification or Social Security numbers and loan information.”

even better:

“the employee “tried to recall the e-mail without success.”” [A.C. – now, success at that would have been totally world-changing….]

and reaches a crescendo here:

“the employee sent a second e-mail to the recipient instructing the person to delete the e-mail and attachment “in its entirety” without opening or reviewing it. The employee also asked the recipient to contact the employee to “discuss his or her actions.””

Ha-ha-ha-ha-haaaaar. This is stupidity at its absolute, highest best!

[source: Wired]

UPDATE: if you think the above was stupid... sit down. Breath deeply. It was just reported, that after the papers were filed the court SIDED WITH THE BANK and asked Google to deactivate an account of a person who received that mistaken communication from the bank... No, I don 't believe it either :-(

UPDATE: good news! Somebody sued Google over that.

Security and Dire Straits

This gets my "exudes pure awesomeness" award of the 1st degree: "a little ditty sung to the tune of “Money for Nothing” by Dire Straits."

Quote:

"Now look at them blackhats that’s the way you do it

Finding holes in your security

That ain’t workin’ that’s the way you do it

Mutating malware very frequently

Now that ain’t workin’ that’s the way you do it

Lemme tell ya them guys ain’t dumb

Maybe get a virus on your little palmtop

Maybe get a virus on your phone..."

Continue here and ROFL, weep, etc!

BlackHat 2009 Inspired – On Media Whoring

There is “security theater” and then there is BlackHat/DEFCON. If it were a vendor glossy, I’d have called BH/DC “the latest version of an ultimate, next-generation, paradigm-shifting, integrated theatrical experience.” :-)

As a result, seeing a few of the speakers [and being in, you know, Las Vegas, Nevada :-)] made me think about whoring; media whoring, to be exact. Obviously, security industry is unthinkable or maybe even provably impossible without some media slutting, but at this year’s show I realized “I ain’t seen nut’n yet.” Some folks are just sooooooooooooooooooooooooooooo good at it.

In any case, my thinking converged into the following over-simplified model (or “muddle”?) which analyzes the intersection of media whoring and subject matter (in this case, security) knowledge:

Security knowledge vs seeking media attention	Media attention not sought	Media attention sought
Knowledge of subject matter  present	Knows his shit + nobody knows about it (case I)	Knows his shit+ makes everybody know it (case III)
Knowledge of subject matter  lacking	Knows nothing + nobody knows about it (case II)	Knows nothing + makes everybody  think that he knows everything (case IV)

What does this teach us?

1. Case I gets respect, but not enough of it. There is nothing we can do about it, however. People, if you are cool, speak up, the world needs you! Get a blog or something…
2. Case II gets nothing, which is coincidentally what it deserves. Stay there :-)
3. Case III  gets non-trivial amount of disdain and some respect  (especially when it involves MD2 crypto :-)) However, is such disdain truly justified?  While there is no metric to compare the value of one’s contribution with an effort needed to get the media to spread his message, common sense criteria definitely apply (“Internet is DEAD! Press conference at 5PM. Live Twitter coverage!” :-))
4. Case IV gets non-trivial amount of hatred and disdain, but IMHO – and this is my MAIN POINT! – nowhere near enough disdain compared to what they actually deserve!

So, action item: get all your disdain, antipathy,  hatred and annoyance that you now spread between cases III and IV, “double it! double it!! – then double it again!!!” and focus it in the direction of case IV people.

Possibly related posts:

• BlackHat 2009 Day 2 – Bruce “Reconceptualizing”

• BlackHat 2009 Day 2 – Fun Cloud Stuff

• BlackHat 2009 Day 1 – Laws of Vulnerabilities Panel

Relation of PCI DSS to Security

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

 

 

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

Search for “PCI DSS”:

Search for “PCI compliance”:

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

Case closed? PCI DSS IS all about security!

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

Nobody Is That Dumb ... Oh, Wait X

It looks like another one of these for my series "Nobody Is That Dumb ... Oh, Wait"  where I made fun of people making dumb claims with apparent - and often scary! - seriousness.

Here is another perfect piece for it, titled “Conficker Worm Is Much Ado About Nothing.”  It goes like this “The Conficker Worm is like the Paris Hilton of computer security: Famous solely for being famous. Neither has actually ever done anything of note. But, at least Paris has a sense of humor about her celebrity. Conficker just wastes people's time.”

Yes, I agree… NOT. A few millions of 0wned boxes is not a big deal. Only noisy malware matters.

“As I write this, Conficker seems to be passing more or less harmlessly by.”

Yes, I agree: if somebody from China controls your PC using a well-written malware application and steals your bank account data, it is totally “harmless.” What? You didn’t know you can do that with Confickr? Reeeally?

“Maybe Conficker will send the message that what we are doing is just fine, thank you. Spend more money to counter threats like this? Why?”

Yes, I agree. We are doing a fiiiiiiiiiiiiiiiined job with infosec. Just like Marcus Ranum confirms here :-)

Can we all go home now? :-)

100% Protection from Confickr Revealed!

 

Recently, it was brought to my attention that security researchers have finally revealed the best, 100% effective method to be protected from Confickr malware. Specifically, the malware “incorporates a Ukraine-avoidance routine that causes the process to suicide if the keyboard language layout has been set to Ukrainian.” I suddenly realized that there has got to be some deep security truth in such “Ukraine-avoidance” and there are lessons to be learned.

Thus, it came to me that the only way to reliably kill the malware (or, more precisely, to cause it “to suicide”) is for all of us to become more Ukrainian and then have the evil malware avoid us.

 

 

 

 

 

Hereby as of 4/1/2009, I am switching to Ukrainian keyboard layout on all my work and home systems, including those running Windows and Linux (ah, just in case, you can never be “too safe”). I am uninstalling the US English keyboard layout and will perform all the communication with the world using the keyboard that looks like this:

 

 

 

 

 

In the unlikely event that such degree of Ukrainian-ness will prove insufficient for 100% malware protection, I promise to route all the TCP/IP communication thru Ukrainian proxies and, in the event of a true malware cyber-apocalypse, will consider moving to Ukraine altogether.

 

Obviously, I call for all my blog readers to do the same:

Be 100% safe from malware! – Increase your Ukraine-ness to safe levels! - Switch to Ukrainian keyboard layout TODAY!

Dillbert on "Risk Management Software"

Dillbert on "Risk Management Software"

How's That For Compliance=Security?

So I was googling for something and happened upon this hilarious gem of a quote (here): somebody "is calling for a PCI DSS status directory in which compliant merchants and processors are publicly listed. Opponents say such a directory could be used by hackers to find vulnerable companies to attack."

I know, I know... it is most likely taken out of context and all; but it doesn't stop me from ROFLMAOing here.

PCI DSS and Data Breaches: Perception and Reality

Now that time has passed since the Heartland credit card data breach (even though we might have another one at our hands), it is a good time to reflect on PCI DSS a bit more. I am AMAZED about how much deep [shallow too!] thinking and, even, soul-searching, has transpired in our community as a result (see all this covered under in my On Heartland I, II, III and IV series). I already posted some of my own thoughts on this in Compliant + 0wned. So, what else is there to reflect on? Plenty!

First, some folks hate PCI DSS because it is – gasp! – not perfect. Some of these same folks have hated firewalls since “firewalls are full of holes,”  hated IDS since “they are trivial to bypass” and hated logging since “good hackers never get logged” (what a bunch of crock :-)) - many also hate “the whole compliance thing” since it is “not security.” Yes, in our industry some people will hate everything that will not stop any and all attacks from an attacker of absurdly arbitrary skill level. And since such a thing doesn’t exist and won’t exist – they just hate everything but their “31337 mad sk1lz.”

To such I say: try to get out more! If you look out of your high-floor ivory tower window, you’d see there is a ginormous crowd of people who confuse a firewall with a fire-extinguisher! And those people have your credit card data, SSNs and medical records in their computers!  Get it? IF PCI DSS made ONE of these people use a firewall or update their AV (after it lapsed back in 2005), we are all better off already!

Second, PCI DSS perception has firmly split from PCI DSS ground reality. I have a love - hate relationship with “perception is reality” maxim; in some cases it rings true, it some cases it sounds silly, but ends up being true, and in some cases it is just plain idiotic and makes you live in your own world of illusions. I’ve long been tempted to summarize the whole PCI DSS perception vs reality:

Perception	Reality
“PCI failed”	PCI DSS works as expected – and not perfectly
PCI DSS is sufficient for good security	PCI DSS is necessary, common-sense basic security
PCI is a complete security checklist	PCI is a base list to build upon and grow
Everybody is just doing the minimum of PCI to get rid of it	For many organizations "this “minimum” adds much needed security!
Breaches prove PCI irrelevant	Breaches prove we need to drive security even more – and PCI helps with it

So, once again:

1. PCI was never supposed to guarantee "intrusion-free"  operation, nothing did, does or will do.
2. No canned checklist is “sufficient for adequate security,” now or ever.
3. It makes no sense to write prescriptive checklists for the impossible (e.g. “your defenses MUST stop all known and unknown malware as well as ‘mal-hard-ware’”)
4. If you find something to be useless for you, think – are you 1 in a 1,000,000? Have you thought about the remaining 999,999 people?
5. There are always people who will avoid common sense, drive without seatbelts and ignore PCI DSS: so, Darwin Awards 2008 (here too) are out!
6. Yes, there might be pressure to choose “an easygrader QSA” for your assessment; but see item #5 above. Then remember – you are still responsible for the breach!
7. Similarly, PCI does not “create” a false sense of security due to #1 and #2 above. If you magically “feel secure” since you’ve “done PCI,” see #5 above :-)
8. Finally, if something is NOT perfect, it does not mean it is useless.

To summarize, this and other previous breaches definitely do NOT prove PCI useless or inefficient.  They simply serve to remind us that PCI DSS was established as a standard of minimum care for card holder data security. It never meant to be sufficient for all security  or “a security silver bullet.”  Today as much as ever, the organizations needs to think about their specific risks and implement controls for dealing with said risks. Following 12 PCI requirements is a great start, but being secure cannot be reduced to a checklist:  PCI does not replace addressing the risks to your business; however, it is an awesome start for those who cannot even spell  the word “risk” today …

What is the perfect ending for this post?

I think  quoting illustrious Dave Aitel is in order: “Who here doesn't think all the payment processors are 0wned and probably always will be?”

Possibly Related Posts:

• On Heartland I
• On Heartland II
• On Heartland III
• On Heartland IV
• Compliant + Owned = ?
• Other PCI DSS coverage

PCI Kitten Cometh...

Here comes the PCI kitten [PDF], not to be confused with Fuzzer, the infosec ph4zzy.

Kudos to pcianswers.com for the picture!

Security (Info/Physical) Humor

What do you need to steal $100m?

1. $1m
2. $5

This comic answers it :-)

BTW, this also tells you how behind I am on blogging... Guess why? 'Cause I also "do stuff."

Quick: Have You Ever Wondered ....

... what happens if you search on Twitter for "Heartland" + "PCI" + "balls" :-)

Titanic Update

Just want to quickly revisit that “Titanic” theme, started here. More people chimed in:

• “Compliance != Security - the Titanic illustration”
• “Parallels between the Titanic and IT Security”

Here is an interesting observation, however. And some more humor, of course.

First, let’s ask why were there boats in the first place (not “why there was NOT enough of them?”)?

Risk decision (to save the passengers in case of a disaster) or compliance decision (to comply with a safety manual)? Personally, I would not be entirely shocked if it was indeed the latter …

So, let’s imagine how different regulations would have handled it:

• PCI – you MUST have (some)  boats or we pull your coal supply. Also, you must have certain type of a boat, even if you don’t like it (we have evidence that you cannot be trusted with boat selection!)
• FISMA – you must have documents about boats; they MUST be complete, but can be stored safely ashore (N.B.: said docs thus might not help as a floatation device…)
• HIPAA – you must have boats, but we promise we will never, ever check. You can pick your favorite type, including a) leaky boat b) paper boat or c) a toy model of “Titanic”
• SOX – you must have boats at least for the captain, so that he survives and can be jailed later. Please call 1-900-BIG4-BOATS to get our boat selection advice.

Making fun of “Titanic WAS Compliant!” is easy; remembering that many businesses now run WITHOUT ANY life boats is harder… If compliance (and PCI DSS in particular) makes certain risks acceptance decisions impossible or at least ‘very illegal’ (or much more risky by adding another risk – an auditor), then it is a good thing!

Possibly related posts:

• Risk vs Risk
• Making PCI Easy?