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

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

Коротко о главном

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

Уведомлять регуляторов нужно в точные сроки: РКН — в течение 24 часов об утечке персональных данных и в течение 72 часов о результатах расследования; НКЦКИ (ГосСОПКА) — в течение 3 часов для значимых объектов КИИ и 24 часов для остальных. Доказательную базу собирают параллельно с реагированием; её юридическое значение зависит от того, как её документировали.

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

В этой статье

Что считается инцидентом информационной безопасности
Пять этапов реагирования на инцидент
Инсайдер как модель нарушителя: почему он опаснее
Как собрать доказательную базу для суда и трудовых споров
Сроки уведомления РКН и ГосСОПКА
Юридическое значение доказательств и ошибки при расследовании

Что такое инцидент информационной безопасности

Инцидент ИБ — это событие, при котором система безопасности информации нарушена или есть реальная угроза её нарушения. Три кита инцидента: конфиденциальность (данные утекли или могут утечь), целостность (информация изменена или может быть изменена) и доступность (сервис недоступен для пользователей).

Не каждое событие — инцидент. Забыл пароль — событие, потеря маршрутизатора с бэкапами — инцидент. Сотрудник три раза ошибся в пароле и заблокировался — событие, которое система отработала. Сотрудник получил доступ к данным, на которые не имеет прав — вот это уже инцидент, если даже он ничего не скопировал.

Инцидент = нарушение политики безопасности или угроза нарушения, требующие немедленного реагирования и документирования.

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

Пять этапов реагирования на инцидент

ГОСТ Р ИСО/МЭК ТО 18044-2007 определяет менеджмент инцидентов ИБ как итеративный процесс. На практике реагирование идёт так:

Этап 1. Обнаружение и оповещение (сразу)

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

Лайфхак: момент обнаружения — самый критический. Сразу же создавайте изолированную копию затронутого сервера или рабочей станции. Не перезагружайте, не очищайте память — отключите от сети и копируйте диск как есть. Живые логи и volatile data (содержимое оперативной памяти) исчезнут при перезагрузке, и восстановить их потом не удастся. Это основная ошибка внутренних IT-отделов: они перезагружают сервер, думая помочь, а на самом деле уничтожают главные улики.

Этап 2. Локализация (часы)

Цель: остановить распространение инцидента. Если скомпрометирован один сервер — его изолируют от сети. Если учётная запись инсайдера — блокируют доступ. Если вирус расползается по шести машинам — отключают все шесть. Локализация идёт параллельно со сбором доказательств: выключаете машину — но только после того, как сделали её снимок.

Этап 3. Устранение и восстановление (часы–дни)

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

Этап 4. Проверка и возврат в нормальное состояние (дни)

Мониторим восстановленные системы: нет ли повторного заражения? Логируется ли доступ? Нет ли новых аномалий? Только когда уверены, что инцидент локализован, возвращаем систему в production.

Этап 5. Разбор и внесение улучшений (недели–месяцы)

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

Инсайдер как модель нарушителя: почему он опаснее

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

Почему инсайдер опаснее:

Он уже внутри периметра. Все трудозатратные защиты (DDoS, фаерволл, выход в интернет) его не касаются. Нет нужды искать 0-day или социально инженировать администратора — уже есть учётная запись.
Знает системы. Знает, где живут ценные данные, какие системы слабо заводятся, кто хранит пароли на стикерах. Это даёт преимущество перед внешним нарушителем, который долго разведку должен проводить.
Может спрятать следы. Как системный администратор, инсайдер часто может редактировать или удалять логи, изменять временные метки файлов, отключать мониторинг. Потом никто и не узнает, что он делал.
Ему верят. Коллеги, руководство и система безопасности относятся к нему доверительнее, чем к неизвестному хакеру. Это психологическое преимущество: просит он логин-пароль соседа — получает без вопросов.

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

