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

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

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

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

---

2. Настройки протоколирования данных ресурсов должны обеспечивать регистрацию (а система мониторинга, в свою очередь, — сбор, обработку и хранение) всех типов событий, приведенных в п. 10.2.1- 10.2.7 стандарта PCI DSS (если имеют смысл для данного типа ресурса), а именно:

• доступ к данным платежных карт (специфично для каждой из форм хранения данных — либо файлы, либо объекты базы данных);

• успешное использование привилегированных административных полномочий и управление системными объектами (управление учетными записями и их правами, старт/остановка сервисов, конфигурирование сетевого оборудования, изменение параметров аудита, изменение протоколов аудита, изменение реестра операционной системы, изменение словарей и сегментов базы данных, создание/монтирование в операционной системе устройств/каналов и др.);

• все события, связанные с работой систем аутентификации (успешный вход в систему, ошибки аутентификации пользователей, ошибки и сбои системы аутентификации);

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

3. В систему мониторинга должны также попадать сообщения от специализированных средств защиты (или мониторинг событий от них организуется децентрализованно):

• межсетевые экраны;

• IDS/IPS;

• средства антивирусной защиты;

• средства контроля целостности и др.

4. Должен обеспечиваться совокупный период хранения зарегистрированных событий информационной безопасности не менее одного года при включенном уровне протоколирования событий на источниках согласно требованиям 10.2.1-10.2.7 стандарта PCI DSS (см. пункт 2 данного списка). Если хранить такой объем событий в системе невозможно (в связи с их объемом и стоимостью хранилища), нужно продумывать решение по архивированию событий (в ручном или автоматическом режиме).

Требование 11: должно выполняться регулярное тестирование систем и процессов обеспечения безопасности.

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

• необходимость ежеквартального (или при изменении конфигурации сети или защищаемых серверов) внешнего сканирования с привлечением сертифицированной организации;

платежных систем и расчетов

• необходимость ежеквартального (или при изменении конфигурации сети или защищаемых серверов) внутреннего сканирования уязвимостей с использованием специальных программных средств;

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

• выявление несанкционированной активности в сети и/или изменения в файловых системах серверов;

• проведение ежегодных (или при изменении конфигурации сети или защищаемых серверов) внутренних и внешних тестов на проникновение.

Особенностью выполнения этих требований является то, что банку недостаточно просто провести сканирование или заказать тест на проникновение. Требование считается выполненным только в том случае, если в ходе тестирования/сканирования не было обнаружено серьезных уязвимостей. И при этом были протестированы все серверы/устройства и службы, которые входят в область применения стандарта. Более того, к моменту ежегодной проверки нужно показать, что на протяжении всего прошлого года своевременно проводились сканирования и оперативно устранялись уязвимости (в случае их наличия). Внутренние сканирования и тесты на проникновения могут проводиться любыми квалифицированными сотрудниками — как изнутри компании, так и приглашенными извне, тогда как внешнее сканирование должно проводиться сертифицированной компанией, имеющей статус Approved Scanning Vendor (ASV)[69].

Поддержание политики информационной безопасности

Требование 12: должна поддерживаться политика, регламентирующая деятельность всех сотрудников.

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

• наличие политики безопасности и процедур, описывающих типовые операции обеспечения защиты;

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

• наличие программы повышения осведомленности и обучения сотрудников в вопросах обеспечения защиты;

• проверку сотрудников на благонадежность перед принятием на работу;

• контроль договорных обязательств в части защиты при передаче данных платежных карт сторонним организациям;

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

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

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

Применение компенсационных мер

Применимость стандарта и подтверждение его соблюдения

Важной особенностью, необходимой для применения стандарта, является понимание различий между выполнением требований стандарта PCI DSS и подтверждением выполнения этих требований.

Сам по себе стандарт PCI DSS применим ко всем организациям, обрабатывающим или хранящим данные платежных карт (как минимум — PAN). Сюда входят и банки, выпускающие эти карты, и магазины (в том числе веб-сайты), принимающие эти карты к оплате, и многочисленные сервис-провайдеры, участвующие в этом процессе (платежные шлюзы, агрегаторы платежей и т. п.). Очевидно, что часть требований в том или ином случае просто неприменима: ну откуда, например, у маленького магазина с POS-терминалом возьмутся процессы разработки приложений?

При этом сам стандарт остается применимым. И вопросы, связанные, например, с контролем физического доступа к POS-терминалу, должны быть решены.

Итак, примем как факт, что если номера карт обращаются в системе — применимые требования PCI DSS нужно выполнять.

Теперь обратимся к требованиям платежных систем (в первую очередь VISA и MasterCard), ведь это именно они определяют, что компании должны делать, чтобы с ними работать.

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

У каждой платежной системы есть своя программа: для VISA — это Account Information Security (AIS) Programme[70], для MasterCard — это Site Data Protection (SDP) Program[71].

Программы немного различаются, но очевиден единый подход к оценке риска — чем больше данных платежных карт проходит через организацию, тем более жесткие требования к ее проверке на соответствие стандарту. При этом максимальный уровень проверки — это проведение ежегодного аудита с привлечением сертифицированного аудитора QSA, а также проведение ежеквартальных сканирований с привлечением сертифицированной компании ASV. Минимальный уровень проверки — это самостоятельное заполнение опросного листа или даже (в случае с MasterCard для торгово-сервисных организаций 3-го и 4-го уровней) отсутствие каких-либо требований (их определяет банк-эквайрер).

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

Итак, необходимо начать с области применения стандарта PCI DSS. Исходно стандарт PCI DSS разрабатывался в основном для крупных торгово-сервисных организаций (миллионы транзакций в год) и сервис-провайдеров и нацелен на снижение рисков утечки данных «чужих» платежных карт в рамках в основном процессов авторизации. Несмотря на это обстоятельство его требования должны выполнять любые компании, в которых происходит обработка, хранение или передача как минимум PAN.

Данную позицию Совет по безопасности PCI (PCI SSC) изложил в своем FAQ.

Сложности при выполнении требований стандарта испытывают банки, которые занимаются выпуском платежных карт, их системы, обеспечивающие выпуск карт (особенно в случае, когда они интегрированы с АБС). В большинстве случаев системы разрабатывались без оглядки на требования PCI DSS (такие, как шифрование PAN, протоколирование доступа к PAN и т. п.). Доработка существующих систем (или замена, что может быть даже дешевле) под выполнение требований по безопасности — задача затратная и по времени, и по ресурсам. И для бизнеса не совсем очевидная.