Также в ходе разработки необходимо учитывать специальную технику и методы программирования, позволяющие избежать типовых уязвимостей, которые потом могут быть использованы злоумышленниками.
Для веб-приложений и этого недостаточно — для дополнительной защиты необходимо устанавливать специальные межсетевые экраны перед веб-серверами или проводить специализированные проверки кода ежегодно.
Реализация мер по строгому контролю доступаТребование 7: доступ к данным держателей карт должен быть ограничен в соответствии со служебной необходимостью.
Данное обобщенное требование содержит 7 требований и 7 соответствующих им процедур оценки, описывающих необходимость продумывания и документирования минимально достаточных прав доступа для выполнения той или иной работы сотрудникам, а также наличия системы контроля доступа, позволяющей реализовать задуманную политику минимально достаточного доступа.
Если в компании есть должностные инструкции и налажена система предоставления доступа через систему заявок, серьезных трудностей с реализацией этих требований обычно не возникает.
Требование 8: каждому лицу, имеющему доступ к вычислительным ресурсам, должен быть назначен уникальный идентификатор.
Данное обобщенное требование содержит 18 требований и 25 соответствующих им процедур оценки, обеспечивающих две важные задачи безопасности — обеспечение мониторинга действий каждого пользователя в любой системе и снижение риска несанкционированного доступа с использованием чужого пароля. Для этого описаны требования по:
• длине, сложности и частоте смены паролей;
• использованию двухфакторной аутентификации при удаленном доступе;
• автоматической блокировке сеансов работы в случае бездействия пользователя;
• хранению паролей в системах в нечитаемом виде;
• удалению неиспользуемых учетных записей;
• запрету прямого доступа к базам данных, содержащим данные платежных карт для всех пользователей, за исключением администраторов СУБД.
Большинство требований достаточно просто реализуются штатными средствами операционных систем и баз данных, а для повышения уверенности, что все системные компоненты будут настроены корректно, настройки, обеспечивающие выполнение этих требований, рекомендуется включать в стандарты конфигурирования (см. Требование 2).
Требование 9: физический доступ к данным держателей карт должен быть ограничен.
Данное обобщенное требование содержит 20 требований и 28 соответствующих им процедур оценки, регламентирующих вопросы физической защиты серверов и сетевого оборудования:
• систем видеонаблюдения и контроля доступа в помещения;
• визуальной идентификации посетителей;
• учета, контроля перемещения и защиты отчуждаемых носителей, содержащих данные платежных карт;
• уничтожения всех видов носителей защищаемой информации, включая жесткие диски, бумажные носители и магнитные ленты.
Обычно к моменту принятия решения о внедрении стандарта PCI DSS большинство требований данного раздела в банковской организации уже выполняется. Особенно в случае, если банк занимается выпуском платежных карт самостоятельно — ведь для выпуска платежных карт предъявлены намного более серьезные требования по физической защите помещений. Вместе с требованием 5 (антивирусная защита) это требование является наиболее простым и понятным в реализации. Особенно если сравнивать его с требованием 3 (защита данных платежных карт) и требованием 10 (протоколирование и мониторинг доступа).
Регулярный мониторинг и тестирование сетейТребование 10: должен отслеживаться и контролироваться любой доступ к сетевым ресурсам и данным держателей карт.
Данное обобщенное требование содержит 27 требований и 29 соответствующих им процедур оценки, регламентирующих вопросы протоколирования и мониторинга событий, включая особенности:
• перечня и состава протоколируемых событий;
• удаленного хранения и защиты собранных журналов аудита;
• синхронизации времени между источниками событий и системой мониторинга;
• периода хранения журналов аудита.
Практика показывает, что одна из самых серьезных проблем на пути к соответствию PCI DSS — организация процесса мониторинга событий ИБ. C точки зрения стандарта организовать процесс можно различными способами: централизованно/децентрализованно, средствами автоматизации или без оных и т. п. Для обычного российского банка, имеющего собственный процессинг, организация мониторинга событий информационной безопасности могла бы выглядеть так:
• сбор событий автоматизирован;
• мониторинг в рабочее время обеспечивает квалифицированный сотрудник из подразделения безопасности;
• в ночное время реагирование обеспечивается только на наиболее критичные события, которые поступают дежурному сотруднику и от которого не требуется знаний по ИБ, а требуется реагирование по инструкции (в норме задействуются уже существующие круглосуточные службы поддержки пользователей).
Необходимо отметить важные особенности системы мониторинга событий ИБ применительно к задачам обеспечения и поддержания соответствия стандарту.
1. В систему мониторинга должны собираться события ИБ от всех типов ресурсов в области действия стандарта:
• операционных систем серверов;
• СУБД;
• сетевое оборудование;
• веб-серверы (если используются для обработки карт);
• реже — прикладное ПО обработки карт, если имеющие к информационной безопасности события не регистрируются на других уровнях (например, добавляемая учетная запись не является учетной записью базы данных и выявить ее появление можно только в прикладных журналах или включая аудит на изменение пользовательской таблицы в базе данных).
2. Настройки протоколирования данных ресурсов должны обеспечивать регистрацию (а система мониторинга, в свою очередь, — сбор, обработку и хранение) всех типов событий, приведенных в п. 10.2.1- 10.2.7 стандарта PCI DSS (если имеют смысл для данного типа ресурса), а именно:
• доступ к данным платежных карт (специфично для каждой из форм хранения данных — либо файлы, либо объекты базы данных);
• успешное использование привилегированных административных полномочий и управление системными объектами (управление учетными записями и их правами, старт/остановка сервисов, конфигурирование сетевого оборудования, изменение параметров аудита, изменение протоколов аудита, изменение реестра операционной системы, изменение словарей и сегментов базы данных, создание/монтирование в операционной системе устройств/каналов и др.);
