RSA 2009 Impressions, Part IV or The Rest of RSA 2009

This is my final RSA 2009 impressions post; check out the previous ones here. Check out other coverage of RSA 2009 on security blogs here.

First, I did go to a few sessions; way less than I wanted. One on SIEM (which was a little sad), one on PCI (which was very exciting) and a few others mentioned below. As many other, I was shocked about how poorly the sessions were scheduled: I had situations where 4 sessions (!) running at the same time were interesting and then there were two time slots where none were (OK, maybe it is just me :-)), Also, I was amazed to see flashes of TweetDeck everywhere in the audience; amazing change from last year when Twitter was virtually unheard of.

Next, I went to Jericho Forum mini-conference, which was kinda fun in its own detached way ;-) There were a few presentations about “cloud security”, cloud cube, etc. And, which was more fun, Philippe gave his pre-keynote presentation to the Jericho club (this is where he first mentioned cloud as a possible way to “invisible/ implicit/ unavoidable”  security), which was then followed by a good discussion. Then Rich Mogul, Gunnar Peterson and Chris Hoff beat up on the Jericho folks a tiny bit ("COA is unimplementable”, “no practical examples in documents”, ”confuses data centricity”, etc). Obviously, the common sense conclusion that ‘"the cloud" is no more/no less secure’ was the pink elephant in the room; it’s what you do with it counts.

Another pinky was the idea that “security is either baked in or none" for consumers; current move to cloud computing is our second chance to bake security in. How can we not miss that chance? Since power of large end user organizations is what often drives security (e.g. trustworthy computing at MS), unless and until large organizations say “I won't use XYZ cloud vendor unless secure up to ABC standards” this second chance will not be taken advantage of [this BTW needs said ABC standard as well a few metrics to boot].

On Thursday, our log standards panel was held; it was lots of fun too and we had almost 100 people (!). Dan Blum, our moderator, has a good account of it here. However, what matters is what happened before the panel: we had a three hour working meeting and made a lot of progress on Common Event Expression (CEE) effort in particular and log standards in general (more details in the future)

On Friday I went to RSA just to see Chris Hoff and Rich Mogul do their “Disruptive Innovation and Security” session, which exuded pure awesomeness! Key items I caught:

• Business innovation vs technology innovation vs security innovation – all 3 often seem out of sync, but security innovation is usually MORE behind.
• Threat innovation IS business innovation – just for the criminal businesses.
• Chris and Rich suggest that the motion from network->host-> data is not linear, but part of a cyclic circular progress; a fun idea.
• I realized that an idea that I recently “suffered” from (“intrusion tolerance”) is the same as what Chris calls “information survivability”
• Also, I liked their technology assessment methodology: security impact vs business impact chart (with IDS is in left bottom corner with both being “low”)

Finally, the most important part: the vendor hall impressions. Every year I am trying to “soak the vendor hall in” – and then produce insight while seating in an armchair (that last part is key for being called “an armchair analyst” :-)). This year I got a bizarre sensation: a whole hall-full of vendors TOTALLY missing both a) security of cloud applications (broadly defined) and b) ability to provide security services via SaaS/cloud (yes, I know these are not the same). No, this is not some Qualys PR talk – just think about it: 23 (!) RSA sessions that mention “SaaS” or “cloud computing” combined with almost NO vendors providing either a) or b) above (apart from blatantly idiotic “cloud gods send us the virus definitions” already ridiculed here). If I were to launch a security company today, I would NEVER even think of doing software, maybe an appliance – but most likely SaaS… I bet in a few years the whole concept of “buying servers to run security on them” will be grounds for being put into asylum (I do remember the time when my employer of 2002-2006 sometimes required 17 servers to run well…)

A few more observations from the expo: vendors who add themselves to all product categories probably means “FAIL due to lack of focus.” I saw a SIEM vendor listing themselves in a whole bunch of categories, including “Vulnerability Scanning” and a scanning vendor listed, among other things, in “DRM” (!) Also, I saw amazing amount of horribly confusing marketing, all the way to “not clear one bit to a certain Ph.D. ‘security insider’” :-) People, grow up! If users don’t get what you do, they will NOT buy your stuff! Among the technologies which vanished from our collective consciousness are: NAC (in a year I bet folks will ask what the letters stand for), anti-spyware and – strangely – DLP.

Overall, awesome show!

Possibly related posts:

• RSA 2009 Impressions, Part I or "PCI DSS is NOT a Pill Against 'Stupid'"
• RSA 2009 Impressions, Part II or The Only Fun RSA Keynote
• RSA 2009 Impressions, Part III - Mini-Metricon 3.5
• RSA 2009 Panel on Log Standards
• All years RSA coverage on my blog.
• Fun RSA impressions from others tagged here: http://delicious.com/anton18/conference+RSA+2009

RSA 2009 Impressions, Part III - Mini-Metricon 3.5