Предупреждение от бывалого: инсайдера часто не ловят, потому что ищут его в логах совсем не так. Если сотрудник имеет права на базу, то факт, что он её открыл, — норма. Аномалия — если он открыл её в 3 часа ночи, или если он скопировал 100 000 строк в одну минуту, или если он открыл данные, которые его должность не требует. Мониторьте именно это: когда доступ получен, сколько данных прошло, что за данные, кто это делает в непривычное время. Без поведенческого анализа инсайдер, который деньги за данные получает, просидит в компании годами.

Как собрать доказательную базу для суда и трудовых споров

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

Что собирать:

Логи системы. Полный лог событий безопасности, лог доступа, лог аутентификации с IP, с временем и учётной записью. Хранить в неизменяемом хранилище (SIEM, выделенный сервер, облако). Если лог находится на диске, который администратор может отредактировать, — это уже не доказательство.
Логи приложений. Если инцидент связан с конкретным приложением (база данных, CRM, финсистема), то логи приложения часто содержат больше деталей, чем системные. Кто подключился, какие операции выполнил, какие ошибки возникли.
Снимки дисков и памяти. Если компьютер скомпрометирован, снимок диска (forensic image) — основное доказательство. Его делают специалисты форензики, с цепочкой документирования и хешами MD5/SHA для подтверждения неизменяемости.
Видеозапись с видеокамер. Если физический доступ в серверную — видео время, человека и его действия. Суд воспринимает видео как веское доказательство, если камеры синхронизированы по времени.
Письменные показания свидетелей. Если сотрудник Y видел, как сотрудник X подходил к чужому компьютеру, это показание должно быть в письменном виде, датировано, подписано и нотариально удостоверено (если для суда). Устные показания — слабое доказательство.

Доказательства должны быть собраны, задокументированы и храниться в условиях, исключающих их изменение или подделку. Нарушение цепочки сохранности (chain of custody) — и судья отклонит их как недостоверные.

Как документировать цепочку сохранности:

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

Шаг 2. Если берёте снимок диска — используйте специальные утилиты (dd, FTK, Encase), которые считают хеш исходного диска и копии. Если хеши совпадают, копия точная и неизменённая. Документируйте: кто снимал, когда, какой инструмент, какой хеш.

Шаг 3. Логи, скопированные вручную, нужно хешировать (sha256) и хранить в виде файла с подписью. Если потом возникнут сомнения, вы сможете доказать, что логи не менялись с момента копирования.

Шаг 4. Если логи находятся на SIEM или облачном хранилище, документируйте, что система логирует неизменяемо (immutable logs). Проверьте, что восстановить или отредактировать старый лог невозможно даже администратору.

Сроки уведомления регуляторов: РКН и ГосСОПКА

Если инцидент затронул персональные данные или объект критической информационной инфраструктуры, уведомлять нужно в жёсткие сроки. Задержка = штраф по административному праву, даже если сам инцидент был незначительным.

Уведомление РКН об утечке персональных данных (ст. 21 ФЗ-152):

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

Уведомление подаётся через форму на сайте РКН (rkn.gov.ru) или почтой. Не уведомить в срок или уведомить невнятно — штраф на организацию от 5 000 до 150 000 рублей, а на руководителя — от 1 000 до 30 000 рублей (по ст. 13.11 КоАП РФ, редакция 2026 года).

Уведомление ГосСОПКА для объектов КИИ (ФЗ-187 от 26.07.2017):

Субъекты КИИ обязаны сообщать в НКЦКИ (Национальный координационный центр компьютерных инцидентов, оперирует ГосСОПКА) об инцидентах и компьютерных атаках:

3 часа — если затронут значимый объект КИИ (категория 1–2 по ПП РФ № 127).
24 часа — если затронут незначимый объект КИИ (категория 3) или произошла компьютерная атака.

