Most merchants are aware of the cardholder data in their database(s). But what about payment applications or payment portals that temporarily store the data? Or customer service reps e-mailing credit card information to confirm or dispute an order?...]]> Mon, 30 Jun 2008 20:00:00 +0000 data cardholder data credit card information customer service reps pci compliance payment applications absolutely critical temporarily store payment portals Finished? Where should I start? http://securityratty.com/article/415bc504c211b5ee78ee15ea0a533277 http://securityratty.com/article/415bc504c211b5ee78ee15ea0a533277 As well you should know by know, the existence of XSS vulnerabilities in a site that is required to meet PCI DSS standards means that the site IS NOT PCI COMPLIANT. Very simple, right?
Let's consider the McAfee Secure/Hacker Safe-branded site for Organize-It.
A seemingly handy site, perfect for your HGTV types, likely with healthy credit card limits. Uh-oh, here it comes. Oh yes, Organize-It handles credit cards and is thus beholden to PCI DSS.
Organize-It is also proudly displaying a current McAfee Secure badge, indicating that it's tested daily.
Given the focus of many a recent discussion it shouldn't shock you that Organize-It is vulnerable to XSS.
What's funny is what Organize-It does with regard to "handling" malformed requests.
Where a typical test string for XSS might be " script payload /script (characters removed or Blogger will let me XSS myself), you won't get much use from such a string via either direct form submittal or URL encoding. But when the site barfed up '; // LEAVE THIS VALUE var sli_cId = 90;, while under investigation, my ruh-roh meter went off.
I decided to play with my trusty marquee test and found interesting results. The actual search form field is limited to 41 characters (er?). So my complete string of " marquee message /marquee didn't fit for direct submittal BUT THE MARQUEE RENDERED ANYWAY! Basically, half the test string worked: " marquee h1 This_site_is_NOT_McAfee_S
Forget the marquee tag on the blacklist, did we?
But here's the real icing on the cake. The uber-intuitive search index reinterpreted my message with what I can only imagine are index keywords. Thus "This site is NOT McAfee Secure" scrolls across the Organize-It site as "this sit is not coffee secure".
OMG! My daily quad shot Americano has been pwn3d to the core!
Here's the URL if you don't believe me, or the video if you prefer.
Forget PCI compliance, bring on the Gong Show hook, Chuck!
Cheers.

del.icio.us | digg]]> Mon, 30 Jun 2008 17:10:00 +0000 site seemingly handy site mcafee secure mcafee test trusty marquee test organize-it site marquee xss XSS Comedy at McAfee Secure's Expense http://securityratty.com/article/20cb5c5674bc648f3e21f47cde22b211 http://securityratty.com/article/20cb5c5674bc648f3e21f47cde22b211

OK, the database cluster is back up and playing nice after its petulant episode.

Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

1. MoD implements new data security measures | PC Advisor
2. Do natural human traits make us more vulnerable to computer malware? | Hexus
3. The staff, the thief, the device and its data | Network World
4. Credit card firms wave stick at retailers | The Australian
5. Merchants call credit card industry’s bluff on compliance | The Register
6. Chairman: Computer Hacking ‘Much More Widespread’ | WYFF 4
7. Fired Houston organ bank worker accused of hacking into system | Houston Chronicle
8. PCI standard ‘ignores’ insider threat | vnunet
9. Student suspended after hacking emails | Stuff NZ

Tags: News, Daily Links, Security Blog, Information Security, Security News

Next, insert appropriate morbid jokes <here> for "IDS is dead", "NAC is dead", "GRC is dead", everybody is dead... WTF? Are we at the cemetery or what? Is "dead" dead? Yeah, but it came back as a zombie :-) So, "dead" is a "living dead" "dead" now. Ha*3.

Finally, think! Why were you thinking of buying a SIEM? 'Cause the big "G" in the sky said so? And while you are thinking, check these fun points out:

1. Does your SIEM require 17 beefy servers to operate? How many gallons of foreign oil have to go up in smoke to power that mammoth up? And you know what happened to mammoths, don't you?
2. If your "high-performance" SIEM appliance can only run 5 correlation rules at the same time, what "high" do they mean, really? Hold this thought....
3. Is five field engineers, two developers and CTO enough to install it? Who else needs to help? Ah, sorry, I missed the DBA :-)
4. Do you know when "If CustomVariable17 = Value5" condition matches? Will you still remember it in a year?
5. Can you tell "taxonomy" from "ontology"? You can now? Good for you. Are you more secure now? More efficient? Compliant?
6. How many shifts of security analysts do you have watching the shiny consoles 24/7? If zero, then why - oh - why those consoles are running in the first place? "If a tree falls..." - you know how this one ends. Correct! You get hit by the bough.
7. When was the last time you built a custom agent for parsing and normalizing, say, SAP logs? Did it work? What did you do after it didn't? Cried? And did it help? Then a burly vendor SE showed up, charged you $37,600 and left? Happy now?
8. Do you automatically correlate IDS/IPS alerts with vulnerability data ... for client-side attacks? Really? :-)
9. There are dozens of firewall, IDS/IPS, router, etc brands, each with its own log type. This is actually simple! But there are thousands upon thousands of applications in use today. Some have logs. All are different. Care to build rules for that? Now you finally know why SIEM vendors don't parse their own Java logs (no shit!)
10. Do you know what "threat x vulnerability x random()" equals to? Yup, it still equals random(). Automated prioritization, you say?
11. Do you know why some SIEM vendors are migrating to IT GRC now? So they can go and die there ... quietly.

All in all, I have to agree with Raffy to a large extent!  The world has evolved - and SIEM has not. It might not be dead (as old attacks and defenses never really die and large organization still build and man massive SOCs where SIEM is "a must"), but in this age of web application hacking, CSRF and XSS, phishing, PCI DSS, massive bot armies, client-side 0-days, stealth malware, etc, paying $x,000,000 for a pile of ugly Java code is insane ... As a result, SIEM has greatly diminished in importance and has become just one small thing you might do with logs and some other data. What made it so? Mostly implementation complexity - but a slew of other factors mentioned above as well.

So, consider this instead:

• Compliance? "Sorry, buddy, you need this for compliance, not that. "
• Want to simplify your incident response? Get log management and fly through all your logs, not crawl through some of them.
• Have a very real need to dig into your logs for troubleshooting or tracking that pesky user? Log management works.

Now, what if you have a latent and vague desire to "correlate something" and a million nice greenbacks to flush down the drain? OK, go get your SIEM toy for $780,000 + 20% maintenance/year ... a true bargain (price valid today only).

Finally, I would like to end this on an optimistic note. Do we need more intelligence to analyze the log data we have collected? Of course! Do we have a widest set of log use cases from today's security  to tomorrow's regulations? You bet. And, for you Raffy, I'd add "... we also have other data to analyze together with logs." So, can we "reinvent SIEM?" Yes, I think so! It just hasn't been done yet ... For now, just use log management.