Реагирование на инциденты: роли, SLA, метрики и порядок действий

Около 20% российских компаний уже взломаны и не знают об этом. И это при том, что средства защиты стоят практически у всех. Такую оценку дают эксперты BI.ZONE, уточняя, что средний ущерб от одной атаки составляет не менее 50 млн рублей.

Причина потерь – «слепая зона» между моментом, когда ИБ-система фиксирует угрозу, и моментом, когда специалист начинает действовать. Единственный способ ликвидировать этот разрыв – выстроить системное реагирование на инциденты.

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

Что такое реагирование на инциденты и чем инцидент отличается от атаки

Реагирование на инциденты – это управляемая последовательность действий от момента обнаружения признака нарушения до момента, когда работоспособность систем восстановлена, установлены причины инцидента и зафиксированы материалы о случившемся. Ключевым в этом определении является слово «управляемая». Набор разрозненных действий дежурного инженера процессом не считается, потому что его нельзя ни повторить, ни измерить, ни предъявить регулятору.

Согласно 187-ФЗ, компьютерная атака – это целенаправленное воздействие на объекты критической информационной инфраструктуры, а компьютерный инцидент – факт нарушения или прекращения работы объекта, в том числе произошедший в результате атаки.

Проще говоря, атака – это то, что делает злоумышленник, а инцидент – это возникшее у вас последствие.

Таблица 1. Различия между компьютерной атакой и компьютерным инцидентом

В отраслевых документах формулировки различаются, и на практике их часто используют как синонимы. «Реагирование на компьютерные инциденты» – это термин из ГОСТов и приказов ФСБ, привязанный к КИИ и ГосСОПКА. Во внутренних регламентах процесс чаще называют «реагированием на инциденты безопасности» или «реагированием на инциденты информационной безопасности»: эта формулировка шире и покрывает любые нарушения конфиденциальности, целостности или доступности. 

Смысл у всех этих терминов единый: вовремя обнаружить угрозу, локализовать ущерб, восстановить системы и провести расследование.

Еще одно различие экономит команде часы. Событием ИБ считают любую запись в журнале, которая теоретически может указывать на проблему, а инцидентом – подтвержденное событие или группу событий, по которым принято решение реагировать. Между ними стоит триаж, и именно на нем отсеиваются ложные срабатывания. Компания, где инцидентом называют каждое сработавшее правило корреляции, обречена на метрики, которыми невозможно управлять.

Почему выявление инцидентов и реагирование на них решают больше, чем защита периметра?

Защита периметра отвечает на вопрос «пустить или не пустить», а реагирование – на вопрос «что делать, когда уже пустили». Второй вопрос возникает у всех, потому что абсолютной защиты не бывает, и эксплойты остаются вектором первичного доступа №1 шестой год подряд. Выявление инцидентов и реагирование на них определяют не факт взлома, а его цену.

Отчет M-Trends 2026 дает медиану глобального dwell time, то есть времени незамеченного присутствия нападающего в инфраструктуре, на уровне 14 дней против 11 годом ранее. Самостоятельно обнаружили вредоносную активность 52% организаций, а остальные 48% узнали о ней снаружи – от партнера, правоохранителей или от самих вымогателей.

Одна цифра лучше всего объясняет, почему ручной процесс перестал работать. Медианное время передачи доступа от группы первичного доступа к оператору-вымогателю составило в 2025 году 22 секунды, тогда как в 2022 году на ту же передачу уходило больше восьми часов. Пока по почте идет согласование, шифрование уже началось.

Экономика этого разрыва считается просто: по оценке BI.ZONE, средний ущерб от одной успешной кибератаки на российскую компанию составляет не менее 50 млн рублей.

Сверху добавляется регуляторная нагрузка, потому что пропущенный срок уведомления превращает технический инцидент в административное дело. С какими именно угрозами российский бизнес сталкивается чаще всего, мы разбирали в материале Топ-10 актуальных киберугроз для сектора B2B.

Что требуют регуляторы в 2026 году?

В конце декабря 2025 года подписана серия новых нормативных актов ФСБ России, разработанных во исполнение Федерального закона от 7 апреля 2025 г. № 58-ФЗ «О внесении изменений в Федеральный закон «О безопасности критической информационной инфраструктуры Российской Федерации» и направленных на регулирование взаимодействия в области ГосСОПКА. 