In this 3rd RSA 2009 blog post I will go back in time to my Day 1 of RSA which I spent at Minimetricon 3.5.  Minimetricon event exuded pure awesomeness! Some people bitch about RSA keynotes AND even about RSA content overall; they say they are there to “meet people.” However, Minimetricon (which just “coincided” with RSA) was all about presentations and discussions, especially the latter. It goes without saying that the caliber of people there was quite impressive (e.g. eBay, Google, etc security folks)

First, as a preface, I happen to believe that our inability to “measure security” is one of the top three problems we are facing in security industry today (no, it is not 0-day defense and not clown computing either – metrics actually underlie both of them too). So, here are some tidbits from talks:

Jeremiah web statistics talk was fun; some insights follow:

• XSS still tops all the web vulnerability charts; SQL injection is close [A.C. - BTW, PCI DSS prohibits both]
• CSRF is heavily underrated (11%) , likely due to not being discovered en masse.
• Retails sites: 61% has critical vulnerabilities [A.C. – to me this is the same as “they are 0wned by somebody who cares…” AND did we mention that PCI prohibits these vulns?]
• Resolution rates are low for XSS; basically, people are just not fixing it [A.C. - did we mention…ah…we did, didn’t we? :-)]
• There is also a long tail of web vulnerabilities; a lot of vulns are rare on few sites.
• Overall, “the whole Interweb thing” is hugely complex today – and has its complexity growing (which makes it more fun…)

Verizon breach report came out a few days before; still, their team’s talk was awesome too (and, yes, PCI section caused a bit of a storm)

• This breach study was insightful, but various people now want “breach cost study”, which will be MUCH harder.
• PCI slide: PCI compliance rates are claimed; some orgs even say this, verbatim: "we had the PCI paperword filled; how can we be compromised?"
• On the other hand, their compliance technology metrics are not claimed, but observed (e.g. that penetration of log management was around 5% across the breached organizations); thus claimed compliance rates are HIGHER then the use of tech mandated for being able to claim such compliance (BTW, see PCI Connect)

Fred Cohen did a fun talk on forensics and objectivity:

• The main idea, as I got it, was that forensics is one area of security where we just HAVE TO be fact-based and objective (and, no, we are not)
• Mysticism vs science in security; Fred thinks that security will have to become fact-based in the future; must have decisions based on intelligent risk management. Today security is pure mysticism and the use of fact-based metrics is very uncommon (and, yes, today’s risk management = voodoo)
• And the big question is: will security stop being a black art and start being a science in 10,20,30 years as IT importance grows?

Many of the MiniMetricon talks made me think about the whole “preventative AND monitoring security FAIL” and that maybe “intrusion tolerance” or … “information survivability” (now, Chris, I’ve said it :-)) is really the only way to go. Otherwise, you just accept that everything is 0wned and go home :-) Or go to the cloud.

Finally, I realize why I liked the event so much: it had a very uncommon balance of academic (=smart + totally out of touch) and real-world (=grounded in reality + not having time to think about said reality) people…

Possibly related posts:

• RSA 2009 Impressions, Part I or "PCI DSS is NOT a Pill Against 'Stupid'"
• RSA 2009 Impressions, Part II or The Only Fun RSA Keynote
• Fun RSA impressions from others tagged here: http://delicious.com/anton18/conference+RSA+2009
• Breach Report 2009 Day ...

RSA 2009 Impressions, Part II or The Only Fun RSA Keynote

OK, so people make fun of RSA keynotes as being “content-free”, buzzword-heavy and overall annoying. I did that too. However, this year I had advance knowledge that one keynote will be very fun, insightful and “B.S.-free”!

So, I came a bit earlier and the previous keynoter (not sure who that was) was working hard proving that RSA keynotes suck by droning on and on about nothing. I just couldn’t wait for Philippe’s keynote to start – and then it did and proved even more fun and insightful than I thought. Here is what caught my attention in his keynote:

• First, “The Inconvenient Truth”: critical data is spread across devices / laptops / phones today; many of such devices are lost every day. Data->gone.
• Second, vulnerabilities are being a) exploited and b) not fixed (updated Laws research shows no change in half-life of a vulnerability – still at 30 days as 4 years ago)
• The above two lines should tell everybody (rephrased by me for increased drama): “cloud is not a threat to data governance, you are!”
• Deploying applications to deal with security problems seems to open more security issues. Thus, enterprise LOST the security battle since it is impossible to secure today's networks and applications. To top it off, business need systems, IT resources faster than ever: and they are impossible to secure even at the slower pace.
• I have heard the whole “$84 billion to maintain Outlook+Exchange per year” line before, but it still has shock value. That is what people pay for insecure apps that handle valuable data (=email) today.
• Answer? SaaS! If you sell software and somebody does it in the cloud, you will be replaced. Good bye!
• Good news: today’s expansion of SaaS is also another chance to “build security in”; we failed this for platforms and applications, now we can [try to] do it for SaaS.
• Also, SaaS allows for more control over data (analogy: old mainframe model) and for more usable-yet-effective security. Obviously, there are a lot of problems to solve (e.g. browsers with holes, authentication across apps, strict and enforceable SLAs, etc)
• Example: end to end secure email was attempted since the 80s (with proven 100% failure of adoption rate), but now a big cloud provider (e.g. Gmail) can do it easily.
• Final word: “in cloud we trust, but it is our job to verify it!”
  

