Google+
Журнал Плас Плас Журнал http://www.plusworld.ru/
ул. Кржижановского, д. 29, корп. 5 Москва, 117218 Россия
+7 495 961 1065 http://www.plusworld.ru/upload/templates/logo_plus_ru.png
RSS RSS RSS RSS

Соответствие стандарту PCI DSS: журналы регистрации событий

(Нет голосов)

12.10.2012 Количество просмотров 1760 просмотров

Павел Федоров, руководитель департамента аудита банков и платежных систем компании Digital Security

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


Во-первых, журналы регистрации событий должны содержать полную информацию о том, кто и когда работал с инфраструктурой и получал доступ к данным держателей карт. Во-вторых, они должны быть достаточно понятны, прозрачны и доступны для ручного или автоматического изучения – иначе даже наличие логов за несколько месяцев вовсе не гарантирует, что ими можно будет воспользоваться для анализа событий, произошедших в IT-инфраструктуре, обрабатывающей карточные данные. 
 
Все сотрудники, имеющие отношение к данной инфраструктуре, делятся на три группы: пользователи, администраторы систем и офицеры безопасности. Задача последних – контролировать действия первых двух групп, при этом необязательно, чтобы у офицеров безопасности был непосредственный доступ к самой инфраструктуре. Однако доступом к журналам офицеры безопасности должны обладать непременно, в отличие от администраторов, имеющих доступ к данным держателей карт. Такое распределение полномочий необходимо для того, чтобы исключить возможность скрытого изменения журналов администратором-злоумышленником. В крупных организациях эта задача решается достаточно легко: в том случае, если администраторами процессинга являются не все системные администраторы организации, сервер, хранящий журналы, легко вывести из-под контроля процессинга. В небольших же компаниях рекомендуется ограничивать доступ системного администратора к серверу, содержащему все журналы, и тщательно отслеживать все производимые изменения.
 
Регулярная проблема на практике: у администратора есть возможность фальсифицировать данные! 

Журналы должны собираться со всего оборудования, входящего в область применения стандарта: с операционных систем серверов, с управляемого сетевого оборудования, со всех мест хранения данных, а также со всего программного обеспечения, обеспечивающего доступ к карточным данным. 
 
Проблема на практике: журналы собираются только с операционных систем!

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

 Регулярная проблема на практике:

1)      администраторы отключают аудит СУБД из-за огромного объема данных; 2) иногда журналы содержат номера карт!

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

Регулярная проблема на практике: гипервизоры исключаются из области применения!

Также журналы должны вестись дополнительными системами безопасности: «антивирусом», системой обнаружения вторжений, системой контроля целостности. Последняя должна отслеживать не только конфигурационные файлы, но и сами журналы (в том числе свои собственные).

Проблема на практике: система контроля целостности не проверяет журналы!

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

Проблема на практике: многие администраторы не понимают целей настройки NTP на дополнительных устройствах, и те остаются «жить» в «своем собственном» времени!

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

 Регулярная проблема на практике: датчики СКУД не синхронизированы с инфраструктурой, возникает сдвиг по времени!

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

Проблема на практике: очень часто фиксируется слишком много «нарушений», по факту такими не являющихся.

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

 Проблема на практике: «мы только настроили это оборудование, журналы с него будем собирать через пару недель, если оно нас устроит»!

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

Регулярная проблема на практике: отсутствует или недостаточно настроена система активного оповещения!

 Следует понимать, что во время аудита безопасности, даже при достаточно небольшой инфраструктуре, попытка убедить QSA-аудитора в том, что анализ журналов проводится «вручную», может оказаться неуспешной: очевидно, что просматривать ежедневно несколько мегабайт логов – задача не только непростая, но и утомительная. С другой стороны, полностью полагаться на автоматизацию также не стоит – периодически следует изучать журналы и «вручную», а также проверять срабатывание системы оповещения, создавая заведомо критические ситуации, чтобы убедиться, что все события успешно отслеживаются.

Регулярная проблема на практике: система формально настроена, но отлавливает далеко не все события!

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

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

Проблема на практике: в журналах хранятся номера карт, потому что их оттуда не вычищают или так сложилось исторически!

А если в наличии номеров карт в журналах и возникнет производственная необходимость – например, для срочной отладки, – необходимо обеспечить безопасность места хранения этих журналов, например, направив их в криптоконтейнер или на RAM-диск.


Комментарии (0):

Добавлять комментарии могут только зарегистрированные Пользователи


Читайте в этом номере:
обновить

а вы знаете, что...

… первым в мире банкоматом с использованием технологии cash-ресайклинга был выпущенный на японский рынок в 1982 г. аппарат OKI AT 100?