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