Для государственных информационных систем (ГИС) процесс реагирования и расследования компьютерных инцидентов дополнительно регламентируется ГОСТ Р 59712-2022, а также требованиями Приказа ФСТЭК России № 117.

В новый пакет вошли следующие приказы ФСБ:

• № 539: устанавливает порядок получения субъектами КИИ информации о средствах и способах проведения компьютерных атак и о методах их предупреждения и обнаружения. 
• № 540: корректирует положение о НКЦКИ, расширяет полномочия НКЦКИ, дополняет его задачи.
• № 546: корректирует порядок обмена информацией о компьютерных атаках и компьютерных инцидентах между субъектами КИИ внутри страны, а также между субъектами КИИ и зарубежными организациями, осуществляющими деятельность в области реагирования на компьютерные инциденты.
• № 547: устанавливает порядок и сроки уведомления ФСБ России о компьютерных атаках и компьютерных инцидентах.
• № 548: устанавливает правила непрерывного взаимодействия с системой ГосСОПКА для субъектов, которым принадлежат значимые объекты КИИ, а также для руководителей органов и организаций.
• № 553: утверждает новый порядок и технические условия установки и эксплуатации средств ГосСОПКА субъектами КИИ, а также государственными органами, предприятиями, корпорациями и иными российскими юрлицами.
• № 554: утверждает обновленные требования к средствам ГосСОПКА.

Приказ ФСБ России № 367 от 24.07.2018, который задает перечень представляемых в ГосСОПКА сведений и порядок их представления, в этот пакет не попал и продолжает действовать, поэтому сроки уведомления берутся именно из него.

Ниже приведены сводные матрицы сроков, по которым надо сверять внутренние регламенты:  

1. Для субъектов КИИ

2. Для операторов персональных данных

Три часа задают норматив, под который проектируется дежурная смена. Отсчет идет от обнаружения, а не от завершения расследования, поэтому уведомление уходит с неполной картиной и дополняется позже. Команды, которые ждут ясности перед отправкой, срок пропускают почти всегда.

Отдельный блок требований применяется к персональным данным. С 30 мая 2025 года действует 420-ФЗ, в соответствии с которым в статью 13.11 КоАП добавлены части 10-18. Пороги считаются по числу субъектов и идентификаторов в утекшей базе. За повторное нарушение предусмотрен оборотный штраф от 1 до 3% годовой выручки с верхней границей 500 млн рублей. Наличие работающего процесса и своевременное уведомление учитываются при определении санкции. Требования к самому хранению данных мы разбирали в материале Обработка и хранение персональных данных.

Соответствие требованиям начинается с площадки, ведь часть требований к защите инфраструктуры заказчик наследует от провайдера. Аттестованные сегменты, сертификации платформы и встроенные сервисы мониторинга снимают с команды тот объем работ, который иначе пришлось бы закрывать своими силами и проходить проверку с нуля. Облачные сервисы K2 Cloud собирают инфраструктуру, средства защиты и соответствие регуляторным требованиям в одном контуре.

Кто отвечает за реагирование: роли и матрица ответственности

Провал реагирования редко выглядит как техническая ошибка. Чаще картина другая: в три часа ночи нужно отключить продуктивный сегмент, но у дежурного инженера нет полномочий, у директора по ИБ нет телефона владельца системы, а сам владелец не понимает, чем грозит бездействие. С помощью матрицы ответственности вы решите эту проблему заранее, на бумаге, в спокойной обстановке.

ГОСТ Р 59712-2022 задает минимальную конструкцию, в которую входят рабочая группа реагирования и специалист, ответственный за реагирование, он же руководитель группы. Но на практике и согласно международным стандартам (в частности, NIST SP 800-61) для работающего процесса необходима расширенная матрица распределения ответственности.

Таблица 2. Реагирование на инциденты – матрица распределения ответственности 

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

Для каждой роли нужно назначить заместителя, потому что инцидент может произойти в отпуск, в новогоднюю ночь и во время релиза, когда основной ответственный будет недоступен.

Как аналитики SOC должны реагировать на инциденты на каждой линии?

