Tuesday, October 09, 2007

Some unanswered website vulnerability questions

Update 10.20.2007: Additional links and press coverage

Some Answers for Jeremiah: Website Vulnerabilities
No Breach, No Foul
Security Experts: Merchants Racing to the Bottom for PCI Certs
Should We Be Legally Obligated to Fix Vulnerabilities?
National Retail Federation takes aim at PCI DSS Council
PCI Extends Its Reach to Application Security
Retailers B*tch Slap PCI Security Standards Council, If You Believe Them
Merchants mad about credit card retention

In the industry we discuss at great length the legal risks and ethical responsibilities of the person disclosing an issue, but not enough about the same when it comes to the business itself. I’ve had a hard time getting authoritative answers to some seemingly simple questions, so I figured I’d give the blog a try. Lets assume a company is informed of a SQLi or XSS vulnerability in their website (I know, shocker) either privately or via public disclosure on sla.ckers.org. And that vulnerability potentially places private personal information (PPI) or intellectual property at risk of compromise. My questions are:

1) Is the company “legally” obligated to fix the issue or can they just accept the risk? Think SOX, GLBA, HIPAA, PCI-DSS, etc.

2) What if repairs require a significant time/money investment? Is there a resolution grace period, does the company have to install compensating controls, or must they shutdown the website while repairs are made?

3) Should an incident occur exploiting the aforementioned vulnerability, does the company carry any additional legal liability?

4) If the company's website is PCI-DSS certified, is the website still be considered certified after the point of disclosure given what the web application security sections dictate?

5) Does the QSA or ASV who certified the website potentially risk any PCI Council disciplinary action for certifying a non-compliant website? What happens if this becomes a pattern?

While I’m happy to hear anyone’s personal opinions, answers backed by cited references are the best. Laws, case law, investigations, news stories, FAQ’s, or whatever are what I’m looking for.

18 comments:

Anonymous said...

My best stab at some answers: http://securosis.com/2007/10/09/some-answers-for-jeremiah-website-vulnerabilities/

In general, there is almost no liability unless a breach occurs, and no liability at all for intellectual property losses.

Anonymous said...