Full keynote video is here (yes, it IS actually worth watching!) and a lot of media coverage is here, here, here ("Cloud: Resistance is futile"), etc.

Enjoy all RSA coverage here.

Possibly related posts:

• RSA 2009 Impressions, Part I or "PCI DSS is NOT a Pill Against 'Stupid'"

RSA 2009 Impressions, Part I or “PCI DSS is NOT a Pill Against ‘Stupid’”

Now, I still have to formulate my [deep?] thoughts about the whole RSA 2009 conference. However, here is one post that I just have to write now… right now :-)

At RSA, I had a few people argue with our “PCI Shrugged” paper by showing examples of where PCI DSS was indeed a distracter and resources were pulled from projects that would have reduced information risk more than implementing PCI DSS controls. Typically, those arguments referred to technologies that are not mentioned in PCI DSS guidance (such as DLP), but that would be more effective in reducing their risks than PCI-mandates controls.  Still, in most cases I thought that our argument about PCI DSS covering the basics first still holds water.

However, one argument did give me pause in a big way.

Imagine that the resources of your security team are being pulled to PCI DSS compliance implementation  from … a response to a live ongoing security incident. You bet it cannot happen? I would bet that too, but we would both lose… The management considered lack of PCI DSS validation to be a bigger risk to their bottom line than an actual ongoing intrusion. This just blows up my mind :-)

In fact, I had nothing to say to whoever brought this argument at the time. I stammered and then remembered that  Requirement 12.5.3 mandates that an organization must “Establish, document, and distribute security incident response and escalation procedures to ensure timely and   effective handling of all situations.” However, when uttering this I knew what their answer would be. “Yup! A plan it does mandate… us acting on this incident here – not so much” was the quoted  response from their management.

However, now that I had time to ponder this (and to fully recover from shock), I have this to say:

• PCI DSS does not cure stupid! It was not supposed to, in can’t, and it won’t!
• PCI guidance lacks the magic power to imbue its reader with a shot of common sense.
• PCI does not add “+5” to Intelligence or Wisdom scores (for those who like game metaphors).

In other words, one CAN be stupid with or without PCI DSS; you  can ignore security even in the face of PCI DSS. One RSA speaker suggested that PCI is like a baseball bat; you can use it to play – or you can have you faced “batted” in by somebody really, really stupid…

Possibly related posts:

• Five Reasons to Dislike PCI DSS - And Why They Are WRONG!
• Risk vs Risk
• On "PCI Shrugged"
• Thoughts After Chicago “PCI Dinner” Panel
• Thoughts After RMISC 2009 PCI Panel

My Favorite "Ranumism" Lately

Marcus Ranum on firewall-wizards list: "Let me belabor that point a bit: security is often seen as a bill that gets presented; a cost of doing business. What they don't understand is that the bill is just interest coming due for when they cut some corners years ago. A break-in or disaster is that interest, compounded."

Qualys PCI Connect is OUT!

Ok, so RSA is an exciting event, but nothing excites me more than the release of Qualys PCI Connect!

"QualysGuard PCI Connect is an on demand ecosystem bringing together multiple security solutions into one unified end-to-end business application for PCI DSS compliance and validation.

As a new addition to the widely adopted QualysGuard PCI service, PCI Connect streamlines business operations related to PCI compliance and validation for merchants and acquirers all from a combined collaborative application with automated report sharing and distribution. PCI compliance status and tracking is performed on an ongoing basis.

Merchants who use QualysGuard PCI Connect can easily identify areas where they may not be meeting compliance requirements. Acquirers who use QualysGuard PCI Connect can easily evaluate whether merchants have met PCI requirements and whether sufficient evidence has been submitted for validation. "

Also, as of today, Qualys is fully in web application scanning business.

Meeting at RSA

If any of my readers want to meet at RSA2009, drop me an email, blog comment here or DM me on Twitter.

See ya at RSA!

On "PCI Shrugged"

Apart from our shared love of Ayn Rand writing, what else do you think of our piece on PCI DSS? Yes, it is aggressive. Yes, it might upset some PCI opponents (just as some of their comments upset me...)

If you think we overdid it, please argue with us! In any case, read "PCI Shrugged"

BTW, if you insist on Cliff's notes version, check out this post "Five Reasons to Dislike PCI DSS – And Why They Are WRONG!"

Breach Report 2009 Day …

… all other security blogging is expressly forbidden :-)

Get it here – and READ!!  This is not your mother’s CSI/FBI survey; this is actually objective data on security (=rare and valuable)!

Fun quotes:

• “83% of attacks were not highly difficult”
• “In 2008, investigators concluded that 87 percent of breaches could have been avoided through the implementation of simple or intermediate controls”
• “As with last year’s report, the majority of breaches are discovered by a third party”
• “The majority of breaches still occur because basic controls were not in place or because those that were present were not consistently implemented across the organization. If  obvious weaknesses are left exposed, chances are the attacker will exploit them.”
• “A very large proportion of attackers gain access to enterprise networks via default, shared, or stolen credentials.“
• “This market saturation has driven the price down to a point where magnetic-stripe information is close to worthless.”
• “2008 continued a downward trend in attacks that exploit patchable vulnerabilities versus those that exploit configuration weaknesses or functionality.”
• “2008 saw only a single instance in which a wireless network was exploited across our entire caseload” [I easily believe that: remote > wireless for an attacker]
• “As a percentage of caseload, payment card breaches remain near the 80 percent mark and far outnumber other data types. They consume 98 percent of all records compromised in the year.”
• “Breaches still go undiscovered and uncontained for weeks or months in 75 percent of cases.”
• “the large majority of organizations within our caseload are subject to the requirements set forth within PCI DSS […] Over three-quarters of organizations suffering payment card breaches within our caseload were found not compliant with PCI DSS or had never been audited.”
• “When reviewing the percentages for each requirement above, several very interesting statistics pop out. Requirements 3, 6, and 10—which many organizations complain are the most onerous—are indeed the least compliant across our caseload. When one considers the prevalence of unnecessary and/or unknown data stores, frequency of SQL injection attacks, and lengthy compromise-to-discovery periods discussed extensively in this (and our last) report, this finding is hardly surprising.”
• “In other words, the typical organization [UNDER PCI DSS requirements!!] had met less than a third of the requirements in PCI DSS. Some fared much better, some much worse, but
  the point made by the data before us is this: these breaches, in general, did not occur in organizations that were highly compliant with PCI DSS.”
• “We find that many organizations achieve very high levels of security in numerous areas but neglect others. Criminals will almost always prefer the easier route.”
• “All too often, evidence of events leading to breaches was available to the victim [in the form of logs] but this information was neither noticed nor acted upon.”

Fun pictures:

Fun commentary:

• Layer8 “Once more into the breach report.”
• SANS “2009 Data Breach Investigation Report” (with the quote of “Being PCI-compliant is critically important”)
• Dave “Verizon 2008 Data Breach Report”
• Treasury Institute “PCI DSS and Data Breaches for 2009”
• Martin “Verizon Data Breach Investigation: The numbers say PCI IS important”

No time for more today :-)  Maybe tomorrow … but this report definitely “exudes pure awesomeness!” Also, from my point of view, there has never been such objective proof of usefulness of everything that PCI DSS stands for!

Fun Contest- Win CSI SX 2009 Conference 50% Discount Code!

OK, so to further prove the oft-contested point that “PCI DSS is fun,” I dreamed up this contest (complete with a prize, of course!) which presents a perfect blend of “PCI DSS compliance” and “fun” :-)

There are TWO ways to win!

1. Submit the most exciting PCI DSS success story (some ideas are: how you got budget, used PCI to reduce risk, eliminated some card data storage, etc), or
2. Submit the most terrifying PCI DSS horror story (won’t give you ideas here).

Upon collecting the stories for 3 days (4/15,4/16,4/17), I will announce the winner late on Apr 17th (initially I thought of online voting as a more fair way, but then I reread this …)

One submitter of the best story of whatever kind wins CSI SX 2009 Conference 50% Discount Code (single-use, unshareable code) and ALSO a surprise prize (directly related to PCI DSS…)

Wonna play?

Hire Andrew Hay at RSA!

Did you happen to know that illustrious Andrew Hay, security product manager (past) and security analyst extraordinaire (now) as well as author of a few security books, is coming to town? You probably did (yes, he is that famous!) But did you ALSO hear that said Andrew Hay is open to your job offers (his resume)? Let me guess, probably not!

Strictly as a favor, I am going to steal his “About section” and post it below:

“Andrew Hay is a security analyst at Capital G Ltd. in Hamilton, Bermuda. Prior to that he worked as the Integration Services Product and Program Manager for Q1 Labs Inc. He has extensive experience in enterprise network, firewall, VPN, intrusion (IDS/IPS/HIPS), and network security management (NSM/SIM/SEM/NBA) technologies and is also strong advocate of security training, certification programs, and public awareness initiatives. He holds several industry-leading certifications including the CCNA, CCSA, CCSE, CCSE NGX, CCSE Plus, Security+, GSEC, GCIA, GCIH, SSP-MPA, SSP-CNSA, NSA, RHCT, RHCE, and CISSP.

Andrew is an active member of several security organizations and, in his spare time, he presents at security conferences, creates security training materials and white papers, contributes to forums, and occasionally acts as an instructor for the SANS Institute.

