JimmyCrackedCorn
Posts: 583
|
| Posted: 12/13/2008, 9:06 AM |
|
Are there any security experts in the forums? I have a CCS application that will store credit card info temporarily (until the site user retrieves it daily) and I'm trying to figure out the best way to secure everything. I'd love to have someone else's thoughts as to whether this approach is solid and I welcome your ideas and improvements!
First of all, my preference is to never store credit card (CC) info at all. The most secure approach is to accept this info using https and then immediately submit it using https to a gateway and only store the result code from that transaction. If I can set it up this way it is probably as secure as it can be.
But, I have a customer who needs to process his orders manually. So in this case we must store CC info temporarily. So given that, the next step is to figure out how to store it securely.
We have decided to encrypt all CC info before inserting it into the database. Then, only the admin/owner of the site would have the password to decrypt this info. That way, in case the database fell into the wrong hands (hacker, rogue IT person at the hosting company, etc.) the sensitive data is securely encrypted.
But, of course, this brings up a new problem of how to do the encryption. To do the encryption requires a password or key. If we embed that key into the system code somewhere then a security breach at the server would expose both the encrypted info (in the database) and the key (in the system code). It is not an option to have the user enter the key since that would then be unknown to the admin folks.
So this is what we were thinking,
- each time we collect CC info we will send it (securely using https) to an off-site server (that we control) that contains the encryption code and key
- the off-site server encrypts the CC info and immediately sends it back (securely using https)
- we will store the newly encrypted data into the database
- we will provide an interface for the admin to retrieve the CC info which requires him to enter the key (which we provide to him separately)
- when he retrieves the CC info we will delete it from the database
here is the code we would use on his server to communicate with the off-site server,
<%
url = "https://www.off-site-server.com/encrypter.asp"
set xmlhttp = CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open "GET", url, false
xmlhttp.send ""
Response.write xmlhttp.responseText
set xmlhttp = nothing
%>
The only flaw I see with this approach is a security breach on the off-site server could lead to a breach in the system with the CC info since they could see that it is being used for the encryption process. One obvious improvement would be to obfuscate the code on the off-site server including the filename so it is not obvious what it is for.
Does anyone see any other holes in our logic? Or do you have any other good ideas to improve this (or even a better way to do it)?
Thanks in advance for any ideas/discussion/etc. Once I get this all resolved I'll post something in the Tips & Solutions section so hopefully it will help someone else in the future.
_________________
Walter Kempees...you are dearly missed. |
 |