1. No. Considering both SOX & GLBA, a vulnerability does NOT equate to a materially weakness, and usually does not even constitute a significant deficiency. In fact, there is a lot in between. Even with a liberal interpretation of PCAOB / ICOFR requirements (see PCAOB standard #2, items 40, 50, 75 & 77), it is tough to quantify a web, application or database security hole as more than a deficiency. You need to establish the direct cause and effect, and show how the process as a whole may succumb to an exploitation of the security defect.

2. That is why a risk based assessment is used: to weigh the risk vs. reward of the fix. If you’re Wells Fargo (hypothetically), your probably going to fix or remediate in some way because potential financial damages and brand impairment is a looming specter. If your ‘ilovecats.com’, you might choose not to.

3. Your bringing lawyers into the mix. If you have ever worked with ITAA, you see it in action all the time, where company representatives are there to protect company turf and not because they want to help shape the IT industry moving forward. In fact, I have seen companies bring in attorneys as a first line of defense, and tell me why the issue could not be legally classified as bug, and threaten a libel suit against anyone who says otherwise. Large firms have legal resources to defend themselves in this area, and / or rewrite their EULA and make it the customers fault. Just kidding. Kind of.

4. This concept is fraught with problems. Who decides what the appropriate fix is? I am aware of several vulnerability ‘fixes’ that break the basic IT infrastructure of certain clientele. I think you need to look at it just like a compensating control, I may choose to patch the SQLi problem, or I may choose to adopt a different compensating option, or (in rare cases) remove functionality from my offering until a happy medium can be found. IMO, legislation tends not to solve the issue.

5. I am going to punt on this one.

Jeremiah Grossman said...

Rich and Adrian, fantastic stuff. This data really helped out a lot. Both of you had similar answers, and interestingly enough, I'm not concerned about validity and effectiveness of PCI-DSS now more than ever.

Jeremiah Grossman said...

Rich, Adrian: So let me get this straight, companies are only obligated to inform people after their data is exposed, but need not take timely action to remediate known issues, and legal liability is either negligible or unknown based upon what we’ve seen so far. In the case of PCI-DSS, it seems to me merchants are compelled to pass their quarterly scans using whatever shoddy ASV they can find who is most likely to find the LEAST. This is perpetuated because as far as we can tell, there are no penalties for ASV’s that we’ve seen and they’re incentivized to find less because that’s what the merchant desires. Greaaat.

I kind of expected these would be the answers, but I needed them confirmed or denied to make sure. Apart from potential brand damage due to an incident, I’m don’t see how PCI-DSS can have any effect on making websites more secure and safe for consumers. Plus I’m hearing rumblings from multiple sources that retailer revolt is already happening because recommendations and reality aren’t matching. It’ll be interesting to see how this really plays out.

Anonymous said...

Isn't there a concept called "proximate causation" that means if something bad happened because you either took action or didn't take action you could be liabel? I believe it's related to the prudent man rule... (Civil cases only)

Anonymous said...

Yes, companies are only required to inform customers who reside in one of the 30 odd states that have adopted something similar to California SB1386 to protect residents. Even then it appears to be a gray area. I am aware of at least one company who has never disclosed a breach as they involved the FBI & Secret Service Cyber-Threat team, and the Federal Government considered a detriment to the investigation if made public.
I am not sure that I would quantify the merchants that way, from my perspective many have a lot to lose if they are not secure and really strive to be secure. But, yeah, half just want a passing grade at the lowest possible cost. The same as we saw with Sarbanes-Oxley.
I find it difficult to pass judgment on PCI-DSS standard adoption as it was a stuttering start not exactly launched with industry consensus IMO. Who had to comply, when they needed to comply, what the remediation process was, what is a valid compensating control and how deficiencies would be communicated did not seem to be clear.
As you hear more about this PCI 'revolt', I would appreciate a post on your site. I am still trying to dig through the industry propaganda on this issue, and I cannot tell who is telling the truth ... or if it is all half-truths.

Jeremiah Grossman said...

Adrian, good point. I'm probably hearing the same rumors and propaganda you are. If something pops up, I'll be sure post it. Thanks!

Anonymous said...

I'd figure I would pipe in a bit on this one. I do a good bit of PCI DSS based work and promised RSnake a writeup but have yet to really get around to it.

The PCI-DSS ASV situation is fairly frustrating as a whole. From a security perspective the better you are, the harder it is to get customers, people are always looking for the path of least resistance. Frequently we have performed the equivalent of a "demo" look at someone's security to find a good number of things that broke PCI on a merchants website only to have the merchant declare that we had found too much that the he was staying with his current PCI ASV.

Sometimes it would be something fairly common, XSS for example (instant failure for PCI), others would have SQL injection where we could pull a shell on the system and still some would have an easy RFI. The majority of the time we were told we found too much and they did not want our services. They simply stopped all contact with us. From time to time I will check to see if what we found and told them about have been fixed. I'm sure there is one case where they have fixed the problems, but for the most part the vulnerabilities are still there.

We have even had a number of people call up and demand to have a certain threat removed from their report or they would cancel their account. Not false positives, but actual confirmed threats. Our typical response was to goto hell. They would cancel their service, go with a competitor with less morals, and be PCI compliant fairly soon, usually without fixing the problems we found.

PCI-DSS is a great idea, but it needs a bit more policing to be effective.

Anonymous said...

I have severely mixed feelings on PCI. It's mostly designed as a tool to protect the credit card companies and push liability onto the retailers. That said, we have to admit that it's improving security in most organizations, if not as much as we'd like.

PCI is a mess. I'd rather see a move to more secure transactions rather than propping up an indefensible system.

At least as a consumer our liability is limited. But it's hard to see PCI as more than a tool to protect the CC companies; one with some ancillary effects that nudge security up a fair bit.

Jeremiah Grossman said...

Anonymous, we're having similar experience, but not to the same degree which you seem to be having. When we saw a certain type of low-end ASV show up on the list, we knew it wasn't going to be business I felt comfortable pursuing. And since there seems to be limited policing, what is a responsible security vendor to do except wait and see. Thanks for sharing your thoughts.

Jeremiah Grossman said...

Hey Rich, I'm slowly being convinced of the liability shift agenda your describing. I mean, there is no other explanation for the current situation. What I don't agree with though is that PCI is making any kind of meaning difference in security.

I thought PCI was/is supposed to make website, and their data, less susceptible compromise. From our experience, nothing noticeable has taken place over its relatively short lifespan. Someone with only a modest level of skill would require no more than a few hours, maybe a day at the most, to find vuln in most websites that should require PCI compliance. It was the same situation a few years ago, and the trends indicate the same thing a few years from now.

But just so I understand where you are coming from, what meaningful improvements are you seeing made across the board as it relates to PCI?

Anonymous said...

Web application security hasn't improved at all, but I've seen a lot of changes on the back end. Sure, it's not enough, but any improvement is better than nothing. Just having network vulnerability scans is a big step forward, and a lot of organizations have started the 2-3 year process to clean up their databases and database security of credit card numbers. It's also slowly improving security on the bricks and morter side and with POS terminals.

It's all.... veeerrrrryyyyy... sloooooooowwwwww, but there's improvement. Many of these companies had little more than a firewall around a flat network with no internal encryption.

...all of which is worthless if any n00b can come through the front door with a SQL injection attack.

Anonymous said...

Web application security hasn't improved at all, but I've seen a lot of changes on the back end. Sure, it's not enough, but any improvement is better than nothing. Just having network vulnerability scans is a big step forward, and a lot of organizations have started the 2-3 year process to clean up their databases and database security of credit card numbers. It's also slowly improving security on the bricks and morter side and with POS terminals.

It's all.... veeerrrrryyyyy... sloooooooowwwwww, but there's improvement. Many of these companies had little more than a firewall around a flat network with no internal encryption.

...all of which is worthless if any n00b can come through the front door with a SQL injection attack.

Jeremiah Grossman said...

Gotcha, Im with ya. I wonder though how many people know, understand, and/or appreciate your last line though. Me thinks not many.

Anonymous said...

I agree with rmogull's last post.

I’ve seen PCI help CSO's get additional resources. The results have been the implementation of HIPS/HIDS, internal VA scanners, improved policies and solid encryption.

However I am still seeing weak SA passwords, SQL injection etc.

Furthermore anything that isn’t related to PCI (but is serious) is ignored.

Anonymous said...

Hi, I work for a Tier 1 merchant and in our case PCI definitely has helped us improve our web application security posture.

Every website that handles credit card data needed to be tested for security. We used Whitehat, AppScan, and our own manual testing. Any High or Critical issues needed to be remediated. In the past it was sometimes very difficult to get non-critical website vulns fixed in a timely manner, but since this was for PCI compliance, teams of developers were assigned where necessary to address all issues. Assuming that Whitehat and AppScan results are a decent measure of our web application security posture, we made a big improvement in a short amount of time.

As far as our auditors were concerned, all they really wanted to see was a clean scan report for each website with no Highs or Criticals. So we could have saved ourselves a lot of remediation work by using a low quality tool that doesn't find much. I suspect that a lot of companies are doing this.

Anonymous said...

Trust the closet lawyers.

Come on people.

How do you take on the issue, which relates to fitness for purpose, when we are comfortable that we don't wish to pay for the capabilities.

The problem stems from requirements creep and no real global security "design" per se of the architectures.

Things evolving from "neat" tools and ideas but not overall arhitecture.

Many of the problems stem solely from code quality.

Much of that is driven now by the view of many that software is a commodity and so prices are driven lower so quality clearly takes a back seat.

What will solve it is when someone with deep pockets needs it and will pay for it to be done properly. Otherwise, dust of your ISO 9001 disaster recovery procedures because you are responsible for defence of your IP.

Jeremiah Grossman said...

An interesting email came in from attorney Alan Wernick worth sharing with the group:

"The recent case is Central Laborers' Pension Fund v. Integrated Elec. Servs. Inc., (5th Cir., 8/21/07) which has language indicating
that this U.S. Court of Appeals (5th Circuit) may, I believe, allow an inference of knowledge under SOX that there was a weakness in the company’s ability to protect its intellectual capital assets. In
her opinion Judge Edith Brown Clement affirms dismissal of a class securities fraud suit, but cited with approval a U.S. Court of Appeals for the 11th Circuit case, (Garfield v. NDC Health Corp., 466 F.3d 1255 (11th Cir. 2006)), which held that Sarbanes-Oxley certifications may allow an inference of scienter “’if the person signing the certification had reason to know, or should have suspected, due to glaring accounting irregularities or other ‘red flags,’ that the financial statements contained material misstatements or omissions.’” A computer system vulnerability may be such a “red flag” as to provide a trigger for the inference of scienter (“knowledge”) under SOX. While this is not meant as definitive or exhaustive research on this issue, perhaps it will fuel your thoughts on this evolving issue. "