On Heartland III

OMG, so much more fun stuff have been posted on the Heartland credit card theft. Read Part 1, then read Part II,  then read this. Also read this and don’t get ‘comp0wn3d’ :-)

• “Heartland data breach proves PCI compliance is not enough” (no shit!) starts with sensible “The data breach at Heartland Payment Systems that exposed millions of credit card holders in the US to fraud, proves regulatory compliance alone is not enough” as well as a deeper version of “Achieving PCI compliance does not imply that a business has achieved real security” which then turns idiotic propaganda “The only solution to eliminate this threat is end-to-end encryption” (
• Branden thinks the same here in “End to End Encryption is NOT the PCI Silver Bullet!”, he also gives more good thoughts there such as “I stand by my original premise which is that the standard [PCI DSS] (properly implemented) would prevent this.” He also has another awesome post “What CEOs (and CISOs!) Can Learn from Heartland” where he goes for the jugular: “Going through the motions of something like PCI without actually committing to it will land you in the "PCI Validated, but Compromised" bucket like so many before you. The Anti-PCI crowd comes in two flavors, the "It's Too Damn Hard" flavor, and the "It's Doesn't Address X Issue" flavor. Both of those flavors have valid points, but they are sooo 2006. 2009 is the time to OWN your security, and PCI is a great place to start.”
• “Just how big was the Heartland security breach” says ”it is known that as many as 600 Million card numbers were exposed to malicious software” and “the number of cards potentially stolen is about 50% more than every single active card of every cardholder in the entire country.” Note this also: “I cannot imagine a scenario where Heartland comes out of this in one piece.”
• Kevin opines here that “Arguing that PCI DSS is a failure because two organization that were compliant experienced breaches is like saying door locks are a failure because somebody broke into your house.” Amen to that!
• Mike Rothman thinks he is no more insane than the rest of us here:  “Maybe it'll take 3-4 years (HIPAA was still an area of focus for 3-4 years after it started it's long downward slope towards irrelevance), but unless something changes – it'll  [PCI’s irrelevance] happen.”  OK, Mike, I still politely disagree..
• “Heartland Sniffer Hid In Unallocated Portion Of Disk” adds some details about the malware in question and contains deep forensic insight: “There is virtually no way to tell in a case like that what really happened.” :-) (the sad part is that they are probably right) Another piece concerns the insider angle: “preliminary indications are pushing them to suspect a fully external attack, with no indications at this time of any help from any Heartland employee or contractor.” The same piece also tells that litigation has started: “And Heartland’s civil legal troubles are just starting, with one of the least surprising lawsuits ever filed. The litigation is the start of a class-action lawsuit that accuses Heartland of having “failed to take appropriate measures to adequately protect” its data.” (this also comments on the above)
• Pete adds two very interesting points: “How many people thought passing a PCI audit meant that an organization was risk-free? If you did, then PCI failed from your perspective. Of course, you might want to go into another line of work.” (here in “How to think about PCI”) and “One way to evaluate the success of PCI is to compare the number of incidents from PCI-certified companies to another set of similar non-PCI-certified companies.” Also, while on his blog, read the comments here.
• On a more analytic side, “Heartland and PCI” reminds that prescriptive regulations like PCI are not the only option: “There is a way to solve that by building risk management based standards, like ISO27001, but they are usually more expensive to implement (and to validate). Also, those standards work very well to deal with risks to the organization, not to third parties (like cardholders), though considering audit issues and fines a risk themselves can help on fixing this “glitch”.” (additionally, as I pointed out in-depth here, they face the issue of people not knowing/not caring about their risks)
• In his “On the Heartland Breach: No It Does NOT Mean the End of PCI” Walt reminds us: “PCI is by its nature backward-looking. Deal with it. Because you are compliant today does not mean you are still compliant tomorrow or even 15 minutes from now.”
• Robert Carr, CEO of Heartland, says here: “PCI is a good and effective standard, but the bad guys have become more sophisticated to the point where encryption of data in motion appears to be one of the next required steps. There is no single silver bullet that will secure payment systems, and constant vigilance and monitoring of the infrastructure will always be required.”  You know what? It sure seems like monitoring is THE NEXT step for them, not the one they took in the past…
• In “PCI = FOI?” Andy writes: “I think PCI is the best regulation because it lacks much of the vagueness that others have” AND “Unfortunately, it does often lull companies into being complacent and/or apathetic.” (both true, sadly) He also brings up more good point in his post: “We have to quit pushing things such as being "complaint" with any regulation as equating to being secure. When I say we I don’t me most of us reading this but the PCI Council and other governing bodies.”
• Finally, the most fun post of the batch (!) here; I am not going to quote it extensively, just go read it! One quote though: “I had a chat with a QSA from a large well know “security” company. He told me he never touched anyone’s systems during a PCI DSS onsite audit. When I asked him how he could possibly then know whether those systems were secure (not using the term compliant), he responded that he based his assessment upon documentation and what the relevant IT staff told him.”

