Правила ведения журналов событий информационной безопасности ИСПДн

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

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

Статусобязательный при обработке ПДн в ИСПДн Основаниеч. 2 ст. 19 152-ФЗ, приказ ФСТЭК № 21 Публичностьвнутренний Кто утверждаетруководитель организации Обновленоиюль 2026 Периодичностьконтроль поступления — не реже раза в неделю

Содержание

01 Назначение

Зачем нужен документ

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

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

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

Требования к самим записям — атрибуты, глубина хранения, защита от изменения — в карточке журнала событий ИБ, а состав фиксируемых событий — в перечне регистрируемых событий.

02 Ответственность

Чем грозит отсутствие

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

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

Просрочка уведомления идёт от неспособности разобраться. На уведомление регулятора об утечке отведены сутки с момента выявления, а ответственность за просрочку по ч. 11 ст. 13.11 КоАП начинается с миллиона рублей для организации. Разбор по неполным журналам растягивается на дни.

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

Формулировки составов и суммы разбираются в карточке журнала событий ИБ — повторять их здесь не имеет смысла. Ценность правил ведения в другом: они единственные отвечают за то, чтобы к моменту разбора записи существовали.

03 Синонимы и поисковые названия

Как ещё называют этот документ

—Порядок ведения журналов событий безопасности

—Правила работы с логами ИСПДн — образец

—Как контролировать, что логирование работает

—Регламент просмотра журналов аудита

—Порядок действий при переполнении журнала событий

—Настройка ротации логов и синхронизация времени

—Кто отвечает за журналы событий информационной безопасности

—Что делать, если логи перестали собираться

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

04 Обязательное содержание

Что должно быть в документе

Каждый пункт закрывает конкретный способ остаться без записей в нужный момент.

Закреплённый перечень источников. Приложением к правилам: какие системы, серверы и средства защиты поставляют события. Без списка проверять нечего — молчащий источник не с чем сравнить.

Ответственный и его заместитель. Названы должности, а не фамилии. Контроль поступления не имеет естественного триггера: если он не закреплён за человеком, его не делает никто.

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

Молчание источника разбирается как инцидент. Отдельный пункт со сроком реакции: установить причину, восстановить сбор, оценить, какой период остался без записей, и зафиксировать этот пробел.

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

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

Порядок просмотра. Кто, с какой периодичностью и что именно смотрит — сводку, выборку по критичным событиям, отказы доступа. С фиксацией факта просмотра: без неё дисциплина держится ровно до первой занятой недели.

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

Обязательная проверка после изменений в системе. Обновление, миграция, замена сервера — и следом контрольная проверка, что все источники снова поставляют записи. Именно здесь теряется сбор чаще всего.

05 Правовая база

Требования законодательства

ч. 2 ст. 19 152-ФЗмеры защиты, включая обнаружение фактов несанкционированного доступа к персональным данным

приказ ФСТЭК № 21группа РСБ: регистрация событий безопасности, мониторинг записей и реагирование на сбои регистрации

ПП РФ № 1119уровень защищённости задаёт состав обязательных мер

ч. 3.1 ст. 21 152-ФЗсрок уведомления регулятора идёт с момента ВЫЯВЛЕНИЯ

В требованиях ФСТЭК есть отдельная мера — реагирование на сбои при регистрации событий безопасности. Её обычно читают как «настроить оповещение об ошибках», но на практике сбой сбора почти никогда не выглядит ошибкой: процесс не падает, он просто перестаёт получать данные. Поэтому проверять надо не наличие ошибок, а наличие записей от каждого источника — и это то, ради чего правила вообще пишутся.

06 Связи в комплекте

Как связан с другими документами

Правила обслуживают журнал событий и открывают цепочку реагирования.

Журнал событий — объект правил. Журнал задаёт требования к записям и хранению, правила — к работоспособности их сбора.

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

Регламент реагирования — продолжение. Признак инцидента, замеченный при просмотре, передаётся по регламенту реагирования, и с этого момента идут сроки.

Внутренний контроль закрепляет периодичность. Еженедельная проверка поступления и ежеквартальная сверка полноты источников встают в план внутреннего контроля с датой и ответственным.

07 Проверка

Что спросит проверяющий

Проверяют не текст правил, а следы их исполнения.

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

Покажите результаты последних проверок. Смотрят, ведётся ли фиксация контроля и есть ли в ней разрывы. Отсутствие записей о проверках приравнивается к отсутствию проверок.

Что произошло после последнего обновления. Сопоставляют даты изменений в системе с первыми записями каждого источника после них. Источник, замолчавший после обновления, — типичная и очень частая находка.

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

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

08 Разбор эксперта

Разбор эксперта

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

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

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

Что мы советуем при подготовке комплекта

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

Александр КеллерманнГенеральный директор, ведущий аудитор ISO/IEC 27001, Комитет по информационной и правовой безопасностиПодробнее об эксперте

09 Частые вопросы

Частые вопросы

Чем эти правила отличаются от требований к самому журналу событий?

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

Как часто проверять, что логирование работает?

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

Почему нельзя ориентироваться на ошибки в мониторинге?

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

Что делать, если источник перестал присылать события?

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

Перезаписывать старые записи при заполнении диска или останавливать систему?

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

Нужно ли просматривать журналы событий вручную?

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

Кто может менять настройки логирования?

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

Связанные документы

Журнал событий информационной безопасности ИСПДнЖурналы учёта Перечень регистрируемых событий информационной безопасности ИСПДнПеречни, матрицы, схемы Регламент реагирования на инциденты информационной безопасностиИнструкции и регламенты

Все документы комплекта

Правила ведения журналов событий — одна из 139 позиций комплекта

Эксперты Комитета разрабатывают комплект под фактическую деятельность организации. Проверьте бесплатно, какие документы обязательны для вас, — по ИНН, за минуту.

или по телефону +7 (812) 240-81-66