Сообщение передают через ГосСОПКА (secure.gks.ru) или интегрированной системой. Невасилие сроков — штраф на организацию до 700 000 рублей, на руководителя до 60 000 рублей (ст. 274.1 УК РФ для критичных нарушений, или административное наказание при меньшей тяжести).

По факту: если инцидент привёл к утечке данных и вы собираются уволить виновного сотрудника, уведомьте РКН раньше, чем подадите приказ об увольнении. Почему? Потому что в судебных спорах по восстановлению на работе, во-первых, сотрудник может поспорить, что данные вообще не утекли, и попросить доказательства. Если РКН уже уведомлена официально, вы держите документ в руках. Во-вторых, сроки важны: явно задокументировано, что расследование было, помогает отбить иск об восстановлении, когда рабочий говорит «они на меня наговорили».

Типичные ошибки при расследовании инцидентов

Спешка и эмоции — враги хорошего расследования. Вот где обычно спотыкаются:

Затирают логи сразу. Сервер висит, вы его перезагружаете — и вся память с живыми логами и open connections стирается. Потом вы обнаруживаете, что логи на диске отключены или логируют недостаточно. Действуй ровно наоборот: сначала снимок, потом перезагрузка.
Дают инцидентнику сообщить. Кто-то обнаружил утечку, начальство сразу звонит в компанию, где была утечка, и говорит: «Ребята, у вас беда, там данные валяются». Нарушитель (если это инсайдер) тут же идёт чистить логи, удалять файлы, переписывается с сообщником. Расследование нужно держать в тайне: уведомляете полицию, ФСБ, РКН — но не самого виновного. Когда уходите в отдел кадров, уже с документами в руках.
Не вызывают форензиков. На критичном инциденте экономят на специалистах по компьютерной криминалистике. Потом пытаются восстановить удалённые файлы через условно-бесплатный софт, теряют файлы совсем. Форензики знают, что могут и чего не могут восстановить, а главное — как документировать процесс, чтобы судья поверил результатам.
Не фиксируют цепочку сохранности. Логи просто скопировали в Excell и послали по почте. Потом в суде адвокат скажет: «А откуда вы знаете, что эти логи подлинные? Никакого хеша, никаких подписей, их мог кто угодно изменить». И суд будет прав.
Ждут слишком долго с уведомлением РКН. Регулятор смотрит на задержку как на попытку скрыть инцидент. Штраф куда больше за задержку в 3 дня, чем за сам инцидент. РКН уведомляют первым делом, параллельно с расследованием, а потом 72 часа разбираетесь.
Полагаются на слова подозреваемого. «Я ничего не брал» — не доказательство. Доказательства — логи, видео, показания свидетелей, форензические анализы. Если это инсайдер, помните: он может врать, а его слова почти ничего не стоят без других улик.

Пошаговый план расследования

Шаг	Что делать	Сроки	Кто отвечает
1. Обнаружение	Зафиксировать время, место, характер инцидента. Создать первичный акт с фактами.	Немедленно	Тот, кто обнаружил + служба БИ
2. Локализация	Изолировать затронутые системы. Заблокировать компрометированные аккаунты. Создать снимок диска/памяти.	Первые часы	Администраторы, CISO
3. Сбор доказательств	Выгрузить логи (неизменяемо), видео с камер, показания свидетелей. Документировать цепочку сохранности.	1–2 дня	IT, служба БИ, форензики
4. Уведомление РКН (если ПДн)	Первичное уведомление об инциденте через РКН.	24 часа	Юридический отдел
5. Уведомление ГосСОПКА (если КИИ)	Уведомление в НКЦКИ через ГосСОПКА.	3 часа (значимые) / 24 часа (остальные)	Юридический отдел, CISO
6. Расследование	Поиск причины, вовлечённых лиц, масштаба компрометации. Интервью с подозреваемыми, свидетелями.	3–7 дней	Следователь / форензик + служба БИ
7. Уведомление РКН о результатах	Второе уведомление в РКН с результатами расследования и мерами.	72 часа от обнаружения	Юридический отдел
8. Восстановление	Чистка вредоноса / восстановление из бэкапов / пересборка систем.	1–4 недели	IT, инженеры
9. Разбор и улучшения	Постмортем-отчёт, изменения в политике, обучение сотрудников.	2–4 недели	CISO, руководство

