Showing posts with label PCI compliance. Show all posts
Showing posts with label PCI compliance. Show all posts

Monday, January 21, 2008

Do you have to fix XSS vulns to be PCI Compliant? ScanAlert Says No

I was reading Jeremiah's blog about ScanAlert's Response - ScanAlert - XSS is not our problem

I had blogged earlier about Should ScanAlert be revoked of their PCI Scanning abilities?

The interesting thing here is that if Hacker Safe is not detecting XSS attacks and I can bet they would not be detecting SQL injection attacks as well. So, what part of web application attacks are they trying to detect? I guess none. Which is OK as long as they don't claim they do. Oh wait..this is what they mention on their website

http://www.scanalert.com/site/en/security/howwescan/

During this testing phase, all HTTP services and virtual domains are checked for the existence of potentially dangerous modules, configurations settings, CGIs and other scripts, and default installed files. The web site is then "deep crawled," including flash embedded links and password protected pages, to find forms and other potentially dangerous "interactive elements." These are then exercised in specific ways to disclose any application-level vulnerabilities such as code revelation, cross-site scripting and SQL injection. Both generic and software specific tests are performed in order to uncover misconfigurations and coding error vulnerabilities.


Well..I don't know what to say here..Let's assume for a second, that they don't detect these vulns..which is OK. Hey!! I am not going to tell ScanAlert what they should and should not do. Its their business. If they don't want to detect XSS or SQL injection, its fine by me. They can say that "HackerSafe" is not going to detect XSS vulns as they are not considered a serious risk. My question is, if they are not detecting XSS vulns and PCI standard says "Web sites should not have XSS vulnerabilities" then can ScanAlert provide a PCI compliance certificate? If they can, then why penalize the merchants?

On the other hand, Lets say if they do scan and detect XSS and SQL injection vulns, then all the websites mentioned on http://sl.ackers.org and XSSed.com which have hackersafe logo on them should not have a PCI Compliance certificate from ScanAlert. Since PCI requirement Section 6.5.4 and 6.5.6 very clearly mentions that XSS and SQL injection vulnerabilities should be detected and fixed before a website becomes PCI certified.

I don't think ScanAlert team understands web application security properly based on some of the comments made by Joseph Pierini, director of enterprise services for the ScanAlert's Hacker Safe program. Here are a few of them below.

“Pierini dismisses the suggestion that certifying a site as "Hacker Safe" when it remains vulnerable to XSS attacks could be confusing to consumers. "

Forget about consumers for a second and talk about the website owners. Does a site which is certified as Hacker Safe is by default PCI compliant or a site can be hacker safe but not PCI compliant? I don't think they differentiate between the two.


“He insists that the meaning of the certification is clear and notes that his company's scanning service reports the XSS flaws it finds to its clients.”

So, if ScanAlert has notified its clients that they have XSS flaws in their system, and the clients have not fixed them, I am assuming then those clients are not PCI compliant and ScanAlert would not have issued them a PCI certificate. If they did, then why penalize the clients alone and not ScanAlert as they knowingly gave a certificate to the clients when they had open vulnerabilities in their system.


“Cross-site scripting can be used to do a variety of things, but it's all on the client side. And that's an area that we don't have control over."

This is exactly the kind of problems merchants are facing. If the PCI ASV doesn't understand XSS attacks or other web application attacks, then how are they going to educate the merchants and as a result, the vulns are left open and exploited by the bad guys. The ASVs wash their hands and merchants gets penalized. I think its time the ASVs are held liable too for their ignorance or incompetence.


Other suggested readings.

Who are the real culprits for PCI compliance?

Many 'Hacker Safe' Web Sites Found Vulnerable

Group Tags More 'Hacker Safe' Sites

Re: [ISN] Many 'Hacker Safe' Web Sites Found Vulnerable

ScanAlert - XSS is Cool with Us

An open letter to Ken Leonard, CEO ScanAlert

Monday, January 07, 2008

Should ScanAlert be revoked of their PCI Scanning abilities?

I was passed on this link today about "Hacker Safe Website gets hit by Hacker". For those who don't know, Hacker Safe is a service provided by Scan Alert (which is set to be acquired by McAfee). I am not going to go into the details of how safe are the sites displaying the logo "Hacker Safe". I don't even want to go into the details of what level of scanning services are provided by ScanAlert through Hacker Safe. What I do want to talk about is, the PCI Compliance Certificate provided by ScanAlert after their scan.

ScanAlert provides a PCI scanning service for $149.00 a year. Oh and their website claims they work directly with VISA and MasterCard. Personally, I don't care about their pricing model, they could provide their service for free, for all I care. What matters to me is, they are "PCI APPROVED VENDOR".

So, the story today was about one of their clients, Geeks.com. Here is an excerpt from the article