Мониторинговый центр работает по трем линиям (L1-L3), у каждой свои набор действий, полномочия и граница компетенций. Разделение обеспечивает скорость: если каждое срабатывание уходит эксперту по форензике, очередь растет и есть риск не разглядеть за шумом критичное событие. Поэтому на вопрос о том, как аналитик SOC должен реагировать на инциденты, надо дать три разных ответа.

Таблица 3. Реагирование на инциденты на разных линиях SOC 

Работа первой линии (L1) держится на трех быстрых решениях, которые аналитик принимает за считаные минуты:

1. Это реальная угроза или ложное срабатывание (False Positive)?
2. Какова критичность инцидента согласно матрице?
3. Есть ли готовый плейбук, который можно применить прямо сейчас?

Всё, что не закрывается этими тремя пунктами, уходит на эскалацию.

Золотое правило L1, которое стоит закрепить в регламенте отдельным пунктом: «cомневаешься – эскалируй». Цена лишней эскалации – это полчаса рабочего времени аналитика L2, а цена пропущенного инцидента – недели восстановления инфраструктуры и оборотные штрафы.

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

Какие этапы проходит реагирование на инцидент?

Этапы реагирования описаны в российском и международном стандартах, причем их наборы почти совпадают. ГОСТ Р 59712-2022 (утвержден приказом Росстандарта от 29.11.2022 № 1378-ст) разбивает стадию реагирования на пять последовательных шагов и два параллельных. National Institute of Standards and Technology (NIST) в апреле 2025 года отозвал вторую редакцию SP 800-61 и выпустил третью, где привычный четырехфазный цикл заменен моделью из шести функций CSF 2.0.

Таблица 4. Этапы реагирования на инцидент  

Смысл смены модели у NIST стоит понять до переписывания регламента. Раньше улучшение процесса было финальной фазой: команда собиралась после инцидента, обсуждала произошедшее и расходилась. В третьей редакции улучшение стало сквозной функцией, работающей на всех стадиях, а жизненный цикл выровнен по функциям Govern, Identify, Protect, Detect, Respond, Recover. Управление и подготовка перестали быть предисловием к реагированию и стали его полноценной частью.

Команды ИБ обычно переносят этапы реагирования во внутренний регламент как есть. Ломать их порядок нельзя: фиксация материалов идет параллельно локализации, а не после нее. Если сначала переустановить зараженную машину и только потом задуматься о расследовании, вы потеряете образ памяти, журналы и возможность установить первопричину. Спустя время тот же вектор сработает повторно, а разбирать его будет нечем.

Как реагировать на инцидент в первый час: порядок действий

Порядок реагирования работает только тогда, когда он записан как последовательность конкретных действий с ответственными, а не как абстрактное описание принципов. Можно рекомендовать приведенный ниже плейбук первого часа для подтвержденного инцидента с признаками компрометации. Он детализирует стадии реагирования (обнаружение, локализация, сбор свидетельств), предусмотренные ГОСТ Р 59712-2022 и NIST SP 800-61:

1. Зафиксируйте время обнаружения. С этой отметки идет отсчет всех регуляторных сроков и метрик. Это первое поле в карточке инцидента.
2. Подтвердите инцидент и присвойте критичность. Проверьте контекст срабатывания, определите категорию по матрице P1–P4. От этого зависят состав команды и SLA.
3. Назначьте руководителя реагирования. Нужна одна точка принятия решений и единая хронология. Далее все действия пишутся в общий журнал с таймкодами.
4. Соберите артефакты до разрушающих действий. Сохраните образ оперативной памяти, снимок диска, журналы СЗИ и сетевые дампы. Зеркалирование трафика в облаке дает для этого готовый поток данных (как это устроено, мы объясняли в материале о сервисе зеркалирования сетевого трафика в К2 Облаке).
5. Локализуйте угрозу. Изолируйте затронутые узлы на сетевом уровне, отзовите сессии и токены скомпрометированных учетных записей, заблокируйте внешние адреса атакующих.
6. Оцените охват. Выясните, какие еще системы имели доверенные связи с затронутыми: общие учетные записи, ключи, сетевые маршруты, задания планировщика.
7. Запустите регуляторный трек. Параллельно технической работе юрист и специалист по комплаенсу оценивают, попадает ли инцидент под 187-ФЗ и затронуты ли персональные данные. Часы на уведомление уже тикают.
8. Оповестите заинтересованных лиц внутри компании. Свяжитесь с владельцами систем, руководством и, при необходимости, техподдержкой, чтобы она давала клиентам согласованные ответы.
9. Проверьте резервные копии. Убедитесь до начала восстановления, что бэкапы целы, изолированы от скомпрометированного контура и из них можно развернуть данные.
10. Зафиксируйте промежуточный статус. В конце первого часа сделайте короткую сводку: что известно, что сделано, каковы следующие шаги и кто за них отвечает.

