Журнал "Information Security/ Информационная безопасность" #1, 2026

• 63 УПРАВЛЕНИЕ www.itsec.ru претерпело серьезные изменения. Теперь факт киберинцидента может быть связан с риском банкротства ком- пании. Конечно же речь идет об оборот- ных штрафах, которые в случае нало- жения на средний и мелкий бизнес могут существенно повлиять на результаты финансово-хозяйственной деятельности компании. Почему разваливаются расследования киберинцидентов? В профессиональной среде существу- ет устойчивый миф: если атака очевид- на, значит виновный будет найден и наказан. На практике всё наоборот – подавляющее большинство киберинци- дентов, даже в случае заинтересован- ности организации, никогда не заканчи- вается судебным решением. Причина почти всегда одна и та же: событие про- изошло, но юридически доказано не было. С точки зрения права мало установить факт атаки. Необходимо доказать, что: l событие действительно имело место, l оно произошло в конкретное время, l действия совершил конкретный субъ- ект, l именно эти действия привели к последствиям, l доказательства получены допустимым способом. Именно последний пункт чаще всего разрушает расследование. Типичные действия службы ИБ после обнаружения атаки (события ИБ): l удаляют вредоносные файлы, l блокируют учетные записи, l перезапускают сервисы, l восстанавливают систему из резерв- ной копии. Инфраструктура спасена, бизнес дово- лен, инцидент закрыт. Но в правовом смысле произошло следующее – доказательства уничтоже- ны самой пострадавшей стороной: l невозможно провести компьютерно- техническую экспертизу, l невозможно установить способ про- никновения, l невозможно доказать причинно-след- ственную связь, l невозможно доказать вину конкрет- ного лица. А, значит, нет состава правонарушения. Таким образом, большинство киберин- цидентов не раскрываются из-за некор- ректной фиксации доказательств в про- цессе реагирования и расследования. В любой организации в процессе реа- гирования на киберинциедент одновре- менно существуют три цели: 1. Цель подразделения ИТ – восста- новить работу. 2. Цель подразделения ИБ – остано- вить атаку. 3. Цель юридического отдела – дока- зать факт нарушения. Проблема в том, что эти цели проти- воречат друг другу: l Чем быстрее восстанавливается система – тем меньше остается доказа- тельств. l Чем тщательнее фиксируются дока- зательства – тем дольше простой. l Юридически корректное реагирова- ние всегда замедляет восстановление сервиса. Поэтому киберинцидент – не только тех- ническое, но и управленческое решение. Руководство (в т.ч. при участии под- разделения ИБ) должно заранее опре- делить приоритет: l немедленное восстановление, l расследование, l уголовное преследование, l страховое возмещение. Без этого решения служба ИБ оказы- вается в ситуации, когда любое действие потенциально ошибочно. Рекомендации для ИБ-подразделений Для того чтобы киберинцидент пра- вильно отработал в правовом поле, необходимо: l Создать положение (регламент) об инцидентах: юридически закрепить, что является инцидентом в конкретной орга- низации с учетом требований действую- щего законодательства и стандартов. l Синхронизировать регламенты: тех- нический план реагирования должен содержать шаги по юридической фик- сации (подключение юридической служ- бы, уведомление регулятора). Когда инцидент зафиксирован, дей- ствия службы ИБ должны быть строго регламентированы, чтобы минимизиро- вать юридические последствия. Фиксация времени обнаружения – отправная точка для всех сроков давности: l Уведомление в адрес НКЦКИ: для значимых объектов КИИ – в течение 3 часов, для иных объектов КИИ – в течение 24 часов. l Уведомление в адрес Роскомнадзора: в течение 24 часов при утечке персо- нальных данных. l Внутреннее расследование: 72 часа, чтобы предоставить регулятору резуль- таты первичного расследования. Чтобы цифровые следы стали дока- зательствами, они должны обладать ключевым свойством – неизменностью. В праве важен не сам файл журнала событий (лога), а возможность доказать, что он существовал в конкретный момент времени и не изменялся после обнару- жения. Для этого используется принцип цепоч- ки хранения доказательств – это доку- ментированная история существования цифрового артефакта от момента обна- ружения до представления в суде. Фиксируется: l кто обнаружил инцидент; l где именно он обнаружен (узел, IP, система); l точное время (с указанием источника синхронизации); l кто производил копирование; l каким инструментом; l контрольные суммы; l где хранится оригинал; l кто имел доступ. Если это правило нарушено, то дока- зательство становится недопустимым независимо от его содержания. В заключении еще раз обратим вни- мание, что компьютерный инцидент в организации – это одновременно техни- ческое событие и юридически значимое обстоятельство. От того, как именно компания реагирует в первые часы, зависит не только восстановление рабо- ты, но и возможность доказать факт нарушения, привлечь виновных к ответ- ственности, получить страховую выплату или избежать штрафа регулятора. Поэтому процедуры реагирования должны учитывать не только остановку атаки и восстановление сервисов, но и сохранение доказательств: фиксацию времени, неизменность логов, коррект- ное уведомление регуляторов и участие юридической службы с момента обна- ружения. Такой подход не усложняет работу службы ИБ, а заранее определяет прио- ритеты: какие действия допустимы сразу, а какие – только после фиксации. В результате инцидент становится управ- ляемым процессом с прогнозируемыми правовыми последствиями. l Рисунок: Гротек Ваше мнение и вопросы присылайте по адресу is@groteck.ru