Заключение

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

РКН смотрит на сроки: 24 часа на первое уведомление, 72 часа на результаты. ГосСОПКА смотрит на то, значим ли ваш объект КИИ: 3 часа для значимых, 24 часа для остальных. Не пропустите эти сроки — регулятор посчитает, что вы скрывали инцидент, и штраф будет в несколько раз больше. Поэтому расписание расследования должно быть синхронизировано с сроками уведомления с самого начала. Звучит сложно, но за практику всё встаёт на свои места: первый инцидент — хаос, второй — уже по процедуре, третий — режимная работа.

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

Чтобы инциденты не застали врасплох, используйте системы контроля и мониторинга — Staffcop позволяет выявить подозрительную активность до того, как она станет инцидентом, и сохранить все доказательства в неизменяемом виде.

Часто задаваемые вопросы

Инцидент произошёл, но данные не утекли — нужно ли уведомлять РКН?

Да, если инцидент привёл к несанкционированному доступу к персональным данным, даже если ничего не скопировали. РКН уведомляют в течение 24 часов об инциденте — это событие, а не результат. Если в процессе расследования выяснится, что доступ был, но данные не просочились, это уточните во втором уведомлении через 72 часа.

Что делать, если подозреваемый инсайдер отрицает всё?

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

Если инцидент критичный, нужно ли привлекать полицию или сразу в суд?

Критичность определяет, куда идти. Если компромет персональных данных (утечка, несанкционированный доступ) — это административное нарушение по ст. 13.11 КоАП (уведомляете РКН, штраф организации). Если украдены коммерческие тайны или хищение денег через информационные системы — это уголовное дело, идите в полицию (статьи 272, 273 УК РФ). Трудовой спор (увольнение после инцидента) идёт в трудовую инспекцию или суд. Обычно параллельно: РКН уведомляете в любом случае, полицию подключаете, если есть признаки преступления.

Сколько времени хранить логи для расследования?

ГОСТ Р ИСО/МЭК ТО 18044-2007 не устанавливает конкретный срок, но ст. 19 ФЗ-152 требует хранить журналы обработки персональных данных минимум три года. На практике: логи доступа и безопасности должны жить не менее года, а логи на серверах, где живут критичные данные, — минимум 3 года. Иначе при расследовании позже года вы просто не найдёте доказательства.

Можно ли уволить сотрудника за подозрение в инциденте, если доказательства неполные?

Нет. Суд потребует «предусмотренные законом доказательства», а подозрение — не доказательство. Если вы уволите без прямых улик, сотрудник выиграет иск о восстановлении и компенсации. Собирайте логи, видео, показания, форензику — пока доказательства не убедят вас самих, что он виноват, не трогайте его статус в компании. Исключение: если поведение сотрудника явно противоправно (попался на кражу, физический взлом), документируйте это и сразу в полицию, потом в суд.

Если логи нельзя восстановить, это значит, что инцидент не случился?

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

Если мы сами нашли инцидент и исправили раньше, чем начали расследование, штраф все равно?

Штраф за то, что инцидент был и попал на персональные данные — да, если не уведомили РКН в срок. РКН штрафует за неуведомление (ст. 13.11 КоАП), а не за сам инцидент. Быстрое обнаружение и контакт с РКН в течение 24 часов может смягчить санкции (суд видит, что организация подходила ответственно), но полностью избежать штрафа при утечке не получится. Поэтому главное — технические меры ПРЕДОТВРАЩЕНИЯ инцидентов, чтобы они вообще не происходили. Когда происходят — минимизируйте ущерб и уведомляйте в срок.