Для субъектов КИИ порядок реагирования отличается: действие на шаге 7 становится обязательным и срочным. Для значимых объектов на уведомление НКЦКИ отводится три часа с момента обнаружения, и укладываться в них приходится параллельно с технической работой.

Что категорически нельзя делать в первый час:

• Переустанавливать систему до снятия образа. Вместе с ней исчезнут следы атаки.
• Менять пароли поштучно. При подозрении на компрометацию контроллера домена это бессмысленно – здесь требуется массовая смена кредов.
• Общаться по скомпрометированным каналам связи. На случай, если нападающий контролирует корпоративную почту или мессенджер, в плане должен быть заранее определен резервный канал.

Как задать SLA и время реагирования на инцидент?

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

Критичность оценивается по двум параметрам: влиянию на бизнес (от «затронут один пользователь» до «остановлен ключевой процесс») и охвату (от одного хоста до всей инфраструктуры).

Таблица 5. Матрица критичности инцидентов и параметров SLA 

Значения в таблице – это рабочая отправная точка для компании среднего размера с собственной дежурной сменой. Они предложены исходя из практики и SLA ведущих центров мониторинга (SOC) и систем управления инцидентами (IRP/SOAR), их нужно адаптировать под свою инфраструктуру и SLA с внешним SOC, если он есть.

Два правила, без которых SLA превращается в формальность:

1. Отсчет ведется от появления события в источнике, а не от заведения карточки. Иначе метрика будет показывать скорость перекладывания тикетов, а не скорость реагирования.
2. Регуляторные сроки не растворяются во внутренних SLA. Три часа для значимых объектов КИИ и 24 часа для Роскомнадзора стоят отдельной строкой и имеют наивысший приоритет.

Для инцидентов P1 полезно завести отдельный таймер на уведомление регулятора и закрепить его за юристом. Технический и регуляторный таймеры идут параллельно.

Какие метрики показывают, что реагирование работает?

Метрики нужны, чтобы ответить на три вопроса: где автоматизировать процессы, кого нанимать и что чинить в первую очередь. Красивые отчеты для руководства – лишь побочный продукт. В соответствии с рекомендациями ГОСТ Р 59711-2022 и NIST SP 800-61, для постоянного совершенствования системы защиты и оценки зрелости процесса реагирования используется ключевой набор метрик (MTTD, MTTR, Dwell Time и др.), собираемый из систем IRP/SOAR.

Таблица 6. Метрики реагирования на инциденты 

Важные нюансы расчетов:

• MTTD и Dwell time часто путают. MTTD считается от начала вредоносной активности (которую вы установили при разборе). Dwell time считается от первичного проникновения (которое могло случиться намного раньше). Разница между ними показывает, сколько времени хакер тихо сидел в инфраструктуре, прежде чем сделать что-то заметное.
• Разложение MTTR полезнее самого MTTR.

         – Если задержка между обнаружением и взятием в работу – проблема в дежурстве и системе оповещений.
         – Если время теряется между реакцией и сдерживанием – проблема в полномочиях L1/L2 и плейбуках.
         – Если буксует этап от сдерживания до восстановления – проблема в бэкапах и процедурах ИТ-отдела.

• Считайте метрики строго по категориям критичности. Средний MTTR «по больнице» – бесполезное число. Сотня автоматически закрытых за минуту инцидентов P4 замаскирует один P1, который парализовал работу на неделю. Как настроить сбор метрик и оповещений на уровне платформы, мы рассказывали в статье Platform as a Service под контролем: метрики, алерты и дашборды.
• Следите за внутренним детектом. Ежеквартально оценивайте долю инцидентов, обнаруженных собственными средствами, и процент повторных атак по старому вектору. Первое отражает зрелость мониторинга (хороший бенчмарк по отчету M-Trends 2026 – около 52%), второе показывает, делаете ли вы выводы после расследований.

