Безопасность карточного бизнеса - страница 50

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

Для веб-приложений и этого недостаточно — для дополнительной защиты необходимо устанавливать специальные межсетевые экраны перед веб-серверами или проводить специализированные проверки кода ежегодно.

Требование 7: доступ к данным держателей карт должен быть ограничен в соответствии со служебной необходимостью.

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

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

Требование 8: каждому лицу, имеющему доступ к вычислительным ресурсам, должен быть назначен уникальный идентификатор.

Данное обобщенное требование содержит 18 требований и 25 соответствующих им процедур оценки, обеспечивающих две важные задачи безопасности — обеспечение мониторинга действий каждого пользователя в любой системе и снижение риска несанкционированного доступа с использованием чужого пароля. Для этого описаны требования по:

• длине, сложности и частоте смены паролей;

• использованию двухфакторной аутентификации при удаленном доступе;

• автоматической блокировке сеансов работы в случае бездействия пользователя;

• хранению паролей в системах в нечитаемом виде;

• удалению неиспользуемых учетных записей;

• запрету прямого доступа к базам данных, содержащим данные платежных карт для всех пользователей, за исключением администраторов СУБД.

Большинство требований достаточно просто реализуются штатными средствами операционных систем и баз данных, а для повышения уверенности, что все системные компоненты будут настроены корректно, настройки, обеспечивающие выполнение этих требований, рекомендуется включать в стандарты конфигурирования (см. Требование 2).

Требование 9: физический доступ к данным держателей карт должен быть ограничен.

Данное обобщенное требование содержит 20 требований и 28 соответствующих им процедур оценки, регламентирующих вопросы физической защиты серверов и сетевого оборудования:

• систем видеонаблюдения и контроля доступа в помещения;

• визуальной идентификации посетителей;

• учета, контроля перемещения и защиты отчуждаемых носителей, содержащих данные платежных карт;

• уничтожения всех видов носителей защищаемой информации, включая жесткие диски, бумажные носители и магнитные ленты.

Обычно к моменту принятия решения о внедрении стандарта PCI DSS большинство требований данного раздела в банковской организации уже выполняется. Особенно в случае, если банк занимается выпуском платежных карт самостоятельно — ведь для выпуска платежных карт предъявлены намного более серьезные требования по физической защите помещений. Вместе с требованием 5 (антивирусная защита) это требование является наиболее простым и понятным в реализации. Особенно если сравнивать его с требованием 3 (защита данных платежных карт) и требованием 10 (протоколирование и мониторинг доступа).

Требование 10: должен отслеживаться и контролироваться любой доступ к сетевым ресурсам и данным держателей карт.

Данное обобщенное требование содержит 27 требований и 29 соответствующих им процедур оценки, регламентирующих вопросы протоколирования и мониторинга событий, включая особенности:

• перечня и состава протоколируемых событий;

• удаленного хранения и защиты собранных журналов аудита;

• синхронизации времени между источниками событий и системой мониторинга;

• периода хранения журналов аудита.

Практика показывает, что одна из самых серьезных проблем на пути к соответствию PCI DSS — организация процесса мониторинга событий ИБ. C точки зрения стандарта организовать процесс можно различными способами: централизованно/децентрализованно, средствами автоматизации или без оных и т. п. Для обычного российского банка, имеющего собственный процессинг, организация мониторинга событий информационной безопасности могла бы выглядеть так: