Жил-был Банк. И пришли к нему аудиторы, и сказали человеческим голосом: «недостаточный уровень протоколирования событий, а журналы с этими событиями тем более никто не смотрит, так что не будет тебе, Банк, сертификата PCI, а с ним и счастья». И пошел Банк к интегратору, и просил его принять в дар каменья драгоценные (сколько унести сможет), а взамен поставить ему волшебную шкатулку с заморским названием Security Information Management System (SIMS), в которую бы все что нужно собиралось, да ещё и заглядывать в ту шкатулку было удобно. На том и порешили. Долго ли коротко, интегратор внедрял-внедрял, да и внедрил. Банк глядит на шкатулочку и не нарадуется, как открывается не знает, но шибко ему нравится. Прошел год, снова тучи собираются, а вместе с ними и аудиторы гостями незваными. На шкатулку и глядеть не хотят, тычут в процедуры аудита, сертификат давать отказываются. И взмолился тогда Банк: «чего же вам, окаянные, ещё нужно?».

Грустная сказка, но, к сожалению, совершенно типовое развитие сюжета. Одна из самых серьезных проблем на пути к PCI DSS Compliance — организация процесса мониторинга событий ИБ. Сразу оговорюсь, что вообще организовать процесс можно как угодно, стандарт PCI DSS это напрямую не регламентирует (централизованно/децентрализовано, средствами автоматизации или без оных и т. п.). Например, в одном очень любимом мною процессинге для мониторинга событий ИБ выделена всего одна девушка с базовыми знаниями командной строки unix (назовем её Катя), которая запускает на сервере, куда по syslog кидаются все журналы, специально подготовленные для нее команды поиска подозрительных событий (в этом процессинге есть много мужчин, любящих unix и regexp). Катя, как и весь коллектив этого процессинга, отличается высокой исполнительской дисциплиной, поэтому я могу ручаться, что в строго положенное время в течение дня она будет запускать команды и вовремя сообщит начальству, если что-то найдет. Так вот, далее речь пойдет все же о других организациях, для которых реализовать этот процесс без специализированных средств автоматизации (SIMS) крайне затруднительно.
Модель построения процесса: сбор событий автоматизирован, мониторинг в рабочее время обеспечивает квалифицированный сотрудник из подразделения безопасности, в ночное время реагирование обеспечивается только на наиболее критичные события, которые поступает дежурному сотруднику, от которого не требуется знаний ИБ, а требуется реагирование по инструкции (в норме задействуются уже существующие круглосуточные службы). Что же нужно от системы?

Функциональные требования к SIMS

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

• ОС серверов
• СУБД;
• Сетевое оборудование;
• Web-серверы (если используются для обработки карт);
• Реже: Прикладное ПО обработки карт (если имеющие к информационной безопасности события не регистрируются на других уровнях, например добавляемая учетная запись не является учетной записью БД и выявить её появление можно только в прикладных журналах или включением аудита на изменение пользовательской таблицы в БД)

• Доступ к данным платежных карт (специфично для каждой из форм хранения данных - либо файлы, либо объекты базы данных).
• Успешное использование привилегированных административных полномочий и управление системными объектами (управление учетными записями и их правами, старт/остановка сервисов, конфигурирование сетевого оборудования, изменение параметров аудита, изменение протоколов аудита, изменение реестра ОС, изменение словарей и сегментов БД, создание/монтирование в ОС устройств/каналов и др.
• Все события, связанные с работой систем аутентификации (успешный вход в систему, ошибки аутентификации пользователей, ошибки и сбои системы аутентификации).
• Попытки использования отсутствующих привилегий, то есть ошибки логического доступа к объектам и функциям систем (например, пользователь БД пытается читать данные из словаря, чтобы узнать структуру БД, а прав на это у него нет)

• Межсетевые экраны;
• IDS/IPS;
• Средства антивирусной защиты;
• Средства контроля целостности и др.

Что нужно от интегратора?

1. Согласовать/определить с заказчиком, какими средствами обеспечивается полнота регистрируемых событий для каждого типа ресурса. В случае, если заказчик к моменту внедрения не имеет представления, как обеспечить необходимый уровень протоколирования на ресурсах, очень вероятно, что он может захотеть включить эту работу в ТЗ интегратору. Тогда определение необходимых для этого настроек подсистем аудита -тоже задача интегратора.
2. Проработать схемы, по которым ВСЕ эти события смогут попасть в хранилище системы или в явном виде обозначить заказчику, что определенные типы событий не смогут обрабатываться централизованно.
3. Сделать сайзинг с учетом предполагаемого объема событий и наличия функционала системы по архивированию
4. Дальше лирика про поставку, установку ядра и прочее — не интересно совершенно
5. Подключить как минимум по одному ресурсу КАЖДОГО типа (проверив сбор согласно 10.2)
6. Обеспечить работоспособность остального функционала — тоже не специфично для PCI
7. Продемонстрировать в рамках приемочных испытаний, что:

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

Что нужно от заказчика?

1. Бюджет и перечень ресурсов, на которые распространяются требования PCI DSS
2. Включить в ТЗ интегратору функциональные требования и требования к составу работ, приведенные выше
3. Настроить подсистемы аудита собственных ресурсов
4. Сформулировать критерии выявления инцидентов (или и это тоже поручить интегратору)
5. Проверить, что в ПИМ включили проверку всех функциональных требований и, желательно, проверку срабатывания системы по сформулированным критериям выявления инцидентов. Если нет уверенности, что все понимаете правильно -позовите для проверки аудиторов.
6. Ну дальше неспецифично для PCI: приемочные испытания и все… можно наконец пользоваться.

Выводы

Для тех, кто осилил этот текст и не заснул, сухой остаток: чем лучше вы сами знаете для чего конкретно внедряете систему и чем точнее поставите эту задачу интегратору, тем меньше будет неоправданных ожиданий после аудита. От выбранного ПО это зависит мало.

Анна Гольдштейн