Enjoy!

Possibly Related Posts:

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

“Compliant” + 0wned = ?

Enough link posting (Part 1, Part II, Part III of the “On Heartland” saga), here is some analysis of this, now that some time has passed.

So, first, how a company, that was audited by a QSA and deemed “PCI DSS compliant” at some point, can be breached and have all their credit card information stolen at some later point? I have not seen this analysis anywhere so I will perform it here in front of your eyes. Altogether, I think the following cases are possible:

1. It was audited by an “easygrader” QSA (here), “we-just-look-at-the-docs” QSA (here), or even “pay-per-compliance” scammer QSA (here). Owned via unpatched MS hole!
2. It was audited by the most rigorous, pedantic, anal QSA ever, who found the organization to be 100.00% compliant. And then the next day it all changed! Owned via password “password”!
3. The company was audited and found to be NOT compliant. They begged, begged, begged and then got a letter from a card brand saying “you are OK… for now.” Same, 0wned via an unpatched MS hole!
4. It was audited by “the Anal QSA,” who found the organization to be 100% compliant and later nothing changed (hah!) However, an attacker wrote a nice little piece of malware (here) which bypassed all PCI-mandated controls (or used something else not covered by PCI). Owned!
5. It was audited by “the Anal QSA,” who found the organization to be 100% compliant, later nothing changed (hah!) and nobody bothered to write a piece of malware just for them. However, their janitor took a backup tape from a closet and sold it to “his relatives” in Ukraine. Insider 0wned!

Is that all? I think so… but please comment, if you can come up with more.

Now, think for a second - which of the above 4 cases indicates that “PCI failed”, “PCI is irrelevant”, etc.

Huh?

None!

None!!

None!!!

So, please shut up :-) PCI DSS remains a solid piece of basic security guidance.

Possibly Related Posts:

• On Heartland I
• On Heartland II
• On Heartland III
  
• PCI DSS coverage

Why?

I am still wondering why nobody sent me a copy of "The New School of Information Security" ...

Fun Class on Logs and Visualization

Just FYI, Raffy is doing his class on logs and visualization at Source 2009. Sadly, I will miss it, but you should not :-)

"LOG ANALYSIS AND SECURITY VISUALIZATION

Course Overview:

Have you noticed that your networks are becoming ever more complex? Isn't the task of securing your network ever more difficult? Have you tried to apply visualization to get better insights into your environment? Using today's data visualization techniques, you can gain a far deeper understanding of what's happening on your network right now. You can uncover hidden patterns of data, identify emerging vulnerabilities and attacks, and respond decisively with countermeasures that are far more likely to succeed than conventional methods.

What You Will Learn In This Training:
The goals is for the students to leave this class with the knowledge to visualize and manage their own IT data. They will learn the basics of log analysis, learn about common data sources, get an overview of visualization techniques, and learn how to generate visual representations of IT data for a number of different use-cases from DoS and worm detection to compliance reporting. The training is filled with hands-on exercises utilizing the DAVIX live CD."

Go here for more details and to sign up now.

On Heartland II

More fun follow-up to Heartland breach coverage and analysis (Part 1 here), including exclusive coverage of Mike Rothman going insane :-)

