Регламент регистрации событий безопасности

Журнал событий безопасности редко используют в спокойном режиме — его читают, когда уже произошёл инцидент: подозрение на утечку, обращение субъекта персональных данных с претензией, внешняя проверка. В этот момент журнал становится единственным источником фактов: кто заходил в систему, кто выгружал данные, кто менял настройки доступа.

Обязанность вести учёт действий с персональными данными вытекает из общей обязанности оператора обеспечивать их безопасность по статье 19 закона 152-ФЗ. Регламент нужен не для того, чтобы просто «включить логирование», а чтобы заранее решить, какие события важны именно для вашей системы, кто их смотрит и что происходит, если в журнале обнаружено что-то подозрительное.

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

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

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

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

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

Журнал, который никто не читает, выполняет функцию только на бумаге. Регламент должен назвать ответственного за периодический просмотр записей — это не обязательно отдельный специалист по информационной безопасности, в небольшой компании эту роль может выполнять администратор системы или руководитель ИТ-направления по совместительству.

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

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

Типичные замечания при проверке журнала событий:

• журнал есть, но никто не может объяснить, кто должен его смотреть и что делать с находками;
• техническое средство логирования настроено «по умолчанию» и фиксирует стандартный набор событий, не соотнесённый с реальными рисками ИСПДн;
• по записям журнала нельзя быстро определить конкретного пользователя и конкретное действие без ручного сопоставления нескольких источников.

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