"Geeks.com is a $150 million company specializing in the sale of computer-related excess inventory and manufacturers' closeouts. Its Web site prominently proclaims that it is tested on a daily basis by ScanAlert Inc."

According to the PCI Compliance guidelines, Geeks.com should now become Level 1 merchant and have to pay fines and everything, now that there has been a breach resulting in loss of credit card details. But, what about ScanAlert, shouldn't they be penalized too?

As I mentioned in my last post -
Who are the real culprits for PCI Compliance?
Geeks.com hired a PCI approved vendor to scan their site and provide them solutions. ScanAlert scans Geeks.com site everyday and didn't find any vulnerabilities. Now that Geeks.com is hacked, I am sure everyone would blame them about lax security practices and what not but what about ScanAlert? Shouldn't they share a part of the blame too?

In the end, I think the bigger question is - Is this level of service accepted by PCI Council?

Wednesday, November 07, 2007

Who are the real culprits for PCI compliance?

There was an article in SearchSecurity today on TJX issue.

Don't blame PCI DSS for TJX troubles, IT pros say
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1280854,00.html?track=sy160&asrc=RSS_RSS-10_160

Here is an excerpt from the article

The auditor said TJX passed a PCI DSS check-up, but that the auditor failed to notice some key problems.

"They had no network monitoring and no logs, and they had unencrypted data," he said. "But this wasn't picked up by the auditor. They passed the Level 1 inspection and shouldn't have."




This makes me wonder what is the real objective of PCI complpiance. Most of the companies are still trying to understand the PCI requirements and hire a third party to assess their infrastructure for PCI compliance. Now, if PCI council has approved a vendor to assess a company's infrastructure for PCI requirements then for a company, the vendor understand PCI requirements and have proven to PCI council that they are qualified and capable of doing a good job. Now if a vendor charges $1000 to do the job or $15000 is upto the vendor. Companies are always looking for a good bargain and there is nothing wrong with that, as long as they are going to an approved vendor.

So if a company still gets breached after they are PCI compliant (assuming the data stored was not encrypted), who is actually liable in this case? The company or the vendor who certified the company for PCI compliance? In my mind, if the vendor would have told the company that they have to encrypt the sensitive data in their database, and company has not done it, then there was no question of company being PCI compliant.

Company getting penalized is understandable but is PCI council also going to impose penalties and fines on vendors who are not doing a good enough job? If a company is PCI compliant then its not completely company's fault for the data breach as much as it is the vendors, who did not identify and report the issues and certified the company as PCI compliant.

Tuesday, February 20, 2007

Compliance - is it worth the money?

While surfing through the net i found a posting on compliance
http://bestsecurity.blogspot.com/2007/02/compliance-audit-is-not-substantive.html

Though it was more of a ranting on the compliance but it certainly made me think my experience on PCI compliance.

I do agree that compliance has a place in the industry. In my experience, had it not been for compliance, many companies have not paid attention towards web application security at all. Unfortunately, many of the product managers or project managers (in big enterprises) still do not understand the issue of web application security (or should i say don't want to understand) and hence we see a lot of vulnerable applications out there. As for small and medium businesses, the sheer cost of securing web applications in itself makes them not go for the solutions. Compliance in a way is forcing them to do something about it. However, the problem starts from the governing agencies enforcing compliance. Take PCI compliance for example. It all started as a good idea to enforce companies to secure customer information but then they lost focus along the way. It is OK as long as you are making sure if the network and the applications aren't vulnerable but if you want to enforce a company to have source code audit by an independent third party, that is where it gets ridiculous.
What about companies who doesnt want to reveal their source code? what if it is proprietary software? Can I trust the company who is doing my source code audit, more importantly can I trust the person who is doing my source code audit? We have seen cases of hackersafe signing websites that they are safe from hackers and we have seen cases of bank's employees (who are the guardians of the customer information) selling the very customer information to the outside agencies. Who can I trust? Not to say what is the guarantee that the person doing the source code audit has enough knowledge of the language and more importantly where are the secure coding guidelines for us to follow?
The sheer cost of doing web application security compliance including black box testing, white box testing, source code analysis, web application firewall, etc, etc will run into hundreds of thousands of dollars (as we saw in RSA Conference) and not to mention the amount you have to pay for the auditors.

The other ugly side of compliance is auditing companies. For PCI compliance, there have been too many companies doing auditing for price ranging from $1000 to $13000. This confused me in the beginning and I started to ask questions about what is the value addition for that extra money and after doing a lot of research, I found out it's not about the value addition for the extra money, it's about saving your neck. When you can buy a compliance certificate for $1000 then why do you want to pay $13000. Of course, if you really are concerned about your security and want to do things the right way, then the price definitely will not be $1000.

I am sorry to say but compliance has become just another way for auditing companies to make money and the real message has gotten lost.