• "Will Heartland Become the Largest Data Breach in History?" reminds us about the breach notification laws (not mentioned so far!) – "Given the mandatory notification laws, which have been passed in almost all 50 states, this is going to equate a lot of people that have to be notified. Simply stated, it's going to be a "notification nightmare." He then sadly says "So far as PCI compliance — which now seems to have been proven ineffective in at least two instances"
• A very good view from VeriSign called "PCI Compliant Companies Don't Suffer Breaches": they say that they "have NEVER concluded that an affected company was compliant at the time of a breach" (!) Think about it! It was always either due to changes after an audit or due to an “easygrader” (or even scammer) QSA. So, they continue '"Is there a problem with PCI? If there is one, the problem lies in the QSA community (or internal auditors that have not been through something like the CPISA training), not the standard itself." and ""So, to recap, our experience shows companies that suffer a breach are not compliant with the entire standard at the time of the breach. We should refrain from saying that another PCI Compliant company was breached because the facts show that it just is not true."
• Martin McKeay confirms here: "But my own experience is that you’re always going to find at least some portion of an enterprise that’s not compliant if you dig deep enough. "
• “SC Magazine” chimes in with “Is PCI working? Maybe, maybe not." There is nothing truly stupid there, but they definitely try: “The Payment Card Industry Data Security Standard (PCI DSS) took a severe blow this week when leading payment processor Heartland Payment Systems announced it had been breached." They also have a few sensible comments like "Compliance is merely a snapshot in time. So if Heartland was deemed compliant last April, as it was, the company could’ve been way out of compliance by the time the hackers go it. Or maybe even as soon as the next day."
• A fun one, from Heartland CEO via this "Heartland CEO Calls for Industry Cooperation to Fight Criminals": "Consumers will know if their card account numbers have been used by reviewing their monthly statements. Cardholders should report suspicious activity to their issuing banks (the bank that issued the card, not the card brand). If unauthorized use is confirmed, cardholders are reimbursed for the fraudulent purchases and are not held financially responsible." (Good idea, buddy! Let the consumers do the work!) and this chunk of hilarity: “For the past year, Carr has been a strong advocate for industry adoption of end-to-end encryption - which protects data at rest as well as data in motion - as an improved and safer standard of payments security.”
• More anti-PCI rhetoric in "Heartland breach raises questions about PCI standard's effectiveness." It is definitely more fun [for them] to report that “something sucks”, compared to reporting that “something works.” A quote: "Billions is being spent on PCI compliance, but it isn't really working," says Gartner analyst Avivah Litan. "PCI's dirty little secret is that it doesn't mandate encryption inside a private network because then all the processors would have to encrypt." and "But some analysts say what is clear is that the Payment Card Industry data security standard that Visa and MasterCard require isn't sufficient to ensure cardholder data is safeguarded.. " (Really? They do say it is “not sufficient”… funny, eh? OF COURSE it is not! But that is not the point.)
• "Lack of transparency on Heartland breach" reminds us about – oh, horror! – lawsuits: "Depending on the results of the on-going investigation, Heartland will face the threat of litigation from issuing banks, merchants and consumers, says Scott Vernick, an attorney with Fox Rothschild LLP in Philadelphia, who specializes in data breach cases" and then again idiotically beats on PCI: "The fact that Heartlands’ system were certified as being fully in compliance with PCI standards underscores questions about the efficacy of the PCI rules."
• Finally, a true shocker!! Mike Rothman apparently drank some vendor koolaid and has gone insane. In his piece "The Increasing Irrelevance of PCI" Mike talks about PCI’s “major problem of relevance, given the second (that we know of) massive data breach on a PCI "compliant" organization." Mike then talks common sense for a second: “Sure the 12 requirements are a good start, but clearly they are not enough and the general consensus-based process of updating the requirements means PCI is always solving the attacks of 2 years ago.” Correct! He then correctly points out that, sadly, "most folks would look at the 12 requirements and figure that's all they needed to do." However, then insanity returns: "The Council needs to act quickly and decisively to stem the rising tide of irrelevance. Or else they'll need to acknowledge that PCI is the next HIPAA and organizations will continue to due the bare minimum to comply, while secretly snickering at the ridiculous hoops they have to jump through to little benefit." and even "So with each data breach PCI becomes weaker and weaker until it ends up similar to HIPAA. Unless something changes organizations will continue to pay lip service to it, customers won't trust it (to the degree they even know about it), and it becomes just another report that is generated out of the security reporting system, which is my definition of irrelevance."
• UPDATE! Already responding to Mike, the post "PCI irrelevant? Or is it just us assessors?" reminds that "In the case of Heartland, they had malware on a system that was passing around track data (at least according to the reports I've seen so far - maybe that's off base.) Is it a problem that that system was asserted to be compliant by a QSA?" [we are not even sure that the malware was there at the time, BTW, but it I would NOT be shocked if it, in fact, WAS!] And then: "Will some of them [QSAs] rubber stamp your dog as being "compliant"?" :-)
• UPDATE! "Does the Heartland breach prove PCI useless?" is another pretty good look at the situation (their answer is: no) - "Should you blame Heartland, PCI regulation, or both?How about none of the above? [...] PCI compliance, much like the often preached Industry Best Practices of IT, amounts to nothing more than a simple list of baselines."
  

I am writing a longer analytical post, but for now: people, think about it for a second – there is NOTHING among the widely deployed and off-the-shelf security gear that will stop a hand-written piece of “application-aware” malware such as the one used in a Heartland hack (source: archetypical little birdie :-)) Why the f* (specifically) do people talk about “PCI FAIL” here? Admittedly, “PCI FAIL” message is mostly strong among the clueless mainstream press, but if you do security, think how would YOU stop custom malware in YOUR environment TODAY?

