Oh and please do excuse my one inaccuracy, there is a difference between a QDSC and a qualified scan vendor (this will most likely merge in the future from what I am hearing from visa people). But if you look hard enough you should see plenty of companies on both lists, amazing how that works out.
Disclaimer: I am not certified by visa in their shiny new QDSP program, I shifted roles and companies during the roll out of that program.
On 3/16/06,
Crayola <[EMAIL PROTECTED]> wrote:
Even level 3 merchants can get nailed with a full on assessment if they screw up on the right scale. I know as i was involved with several such cases. And service providers tend to get more attention (and rightfully so) by visa when "issues" occur. This can be some what arbitrary in some cases, i have seen level 2 merchants get more flack then some level 2 service providers. This seemed to be the issue of who was being tasked with the "acceptance" on visa's end.
Its not, its a complete fabrication/misunderstanding. Unless of course things have changed in the last 4 months or so.
That being said I am very pleased that VISA is addressing one of the most glaring issues of the standard.
How to interpret the standard.
I just hope this QDSC/QDSSV/QDSP program can educate the assessors/auditors on HOW VISA wants the standard to be interpreted and executed. In my dealings with PCI-DSS the final interpretation depended on who you talked to at VISA and their knowledge of the systems being worked with. (ie you find out quickly who knows obscure mainframes and who doesn't)
I still feel that there are some issues that need to be worked out with the standard in general. But that is best for another time and a different list.
Classic line, I used that one a few times ;)
(the we have lots of clout with VISA, we can take care of it for you)
The secret is VISA is BACKLOGGED with ROC's from overdue merchants, SP's, and acquiring organization. All they are concerned about is insuring that everyone is going after compliance (and there for they have covered their arse). Oh and of course they can drop some nice fines on you and the acquiring entity in the equation.
ROC's for service providers and ROC's for merchants are treated differently. A ROC for a SP goes directly to VISA. Where as a ROC for a merchant "should" be sent to the merchant and the acquirer. (technically i think the QDSC only has to send it to the merchant)
I was under the "assumption" that jason was looking for not only information on PCI compliance. But also on leveraging nessus for internal "preparatory" scans. Which are a CRITICAL portion of PCI compliance, last thing any organization should want to do is walk blindly into PCI compliance and figure that everything will turn out ok.
So to sum up... READ MY DISCLAIMER, and take everything I say for what it is worth (here is a hint it rhymes with mothing).
And can we get back to the discussion on how Nessus requires a PHD in CS to run and install? Does anyone have an idea where I can enroll in in that CS program? I need more letters for my name.
Andre Ludwig CIOS DSOPI DSY ADSJ DHP
Actually it looks like Visa does the following.
http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_service
_providers.html?it=c|/business/accepting_visa/ops_risk_management/index%2Eht
ml|Service%20Providers
> The QDSC only comes into play for Level I merchants (firms
> that process more than 6 million card transactions per year),
> and it's not a requirement. Those firms must have an on-site
> assessment performed by a QDSC **OR**
Both level 1 and 2 merchants/service providers
are required to have an onsite assessment preformed by
an authorized firm. Level 3 (less then 1 million transactions)
get to do a self assessment signed by the execs.
Even level 3 merchants can get nailed with a full on assessment if they screw up on the right scale. I know as i was involved with several such cases. And service providers tend to get more attention (and rightfully so) by visa when "issues" occur. This can be some what arbitrary in some cases, i have seen level 2 merchants get more flack then some level 2 service providers. This seemed to be the issue of who was being tasked with the "acceptance" on visa's end.
> must conduct an
> internal audit and have an officer of the company attest to
> the accuracy and completeness of the audit (by his/her
> signature on the Report on Compliance).
Where is this written that a level 1 or 2 company can get away with
this? I have never seen this as an option.
Its not, its a complete fabrication/misunderstanding. Unless of course things have changed in the last 4 months or so.
That being said I am very pleased that VISA is addressing one of the most glaring issues of the standard.
How to interpret the standard.
I just hope this QDSC/QDSSV/QDSP program can educate the assessors/auditors on HOW VISA wants the standard to be interpreted and executed. In my dealings with PCI-DSS the final interpretation depended on who you talked to at VISA and their knowledge of the systems being worked with. (ie you find out quickly who knows obscure mainframes and who doesn't)
I still feel that there are some issues that need to be worked out with the standard in general. But that is best for another time and a different list.
> Also, VISA doesn't take scan reports from anyone, and they
> don't take anything from merchants.
Our QDSC (trustwave) said that it was normal for us to transmit
the ROC directly to visa. Visa will only accept a compliant ROC
Trustwave indicated they would do it for us this time since they
have a lot of clout with Visa and can rush it through the process
(we are approaching 60 days over due).
Classic line, I used that one a few times ;)
(the we have lots of clout with VISA, we can take care of it for you)
The secret is VISA is BACKLOGGED with ROC's from overdue merchants, SP's, and acquiring organization. All they are concerned about is insuring that everyone is going after compliance (and there for they have covered their arse). Oh and of course they can drop some nice fines on you and the acquiring entity in the equation.
ROC's for service providers and ROC's for merchants are treated differently. A ROC for a SP goes directly to VISA. Where as a ROC for a merchant "should" be sent to the merchant and the acquirer. (technically i think the QDSC only has to send it to the merchant)
> To certain other parties who responded to Jason's message: If
> you're going to answer a question, please make sure it's
> accurate and well-researched. PCI is difficult enough
> without bad scoop from other security professionals.
PCI compliance can not be achieved by running a simple nessus
scan.. it's a lot more involved, especially if you are a service
provider (believe me I've been going through it for months now).
See this doc for all the gorey details.
http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cis
p_PCI_Security_Audit_Procedures_and_Reporting.doc?it=il|/business/accepting_
visa/ops_risk_management/cisp_service_providers.html|PCI%20Security%20Audit%
20Procedures
I was under the "assumption" that jason was looking for not only information on PCI compliance. But also on leveraging nessus for internal "preparatory" scans. Which are a CRITICAL portion of PCI compliance, last thing any organization should want to do is walk blindly into PCI compliance and figure that everything will turn out ok.
So to sum up... READ MY DISCLAIMER, and take everything I say for what it is worth (here is a hint it rhymes with mothing).
And can we get back to the discussion on how Nessus requires a PHD in CS to run and install? Does anyone have an idea where I can enroll in in that CS program? I need more letters for my name.
Andre Ludwig CIOS DSOPI DSY ADSJ DHP
_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
_______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
