Управление журналами IIS

Если данные кредитной карты регистрируются IIS, вы, очевидно, проводите публикацию с помощью метода GET вместо метода method = "POST". Аудиторы PCI воля проверьте свои журналы (хотя они обычно больше касаются журналов транзакций базы данных, а не журналов W3) - стандарт PCI действительно утверждает, что журналы не могут представлять уязвимости. Если вы измените свои журналы (даже программно), вас поймают и обнаружат в несоответствии, что может повлечь за собой крупный штраф и большие неприятные проверки. Итак, DJ Pon3 выше прав, вам лучше начать редизайн с совершенно чистого листа бумаги.

Splunk - хороший инструмент для разбора все Ваши журналы на предмет потенциальных уязвимостей, журналы W3, AV, System, Error и DB должны быть просмотрены.

Программисты, которые сегодня следуют ЛУЧШИМ практикам, пытаются программировать так, чтобы ваша система НИКОГДА не увидела номер кредитной карты, даже на миллисекунду только в памяти, не говоря уже о том, чтобы записать его в вашу собственную базу данных. Как? На самом деле это довольно просто, сохраняя при этом идеальный контрольный журнал. Вы создаете последний экран, на котором дается номер кредитной карты, чтобы он отправлялся НЕПОСРЕДСТВЕННО на шлюз, такой как Authorize.net, Linkpoint или FirstData. У вас есть шлюз, настроенный на выполнение «обратного вызова» для каждой транзакции - вы даже можете указать с некоторыми шлюзами, где выполнять обратный вызов, прямо при отправке транзакции в скрытом поле. Обратный вызов представляет собой отправку формы (POST) обратно на ваш веб-сайт с результатами транзакции по кредитной карте, и обычно она будет довольно полной. У вас есть веб-приложение для обработки обратного вызова и вставки его в базу данных. Экран, за которым смотрит ваш покупатель, чтобы узнать, была ли его транзакция одобрена, выглядит так, как будто он обращается к компании-эмитенту кредитной карты, но на самом деле это js опрос вашей локальной базы данных «обратного вызова» на предмет результата обратного вызова от шлюза. На хорошем шлюзе вроде authorize.net все это занимает всего 2-4 секунды. Обратный вызов будет содержать ВСЮ информацию, необходимую для сохранения контрольного журнала для продавца, такую ​​как номер авторизации и номер транзакции. Но обратный вызов НЕ будет иметь номера кредитной карты или CVV (конечно) - иногда вы получите отредактированный номер CC, например, ************ 5454 для удобства без ущерба для безопасности. Теперь вы и продавец можете честно сказать: «Мы никогда не видим номер кредитной карты или CVV - даже на миллисекунду», и это верно и для ваших серверов.

За 20 лет проведения карточных транзакций в Интернете я ни разу не разговаривал с бизнесменом, который сталкивался бы со мной с бизнес-требованиями или моделью, которые нельзя было бы решить с помощью модели, которую я предлагаю выше. Если бизнесмен убеждает вас, что у него есть законная потребность сохранить номер кредитной карты и выдержать необходимое соблюдение, тогда и вам, и ему необходимо узнать, как на самом деле работает система кредитных карт.

Таким образом, вы избавляетесь от примерно 85% соответствия требованиям PCI, потому что вы никогда не видите, не нужно видеть или даже обрабатывать один номер кредитной карты или CVV. Вы по-прежнему обязаны зашифровать большую часть информации о держателях карт (это просто хорошая практика) и позаботиться о ключах API продавца, которые позволяют им использовать шлюз. Но эти опасения тривиальны наряду с бременем, связанным с просмотром кредитной карты / CVV даже на миллисекунду - так что избегайте этого!

Stripe.com имеет в основном правильную идею, и у них есть хороший код, хранящийся на github, который вы можете адаптировать для своего проекта (ссылка на их сайт). Но Stripe.com требует, чтобы продавец переместил свою «учетную запись продавца» в их сервис и, по сути, повторно запустил процессинг своей кредитной карты, а это трудная задача для ИТ-разработчика. Большинство деловых людей действительно не хотят перемещать свой торговый счет. Но вы можете почерпнуть несколько отличных идей, изучив код, который они публикуют / комментируют на github, и стать намного мудрее в отношении хороших методов разработки для обработки кредитных карт.

но...

НЕ используйте GET для отправки транзакции по кредитной карте - это глупая ошибка, которую можно избежать, и ваш продавец воля стал известен как продавец, «посткомпромиссный», который заплатил большой штраф и был вынужден потратить десятки тысяч долларов на судебно-медицинскую экспертизу PCI и «исправление ошибок».

ЗАПРЕЩАЕТСЯ отправлять транзакции по кредитным картам на ваш собственный сервер, отправляйте их напрямую на шлюз, следите за обратным вызовом от веб-перехватчика, который вы настроили на шлюзе, и элегантно и полностью законно обходите многие проблемы соответствия PCI. Шлюзы начинают отдавать предпочтение этой идее, и некоторые даже будут включать в обратный вызов все скрытые поля, которые вы отправили в свою РАЗМЕЩЕННУЮ форму кредитной карты, чтобы у вас было НАМНОГО меньше программирования, которое нужно делать на вашем конце для сохранения состояния и т. Д.

НЕ подделывайте и не изменяйте журналы - номер вашей кредитной карты в строке запроса воля идти на компромисс очень банально, система воля быть скомпрометированным, ваш клиент воля платить десятки тысяч за привилегию иметь судебных аудиторов, которые бегают по бизнесу и обращаются с сотрудниками как с преступниками, и вы сделаете своего адвоката очень, очень, очень довольным всеми счетами, которые он будет отправлять вам, чтобы защищать вас.

Я бы посоветовал вместо того, чтобы пытаться вычистить номера кредитных карт из журналов, вы в первую очередь должны делать то, что должны, а именно не хранить и не обрабатывать эту информацию в виде открытого текста. Фактически, вы нарушаете ряд правил, регулирующих процессоры кредитных карт и транзакции по кредитным картам, делая это вообще, и редактирования информации из журналов IIS будет недостаточно, чтобы обеспечить соответствие.

И да, вы обязаны соблюдать правила PCI.:

В: Кому применяется PCI?
A: PCI применяется ко ВСЕМ организациям или торговцам, независимо от размера или количества транзакций, которые принимают, передают или хранят любые данные держателей карт. Другими словами, если какой-либо клиент этой организации когда-либо платит продавцу напрямую с помощью кредитной или дебетовой карты, то применяются требования PCI DSS.

Стандарты.

Требование 3 стандарта PCI-DSS регулирует хранение конфиденциальных данных, включая номера кредитных карт и коды проверки карт.

Правило №1 - не хранить информацию, если вам не нужно (и есть некоторые данные, такие как CVV, которые никогда для хранения, даже если они зашифрованы). Правило №2 - всегда шифровать информацию, если вы ее храните.

Если он попадает в журналы IIS в виде открытого текста, вы уже нарушаете требование 3, и просто прекращения ведения журнала IIS недостаточно, чтобы вернуться в соответствие. И, если вы не знаете, на организации, которые не соблюдают правила, могут быть наложены штрафы в размере до 500 000 долларов США.

Итак, в основном, вам нужно исправить весь процесс и последовательность обработки данных кредитной карты, а не просто заткнуть это отверстие. Если вы все делаете правильно, вам даже не нужно беспокоиться о том, что записывается в журналах IIS, потому что любые номера кредитных карт, зафиксированные в журналах, будут зашифрованы или зашифрованы.

Другими словами, уход за xkcd ...