Eh?

Exactly!

On "PCI for Dummies"

I didn't write it, but it doesn't mean you should not read it :-) - Qualys publlishes "PCI Compliance for Dummies" book.

On Heartland

Before I post anything long and thoughtful (aka “a rant” :-)), I wanted to summarize a few interesting  bits on the Heartland breach I have seen (warning for folks with ADD: some of the juiciest blurbs are in the end; also, some of the most enlightening bits are in comments – including one from someone who claims to be from Heartland). This breach definitely blew open the debate about PCI DSS usefulness and efficiency (as well as restarted a broader “security vs. compliance” debate)

• “Heartland Payment Systems Breach - Why it likely happened”  by Ryan from Panda Security hypothesizes a bit about why the breach happened.
• Via “Heartland Payment System - biggest ever data breach?” we find this GEM [PDF]. Did someone say “OMFG”?!
• “A few Heartland links” – a few really fun comments here, below the blurb itself. For example, why the only “early indicator” was the resulting fraud? Where was IDS? IPS? Logs? AV?
• “From The Heartland Breach To Second Guessing Service Providers” contains a few good ideas, including (thanks Dave!) a reminder that “Honestly, most companies, as a whole, don’t take data security very seriously.” Definitely a  good read.
• “Massachusetts Analyzes its Breach Reports” contains the magic line from some MA report “The Hannaford incident suggests that the Payment Card Industry Data Security Standards are not an effective standard in light of the need for encryption.”
• Amrit’s “2009 The Year of the Largest Security Incidents Since the Beginning of Forever” was the first to reveal that Heartland was indeed PCI-compliant (as per this [PDF], it even covers who was their QSA…) ; Amrit also cutely reminds us that this breach is THE largest EVER… until the next one :-)
• “HPY - The latest breach.... 100 million credit cards stolen“ states “QSAs cannot be held liable for customer breaches, but seeming the compromise occurred only a few months after their final audit it does bring into question PCI DSS auditing practices [A.C. – OF THAT PARTICULAR QSA?] and whether or not they're just 'tick in the box' or actually leave companies with a long-lasting compliance strategy that actually helps merchants/service providers remain compliant. [A.C. – hmmm, are QSAs supposed to do that?]”
• Somebody who claims to be from Heartland shares just how fucked up they were IT-wise (here, in comments, read all, really). Some comments do beat up on their QSA as being “the checklist monkeys.”
• ”Heartland Payment Systems - Quick Point...” reminds people that under the “right” – not too extreme! - circumstances it may end up a $1.5b (!) incident.
• “cutting corners with security*” reminds us that “If a company is cutting corners, choosing to accept risk poorly, or simply incompetent, I would bet they will actively make sure PCI doesn't catch it, or outright lie, fudge, or (hah) cut corners with the Assessor [=QSA].”
• Mike R weighs in with “I'm thinking about the future of PCI a lot in the wake of another mishap, and the news isn't good.” (however, the sad part about Mike here is that he is wearing a vendor hat … well, that is how it sounded to me, at least)
• Matasano folks remind us “Heartland: First Thoughts“ to ask: “Did the intrusion happen before April 30th, 2008?” [the date of their PCI validation date]
• “More PCI Compliant Companies Breached“ does say it: “These incidents again raise the question as to the efficacy of PCI.  Of course it is possible that these processors made a mistake in validating their PCI compliance.” and “The question from my perspective (legal) is whether PCI compliance constitutes reasonable security.” (do read the comments also); this particular post BTW is a must-read, not just a good read!
• Mike Dahn explains “What PCI compliance really means”, but do read the debate/comments below it (E.g. “How do we measure the positive security impact of PCI DSS?” and “Why are people chasing compliance at the cost of proper risk management?”, “I would go further and assert that compliance and security are largely independent with only a few limited touchpoints” and the liability argument – it is HOT!); then read the next item.
• The debate then continues in “Is Something Wrong With PCI?”: “Nobody checks if you REALLY ARE PCI compliant or whether you ACTUALLY have reduced any risk.”

My conclusions? See next post…

Quick: Have You Ever Wondered ....

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

Largest Card Data Breach Ever?

"A data breach last year at Princeton, N.J., payment processor Heartland Payment Systems may have led to the theft of more than 100 million credit and debit card accounts, the company said today. If accurate, such figures may make the Heartland incident one of the largest data breaches ever reported."