In February 2008 Andrew released his first book entitled The OSSEC Host-based Intrusion Detection Guide (Syngress, ISBN 9781597492409). He has also contributed to Nagios 3 Enterprise Network Monitoring (Syngress, ISBN 9781597492676) and has just completed the Nokia Firewall, VPN, and IPSO Configuration Guide (Syngress, ISBN 9781597492867). He is currently in talks with publishers and colleagues on several new book projects for the future.”

What are you waiting for? Check out his resume or his LinkedIn profile, contact Andrew NOW and set up a meeting!

MUST Read: ”Who is Minding the Legal Risk around PCI?” by David Navetta

Initially this was supposed to go into my next Security Reading review, but as I was reading the paper I was getting more and more excited about it [please don’t tell me I am weird because of it :-)]

A very, very good read by David Navetta  ”Who is Minding the Legal Risk around PCI?”  [PDF]

It’s official, this paper  gets my “Exudes Pure Awesomeness!” of the 1st degree award.

Quotes:

“In the PCI context, plaintiffs can allege negligence by arguing that a merchant handling payment card data has a duty to protect such data, and that the PCI Standard is evidence of what merchants must do to achieve “ordinary care” or “reasonable security.” If the merchant suffers a security breach exposing payment card data, the failure to comply with PCI would arguably amount to a breach of that duty.”

“Since TJX there have been several lawsuits filed against organizations that had been validated PCI-compliant at the time of the breach. It can be expected that plaintiffs  and courts in these suits are going to finely scrutinize every decision, practice, and interpretation around the stated PCI validation. The plaintiffs’ hope will be to discover that these merchants were not actually PCI-compliant despite the validation.“

However!

“Actual PCI compliance, however, does not necessarily absolve an organization from liability in the negligence context. In fact, PCI, as an industry standard, should be  viewed as the minimum or floor in terms of what a court will consider “reasonable security.”” and “Security professionals and organizations need to know that when
determining which controls to implement to protect cardholder data, PCI compliance may not be enough in a court of law.” (and, obviously, not enough “in the trenches”)

“However, the Federal appellate court in Sovereign Bank v. B.J. Wholesale Club & Fifth Third Bank, No. 06-3392/3405 (3rd Circuit, July 13, 2008) has allowed an issuing bank’s breach of contract claim to continue against a merchant bank that sponsored a merchant.” (even though issuing bank’s name was not on a contract)

“The Minnesota [PCI DSS-based] law (potentially others if they pass) provides a direct path to liability based in part on whether an entity was PCI-compliant.”

“One of the biggest challenges faced by organizations is resolving ambiguities in the PCI Standard as written and especially s applied to a particular organization or environment. Unfortunately, as PCI becomes a legal standard, the ambiguities arising out of the PCI Standard could increase the risk of legal liability.”

“In other words, being right on your judgment call [e.g. about the compensating control] at the end of the day will not necessarily eliminate legal risk, especially in the face of breach that has already occurred.  The problem is further complicated because there is no definitive way to resolve ambiguities under the PCI system.” (and, no, it is not always the QSA)

My fave part:

“Legally risky PCI practices:

#1 QSA shopping – With hundreds of qualified security assessors of varying sizes, sophistications, and skills, some companies will shop for the cheapest QSA that will validate their compliance in the least expensive and least painful way. […]

#2 Rubber stamping -  Another legally risky practice is “rubber stamping”: essentially failing to analyze actual security and simply treating PCI compliance like a facile  checklist. In short, when QSA shopping occurs, rubber stamping is what can result.

#3 Scoping - The legal risk posed in this instance is obvious: if a breach occurs with respect to part of a cardholder environment that did not have proper PCI controls [since it was deemed ‘out of scope’] in place, this fact will be used against the organization in court.”

“Another key point that could increase the legal risk associated with PCI is the potentially false sense of security that can arise after being validated PCI-compliant. Validation does not necessarily equal compliance with PCI or “reasonable security” under the law.”

“Until much more is learned about how alleged “safe harbors” [something that allows them to claim ‘compliant + breached –> not liable’] work, and until service providers and merchants have a legal  mechanism to actually enforce “safe harbor,” organizations should not assume they are protected.”

“Despite its security-centric origins, PCI compliance is posing increased legal risk. For organizations with a strong risk management ethos the approach to PCI compliance will likely involve a legal perspective and risk analysis.”

Read it now, whether you are a “PCI optimist”, “PCI pessimist” or a “PCI ambivalent-ist” :-) Something for everybody in there!

Technorati Tags: PCI DSS,PCI,compliance,security,legal,risk

CSI SX 2009: Thoughts + Discount Code

This is that time of the year again, and, courtesy of fine folks at CSI, I would like to give my readers a discount code for CSI SX 2009 conference to be held May 17-21, 2009 in Las Vegas.

The discount code  is “ACSX”

