Журнал событий информационной безопасности ИСПДн
Единственный журнал комплекта, который не заполняет человек: записи в него делает сама информационная система. Обязанность организации здесь другая — обеспечить, чтобы записи были полными, читаемыми и неизменяемыми.
Зачем нужен документ
Журнал событий информационной безопасности выпадает из ряда остальных журналов комплекта. Обращения субъектов, выдачу паролей, пронос устройств записывает человек и записывает про других людей. Здесь записи делает система, автоматически, тысячами строк в сутки, и полный доступ к этому потоку имеет администратор — то же лицо, чьи собственные действия в нём и фиксируются.
Из этого разворачивается всё содержание документа. Ценность журнала событий не в том, что он есть: логи включены почти везде, потому что включены по умолчанию. Ценность в том, можно ли им верить в тот момент, когда они понадобятся. А понадобятся они ровно в одном случае — при разборе инцидента, где нужно установить, кто, когда и к каким данным получил доступ. Если к этому моменту записи могли быть изменены или удалены изнутри, разбор превращается в предположения.
Поэтому организация утверждает не «форму журнала» в привычном смысле, а требования к нему: обязательные атрибуты записи, глубину хранения, режим доступа, место, где лежит копия вне зоны влияния администратора, и порядок выгрузки для расследования. Это и есть документ.
Чем грозит отсутствие
Прямого штрафа за отсутствие журнала событий в законодательстве нет — регистрация событий безопасности предъявляется как мера защиты. Но последствие ощущается на сроке уведомления регулятора, а он наказывается отдельно и дорого.
Как ещё называют этот документ
Что должно быть в документе
Организация утверждает не графы, а требования к записям и к самому хранилищу.
Требования законодательства
Как связан с другими документами
Журнал событий — вход в цепочку реагирования, а не её финал.
Что спросит проверяющий
Журнал событий проверяют не на наличие, а на пригодность.
Разбор эксперта
С журналом событий связано редкое для комплекта заблуждение: считается, что он есть у всех. Формально так и есть — операционные системы и базы данных пишут события по умолчанию, галочка стоит, документ можно закрывать. Но вопрос к этому журналу задают всегда один и тот же и всегда постфактум: покажите, кто обращался к этим данным в прошлом месяце. И вот тут выясняется, что записи хранились неделю, лежали на том же сервере, который скомпрометирован, а очистить их мог тот же человек, чьи действия мы и хотим восстановить.
Именно поэтому мы советуем читать требование ФСТЭК целиком. Мера состоит из двух частей: регистрировать события и защищать сведения о них от удаления и изменения. Первую часть выполняет техника сама, вторую — только осознанное решение организации: вынести копию журналов за пределы сегмента, забрать право очистки у администратора системы и отдать чтение ответственному за безопасность. Пока эти три вещи не сделаны, журнал событий доказывает добросовестность, но не факты.
И совет, который экономит больше всего при реальном разборе, — про время. Инцидент почти никогда не виден в одной системе: часть следов в журнале входов, часть в базе, часть на шлюзе. Если часы этих трёх источников разъехались на минуты, последовательность событий не выстраивается, и вместо картины остаётся набор фрагментов, каждый из которых по отдельности ничего не доказывает. Синхронизация времени стоит один вечер работы и делается один раз, а без неё вся глубина хранения теряет половину смысла.
Задайте глубину хранения сознательно и обоснуйте её сроком, за который у вас реально обнаруживаются инциденты, — а не оставляйте значение по умолчанию. Настройте передачу записей на отдельный узел вне контура основной системы. Заберите право удаления и изменения журналов у тех, чьи действия в них фиксируются, оставив чтение ответственному за безопасность. Синхронизируйте время во всех источниках. Опишите порядок выгрузки для расследования с фиксацией самого факта выгрузки. И проверяйте раз в период, что записи поступают из всех заявленных источников: молчащий источник выглядит точно так же, как спокойный.
Александр КеллерманнГенеральный директор, ведущий аудитор ISO/IEC 27001, Комитет по информационной и правовой безопасностиПодробнее об экспертеЧастые вопросы
Журнал событий пишет система: это поток технических записей, из которого инцидент ещё предстоит увидеть. Журнал инцидентов ведёт человек и заносит туда уже признанные и разобранные случаи с последствиями и принятыми мерами.
Конкретный срок законодательство не устанавливает — его определяет организация. Ориентир простой: глубина хранения должна превышать типичное время обнаружения инцидента, поэтому для доступа к персональным данным разумно говорить о месяцах, а не о нескольких сутках, оставшихся от настроек по умолчанию.
Прямого предписания нет, но приказ ФСТЭК требует защищать сведения о событиях от удаления и изменения. Копия за пределами защищаемого сегмента — единственная мера, которая работает в сценарии, когда нарушитель получил права администратора на самой системе.
Не должен. Право очистки у того, чьи действия фиксируются, обесценивает журнал целиком: любая запись становится оспоримой. Разделение ролей здесь важнее любых технических средств.
Дата и время с часовым поясом, источник, учётная запись, объект доступа, тип события и его результат. Результат критичен: неудачные попытки доступа — самый ранний признак подбора, и без них журнал показывает только успешную часть картины.
Инцидент почти всегда виден в нескольких источниках сразу. При разных часах записи не выстраиваются в последовательность, и восстановить, что за чем следовало, невозможно даже при полной сохранности всех журналов.
Разбирать как инцидент: установить, было ли остановлено логирование, кем и когда, и сохранились ли записи в резервной копии. Пробел, замеченный через месяц, объяснить обычно уже нечем, поэтому контроль поступления записей должен быть регулярным.