"A piece of malicious software planted on the company's payment processing network that recorded payment card data as it was being sent for processing to Heartland by thousands of the company's retail clients."

"Heartland does not know how long the malicious software was in place, how it got there or how many accounts may have been compromised. "(some details)

So, TJX, rest-in-peace! Your record has been broken!

UPDATE: fun comments from Rich (here), Michael (here) - more as I see them.

Fun Reading on Security and Compliance #11

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 #11, dated January 19th, 2009 (read past ones here). I admit that some stuff has been sitting in my “2blog queue” for way too long, but you know what? If it is relevant after a few weeks of “cooling down,” it is even more worth reading :-)

1. “SOA Security in Real Life” – if you have to read up on SOA security, you really MUST do it at Gunnar ‘s site :-) Fabulous quote: “Infosec is spending waaayyyy too much time and money protecting garages and not enough protecting assets.”
2. “What are we on the lookout for?” from Verizon Business Services, a fun read.
3. “Enterprise Security 2009 To Do List” from Gunnar Peterson.  No, not “firewall + SSL” :-)  The post contains great tips on application security. While reading that, also check this other piece.
4. Pete’s brief observation on “Risk Tolerance.” Scary, eh?
5. LOLCAT CISO wisdom bit. Why is the hakker kitteh so darn fat?
6. “How to choose a PCI DSS QSA Auditor!!” Yep, I agree with two “!” as well.
7. A really good post from a new SANS Forensic Blog: “Law Is Not A Science: Admissibility of Computer Evidence and MD5 Hashes.”  It serves as a VERY useful reminder: “Could you get electronic evidence admitted without hashing? Yep.” and “Will hashing help admissibility of my evidence? Certainly, but it is not legally required.”
8. “How'd Dilbert know about PCI?” asks Mike. He did somehow :-)
9. Really, really good read from Jeremiah “History Repeating Itself.”  If you have no time to read it (even though you MUST), just look at the pic.  Also, you need to think about it, not just read it! While you are reading it, check this one too (on webapp security “arriving”)
10. “MS08-078 and the SDL” from MS explains why we will always have vulnerabilities.
11. Mike’s report card on 2008 predictions. Here is mine too, BTW.
12. “When Not to do Forensics” from Verisign Security Blog. A good read, even though I still think they missed “How like is the perpetrator to sue us?” case. While there, read this as well.
13. “How The Cloud Destroys Everything I Love (About Web App Security) “ … and how it may yet be a good thing :-) from Rich. All SaaS/cloud security fans should read it.
14. “On the nature of perimeters and shifting defenses to endpoints and data“ from Burton raises a darn good question: deperimeterization of IT + consumerization of IT = disaster. “The shifting of focus to the desktop security defense runs counter to the “consumerization of IT” trend that includes a strategy of allowing employees to bring their own computer to work.”  Just think about it! Oooh.
15. Finally, “Is FUD Always With Us?” I bet ‘yes’ for the foreseeable future.

Enjoy!

Webcast Summit on PCI And Other Fun Stuff (Yes, GRCToo :-))

Here is a fun event ("online webcast summit") at BrightTalk to be held on . Among the highlights:

"Beating PCI in 2009" by- Branden R. Williams, Director, PCI Practice at VeriSign

and other speakers. Logs are featured as well...

Tales From the “Compliance First!” World

This is like “Tales from the Crypt”, but much, much scarier…

Last time we talked about “Making PCI Compliance Easier” and now my subject is something that few people admit, most criticize and – that is the dirty truth! – a lot of people actually do. Namely, despite all the talk about “’compliant’ does NOT mean ‘secure’”, “Titanic WAS Compliant!” (and Part II here) , “unified compliance” (e.g. here)  and “do security first!” (e.g. succinctly here and better here [PPT]) there is a sizable  (multiply your wildest estimate, by, say, 10x!) population that treats, for example, PCI DSS compliance as just another IT project. A sad side project implemented in a siloed, “shoot and forget”, “plan to do as little as possible – and then cut the plan by 2” fashion.

First, imagine this hypothetical situation: a medium-size organization’s management finally “gets the PCI message” and decides that it is important to deal with PCI DSS compliance. Maybe their acquiring bank “introduces” them to PCI or maybe their service provider starts bugging them about “that PCI thing.”  What  happens next?  In the “compliance first” mindset, the management  summons an IT manager (for they are probably not big enough to have full-time security people) and hands him a copy of PCI DSS, a mandate to “do this!”, and a generous budget of $5.50, enough to procure one Venti Latte at “Starbucks.” Notice that this case does not fall under “just say ‘Yes’ on the SAQ” (like I describe here); here the organization does in fact intend to “address compliance.”