Что должно быть в плане реагирования на инциденты?

План реагирования (IRP) – это рабочий инструмент дежурной смены, а не кипа бумаг для аудитора. Главный критерий качества: сможет ли новый аналитик в 3 часа ночи открыть план и за десять минут понять, что ему делать? Если для этого нужно прочитать 80 страниц – план не работает.

Рабочий IRP строится на восьми блоках:

1. Область действия и классификация. Список покрываемых систем, матрица критичности (P1–P4) и четкие критерии распределения инцидентов.
2. Роли, контакты и замены. Таблица с именами, телефонами, резервными каналами связи и заместителями. Отдельным пунктом – кто имеет право «рубильником» отключить продуктив.
3. Сроки. Внутренние SLA и регуляторные тайминги в единой таблице с закрепленными ответственными.
4. Порядок действий по типам инцидентов (плейбуки). Сценарии на случай шифровальщика, компрометации учетки, утечки данных, DDoS-атаки или взлома веб-приложения.
5. Порядок сбора и хранения артефактов. Что именно снимаем, какими инструментами, где храним, как долго и кто имеет к этому доступ.
6. Взаимодействие с внешними сторонами. НКЦКИ, Роскомнадзор, провайдер, внешняя форензик-команда, страховая. Обязательно приложите готовые шаблоны уведомлений.
7. Порядок восстановления. Приоритеты поднятия систем, алгоритм проверки бэкапов, критерии для финального закрытия инцидента.
8. Порядок разбора (Post-Incident Review). Когда проводится ретроспектива, что фиксируется, как выводы конвертируются в новые правила детекта и правки плейбуков.

Для субъектов КИИ план дополняется требованиями приказов ФСБ: состав передаваемых в ГосСОПКА сведений, схема взаимодействия с НКЦКИ и назначенные ответственные. Для ГИС добавляются требования приказа ФСТЭК России № 117. Для операторов персональных данных (в соответствии с 152-ФЗ) план должен включать процедуру двухэтапного уведомления Роскомнадзора (в течение 24 часов о факте инцидента и в течение 72 часов о результатах внутреннего расследования), а также интеграцию с ГосСОПКА для передачи сведений об утечках.

Планы реагирования на инциденты безопасности и ИТ-инциденты часто объединяют. Разделять их логично, только если у вас разные команды и SLA. Практичнее держать единый каркас с профильными плейбуками в приложениях.

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

Чем политика реагирования на инциденты отличается от плана и инструкции?

Смешивание стратегических и рабочих документов в один файл делает текст нечитаемым, а процесс согласования – бесконечным. Политика отвечает на вопрос «зачем», план – «что делаем», а инструкция – «как именно».

Таблица 7. Документы, необходимые для реагирования на инциденты

Разработка и разделение комплекта документов (политика, план, инструкции/плейбуки) обязательны для: 

• субъектов КИИ (187-ФЗ и нормативные акты ФСБ России)
• операторов ГИС (Приказ ФСТЭК № 117,  ГОСТ Р 59712-2022)
• операторов ПДн (152-ФЗ)

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

Внутреннее руководство по реагированию обычно оформляют как сборник, объединяющий под одной обложкой политику, план, регламент и инструкции. Опираться при этом удобно на национальные стандарты:

• ГОСТ Р 59709-2022 (термины и определения)
• ГОСТ Р 59710-2022 (общие положения)
• ГОСТ Р 59711-2022 (организация деятельности)
• ГОСТ Р 59712-2022 (руководство по реагированию)

Практическое правило объема: всё, что аналитик должен открыть в момент инцидента, обязано умещаться на одной странице (матрица P1-P4, контакты, сроки, ссылки на плейбуки). Остальной текст читается в спокойной обстановке заранее.

Какие ошибки чаще всего срывают реагирование?

Сбои в процессе реагирования типичны и имеют организационную, а не техническую природу. СЗИ работают, логи собираются, алерты падают, но процесс разваливается из-за нехватки полномочий, срыва сроков или игнорирования post-mortem разборов.

Восемь самых частых ошибок:

1. Отсчет нормативных сроков от завершения расследования. Часы регулятора тикают с момента обнаружения. Лучше отправить первичное уведомление с неполными данными и позже его дополнить, чем ждать идеальной картины и сорвать сроки.
2. Разрушающие действия до форензики. Переустановка зараженного хоста стирает цифровые улики. Вы не найдете точку входа, и вектор атаки повторится через квартал.
3. Единая критичность для всех алертов. Без разбивки на P1-P4 нет приоритизации, нет понимания просрочек и нет управляемых метрик.
4. Дежурство без полномочий. L1 видит компрометацию, но вынужден часами согласовывать блокировку хоста. Тем временем данные утекают за секунды.
5. Средний MTTR «по больнице». Отслеживать среднее время восстановления без привязки к критичности – значит обманывать себя метриками.
6. Бумажный план без учений. В реальном инциденте внезапно выясняется, что нужный админ уволился, а резервный канал связи развернут в том же скомпрометированном домене.
7. Бэкапы в основном контуре. Шифровальщик уничтожит их вместе с продуктивом. Копии должны быть изолированы и регулярно проверяться на восстановимость.
8. Разбор инцидента «в стол». Выводы записали, но правила детекта и плейбуки не обновили. Ждите повторения инцидента.

Еще одна ошибка – фокусироваться только на сложных APT-атаках. Базовый DDoS остановит ваши бизнес-процессы не менее надежно, чем хитрый шифровальщик, но отражается он совершенно иначе (детали – в нашем разборе Защита от DDoS-атак в облаке).

Как облако меняет реагирование на инциденты кибербезопасности?

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

Таблица 8. Разделение ответственности за реагирование на инциденты между облачным провайдером и заказчиком 

Три вопроса, которые нужно закрыть с провайдером до инцидента:

1. Какие журналы (логи) вам доступны и какова глубина их хранения?
2. Какой канал связи использовать при инциденте и какой SLA у техподдержки?
3. Кто и как передает данные в НКЦКИ, если атака затрагивает инфраструктуру платформы (для субъектов КИИ)?

Технологический стек облака напрямую режет MTTC и MTTR. Зеркалирование трафика дает чистые данные для расследования, снапшоты в соседнем регионе – мгновенную точку восстановления, а встроенные сервисы безопасности (о них мы рассказывали в материале Безопасная миграция в облако: оценка рисков и пошаговый план) позволяют выстроить мониторинг без долгого внедрения.

Часто заказчики приходят к нам уже в разгар инцидента, когда выясняется, что решение об экстренной остановке продуктива принять просто некому. В этот момент вопрос выбора средств защиты уходит на второй план. Технический стек обычно собран неплохо, логи пишутся, алерты доходят. Бизнесу не хватает тех самых трех страниц плана: с распределенными ролями, жесткими сроками и понятной матрицей критичности.

В К2 Облаке мы поддерживаем защищенные сегменты (до УЗ-1 по 152-ФЗ, ГОСТ Р 57580, PCI DSS). Перенося ресурсы к нам, заказчик «наследует» часть этого комплаенса. Мониторинг и реагирование можно подключить как сервис вместе с вычислительными мощностями – тогда дежурная смена ИБ появляется у вас в день переезда, а не через полгода мучительного найма. Зоны ответственности мы жестко фиксируем в договоре на старте, потому что во время кибератаки выяснять, «чей это участок», уже поздно.

Анжелика Захарова, руководитель практик кибербезопасности и 1С, K2 Cloud 

С чего начать

Три базовых шага, которые за первую же неделю снимут с вас львиную долю рисков:

1. Соберите «страницу первого часа». Сведите воедино матрицу P1-P4, телефоны ответственных лиц (с заместителями) и таблицу регуляторных сроков. Дежурный не должен терять драгоценные минуты на выяснение того, кого будить ночью.
2. Определите регуляторный статус. Выясните, попадают ли ваши системы под 187-ФЗ и обрабатывают ли ПДн. От этого зависит таймер, который запустится при инциденте: 3, 24 или 72 часа.
3. Проведите настольные учения. Выберите один сценарий (например, атаку шифровальщика), соберите команду на два часа и проговорите весь план действий вслух. Список вскрывшихся проблем и неувязок гарантированно окажется длиннее, чем вы ожидали.

Изображение на обложке: K2 Cloud, генерация через ИИ