What’s funny though is that the email from CSI folks came right when I was reading their brochure for CSI SX 2009 and it started like this: “CSI SX: Security Exchange will be held May 17-21 in Las Vegas and focuses on topics of urgent importance today: virtualization, cloud, compliance, web security, security management and more.“ (all links to CSI SX track info)

Is that me or or maybe things like “getting people [in small companies] to update their anti-malware” (despite its oft-claimed inefficiency vs modern malware) or “using a firewall [in small companies]” (yes, despite this) or “encrypting data in a database”  or “migrating from WEP” or “struggling with PCI DSS” or a host of other “non-virtual/non-cloud/non-web2.0”, “boring” security issues keep MORE people awake at night? Is virtsec THE ONLY unsolved security problem, apart from cloudsec, that is? (Marcus sure seems to think otherwise) Maybe not…

But then again, if I were in the audience, what would be more fun for me: “how I secured advanced web services and my SaaS” security presentation or a rant called “how I beat my head against the wall of security awareness for 3 years – and then tried to commit suicide [but failed at that too]”…

BTW, stand by for a fun contest with a chance to win a DEEPER (50%) discount for CSI SX… And, yes, OF COURSE, it will involve PCI DSS :-)

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? :-)

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

These will become a core of a longer paper to be released soon. For now, enjoy these:

1. PCI DSS is a distraction from “real” risk management and security: WRONG! Your “real”, risk-focused, advanced  security must start somewhere – why not start from the basics, which happen to be mentioned in PCI DSS documents. Surely you wouldn’t want DLP (not in PCI) before you have a firewall (in PCI DSS) or a security policy (in PCI too)?
2. PCI is just checklist security: WRONG! “Checklist security” and “Compliance First!” approach is indeed  ugly and harmful, but prescriptive security guidance  (like PCI) is NOT the same as “checklist security;” it just contains more useful details on means, not just goals. On the other hand, if you are hell-bent on following the letter (1.1 … check; 1.2 … check, etc) and not the spirit (=protect card holder data), you can. Just don’t fault PCI for it – fault yourself!
3. We “got compliant” and now we are breached – it’s PCI’s fault: WRONG! First, you probably were not compliant during the breach since you “forgot” about ongoing compliance (and only focused on point-in-time validation). Second, if you are breached, it is attacker’s and [maybe, if you were negligent] your fault, but definitely not PCI’s.
4. PCI is “security theater,” appearance of security with no real risk reduction: WRONG! How is having a security policy, incident response plan, firewall, encryption, log management, etc appearance of security? One can be “faking it”, but then again: how is it PCI DSS fault? It is the faker’s fault! “Faking security” is no better (in fact, worse!) than “ignoring security” altogether, but the mandate didn’t cause it.
5. PCI is just not enough: RIGHT! So, again, why do you dislike it for this? Did you really expect some document from somebody to guarantee your security? Reeeally? So, yes, PCI DSS is not enough, but it is a useful starting point for many, many organizations who would otherwise not start AT ALL and will have your credit card data neatly stored in a text file on their MS IIS 4.0 web server…

Are there more reasons? Likely, yes. Feel free to add them – and we can debate.

Possibly related posts:

• PCI DSS and Data Breaches: Perception and Reality
• Myths and Misconceptions of PCI DSS (excerpt)
• Is PCI DSS "Too Prescriptive"?
• RSA [2008] Impressions - 2: Compliance "Megatrends"

Briefly on Confickr

Not that I am trying to restart the “AV is dead” frenzy (everybody is sooooooooooo tired of it, anyhow), but, pray tell, me how come Confickr was such a “remote detection/scanning” issue and not a “malware/anti-malware” issue?

I am definitely impressed by the Honeynet Project work, but how come that after having AV deployed and updated on [supposedly] 98%+ systems out there, “scan for Confickr” was HOT!, but "your AV will protect you” was NOT?

Just a thought…

Monthly Blog Round-Up – March 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 an attempt to remind people of useful content from the past month! If you are “too busy to read the blogs” (eh…cause you spent all your time on twitter? :-)), at least read these.

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

1. In a surprising twist, “Stratfor on Chinese Bots” took the #1 spot. This is my link and commentary on a Stratfor piece.
2. Also surprisingly, next comes my blurb (“OMFG - Mutiny on Board”) about Cory Doctorow’s  piece "The High Priests of IT — And the Heretics"
3. And only at #3 it becomes predictable: The Heartland Saga “On Heartland”, “Heartland II”,“Heartland III”, “On Heartland IV” and “On Heartland V” as well as my original posts  “Compliant + 0wned” and “PCI DSS and Data Breaches: Perception and Reality”.
4. Next is “Fun Views on DLP,” a post where I look at some opinions people express on “Data Leak/Loss Prevention/Protection” (DLP) and what they likely mean.
5. Last are my impressions from two PCI DSS –related panels that I did that week:  “Thoughts After RMISC 2009 PCI Panel” and “Thoughts After Chicago “PCI Dinner” Panel”