What happens next? The IT manager reviews the requirement list and notices that he already has some of the things done. For example, a network diagram (PCI Req 1.1.2) is proudly displayed on his cubicle wall. How about the rest though? Let’s look at some of the specific requirements, his responses (and some of his unspoken thoughts):

• Req 5.1 “Deploy anti-virus software on all systems commonly affected by malicious software” - “OK, we have anti-virus! Great!”   (Is it on all ‘at-risk’ systems? Maybe not…)
• Req 5.2 “Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.” - “Hmmm, what do they mean here? I guess they do run, don’t they?”  (Antivirus audit logs? Huh?)
• Req 6.6 “… Installing a web-application firewall in front of public-facing web applications” - “Oh, we already have a firewall in front of the website!” (Web + firewall = web firewall... I think?)
• Req 10.6 “Review logs for all system components at least daily.” -“Log management?  Let’s get the syslog server up.”   (Review all logs daily? Do they really say it?)
• Req 11.4 “Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic in the cardholder data  environment and alert personnel to suspected  compromises.” - “OK, let’s put snort on this box here, and start it. We will (read: might) look at the alerts later.”  (I’ve heard IDS is a pain, but we can just drop it in and be compliant, right?)

Requirement  by requirement he goes and figures out what is on his network vs what is in the document; sometimes he plans to make a change here and there.

Ta-dam. Done.  PCI DSS is “covered.”

Is he compliant now? It depends. If they are not to be audited (and sometimes even if they are), they might well consider themselves “compliant with PCI DSS” (as long as they pass the scans – more on that below)

Is he more secure now? It depends. There is a good chance that if he were aware of the risks to his company (and few such organizations are) and have taken simple actions to deal with those particular risks (and almost no such organization does), he would have been more secure. However, there is a still some possibility that his security has improved a bit due to his PCI DSS “effort” (e.g. if he had to change his password policy to a more stringent one).

In any case, they now feel better about answering that self-assessment questionnaire (SAQ) and getting scanned.

Scanned? Yes, scanned for vulnerabilities by a PCI Approved Scanning Vendor (ASV), such as Qualys. Such scan must come up with no “PCI-scope vulnerabilities” (example). If it in fact does, the organization will likely feel much better about their overall PCI compliance status.

However, what happens if they rescan in a month, right before submitting the report on compliance (RoC) to their acquiring bank, while new vulnerabilities have been discovered in the software they use?

‘OMG! Somebody just “BROKE OUR PCI COMPLIANCE!”’

“Why is this scan showing vulnerabilities if we were just about to report the success of our little compliance project? Why are you, an evil ASV, breaking our beautiful PCI compliance? Have you got no shame? How about we replace you with another product that shows us compliant… always (like Scanless PCI or similar :-))”

People, it really doesn’t matter how many times we say “security first!” If some organizations don’t get security with all of its complexities and ignore it for years, “compliance first” becomes a real choice for them. At least they can understand it. And then later, “compliance first” becomes “compliance ONLY,” “checklists” replace “risk awareness,“ “flowcharts” replace thinking about their threats and vulnerabilities.

And then they get 0WNED. And CNN writes a great story about them!

To top it off, PCI Council also fines them since they were NOT even compliant…

So, make your choice:

“Security FIRST” or “Compliance FIRST”

Final word: if upon reading this, you excitedly choose ‘Compliance First!"’, please at least make sure that “Security SECOND” happens. If you have to focus on compliance first, please make sure to address security second because security is what probably drove the compliance requirements in the first place…

Possibly related posts:

• Making PCI Easy?
• Risk vs Risk 
• Titanic WAS Compliant! 
• Titanic Update 
   

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?

SANS Log Management Survey 2009

SANS Log Management Survey 2009 - vote now.

Making PCI Easy?

Here is an observation about PCI DSS and “making PCI easy.” BTW, before reading further check out the previous burst of hoopla over this exciting subject - Mike R freaks out and they respond. So, OK,  how can one make PCI compliance EASIER? Is this akin to "quick tips on nuclear reactor building", "neuroscience for dummies" or – my fave! – “making complexity science simple”?

So, fine, PCI compliance is NOT easy. And, OMFG, security is definitely NOT easy either. Remember Dan Geer saying that “security is perhaps the most difficult intellectual profession on the planet” (here). Also check this essay “What is it that makes security hard?” (here)

Alright, we established that. Now what? Should we not try to make it easier to help people who struggle with PCI on a daily basis (and sometimes curse it with much drama…)