|
mentecky
Posts: 321
|
| Posted: 12/13/2008, 11:53 AM |
|
JCC,
I've been working on this exact process for a couple years now. The unfortunate reality is the new PCI compliance rules imposed by all major credit card companies pretty much make storing of any credit card information virtually impossible. One of my customers has a very good and brief description of PCI requirements at:
http://www.onehealthsystem.com/html/PCI_Compliance.html
This is not to say that you can't write your application as you describe, it basically does mean that you are taking several risks. First, you can lose your merchant status if VISA or the other CC companies catch wind of it. Since they are all now working together on this... you can lose the ability to process cards from ALL providers until you prove you have come into compliance. Second, you become responsible for that data and the fines are HEAVY if you lose even one card number. Third, if any data gets stolen you are open to law suits and damages.
Your best bet is to use the processor's gateway in a compliant manner. I could hook you up with one of my customers if you need access to a gateway and a merchant account. I'm not sure why your customer needs to manually process cards, but there are ways through the gateways to do that without storing CC information on your own servers.
I'd be happy to discuss that with you more if it seems like a valid option to your customer.
Just my thoughts on it,
Rick
_________________
http://www.ccselite.com |
|
|
|
JimmyCrackedCorn
Posts: 583
|
| Posted: 12/13/2008, 12:53 PM |
|
Thanks Rick.
We do have quite a few customers where we connect their systems directly to gateways and this is definitely the best approach! In those cases we never store the credit card except for a few seconds while waiting for the gateway to process.
However, sometimes this is not practical. For example, in our current project the seller is offering events that typically fill up quickly. Because they are a community organization, they must allow everyone to register for the events and then once the registration deadline has passed they conduct a lottery to determine who gets in and who does not.
In that scenario, if they processed every payment they would end up with far more refunds to issue than they have orders!! And every refund carries a fee from the merchant account company! So they wait until they see who gets in before they charge anyone's credit card. Also, charging someone's card before knowing they are getting in the event seems to me to be quite a breach of contract too!
So there is the problem. They want to do online transactions but they cannot do immediate processing of the payments. That is why I am seeking a safe, secure and compliant way to do this.
I have read quite a bit recently (including the link you provided) about PCI. And while I agree it is definitely all about tightening up security, I have not found a statement quite as strong as yours when you say "new PCI compliance rules imposed by all major credit card companies pretty much make storing of any credit card information virtually impossible".
Are you sure this is correct? I buy a lot of stuff online from the big guys like Amazon all the way down to my local pet store and almost everyone still "remembers" my CC info which seems to imply they are storing it. Are they all out of compliance or is storing it OK so long as you do so securely?
Can you possibly point me to official verbiage where it is stated that you cannot store this info?
Thanks for your comments. I'll share anything I find as well.
_________________
Walter Kempees...you are dearly missed. |
|
|
|
mentecky
Posts: 321
|
| Posted: 12/13/2008, 1:48 PM |
|
JCC,
Quote :However, sometimes this is not practical. For example, in our current project the seller is offering events that typically fill up quickly. Because they are a community organization, they must allow everyone to register for the events and then once the registration deadline has passed they conduct a lottery to determine who gets in and who does not.
I'm not sure about all gateways but this can be done without incurring fees on the ones I work with. It becomes a 2 step process. First I AUTHORIZE the transaction and store just the transaction ID returned by the processor. An "Authorize" does not charge the card it merely verifies the account is good for the amount. Later, depending on the processor you have up to 3-7 days, you issue an "AUTHORIZE" using the transaction ID. This way you don't need the CC number. The drawback is you are limited to the window your provider defines.
Other gateway features will let you store the customer on their servers and you use a branded page for payment on the gateway. We do that and I know my favorite music store on-line does. It redirects to the provider's site to a page that looks like it's on your server. They store the CC info and I never even see it.
Quote :Are you sure this is correct? I buy a lot of stuff on-line from the big guys like Amazon all the way down to my local pet store and almost everyone still "remembers" my CC info which seems to imply they are storing it. Are they all out of compliance or is storing it OK so long as you do so securely?
Yes, I am sure. The requirements for storing CC data are extreme. They range from firewalling the server to physically securing the server in a locked, limited access room. For example, you have to prove that any access to the servers is logged. Be that by having a security guard and a sign-in sheet or a swipe card security system. In most cases where you are buying something on-line that remembers your card numbers, you are probably on a provider's server and not actually a server that the web site owns. We do that for some customers, hosting a site in their domain that is actually in a secured facility elsewhere.
I'm going to send a link to this conversation to a customer of mine that knows way more than me. I focus on the software aspect and he can probably help more with the logistics and storage ends. He also knows more about what the different tiers are for compliance. I get to deal with the higher levels, but I'm pretty sure what I have to deal with is the same as you as far as the storing of credit card numbers.
Rick
_________________
http://www.ccselite.com |
|
|
|
JimmyCrackedCorn
Posts: 583
|
| Posted: 12/13/2008, 3:09 PM |
|
Quote mentecky:
I'm not sure about all gateways but this can be done without incurring fees on the ones I work with. It becomes a 2 step process. First I AUTHORIZE the transaction and store just the transaction ID returned by the processor. An "Authorize" does not charge the card it merely verifies the account is good for the amount. Later, depending on the processor you have up to 3-7 days, you issue an "AUTHORIZE" using the transaction ID. This way you don't need the CC number. The drawback is you are limited to the window your provider defines.
I'm quite familiar with credit card transaction types. The two most common types are "Authorization and Capture" and "Authorization Only". The first authorizes and is automatically submitted for settlement (assuming it was approved). The second does as you describe where it only authorizes but does not submit for settlement. Later you can "finish" the transaction.
The time you mentioned, 3-7 days, would not be nearly enough for my purposes as they typically go a month or more between the time they start accepting orders and the time they run lottery. And even if the time were OK, I would still need to investigate this further to see if using the system in this way would be acceptable since I literally know that most of the transactions will never be finalized.
Quote :
Other gateway features will let you store the customer on their servers and you use a branded page for payment on the gateway. We do that and I know my favorite music store on-line does. It redirects to the provider's site to a page that looks like it's on your server. They store the CC info and I never even see it.
For our purposes, using a 3rd-party branded page would not usually be considered a viable option. And I know there are all kinds of ways (iframe, AJAX, etc.) to hide this but again our customers want it all to be on their servers.
Quote :
Yes, I am sure. The requirements for storing CC data are extreme. They range from firewalling the server to physically securing the server in a locked, limited access room. For example, you have to prove that any access to the servers is logged. Be that by having a security guard and a sign-in sheet or a swipe card security system.
We provide all of these security features and more! 24/7 security with video monitoring. background checks on employees. sign-in/sign-out. etc. We would have no problem passing the physical security specs.
BTW, I just perused this document,
Payment Card Industry (PCI)
Data Security Standard
Requirements and Security Assessment Procedures
Version 1.2
and was unable to find anything that prohibits the storage of credit card info except for the card verification code. Here is what they say in summary,
3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
So, I would welcome any definitive info you could provide that shows storing credit card numbers is prohibited. Maybe I missed this somewhere. Thanks again for the conversation.
_________________
Walter Kempees...you are dearly missed. |
|
|
|
Stanj
Posts: 166
|
| Posted: 12/17/2008, 9:28 PM |
|
This topic is of interest to almost everyone on the forum in some way. We have a situation where the Authorize only type transaction is not nearly long enough. We conduct shore excursions for cruise ship passengers on voyages in the Baltic Seas region with most of our tours in St Petersburg Russia.
Normally, cruises are booked 3-9 months in advance and shore excursions are often booked within days after the cruise is confirm. For example January is our peak booking time for tours conducted in May-September. Our two gateways have a limit of 30day for Authorize transactions. We have been storing the CC information on a seperate highly physical secure with a dedicated server for our cart with a different host than our general non-SSL web site.
We have a policy in place, known to the client about how long the information is being held and how it is disposed of. We can't charge for services not yet rendered, in our case when we buy the venue(museum and palace ) tickets for their tour 30 days before their arrival.
As soon as we complete something(secure their personal non-refundable tickets) we can, according to the VISA/MC rules debit the card. The data is purged at the same time.
So under the current system we are storing CC data for up to 8 months.
I can't figure out any other way of doing this. Any ideas? From my less than informed reading of the new requirements, there is wiggle room but this much?
What are your "expert" opinions of this situation.
Thanks for any suggestions.
_________________
Stan
St Petersburg Russia |
|
|
|
JimmyCrackedCorn
Posts: 583
|
| Posted: 12/17/2008, 11:42 PM |
|
Stan,
Thanks for the scenario you shared. Yours is a great example of a legitimate need for storing credit card info.
I think everyone's first response is the safe one, "Don't store this info!!" And, wheverever possible I think that is the best approach. But, as you and I have both shown, there are situations where storing sensitive data is a neccessity.
For me this leaves two main questions...
1) are we allowed to store this info?
2) how can we do this securely?
Based on what I am reading, so far, it appears we are allowed to store the info so long as we do so securely, however, the card verification code cannot be stored. For our applications this does not matter since our customers are not using it yet. NOTE: I am speaking primarily for USA-based customers since we do not conduct business outside the USA.
So the next question is how to do the storage securely. I think the answer lies with encrypting the data. But how do we do that securely? So far, our thought has been to use a second server for the encryption and keep that completely separate from the eCommerce system - different domain, different physical server, different physical location, etc. That way the only way a breach could occur is if both servers were compromised within the same time-frame.
My original post above outlines our thoughts so far.
I welcome further discussion and agree that any solutions we can come up with here would be helpful to many CCS users.
_________________
Walter Kempees...you are dearly missed. |
|
|
|
datadoit
|
| Posted: 12/18/2008, 9:22 AM |
|
JimmyCrackedCorn wrote:
> 1) are we allowed to store this info?
>
> Based on what I am reading, so far, it appears we are allowed to store the info
> so long as we do so securely, however, the card verification code cannot be
> stored.
I don't think there's a federal -law- in the United States about not
being allowed to store someone's credit card information if that
information is willfully given to you by the consumer. I could be wrong
and am really talking out of my ass, and would like to be proven wrong,
but I don't think so. There are recommendations from merchants and even
the FDIC, but there aren't laws that I'm aware of. If I take someone's
credit card information over the phone (hope it's not on a VoIP or cell
line!), I haven't broken any law by writing that information on a
post-it note and leaving it on my desk for perhaps the janitor to see.
If there were a law, then it seems to me it would be nearly
unenforceable, since in a court of law you have to prove willful
negligence or criminal activity.
However, it is certainly in the best interest of your own business
success to protect the privacy and 'merchantability' of your customers.
I think as long as you take documented reasonable precautions to
protect the privacy of your customers, you'll be okay (in a court of law).
Again, me don't thinks it's against any law to have credit card
information. There are laws that pertain to the methods of acquisition
and distribution, but not storing. I'd call our attorney on this, but
then he'd strip me of my wallet and it's contents - I need those for the
holidays.
|
|
|
|
JimmyCrackedCorn
Posts: 583
|
| Posted: 12/18/2008, 10:18 AM |
|
@datadoit
I think you are correct about the law. of course the credit card companies can dictate policies and procedures and then cancel your merchant account if you don't play by the rules.
they also claim you (the merchant account holder) can be liable for losses and damages which, if true, even trumps legal issues for me!
thanks for sharing your thoughts!
_________________
Walter Kempees...you are dearly missed. |
|
|
|
Stanj
Posts: 166
|
| Posted: 12/18/2008, 10:40 AM |
|
Thanks for the reply JCC
Has anyone on the forum had a scan done on their CCS generated card processing site?
One of the audit companies, Scanalert, stresses only XSS (cross site scripting) injections, and passes those sites that properly filter entry fields and ignores other common exploits for some strange reason. This all looks like another way of giving the impression of being secure but isn't despite the site scanning industry claims.
_________________
Stan
St Petersburg Russia |
|
|
|
Stanj
Posts: 166
|
| Posted: 12/18/2008, 10:43 AM |
|
Quote JimmyCrackedCorn:
@datadoit
I think you are correct about the law. of course the credit card companies can dictate policies and procedures and then cancel your merchant account if you don't play by the rules.
they also claim you (the merchant account holder) can be liable for losses and damages which, if true, even trumps legal issues for me!
thanks for sharing your thoughts!
The rule is that of the card companies as a condition of the Merchant Agreement, not federal law. Violation of the MA can have worse results than violating law, it can put you out of business without court review.
_________________
Stan
St Petersburg Russia |
|
|
|
Zye
Posts: 56
|
| Posted: 12/18/2008, 12:57 PM |
|
Hi peeps
I installed an oscommerce store for a client which had a contribution/plugin to send the middle 8 digits of the CC to the owners email address, so that the whole number isn't stored. I know it is still not PCI compliant but I thought I would mention. It has worked well for him for 3 years. He has been pulled up by Barclays recently, so I am seeking a solution besides a payment gateway. Don't think it exists. Some interesting threads that I have come across:
http://forums.oscommerce.com/index.php?showtopic=273891
http://forums.oscommerce.com/index.php?showtopic=300165...1&#entry1243461
http://community.actinic.com/showthread.php?t=34718
Free PCI compliance scan
http://www.hackerguardian.com/
If I find anything I will post here.
Zye ...
|
|
|
|
ThomC
Posts: 8
|
| Posted: 12/19/2008, 12:14 AM |
|
To all interested in PCI Compliance....here are the real answers to the questions you have been asking.
Rick Mentecky asked that I chime in on the forum to shed light on the PCI Compliance issue of card processing. I work for a merchant processing/PCI Compliance company and Rick is our key system developer of our card/check payment gateway. What he has said in the forum thus far is true, however, the issue is far bigger and the compliance requirements are overwhelming.
I could write volumes about the PCI Compliance issue and I am very close to the people that sit on the PCI Security Standards Council that make and govern the PCI rules. That said, I will offer some pertinent thoughts specific to the audience in this forum.
1) Yes you can store card data, but believe me...... you don't want to. If you store card data, you must undergo an onsite PCI Security audit by a qualified security assessor (QSA) at a starting cost of $30,000 and you better have a very very good business reason for storing card data. You have 12 major PCI requirement categories totaling 214 sub requirements, 14 business policies, and 19 data logs that you must maintain at all times. It takes no less that 6 months to complete the audit and that's if you can pass the first time around which never happens. The time and money go up exponentially from there. So.....I hope I have convinced you to abandon that idea completely. Only banks and processors store card data. Merchants and ISP's and shopping carts do not.
2) If you are writing an application that touches, processes, or handles card data in ANY manner, then your application is subject to PA-DSS compliance requirements and site penetration scanning by an approved scanning vendor (ASV). That means that your code, methods, logic model, and change management procedures must be audited by a qualified security assessor (QSA) and filed with the PCI Security Standards Council so that your application is listed as an "approved" payment application that is safe to use. Merchants are only allowed to use PA-DSS approved payment applications or they are not considered PCI Compliant and will lose their merchant account. Processors will not let their merchants use your software if it is not PA-DSS compliant and you can show your ROC (Report of Compliance)
Rick's payment gateway that he has spent more than a year on now is currently undergoing PA-DSS compliance auditing at a starting cost of $40,000 and that's only if he did a good job and followed the (DSS) data security standards as set by SANS. Every single version upgrade must be re-audited thereafter. Developers are required to take certified classes on DSS and show their certificate in order for their app to be PA-DSS approved.
3) PCI Compliance of the merchant and PA-DSS compliance of your application is MANDATORY! It is not a federal law, it is Visa/MC/Discover/AmEx rules and they will terminate your client's merchant account permanently if either of you are non compliant. The issue is not legal, its a matter of losing the "privilege of processing" that the merchant is granted by the bank. Once you lose your merchant account, you are placed on the TMF (Terminated Merchant File) and no processor will take you. You are out of business.
4) This is the most important advice of all.......get with a processor that will supply you the API and the gateway site and take the burden of card handling off your application. Just don't touch it. Get out of the card processing coding business unless you are prepared to walk the walk of PCI and write the check$$$$ for your audits.
5) Obviously, we would love you have all of your business. We can supply you with the compliant API and gateway that you simply 'plug into' your application and be done with it. Your merchant would have to switch to our bank and you would have to use our API for transactions and gateway portal for your reporting. Rick supports it and is the best in the business. We supply all the code and you can even take in person swiped cards and checks.
I realize that this forum is not for selling products or services and I am not really trying to do that, but, you do have to re-engineer your apps to conform to PCI and PA-DSS and the only way to do that is to get with a processor that can hand you the tools to do it and support you all the way.
I hope I have been of some help. If there is more interest on the issue, maybe we can do a webinar on the subject if there are 10 or more people willing to participate. I'm sure Rick will let me know if there is.
Good Luck,
Thom
|
|
|
|
ThomC
|
| Posted: 12/19/2008, 12:14 AM |
|
To all interested in PCI Compliance....here are the real answers to the
questions you have been asking.
Rick Mentecky asked that I chime in on the forum to shed light on the PCI
Compliance issue of card processing. I work for a merchant processing/PCI
Compliance company and Rick is our key system developer of our card/check
payment gateway. What he has said in the forum thus far is true, however, the
issue is far bigger and the compliance requirements are overwhelming.
I could write volumes about the PCI Compliance issue and I am very close to the
people that sit on the PCI Security Standards Council that make and govern the
PCI rules. That said, I will offer some pertinent thoughts specific to the
audience in this forum.
1) Yes you can store card data, but believe me...... you don't want to. If you
store card data, you must undergo an onsite PCI Security audit by a qualified
security assessor (QSA) at a starting cost of $30,000 and you better have a very
very good business reason for storing card data. You have 12 major PCI
requirement categories totaling 214 sub requirements, 14 business policies, and
19 data logs that you must maintain at all times. It takes no less that 6 months
to complete the audit and that's if you can pass the first time around which
never happens. The time and money go up exponentially from there. So.....I hope
I have convinced you to abandon that idea completely. Only banks and processors
store card data. Merchants and ISP's and shopping carts do not.
2) If you are writing an application that touches, processes, or handles card
data in ANY manner, then your application is subject to PA-DSS compliance
requirements and site penetration scanning by an approved scanning vendor (ASV).
That means that your code, methods, logic model, and change management
procedures must be audited by a qualified security assessor (QSA) and filed with
the PCI Security Standards Council so that your application is listed as an
"approved" payment application that is safe to use. Merchants are only allowed
to use PA-DSS approved payment applications or they are not considered PCI
Compliant and will lose their merchant account. Processors will not let their
merchants use your software if it is not PA-DSS compliant and you can show your
ROC (Report of Compliance)
Rick's payment gateway that he has spent more than a year on now is currently
undergoing PA-DSS compliance auditing at a starting cost of $40,000 and that's
only if he did a good job and followed the (DSS) data security standards as set
by SANS. Every single version upgrade must be re-audited thereafter. Developers
are required to take certified classes on DSS and show their certificate in
order for their app to be PA-DSS approved.
3) PCI Compliance of the merchant and PA-DSS compliance of your application is
MANDATORY! It is not a federal law, it is Visa/MC/Discover/AmEx rules and they
will terminate your client's merchant account permanently if either of you are
non compliant. The issue is not legal, its a matter of losing the "privilege of
processing" that the merchant is granted by the bank. Once you lose your
merchant account, you are placed on the TMF (Terminated Merchant File) and no
processor will take you. You are out of business.
4) This is the most important advice of all.......get with a processor that
will supply you the API and the gateway site and take the burden of card
handling off your application. Just don't touch it. Get out of the card
processing coding business unless you are prepared to walk the walk of PCI and
write the check$$$$ for your audits.
5) Obviously, we would love you have all of your business. We can supply you
with the compliant API and gateway that you simply 'plug into' your application
and be done with it. Your merchant would have to switch to our bank and you
would have to use our API for transactions and gateway portal for your
reporting. Rick supports it and is the best in the business. We supply all the
code and you can even take in person swiped cards and checks.
I realize that this forum is not for selling products or services and I am not
really trying to do that, but, you do have to re-engineer your apps to conform
to PCI and PA-DSS and the only way to do that is to get with a processor that
can hand you the tools to do it and support you all the way.
I hope I have been of some help. If there is more interest on the issue, maybe
we can do a webinar on the subject if there are 10 or more people willing to
participate. I'm sure Rick will let me know if there is.
Good Luck,
Thom
---------------------------------------
Sent from YesSoftware forum
http://forums.yessoftware.com/
|
|
|
|
JimmyCrackedCorn
Posts: 583
|
| Posted: 12/19/2008, 2:58 AM |
|
Thom, thanks for the detailed response. And I appreciate that you stated your bias (ie. you are selling a solution to this problem!)
I am curious if you know why so many merchants are not yet in compliance with these rules? And why has there not been a tidal wave of cancelled merchant accounts?
I suspect we are in a transitionary period where the credit card companies want everyone to change and naturally that will take some time. Cancelling 50% or more of the merchant accounts out there would obviously not be in anyone's best interest.
And, I suspect larger merchants would be targeted more aggressively than mom & pop net stores selling t-shirts and mugs.
So, what I am trying to get to the bottom of is where are we in this transition? Maybe the sky is falling and then again...maybe not! Maybe we should be shutting down all of our non-compliant eCommerce systems tomorrow morning and keep them turned off until we can achieve the level of compliance you suggest. Or maybe we should begin the transition process and take preliminary steps to secure our data with an eye toward the future and a plan for achieving full compliance at some point.
Your thoughts?
Also, one more question. If I use a gateway for the portion of my transactions where the credit card info is submitted and I never store that info and I only store the approval code, does my system need to go through any sort of compliance certification? Let me rephrase that...am I REQUIRED to go through any sort of compliance certification in this scenario?
Thanks again for sharing your expertise.
_________________
Walter Kempees...you are dearly missed. |
|
|
|
Stanj
Posts: 166
|
| Posted: 12/19/2008, 6:17 AM |
|
Hi Group
Thank you Tom for the detailed explanation.
The more I read the more conffused the whole picture is. Not the rules, they seem pretty direct enough but rather the real security needed to qualify for the certificate and to displace the logo on your web site. I've read dozens of forums and one thing come out, there are a lot of bogus security auditors. Time after time I've read how a webmasters web site was far from compliant and suddenly upon paying the scanning/monitoring company, it instantly becomes good to go with no changes. It causes me to suspect any cite that displays the compliant logo.
It reminds me of a recent application for a visa to a country that had stern warnings on its consulate's web site about how any deviation from the procedure or any missing information would mean automatic rejection. I poured over the application and double and triple checked it all, making sure my passport type photo was exactly the right size as specificed . I made out two copies of the application and sent it off. A few days later the consulate called to say my application was not signed and the photos were not signed....I had stuffed the wrong aplication, the one for me got into the envelope. The money order was for $205 as the consular fee that was a waste I figured. I asked if I could come to the consulate and sign them instead of lose the $205. All the officer wanted to know was if the money was good. Yes. its a money order. so he replied "no problem, just cime pick up your visa.
This 3rd party sanning industry feels the exact same way..."you must be a safe and good guy...your money is good"
_________________
Stan
St Petersburg Russia |
|
|
|
mentecky
Posts: 321
|
| Posted: 12/19/2008, 10:31 AM |
|
Thom,
Thanks for joining this discussion. Although I know the rules and code to them, you know a lot more about the "why", logistics and the penalties. That said, your answers are a lot more complete than I can provide these guys.
To the rest of you guys, sorry if it seamed I bailed on the discussion. I'm still watching and will answer what I can. I'm just busy with this exact issue and I have my audit coming up. Thom can give you better answers anyway. He deals with the entire process and he's very good at it, probably the best... but I'll deny ever saying that if it comes up in a conference call. 
Rick
_________________
http://www.ccselite.com |
|
|
|
Stanj
|
| Posted: 12/22/2008, 11:31 PM |
|
_________________
Stan
St Petersburg Russia
---------------------------------------
Sent from YesSoftware forum
http://forums.yessoftware.com/
|
|
|
|
Stanj
Posts: 166
|
| Posted: 12/22/2008, 11:34 PM |
|
I had a scan done on our dedicated server that has our shopping cart and it came up with a number of patches not up to date. All that was easy to resolve but required recompiling the OpenSSH and FTP programs. The CCS created shopping cart passed a lot , all I could figure out how to run, of intrusion tests so it is good to know that things are buttoned down.
A major selling point for YesSoftware ought to be the ease of making secure sites, not just ease of making sites. I never ran exploit or intrusion tests before this last week on the web applications I've done with CCS so it is confidence inspiring that to prove to myself these are solid.
The real question remains, what to do to conform to the PCI DSS? We are exploring completely changing or modifying our business work flow so that we do not use cards on the Internet at all, and instead use wireless swipe terminals in each port and increase a reserve for no-shows which can be very expensive losses. The price of the tours would increase a little by not having a deposit yet spending hundreds per person in out of pocket prearrival expenses( we pay in advance for each venue ticket, up to $20 each for the 10-15 museums and palaces each person visits), which is helped by the lower Card Present merchant discount rate, which should by itself save $20,000 every month in lower processing fees.
It will be a risk and gamble but with the war on small business by the card companies it is the best we can do now.
A lot of other small businesses will likely be forced out of business which is all that is NOT needed in an economy (USA) where most of the employees are in small businesses and in critical condition already due to corrupt large business and government practices.
_________________
Stan
St Petersburg Russia |
|
|
|
|
 |
|
|
|
