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

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

Splunk - хороший инструмент для анализа всех ваших журналов на предмет потенциальных уязвимостей, W3, AV , Журналы системы, ошибок и БД должны быть просмотрены.

Программисты, которые сегодня следуют ЛУЧШИМ практикам, пытаются программировать так, чтобы ваша система НИКОГДА не видела номер кредитной карты, даже на миллисекунду только в памяти, не говоря уже о том, чтобы записывать его в вашу собственную базу данных. Как? На самом деле это довольно просто, сохраняя при этом идеальный контрольный журнал. Вы создаете последний экран, на котором указывается номер кредитной карты, чтобы он отправлялся НАПРЯМУЮ на шлюз, такой как 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. . Шлюзы начинают отдавать предпочтение этой идее, а некоторые даже включают в обратный вызов все скрытые поля, которые вы указали в своей РАЗМЕЩЕННОЙ форме кредитной карты, так что у вас будет НАМНОГО меньше программирования, которое нужно сделать на вашем конце для сохранения состояния и т. Д. T подделывать или изменять журналы - ваш номер кредитной карты в строке запроса сделает компромисс очень тривиальным, система будет скомпрометирована, ваш клиент будет платить десятки тысяч за привилегию иметь судебных аудиторов, работающих по всему бизнесу, которые обращаются с сотрудниками как с преступниками, и вы сделаете своего адвоката очень, очень, очень доволен всеми счетами, которые он пришлет вам, чтобы защитить вас.

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

Стандарты.

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

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

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

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

Другими словами, позаботьтесь о xkcd. ...