I am not that old, but I remember the times when only “An Enlightened Expert” (by whatever definition) was able to perform an uncanny magic of a vulnerability scan. Today, nobody would argue that Qualys made vulnerability management MUCH easier (still, I would not say that enterprise vulnerability management is easy … don’t hold out for this one :-)). We will soon make web application security scanning easier (yes, we will)! In any case, when people think about “making PCI easier” they often split into two camps:

1. “Please, please make PCI easier by letting us skip the requirements; or, better, just let us ‘SAY YES ON THE SAQ!’” camp.
2. “We know that our security program makes us PCI –compliant; please make it easier for us to prove it!” camp.

As you can guess, the organizations that fit into camp #1 and camp #2 are very different: while some in camp #1 will miss the joke in ScanlessPCI :-), the #2 are often concerned with relating their “risk-focused” approach to PCI’s mostly “control-focused” approach. And don’t remind me about confusing a firewall with a fire extinguisher (camp #1).

Moreover, in camp #1 people sometimes say things like (oh horror!) “PCI is already easy, you just need to ‘get scanned’ and answer ‘Yes’ to a bunch of questions.”  And so, yes, if a mysterious device called “a firewall” is mentioned in the question, saying “Yes” is probably acceptable :-)   Still, it is possible to make PCI easier even for those who just want it gone: make doing the right thing easier for them (while making doing the wrong thing harder)

On the other hand, while in camp #2, one sometimes hears things like “we have a good security program [we manage risk well!] – why should we spent time on that PCI thing? We are probably in a good shape already!” These organization are likely doing a good job with security (OK, “good” in the Ranum-ian sense: by being as insecure  as possible while continuing to do business) and want to use all that to quickly “prove compliance.” In this case, making PCI easier will include making it easier to assess, validate and prove compliance and overall make the whole “audit experience” (for those of the L1 variety) a little less painful (BTW, read “Risk vs Risk” on that).

OK, the above is definitely an oversimplification, but you get the point.

So, what are some of the ideas on how to make “PCI easier”:  make proving it easier, make boring process simpler thus allowing more time for becoming more secure (but not “more secure than needed”), make choosing the right thing easier (and the wrong thing harder), etc.

Finally, here is a parting thought: have you ever met anybody who wants to “do a good job with compliance [for the sake of compliance]?” is there any such crowd? :-)

Do You Think The World Needs A Conference Dedicated to PCI DSS?

Do You Think The World Needs A Conference Dedicated to PCI DSS?

Comment away!

STRONG Security Humor :-)

Read it and ROFL, then ROFLMAO :-)

"Bruce Schneier can conduct secure multiparty computation... on his own.
Bruce Schneier mounts side-channel attacks through the front channel.
Bruce Schneier's discrete logarithms are uncountable and continuous
Bruce Schneier knows Alice and Bob's shared secret.
Bruce Schneier memorizes his one time pads.
Bruce Schneier's secure handshake is so strong, you won't be able to exchange keys with anyone else for days.
When he was three, Bruce Schneier built an Enigma machine out of Legos.
Bruce Schneier once found the inverse of a trapdoor function counting only on the fingers of one hand.
When Bruce Schneier does modulo arithmetic, there are no remainders. Ever.
When Bruce Schneier uses double ROT13 encryption, the ciphertext is totally unbreakable.
Bruce Schneier can straighten out an elliptic curve with nothing but his teeth."
(more)

NEWS FLASH! Titanic Was Compliant :-)

Just love this: " ... the problem here was that the Titanic indeed did meet all of the safety requirements of the time. And that a big part of the problem was that the safety requirements were drafted in 1894 at a time when there were rapid changes and in the size and design of ships of this kind. Those regulations indicated that all passenger ships over 10,000 tons required 16 life boats, and that’s how many the Titanic had."

Fun to read and think about compliance and security... esp. for those who cannot grasp the relationship without overly dramatic examples :-)

Annual Blog Round-Up – 2008

If monthly, why not annual blog round-up? These are my top popular "Security Warrior" blog posts for 2008. Enjoy!

1. Just as last year (!!!), the "fallout" from being featured on a high-profile programming site continues to drive humongous loads of traffic which made this set of posts the most popular, even for this year  year, even though it was posted more than a year ago.  The topic that got such a huge boost was anti-virus efficiency. The posts are: Answer to My Antivirus Mystery Question and a "Fun" Story, More on Anti-virus and Anti-malware, Let's Play a Fun Game Here ... A Scary Game, The Original Anti-Virus Test Paper is Here!, Protected but Owned: My Little Investigation as well as a final entry about my own switch away from mainstream major-vendor anti-virus tool: A Bit More on AV  and Closure (Kind of) to the Anti-Virus Efficiency/Effectiveness Saga. The staying power of this series of posts is truly astounding; pretty much a Slashdot effect.
2. Due to totally bizarre reasons that just blow my mind, people keep obsessively googling for “open source SIEM” and thus I have to add this little post called On Open Source in SIEM and Log Management to a top list as – oh, shock! - #2. Just as a reminder, there is no credible open source SIEM tool (no “snort of SIEM”) – and there probably never will be. OSSEC comes kinda close, but solves a much more narrow problem (really well!)
3. Next by rank (amazingly, just as last year!) is a set of my Top11 lists:  Top 11 Reasons to Collect and Preserve Computer Logs and  Top 11 Reasons to Look at Your Logs (BTW, the third list, Top 11 Reasons to Secure and Protect Your Logs, was much more popular this year compared to last year – is log security finally coming?)
4. A champion of multiple months, “MUST-DO Logging for PCI?”  is also on the list; the world does need more specific PCI DSS guidance. PCI DSS guidance is not “too prescriptive,” it is more often not prescriptive enough!
5. I did a lot of polls in 2008 (mostly on logs, but on other subjects as well)  and many were on the top lists. I will do more polls this year as well; obviously, on more topics than just logs.
6. In a similar Slashdot-like effect, my comments on Terry Child saga “On Doomsaying (Terry Childs case)”, “So ... Am I? Maybe I Am!” and “Admins , Good Guys or "I am NOT an Idiot!"” were on the top list. The whole thing REALLY opened my eyes that “information security” and “IT” are not always friends, lovers or even good neighbors … Security people often bitch about management – this saga made me think we need to bitch about IT more :-)
7. This cute, semi-humorous post  on SIEM (“11 Signs That Your SIEM Is A Dog or "Raffy, You Killed SIM!"”) was hot this year; it generate a lot of soul-searching about SIEM (some items are linked here)
8. Accidentally launching a “security idiot” meme (“You Are "A Security Idiot" If ...”) was also one of the highlights. The “security idiot” meme lives on.  (one day I will have to explain how the original post originated)
9. Hurray to database logging (finally!) My posts related to database logging top the charts in 2008. Specifically, How to Do Database Logging/Monitoring "Right"? as well as its "prequels" Full Paper on Database Log Management Posted and On Database Logging and Auditing (Teaser + NOW Full Paper).

Also enjoy:

Monthly tops:

• Monthly Blog Round-Up – December 2008
• Monthly Blog Round-Up - November 2008
• Monthly Blog Round-Up - October 2008
• Monthly Blog Round-Up - September 2008
• Monthly Blog Round-Up - August 2008
• Monthly Blog Round-Up - July 2008
• Monthly Blog Round-Up - June 2008
• Monthly Blog Round-Up - May 2008  
• Monthly Blog Round-Up - April 2008  
• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

 

Annual tops:

• Annual Blog Round-Up – 2007

 

Technorati Tags: security,blog,blogs,blogging,chuvakin,annual

Monthly Blog Round-Up – December 2008

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 an attempt to remind people of useful content from the past month! If you are “too busy to read the blogs” (!), at least read these.

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

1. Truly shockingly, AGAINx3 :-) this month, the "Top 11 Reasons to Secure and Protect Your Logs" came up as on the Top list.  My Top 11 lists on logging live on! Is log security finally of interest to people?
2. Admittedly, making fun of other’s security predictions is easier than predicting correctly. In any case, “On Retarded Year-end Security Predictions” got the #2 spot this month.
3. People, there is NO open source SIEM that you can use in place of “market-leaning” (aka “expensive”) products! Despite that “On Open Source in SIEM and Log Management” is also again on the top list, to much of my amazement.
4. My list of PCI DSS-related blogs is in on the top list: “PCI DSS Blogs”
5. For whatever bizarre reason, the anti-virus saga is back to the top, where it stayed for many months.

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

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

• Monthly Blog Round-Up - November 2008
• Monthly Blog Round-Up - October 2008
• Monthly Blog Round-Up - September 2008
• Monthly Blog Round-Up - August 2008
• Monthly Blog Round-Up - July 2008
• Monthly Blog Round-Up - June 2008
• Monthly Blog Round-Up - May 2008  
• Monthly Blog Round-Up - April 2008  
• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

 

Technorati Tags: blog,security,loggings,monthly

Happy New Year!

Happy New Year to all my readers! Have a happy, exciting and prosperous 2009!