А. Алексанов - Безопасность карточного бизнеса : бизнес-энциклопедия

• Название: Безопасность карточного бизнеса : бизнес-энциклопедия
• Автор: А. Алексанов
• Издательство: Московская финансово-промышленная академия; ЦИПСиР
• Жанр: О бизнесе популярно
• Год: 2012
• ISBN: 978-5-4257-0018-6

В книге дано подробное описание политики безопасности на всех этапах жизненного цикла банковской карты — от цеха, где производится пластиковая заготовка будущей карты, до торговой и сервисной сферы, где карта принимается к оплате. Отдельно рассмотрены международные стандарты PSI DSS и практика их применения. Дана классификация карточных рисков, изложена методика оценки рисков эмитента с использованием мониторинга карточных транзакций. Подробно описаны виды карточного мошенничества и методы его профилактики. Отдельные главы посвящены претензионной работе по операциям с банковскими картами и обеспечению безопасности процессингового центра. Проанализировано действующее российское законодательство, изложена судебная практика с подробным описанием уголовных дел, связанных с карточным мошенничеством, доведенных до суда. Даны общие рекомендации по информационной безопасности корпоративной системы банка как фундамента безопасности карточного бизнеса.

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

---

Требование 6: должна обеспечиваться безопасность при разработке и поддержке систем и приложений.

Данное обобщенное требование содержит 24 требования и 32 соответствующие им процедуры оценки, регламентирующие вопросы поддержки и обновления систем и регламентирующие вопросы разработки.

Реализация данных требований обычно вызывает серьезные сложности по ряду причин:

1) в большинстве российских компаний обновления безопасности на внутренние серверы, особенно на базы данных, практически никогда не ставились, так как, по мнению администраторов, безопасность обеспечивают внешние межсетевые экраны, а любое обновление может нарушить работоспособность системы, что чревато намного большими проблемами, чем гипотетический взлом. К сожалению, эту логику администраторов вполне понимают и злоумышленники. И, как правило, очень успешно используют уязвимость внутренних серверов для получения доступа к данным пластиковых карт;

2) вендоры прикладного программного обеспечения обычно тестируют совместимость своих приложений с обновлениями операционных систем и баз данных с достаточно большим опозданием, и чаще всего четко прописывают в контрактах на поддержку, с какой именно версией и какими обновлениями операционной системы и базы данных они готовы поддерживать свои приложения, чем ставят своих клиентов в очень неудобное положение — или выполняются требования стандарта, или теряется поддержка вендора для прикладных систем. Впрочем, стандарт безопасности для вендоров PA DSS частично позволяет решить эту проблему, обязывая вендора своевременно тестировать совместимость своих приложений с выходящими обновлениями безопасности.

Еще хуже ситуация обстоит с вопросами разработки программного обеспечения. Как правило, если мы говорим о банковской организации, разработка программного обеспечения для него носит характер побочной деятельности. Количество разработчиков обычно небольшое даже по сравнению с количеством ИТ персонала, поддерживающего системы. Когда ПО разрабатывается своими силами, как правило, процессы разработки не документируются, тестовые системы не выделяются в отдельный сегмент сети, сами разработчики принимают участие и в тестировании, и в поддержке систем, уже находящихся в эксплуатации. Все это является нарушением стандарта, требования которого предполагают наличие задокументированных процессов разработки, четко разделенных на стадии, в рамках каждой их которых учитываются вопросы обеспечения ИБ. Разработка и тестирование должны быть явно разделены, тестирование не должно проводиться на реальных номерах карт, изменения в программном обеспечении должны быть утверждены руководством — это лишь небольшая часть требований, которые не всегда выполняются даже в компаниях, профессионально разрабатывающих программное обеспечение, что уж тут говорить о банке с совершенно другой специализацией.

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

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

Реализация мер по строгому контролю доступа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Регулярный мониторинг и тестирование сетей

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

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

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

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

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

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

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

• сбор событий автоматизирован;

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

• в ночное время реагирование обеспечивается только на наиболее критичные события, которые поступают дежурному сотруднику и от которого не требуется знаний по ИБ, а требуется реагирование по инструкции (в норме задействуются уже существующие круглосуточные службы поддержки пользователей).

Необходимо отметить важные особенности системы мониторинга событий ИБ применительно к задачам обеспечения и поддержания соответствия стандарту.

1. В систему мониторинга должны собираться события ИБ от всех типов ресурсов в области действия стандарта:

• операционных систем серверов;

• СУБД;

• сетевое оборудование;

• веб-серверы (если используются для обработки карт);

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