See you in April where Confickr will likely dominate the traffic. Also see my annual “Top Posts” (2007, 2008)

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

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

 

Technorati Tags: chuvakin,monthly,blog,security

Read Ranum’s Anatomy of Security Disasters

If you will read one article on security today (and, in fact, this whole week), read this: “Ranum's Rants - The Anatomy of Security Disasters” (here also in PDF and here in slide form)

The piece is fun to read (especially if you are fond of saying “EPIC F.A.I.L.” :-)) and is full of lines which promise to be useful and insight for the next…let’s say… 30 years :-)

Just quotes:

“So, what’s going on? We’ve finally managed to get security on the road-map for many major organizations, thanks to initiatives like PCI and some of the government IT audit standards. But is that true? Was it PCI that got security its current place at the table, or was it Heartland Data, ChoicePoint, TJX, and the Social Security Administration? This is a serious, and important, question because the answer tells us a lot about whether or not the effort is ultimately going to be successful.” [A.C. – it was PCI DSS, actually, and not the breaches. The later can be “it-won’t-happen-to-us”’ed away easily]

“I’m very skeptical of the notion that "Risk Management" has any value beyond the butt-covering obviousness of having made an attempt.” and later “If you accept the argument I am making so far, perhaps I can convince you that "risk management" is a fiction that plays into the disaster-cycle.” and even “Ultimately, risk management is a numbers game; you multiply a wild-ass guess by a fudge factor. Worse, the potential cost of failure is estimated in as a factor, too. So you're trying to balance an unjustified estimate of cost of failure against a wild-ass guess multiplied by a fudge factor.”

“The difference between Alan’s viewpoint (other than that security practitioners are ‘whiners’) and mine is that he appears to believe that anything worth doing, can be done safely. Or, at least, with controlled risk.”

“Computer security hasn’t been tagged with an epic failure, yet. So far, computer security has "merely" been blamed for things like billions of dollars of losses. In its simplest form, the problem with computer security is that (like most risky propositions) it's easy to simply not worry about it as long as "nothing has gone wrong, yet."”

“I describe that as having happened in the past tense because it's important to emphasize that the computer security disaster has already happened - we simply have not yet reached the end of the sequence of events that started being put into motion in the mid 1990s.” [think about this one!]

“The reality gap comes into play when the executive decided to shop the idea around: he asked for this thing to be done securely, and got a resounding "no" from the security group, but a "yes" (it can be done, but not securely) from the web group. All he hears is the "yes" and when the whole thing blows up a year later, his memory will be that he asked if it could be done safely, but someone lied to him.”

“A few years ago, when a friend and I were discussing this problem at a conference, he said, "Yeah, but what should we do about it?" The only answer I can honestly give is: "The wrong decisions got made 15 years ago and now it's too late to go back and un-make them." “

“Remember: every fatal skydiving accident is that diver’s first fatal accident.”

“Do not allow management or clients to believe that they can do dumb things in safety, and do not hide behind bogus probability guesses.”

… but you MUST read the whole thing!!

UPDATE: fun comments to it can be read here.

Thoughts and Notes from PCI DSS Hearing in US House of Representatives

Ok, so it took me 2 days to organize my thoughts; meanwhile, I’ve seen some excellent accounts of this, as well as some truly sucky ones.

So, objective content first:

• “Do the Payment Card Industry Data Standards Reduce Cybercrime?”  in US House of Representatives Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology  hearing on Tuesday, March 31, 2009 @ 2PM: video recording, testimony by the participants [all PDFs linked from here]
• Specifically, two key statements by the subcommittee members (they are also quoted below): Prepared Statement - Chairwoman Clarke and Prepared Statement - Chairman Thompson.
• Best account (by far) by Branden Williams:  “Review of PCI Congressional Hearing.” Branden, you rock!
• PCI Answers blog has good coverage as well: “Summary of the Congressional Hearing on PCI DSS” and “Congressional Hearing on PCI DSS (on NOW!!)”
• To know why one of the witnesses (the merchant CIO) hated PCI go here and read “PCI Hearing Recap” (no comment!)
• Live and later Twitter coverage (all posts tagged with #pcihearing); if this annoyed you, I apologize for starting it and promise to never do it again. If you liked it, sorry, do it yourself next time :-(
• Sucky accounts, mostly in mainstream IT media, will NOT be linked to - you know who you are. Forbes  account was actually not bad, even though they missed most of the undercurrents.

Second, key quotes from the hearing for those too busy/lazy/tired of the whole thing :-)

Intro by Chairwoman Clarke [full testimony PDF]:

“In light of the rising number of publicly reported data breaches, Chairman Thompson launched an investigation to determine whether the PCI Standards have been effective in reducing cybercrime. The results of this investigation suggest that the PCI Standards are of questionable strength and effectiveness” [for decreasing cybercrime and data theft].

“I do not believe the PCI Standards are worthless; in the absence of other requirements, they do serve some purpose. But I do want to dispel the myth once and for all that PCI compliance is enough to keep a company secure. It is not, and the credit card companies acknowledge that.”

