Электронный документооборот
Учет и отчетность
Проверка контрагентов
Торговля и ритейл
Автоматизация бизнеса
Управление HR‑процессами
Участие в закупках
Коммуникации
Сделки с недвижимостью
Банковские услуги
Поиск клиентов
Маркировка товаров
Информационная безопасность
Админ
ID
Инцидент в ИБ — это всегда неудобно и некстати. В обычный день вдруг сыпятся алерты, «падают» сервисы, в почту приходит письмо с требованием выкупа. Здесь нужен ясный порядок действий и команда, которая знает, что нужно делать и кто за что отвечает. Расскажем, что действительно помогает сократить ущерб и вернуться к нормальной работе.
Как понять, что это уже инцидент
Признаки похожи у всех. Резко растет число операций с файлами на нескольких АРМ. В логах — нетипичные подключения. Пользовательские жалобы приходят пачками. Внутренние сервисы начинают «сыпаться» друг за другом. Любого признака из перечисленных достаточно, чтобы начать реагирование. Спорить о формальном определении бессмысленно. Лучше заранее закрепить эти маркеры в инструкции первой линии и на дашборде мониторинга, чтобы инженер не гадал, инцидент это или нет, а сразу звал координатора.
Что показывает практика
Реальные инциденты всегда происходят по-разному, но выводы у всех похожи. Ниже три истории, в которых важны не технические детали, а организационные решения, определившие исход.
Кейс 1. Спасение бухгалтерии
Поздно ночью в крупной торговой сети на дашборде телеметрии вспыхнули десятки алертов — пошёл лавинообразный рост операций с файлами в сегменте бухгалтерии. Сначала решили, что это плановая обработка архивов, но через пару минут в журналах появились странные подключения к сетевым ресурсам.
Координатор дал команду изолировать сегмент и отключить учетные записи, от которых шла активность. Дежурные инженеры нашли «нулевого пациента» — заражённый ноутбук сотрудника, получившего фишинговое письмо от «банка-партнёра». После изоляции и проверки резервных копий критичные сервисы — расчёт зарплаты, выгрузка в ФНС, взаимодействие с банком — восстановили за ночь. Наутро бизнес не заметил сбоя: зарплата ушла в срок. Вывод: заранее настроенная телеметрия, живые контакты и регулярные учения позволяют сэкономить часы и минимизировать ущерб.
Кейс 2. Быстрый рестор и второй удар
В производственной компании ночью зашифровались сервера 1С и документооборота. Администраторы, не проводя расследования, просто восстановили данные из резервных копий. Системы запустились, руководство выдохнуло. Однако через неделю — повторное шифрование. В планировщике осталась отложенная задача с запуском вредоноса, а у злоумышленников всё ещё были валидные учетные данные администратора домена. В итоге пришлось восстанавливаться из месячного бэкапа, теряя документы и заказы.
Вывод: рестор без анализа причин и локализации — это игра «на удачу». Сначала расследование, потом восстановление.
Кейс 3. Подрядчик с вечными правами
ИТ-подрядчик, помогавший с модернизацией CRM, имел «вечную» учётную запись с административными правами. Двухфакторная аутентификация не была включена, а логирование активности велось только частично. Через несколько месяцев после завершения проекта подрядчик уже не работал с компанией, но его учетка осталась активной. Через неё в инфраструктуру зашёл злоумышленник, получил доступ к клиентской базе и вывел её фрагменты в сеть. Расследование показало, что доступ использовался из зарубежного IP-адреса и что внутренняя служба безопасности даже не заметила подключения, потому что у подрядчика было разрешение на VPN.
После инцидента компания пересобрала матрицу доступов, включила MFA, ввела правило автоматического отключения учеток в день завершения договора и провела учения с участием всех подрядчиков.
Вывод: избыточные права и неотключенные учётки подрядчиков — одна из самых частых точек входа.
Сдержать и не потерять доказательства
Может быть дорогой ошибкой — перезагрузка «на авось». Кажется, что компьютер «очнётся», и всё станет лучше. На деле вы уничтожаете следы в памяти и может сломать картину произошедшего, а ещё хуже — может просто терять время на бесполезные действия. Правильный ход — изолировать машины от сети, не выключая питание. Проще всего вытащить интернет кабель, отключить WiFi. Это останавливает распространение по сети и сохраняет артефакты, а файлы на локальном компьютере, если вы уже обнаружили шифрование, — уже не спасти.
Дальше — фиксация. Кто сообщил, когда, какие алерты были, что видим в журналах событий, какие процессы запущены, какие файлы менялись. Скриншоты, выгрузки логов, контрольные суммы, единый журнал действий. Этот журнал потом выручит и в техническом разборе, и в разговорах с руководством, и при необходимости — с регуляторами и правоохранителями.
Параллельно координатор уведомляет руководителя о начале реагирования, чтобы обеспечить доступ к людям и ресурсам. Одновременно собирается минимальный штаб.
Важно: приведенный порядок действий не является универсальным. Реальные сроки реагирования и восстановления зависят от зрелости процессов и готовности команды. Чтобы разработать собственный план и провести учения, стоит привлечь специалистов по ИБ, знакомых с вашей инфраструктурой.
Кто в штабе
Один сильный админ инцидент не закрывает. Минимальный состав штаба выглядит так:
- Координатор — ведет процесс, ставит приоритеты, держит связь с руководством.
- Офицер ИБ – отвечает за работу с рисками,и как следствие с инцидентами. Эксперт в ИБ.
- Владельцы ключевых систем – отвечают за контекст и восстановление своих ИС.
- Администраторы — контролируют сети, серверы, домены, хранилища по зонам. Являются экспертами в ИТ.
- Юрист – оценивает обязательства по уведомлениям госструктур и фиксирует юридически значимые факты.
- PR или маркетинг — готовят внутренние и, при необходимости, внешние сообщения.
Работа строится короткими циклами. В конце каждого — короткий итог: что сделано, результаты, что делаем дальше, что мешает или требуется. Все действия заносятся в общий журнал. Важный принцип - восстановление из резервных копий только после локализации и сбора следов, а не вместо них. Иначе вредонос может вернутся отложенной задачей или сохранённым доступом.
Анти-кейс. После инцидента с шифрованием 1С компания «подняла» сервисы из вчерашнего бэкапа и успокоилась. Через неделю — повторное шифрование. В планировщике жил отложенный запуск, а валидные учётные данные у злоумышленников никто не отобрал. Пришлось откатиться на месячную копию. Итог простой — лишние расходы и испорченные нервы. Причина в том, что попытались починить все сразу без локализации и расследования инцидента.
План на первые дни
Первый этап. Отмечаем границы поражения. Изолируем сегменты сети и отдельные узлы. Блокируем скомпрометированные учетные записи и ключи. Собираем артефакты: логи, снимки, хэши, копии подозрительных файлов. Организуем отдельный защищённый канал связи штаба. Юрист параллельно оценивает, попадают ли произошедшие события под обязательные уведомления (для персональных данных и объектов КИИ).
Второй этап. Переходим к стабилизации. Поднимаем критичные процессы — из проверенных копий, с проверкой «чистоты» перед восстановлением. По плану меняем пароли и ключи, убираем лишние права, включаем дополнительный мониторинг на повторное проникновение. Внутреннее сообщение — коротко и по делу: что случилось, что уже сделано, что временно недоступно, куда обращаться, когда будет следующий апдейт.
Третий этап. Контрольная проверка сервисов и телеметрии. Закрываем «дыры», чтобы исключить повтор. Готовим отчет руководству: что произошло, какие меры приняты, что ещё предстоит сделать, каковы предварительные сроки. Назначаем ретроспективу с обязательным списком изменений: кто владелец каждого пункта и когда даст результат.
Юридическая часть: что обязательно учесть
В России есть несколько структур требующих обязательного набора действий. Например, самые популярные:
Персональные данные. Если инцидент затронул ПДн, оператор обязан оперативно уведомить Роскомнадзор. По факту события — в течение 24-х часов; в течение 72-х часов — о результатах внутреннего расследования. Чтобы уложиться в сроки, заранее проверьте, что у ответственного есть доступ к форме, что шаблоны уведомлений готовы, а маршрут согласования короткий. Нужны факты и четкие формулировки.
Критическая информационная инфраструктура. Для субъектов КИИ действует свое информирование через НКЦКИ — Национальный координационный центр по компьютерным инцидентам. Срок зависит от класса объекта и характера события, поэтому процедура должна быть отрепетирована: контакты, каналы связи, формат сообщения. Этим должен владеть не один человек «в курсе», а дежурная связка юрист + ИБ.
Игнорирование уведомлений оборачивается штрафами и затяжными проверками. Гораздо дешевле подать краткое, точное первичное сообщение в срок, чем потом оправдываться, почему не успели.
Что говорить вовне
В кризисе молчание может навредить больше, чем сам факт инцидента. Внешние сообщения делаются при осознанной необходимости, по четкой схеме:
что произошло – понятным языком, без технических деталей;
что уже сделано – меры по локализации и защите клиентов;
что будет дальше – расследование, дополнительные проверки, улучшения;
как себя могут защитить пользователи – поменять пароль, включить MFA, проверить активность;
когда ждать обновлений – четкие временные рамки.
Не обещать невозможных сроков, не сваливать всю вину на других и не давать противоречивых комментариев. Скорость, простота объяснений, ответственность, эмпатия и конкретные меры — именно эти элементы позволяют снизить панику и сохранить доверие.
Что нужно всегда проверять, а что проводить
- Актуальный лист команды реагирования: координатор, владельцы систем, юрист, PR, внешние эксперты.
- Роли: кто восстанавливает, кто расследует, кто коммуницирует.
- Прогон процедур уведомления (РКН, НКЦКИ): доступы, шаблоны, сроки.
- Бэкапы: частота, хранение, тест восстановления «на стенде» по расписанию.
- Доступы: убрать «вечные» учётки, сократить права, включить MFA.
- Сбор и хранение логов на критичных узлах: проверить, что пишутся и не затираются.
- Настольные учения раз в квартал с реальными сценариями и ретро по итогам.
- Короткий формат отчёта руководству: полстраницы фактов и сроки, а не роман.
Реагирование — это про дисциплину. Про то, что кто-то заранее проверил бэкапы, включил сбор логов, разложил роли, потренировал команду и удостоверился, что процедуры уведомления работают. Тогда в “час П”компания действует эффективно и не усиливает ущерб: быстро локализует, поднимает критичные сервисы, выполняет обязательства перед государством и клиентами, фиксирует уроки и встраивает их в процессы. Когда этого нет — обучение начинается в самый дорогой момент.
Информационная безопасность бизнеса
Контур.Эгида — сервисы информационной безопасности: уменьшение рисков внутренних угроз и утечек конфиденциальных данных, предотвращение атак злоумышленников.
