Is it possible to prevent IIS to log specified type of data(i.e credit card data)? I mean can I say to IIS; -If a credit card number is searched, do not log this, or do not log all credit card number(mask it).
or is it possible to encrypt iis logs?
Thanks in advance
If credit card data is being logged by IIS, then you are obviously posting via the GET method instead of the method="POST" method. PCI auditors will inspect your logs (although they are usually more concerned with database transaction logs rather than W3 logs) - the PCI standard does state that logs cannot represent vulnerabilities. If you alter your logs (even programmatically) you will get caught and found in non-compliance and that could carry a hefty fine, and big nasty audits. So DJ Pon3 above is right, you better start off on a re-design with a totally clean sheet of paper.
Splunk is a good tool to parse all your logs for potential vulnerabilities, W3, AV, System, Error and DB logs should all be watched.
Programmers following BEST practices today try to program so your system NEVER sees a credit card number, not even for a millisecond in memory only, much less record it to your own database. How? It's actually pretty easy while still preserving a perfect audit trail. You craft the final screen where the credit card number is given so it submits DIRECTLY to the gateway like Authorize.net or Linkpoint or FirstData. You have the gateway set to do a 'callback' on every transaction - you can even specify with some gateways where to do the callback right in your transaction submission in a hidden field. The callback is a form submit (POST) back to your web site with the results of the credit card transaction, and it'll usually be fairly complete. You have a web app to handle the callback and insert it into the database. The screen your shopper is watching to see if their transaction was approved looks like it's talking to the credit card company, but it's really js polling your local transaction 'callback' database for the result of the callback from the gateway. All this takes only 2-4 seconds on a good gateway like authorize.net. The callback will have ALL the information you need to preserve the audit trail for the merchant, such as the authorization number and the transaction number. But the callback will NOT have the credit card number or CVV (of course) - sometimes you will get back a redacted CC number like ************5454 for convenience without sacrificing security. Now you and the merchant can honestly say "We never see a credit card number or CVV - not even for a millisecond" and it's true of your servers, too.
In 20 years of doing card transactions online, I have never talked to a businessman who confronted me with a business requirement or model that could not be handled using the model I suggest above. If a businessman convinces you that he has a legit need to store the credit card number and endure the requisite compliance, then both you and he need to learn how the credit card system really actually works.
Thus you are relieved of about 85% of PCI compliance because you never see, don't need to see, or even handle a single credit card number or CVV. You are still under the burden to encrypt most of the cardholder information (it's just a good practice) and take care with the merchant API keys which let them use the gateway. But these concerns are trivial alongside the burden imposed by seeing a credit card/CVV for even a millisecond - so avoid that!
Stripe.com has mostly the right idea, and they have some good code filed away on github that you can adapt for your project (linked on their site). But Stripe.com requires the merchant to move his 'merchant account' to their service and basically re-board their credit card processing and that's a tough sell for an IT developer. Most business people are really reluctant to move their merchant account. But you can take some great ideas by studying the code they publish/comment on github and become much the wiser for good development practices for credit card processing.
but...
DON'T use GET to submit a credit card transaction - that's a silly, avoidable mistake and your merchant will become known as a 'post-compromise' merchant who paid a big fine and had to spend tens of thousands for forensic PCI audits and 'remediation'.
DON'T allow credit card transactions to submit to your own server at all, submit them directly to the gateway, watch for the callback from the webhook you set up with the gateway, and elegantly and totally legally sidestep many PCI compliance issues. Gateways are beginning to favor this idea, and some will even include in the callback every hidden field you submitted in your POSTED credit card form so you have a LOT less programming to do on your end to preserve state, etc.
DON'T forge or alter logs - your credit-card-number-in-a-querystring will make a compromise very trivial, the system will be compromised, your customer will be paying tens of thousands for the privilege of having forensic auditors running around the business treating employees like criminals, and you will make your attorney very, very, very happy with all the bills he will be sending you to defend you.
I'd suggest that rather than trying to purge credit card numbers from your logs, you do what you're supposed to in the first place, which is not store or process that information in plaintext at all. You're actually in violation of a number of rules governing credit card processors and credit card transactions by doing this at all, and redacting the information from your IIS logs will be insufficient to be in compliance.
And yes, you are bound by those PCI regulations:
Q: To whom does PCI apply?
A: PCI applies to ALL organizations or merchants, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data. Said another way, if any customer of that organization ever pays the merchant directly using a credit card or debit card, then the PCI DSS requirements apply.
Requirement 3 of PCI-DSS governs the storage of sensitive data, including credit card numbers and card verification codes.
Rule #1 is not to store the information unless you have to (and there is some data, like CVVs that is never to be stored, even if encrypted). Rule #2 is to always encrypt the information if you do store it.
If it's reaching the IIS logs in plaintext, you're already in violation of requirement 3, and just stopping IIS from logging it is not enough to get back into compliance. And, in case you don't know, fines of up to $500,000 can be assessed on organizations that don't comply.
So, basically, you need to fix the whole process and flow of how you handle credit card data, not just plug this one hole. If you're doing it right, you don't even need to worry about what the IIS logs record, because any credit card numbers captured in the logs will be scrambled or encrypted.
To put it another way, care of xkcd...
