Безопасность карточного бизнеса : бизнес-энциклопедия
Шрифт:
• разработка стандартов безопасной настройки, определяющих конкретные параметры безопасности для каждого вида используемых систем;
• изменение параметров систем, установленных по умолчанию;
• разделение важных функций между различными серверами;
• удаление ненужного или неиспользуемого функционала;
• регламентация используемых протоколов взаимодействия;
• обеспечение безопасного удаленного доступа администраторов для управления системами.
Как правило, реализация данного набора требований требует определенного времени как на разработку необходимых параметров безопасности, так и на тестирование их работоспособности и применение на всех системных компонентах.
Но в результате безопасность систем существенно возрастает, особенно в совокупности с правильно настроенным межсетевым экраном и вовремя устанавливаемыми обновлениями безопасности. По сути, реализация требований 1, 2 и 6 в полном объеме могли бы предотвратить более 90 % случившихся взломов систем с последующими утечками данных платежных карт.
Требование 3: должна быть обеспечена защита данных держателей карт при хранении.
Данное обобщенное требование содержит 15 требований и соответствующих им процедур оценки, определяющих, как необходимо обрабатывать, хранить и защищать непосредственно данные платежных карт (такие как PAN, TRACK, PINBLOCK и т. п.), в том числе:
• необходимо хранить номера карт только в тех местах и в течение такого срока, которые явно определены бизнес-целями;
• соблюдать политику по уничтожению номеров карт после истечения срока их обоснованного хранения;
• ограничивать доступ сотрудников к номерам карт в приложениях;
• маскировать, шифровать, использовать другие способы затруднения получения полного номера карт при хранении;
• жесткие запреты хранения критичных данных карт, используемых для авторизации после ее завершения;
• управлять криптографическими ключами, используемыми для шифрования данных при хранении.
Необходимо отметить следующее: так как стандарт разрабатывался в первую очередь для снижения рисков мошенничества в инфраструктурах торгово-сервисных предприятий и поставщиков сервиса (таких как платежные шлюзы, процессинговые центры и т. п.), вопросы защиты и хранения данных платежных карт в банковских организациях в рамках их выпуска не рассмотрены достаточно подробно. В результате при подтверждении соответствия стандарту в банках, где осуществляется и эквайринг, и выпуск карт на базе решения некоторых вендоров (таких как OpenWay, например), возникает ситуация, при которой в одной базе данных могут храниться критичные данные авторизации как сохраненные в процессе выпуска карт, так и сохраненные после авторизации. В этом случае необходимо рассматривать каждое место хранения данных в привязке к процессу, в рамках которого они возникают, — ведь в стандарте запрещено хранить критичные данные, возникшие только в результате авторизации, но ничего не сказано о данных, возникающих в рамках выпуска карт.
Наиболее проблемным при внедрении всего стандарта обычно считается требование 3.4 (приведение номеров карт при хранении к нечитаемому виду путем использования шифрования, маскирования и т. п.), поскольку это требует:
• доработки/замены прикладного программного обеспечения, используемого для обработки карт, включая изменение алгоритмов поиска номеров карт, в частности по маске;
• обновления базы данных, поскольку, например, в СУБД Oracle шифрование хорошо поддерживается начиная с 10-й версии;
• апгрейда оборудования на более производительное, поскольку шифрование требует больших аппаратных ресурсов;
• обеспечения шифрования резервных копий баз данных;
• серьезной проработки и регламентации вопросов управления
Требование 4: должно быть обеспечено шифрование передачи данных держателей карт по сетям общего пользования.
Данное обобщенное требование содержит 3 требования и 9 соответствующих им процедур оценки, регламентирующих вопросы шифрования данных платежных карт при передаче их по открытым каналам связи, с использованием программ мгновенного обмена сообщениями (таких как Skype, ICQ и т. п.) и через беспроводные сети.
Необходимо заметить, что в рамках данного требования каналы GSM считаются публичными и требуют криптозащиты трафика. И это несмотря на то, что во многих сетях мобильных операторов реализовано шифрование, а, например, каналы FrameRelay считаются достаточно защищенными и не требуют дополнительного шифрования. А с точки зрения используемых алгоритмов для шифрования можно использовать не только сертифицированную российскую криптографию, но также и другие алгоритмы с достаточной криптозащитой (например, AES 256).
Реализация данного требования в российских банках обычно вызывает наименьшее количество проблем, поскольку исторически у нас вопросам криптозащиты трафика уделают большое внимание как сами банки, так и регулятор в лице ФСБ. Обычно все каналы связи с филиалами, терминальные сети банкоматов уже защищены с помощью VPN, и это вполне соответствует тому, что требует стандарт PCI DSS.
Требование 5: должно использоваться регулярно обновляемое антивирусное программное обеспечение.
Данное обобщенное требование содержит всего 3 требования и 6 соответствующих им процедур оценки, описывающих особенности применения и управления системами антивирусной защиты.
Реализация данных требований обычно не вызывает больших проблем, так как в большинстве организаций уже стоит какая-либо система антивирусной защиты. Реализация требований сводится к правильной настройке системы антивирусной защиты и механизмов протоколирования событий, а также, при необходимости, закупке дополнительных лицензий на серверы, так как в соответствии со стандартом все системные компоненты, потенциально подверженные вирусным атакам, требуют антивирусной защиты. Хотя на практике известны случаи, когда из-за падения производительности ввиду установки антивируса приходилось либо обновлять аппаратную часть серверов, либо менять антивирус на менее требовательный к ресурсам.
Требование 6: должна обеспечиваться безопасность при разработке и поддержке систем и приложений.
Данное обобщенное требование содержит 24 требования и 32 соответствующие им процедуры оценки, регламентирующие вопросы поддержки и обновления систем и регламентирующие вопросы разработки.
Реализация данных требований обычно вызывает серьезные сложности по ряду причин:
1) в большинстве российских компаний обновления безопасности на внутренние серверы, особенно на базы данных, практически никогда не ставились, так как, по мнению администраторов, безопасность обеспечивают внешние межсетевые экраны, а любое обновление может нарушить работоспособность системы, что чревато намного большими проблемами, чем гипотетический взлом. К сожалению, эту логику администраторов вполне понимают и злоумышленники. И, как правило, очень успешно используют уязвимость внутренних серверов для получения доступа к данным пластиковых карт;