“The bottom line is that if we care about keeping money out of the hands of terrorists and organized criminals, we have to do more, and we have to do it now.” [emphasis by A.C.]

“First, the standards have to be better because they are inadequate to protect against the methods used by modern attackers. Despite what the credit card companies say, for millions of small and large businesses out there, the PCI Standards are the ceiling and not the floor. The bar has to be raised.” [emphasis by A.C.]

“Part of the problem is that the standards do not require more frequent penetration testing. The only way to reduce breaches is by continuously testing and attacking a system through penetration testing and timely mitigation.” [emphasis by A.C.]

“Second, the payment card industry and issuing banks need to commit to investing in [payment] infrastructure upgrades here in the United States. In a response to the Committee’s investigation, one breached company noted that ‘the effectiveness of data security standards in inherently limited by the technology base of U.S. credit and signature debit card processing networks.’”

Follow-up by Chairman Thomson [full testimony PDF], who actually led the investigation of the whole problem:

“We are here today to learn about the private sector efforts to combat data breaches and cybercrime, and to assess the quality of the Payment Card Industry Data Security Standards. The Standards have been around for several years, but massive, ongoing data breaches at some of America’s largest merchants suggests that the Standards are inadequate to prevent breaches. The essential flaw with the PCI Standards is that it allows companies to check boxes, but not necessarily be secure. Checking boxes makes it easier to assess compliance with a Standard. But compliance does not equal security.”

“We have to get beyond check box security. It provides a false sense of security for everyone Involved, and it is ineffective in reducing the real threats. Companies need to understand that even if 100 percent compliance with the PCI Standards is achieved, hackers will continue to develop techniques to exploit the computer systems of companies holding cardholder data. You are not safe unless you continually test your systems.” [emphasis by A.C.]

“We in Congress must seriously consider whether we can continue to rely on industry created and enforced standards, particularly if they are inadequate to address ongoing threats. I look forward to working with my colleagues on both sides of the aisle and across Committee lines to further explore whether government action is necessary to protect against these threats. One thing is certain: the current system is not working.”

I am unable to quote some other testimony, as I will get angry (e.g. testimony from a CIO [PDF] who thinks PCI is “onerous”, but has XSS and SQL injection flaws on his “compliant” site, more XSS here); let others who are more relaxed do that. In brief, these are the folks who think that PCI is waaaaaaaaaaaaaaaaaaaaaay more security than they think they will ever need.

Last, some minor league punditry – I’d will try to focus on highlights only as there was A LOT going on:

• The purpose of the hearing was very simple: continue subcommittee’s investigation into whether PCI DSS helps to reduce cybercrime and data theft.
• I was amazed about how well-prepared the congressmen were and how they asked the right questions (e.g. “Where are the metrics showing how many breaches that were prevented?”)! Their briefs/prepared statements as well as questions they asked during the hearing revealed that they did get to some of the “hidden truths” about security, compliance, data loss, cybercrime, etc.
• There was a lot talk about “shifting risk”, mostly as if it is a bad things. Somehow nobody noted that shifting risk to where it belongs is exactly what is needed (why should an issuing bank pay if merchant loses the data?) Apart from this, there was a lot of very public and noisy blaming, from merchants to brands, and not enough “let’s solve this problem together!” And you know what? Blaming today –> legislation tomorrow –> you go to jail the day after…
• At one point in the hearing point, I felt that a pillow fight was imminent!  The subject was card data storage by merchants. PCI limits such storage and mandates protections to what you can store (the “render unreadable” clause), but merchants keep saying “PCI makes us store data” (even though only some acquirers might and there are method to do chargebacks without PAN storage) and Visa/PCI Co stating the exact opposite. All this accomplished was made committee members angry (they said “this discrepancy is VERY troubling!")! BTW, here is a fun resource for merchants that was mentioned: Visa’s “Drop the Data!” site.
• The theme that was mentioned many, many times by the government side was: we need more security testing, more ongoing monitoring and more focus on securing the data. Things like that made me think that committee members actually “get it.”
• The subject of the future came up as well – most agreed that changes towards more secure payment networks and methods are needed, but Branden’s take on this is best: today, sadly, we have BOTH insecure payment method and insecure merchant networks. So, stop blaming and start securing!

Finally, for me the the key takeaway (BTW, missed by the media coverage) was:

Yes, PCI DSS was criticized by BOTH government AND the merchants/NRF, BUT for ABSOLUTELY OPPOSITE REASONS (!!!)

…Please pause here and think…

Congress essentially said “PCI is not enough; we need to do more! Do more now – or we will legislate” while the merchants said “PCI is way too much; we don’t, can’t and won’t do even less.” That to me was the central point to ponder – also, I hope that this hearing will lead to more focus on data security, more attention to continuous security/compliance, better compliance rules and more enforcement of such rules. This can only be good for everybody!

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!