Первые 72 часа и жизнь после инцидента
Нужно решать, что отключать, кого уведомлять, где можно перейти на ручной режим и сколько вообще времени есть до того, как техническая проблема начнет напрямую бить по бизнесу.
На Петербургском цифровом форуме эти первые часы обсуждали ИТ- и ИБ-руководители промышленных компаний, инфраструктурных организаций и сервисов вместе с представителями страховой и ИТ-компании. Дискуссию модерировал известный эксперт, бизнес-консультант по безопасности Positive Technologies Алексей Лукацкий.
Главное — не остановить компанию
Регламент, план реагирования на инциденты должен быть одним из главных документов у компании, когда информационной безопасностью занимаются системно. По нему нужно сразу собрать максимум доступных данных и быстро определить, кого требуется уведомить. «С него начинается информационная безопасность. Когда ты признаешь, что не “если”, а “когда” это произойдет», — уверен Иван Козлов (Группа Латео).
Роман Цыганков («Автозавод Санкт-Петербург») свое рабочее место во время серьезных происшествий в шутку называет «центром паники». Сначала приходится немного снизить градус, потом решать, что компания будет делать прямо сейчас. «Произошло — мы с этим уже ничего сделать не можем, потому что событие наступило. Первое — продолжаем производство. Второе — разбираемся с тем, что уже есть, — говорит Роман, — Если потребуется, его можно отсечь от остальной инфраструктуры, перейти в полуручной режим и параллельно разбираться с инцидентом». При серьезном нарушении цифровых процессов такой вариант может оказаться вполне рабочим способом сократить простой.
Для страховщиков это тоже вопрос не эстетики, а размера потерь. Александр Терехов (СОГАЗ) считает, что бумажный и ручной режим — вполне рабочий сценарий, который стоит сохранить на случай тяжелого сбоя. Если компания способна хоть как-то работать без привычных систем, ущерб уже будет меньше.
Полной ясности в первые минуты может и не быть. Александр Васильев (Невский экологический оператор) считает, что ждать ее не нужно: «Первое - проинформировать генерального директора: событие есть, оно развивается. Если оно затрагивает профильные подразделения — проинформировать и их. И сразу предусмотреть перевод ключевых процессов на ручной, на бумажный режим, чтобы компания продолжала работать».
Джун с нейронкой и оператор с вайбкодингом
«Что вы знаете про нетипичные инциденты ИТ-инфраструктуры, когда у вас есть джун и нейронка?» — спрашивает коллег Анастасия Гайнетдинова (Whoosh). Представление о том, что ИТ-инциденты в основном понятны и предсказуемы, она не разделяет. Новые инструменты слишком быстро меняют набор возможных сценариев. Вчера в плане реагирования не было сотрудника, который принесет в корпоративный контур нейросеть. Сегодня он уже есть — вместе с последствиями своих экспериментов.
Но это еще не все интересные варианты. Один из участников вспомнил операторов на производственной линии с вайбкодингом. Доступных инструментов становится больше, а цифровая гигиена за ними поспевает не всегда. Данные легко уезжают непонятно куда, код появляется непонятно откуда, а дальше ИТ и ИБ получают еще один повод для ранней седины.
Но за шутками остается и вполне практическая проблема. Регламент можно отработать на известных сценариях, а новые появляются быстрее, чем успевают обновляться инструкции. ИИ и инструменты разработки дают сотрудникам возможности, которых еще недавно у них не было. Вместе с ними появляются и новые способы случайно создать компании очень нетипичный инцидент. Который потом превращается в деньги.
И если для ИТ и ИБ проблема начинается с систем, данных и инфраструктуры, то для бизнеса довольно быстро включается другой счетчик с вопросом «сколько стоит?»
Именно поэтому оценка ущерба нужна до инцидента, а не после него. Какие финансовые потери возможны при атаке? Какие статьи расходов окажутся самыми тяжелыми? Что удастся сохранить за счет резервных или ручных процессов?
Александр Терехов (СОГАЗ) предлагает смотреть на киберриск в том числе через эти цифры. Страхование может покрыть часть потерь, но сначала компании придется самой понять, чем она рискует: «Первое, что надо сделать, — осознать, к каким финансовым потерям может привести кибератака на предприятие».
Что написано в плане и что происходит на самом деле
Можно сколько угодно проверять инструкцию на учениях. Но реальный инцидент все равно находит место, где человек остановится и скажет: «Я это делать не буду».
В «Водоканале» по одному из сценариев охранник должен был зайти в серверную и выдернуть два линка. На бумаге — действие на несколько секунд. На практике охранник увидел дорогое оборудование и вполне резонно решил, что крайним в случае чего окажется именно он. «Он был уверен, что на него потом повесят стоимость сервера», — говорит Геннадий Стародубцев. Проблему решили без нового многостраничного приложения к регламенту. Нужные кабели сделали красными. Теперь на тренировках их выдергивают без долгих размышлений.
С DevOps-инженерами история оказалась похожей, хотя оборудование они знают куда лучше охранника. Начинающий специалист получает инструкцию погасить кластер или разорвать сетевое подключение — и в последний момент начинает считать возможные последствия. А резерв точно поднимется? А бэкапы сработают? А если именно после моего действия все окончательно ляжет?
Инструкция может быть совершенно правильной. Но если человек боится ее выполнить, для инцидента разница невелика. По словам Анастасии Гайнетдиновой, такие процедуры пишут сами специалисты, которые потом по ним работают. И этого тоже мало. Инструкцию дают другим сотрудникам и заставляют пройти весь путь под присмотром более опытных коллег. Только тогда становятся видны места, которые автору казались очевидными. Иногда тест проваливается не на техническом шаге, а на телефонном звонке.
Молодой специалист видит подозрительное событие, но не спешит эскалировать. Вдруг тревога ложная? Вдруг он поднимет ночью половину руководства из-за ерунды? Желание сначала разобраться самостоятельно вполне понятно — и способно отнять несколько очень дорогих часов. «Если ты мне позвонишь в субботу в девять вечера, я, конечно, скажу, что не очень рада тебя слышать. Но если это сохранит компании кучу денег, то ты молодец и правильно все сделал», — объясняет Анастасия.
После реальных происшествий планы обычно переписывают. У Сергея Савченко («Воздушные ворота Северной Столицы») один из таких инцидентов закончился тремя сутками работы вместе с ИТ-директором, а затем — заметной переработкой прежнего регламента. Документ был слишком общим; опыт добавил в него детали, о которых заранее не подумали.
«Для первых, кто принимает решение, чек-листы должны быть очень короткие. Это не больше одной страницы. Если вы видите, что инструкция оперативного дежурного, инструкция дежурного предприятия или генерального директора 50 страниц, ну, значит, это ваша ошибка. Один лист, на котором 2–3 решения, куда бежать и что делать» — дополняет коллег Геннадий Стародубцев (ГУП «Водоканал»).
Пятьдесят страниц могут пригодится потом. В три часа ночи эффективнее работает красный кабель.
Кто записывал, что мы делали?
«Абсолютно забили все на порядок уведомлений и на документирование того, что вы разгребаете», — так Анастасия Гайнетдинова вспоминает свой первый серьезный инцидент. После того как первоначальная паника прошла, команда начала расследование. Хотелось раскопать причину, понять масштаб, проверить, что еще пострадало. Записывать собственные действия на этом фоне казалось делом, которое вполне можно оставить на потом. А далее наступило это самое «потом». Через сутки понадобилось готовить уведомление: когда что произошло, кто что проверял, какие действия предпринимали. Часть расследования пришлось проходить заново — уже не ради поиска причины, а чтобы восстановить собственную хронологию.
После этого в процедуре появилось требование хотя бы раз в десять минут фиксировать, чем занята команда. «Иначе вы потом это устанете восстанавливать тем же самым маршрутом, которым уже прошли», — советует Анастасия.
Есть и вторая причина не полагаться на память. Тяжелый инцидент вполне способен пережить одну рабочую смену. И две тоже.
Собрать в первые часы всех самых сильных специалистов кажется естественным. Только через пару суток понадобятся люди, которые еще способны соображать. Геннадий Стародубцев предостерегает как раз от попытки сразу бросить на проблему весь состав: «Инциденты информационной безопасности и ИТ стали долгоиграющими. Это несколько суток. И выгорание команды за двое-трое суток случается очень быстро. А работать надо дальше».
Значит, людей придется менять. Следующая смена получает не чистый лист, а систему, в которой уже что-то отключили, что-то перезапустили, где-то ждут завершения процесса, а к какой-то проверке надо вернуться через двадцать минут. Если предыдущая команда ничего не записала, новичкам остается расспрашивать уставших коллег или повторять часть работы.
На тренировках Whoosh для этой роли иногда используют джуна. Пока более опытные специалисты разбираются с инцидентом, он сидит рядом и фиксирует команды, действия, скриншоты, промежуточные результаты. Работа не самая героическая, но пользы от нее много. Заодно новичок привыкает к обстановке, в которой вокруг все куда-то бегут и что-нибудь срочно чинят. «Если тебе дают четкие инструкции, паника отступает. Во-первых, он привыкает не паниковать, во-вторых, он привыкает все это дело записывать», — добавляет Анастасия.
Все инциденты в одну тикетницу?
Не обязательно. У ИТ, ИБ, службы безопасности и производственных подразделений разные задачи, сроки реакции и набор данных, которые им вообще нужно видеть. В одной компании события сначала попадают в общий ситуационный центр и уже там расходятся по направлениям. В другой ИТ и ИБ работают в разных системах. Где-то служба информационной безопасности следит за ИТ-инцидентами, но сама открывает свои только тем, кому это действительно нужно.
У Александра Васильева (Невский экологический оператор) В АО «Невский экологический оператор» ИТ- и ИБ-инциденты ведутся раздельно. При подозрительном событии службы связываются напрямую и в рабочем порядке определяют, что перед ними: инцидент, техническая неисправность или плановые работы.
В других компаниях разведение процессов связано уже не с исторически сложившейся архитектурой, а с характером самих событий.
«У нас инциденты разные, они делятся: у айтишников — свои, у нас — свои. При этом мы мониторим все инциденты ИТ. Это сделано специально, потому что есть инциденты, в которых ИТ не принимают участие и не должны знать», — поясняет логику действий Сергей Савченко.
Слишком жесткие границы между службами, впрочем, иногда начинают мешать. Неопознанная аномалия сначала может выглядеть как обычный технический сбой, а через несколько минут — как ИБ-инцидент. Или, наоборот. Пока подразделения выясняют, чья это территория, время уже идет. Поэтому в планах нужны не только свои чек-листы, но и понятные точки передачи. Кто звонит кому? При каком событии подключается ИБ? Когда ИТ обязано передать информацию дальше? Что делать, если природа аномалии пока неясна?
Общая система регистрации может помочь, но сама по себе ничего не гарантирует. Инциденту все равно, в какой очереди он стоит и какой у него номер тикета. Ему гораздо полезнее, когда нужные люди узнают о нем через несколько минут, а не после того, как службы закончат спорить о принадлежности.
Когда подрядчик решил помочь
У компании может быть прекрасный план реагирования. Но достаточно одного внешнего исполнителя, который в критический момент решит действовать по-своему.
Во время одного из инцидентов подрядчика попросили сохранить логи и виртуальные машины — они требовались для дальнейшего разбора и передачи специалистам. Вместо этого систему без согласования откатили на два дня назад. Да, сервис надо было быстрее вернуть в строй. Только вместе с восстановлением исчезла часть нужной информации. «Для нас это был, конечно, немножко шок. Ребята, мы же вас просили, вы должны были предоставить эти данные. А они решили, что быстренько надо восстановить, и восстановили», — вспоминает Сергей Савченко. Позже выяснилось, что подрядчик таким способом еще и пытался затереть собственные ошибки.
К сожалению, и с деньгами утешения здесь немного. Ответственность подрядчика часто ограничена одним, двумя или тремя месячными платежами. Для бизнеса, у которого встал критичный сервис или производство, это слабая компенсация. «Это все равно какие-то абсолютные копейки, которые по сравнению с реализованным инцидентом, если это реальный простой, ни холодно, ни горячо бизнесу», — замечает Иван Козлов (Группа Латео).
Но даже небольшая договорная компенсация — больше, чем можно получить с собственного сотрудника: «С подрядчика по договору можно получить хотя бы что-то. Со штатного сотрудника - практически ничего: трудовое законодательство ограничивает его материальную ответственность, и понесённые компанией затраты она не покрывает», — считает Александр Васильев (Невский экологический оператор).
Попытки прописать более серьезную ответственность в договоре успехом заканчиваются нечасто. Исполнитель тоже умеет считать риски и брать на себя потенциальные убытки заказчика не рвется.
Своя головная боль и у государственных организаций. Спор с подрядчиком способен продолжаться годами, а дополнительные требования на закупке могут признать ограничивающими конкуренцию. Геннадий Стародубцев (ГУП Водоканал) вспомнил, как разбирательства по инцидентам 2022 года лишь спустя несколько лет подошли к финишу. Суд, по его словам, подрядчиков воспитывает хорошо. Просто педагогический эффект сильно отложенный.
Но договорная ответственность — еще не самое неприятное. Подрядчик может сам стать дорогой внутрь хорошо защищенной компании. В одном из страховых расследований долго не могли понять источник компрометации. След привел к внешнему исполнителю, а там на открытом диске обнаружился файл с логинами и паролями. Его злоумышленники аккуратно скачивали примерно раз в месяц. Причем внутри лежали учетные данные не одного клиента, а сразу нескольких.
«Больше половины инцидентов в текущих реалиях происходит по вине подрядчиков. У крупных компаний могут быть огромные бюджеты, сильные команды, учения, регламенты — а с подрядчиками намного сложнее», — рассказал Александр Терехов (АО СОГАЗ).
Проверить каждого поставщика так же тщательно, как собственную команду, почти невозможно. У него меняются сотрудники, инфраструктура, внутренние правила. Сегодня все выглядит прилично, завтра кто-нибудь положит пароль на общий диск. Поэтому внешний исполнитель — не приложение к плану реагирования. Он его полноценная часть. Иначе в первые часы придется спасать не только системы, но еще и результаты чужой инициативы.
Регулятору тоже придется объяснять, что произошло
Что делать, если техническая команда занята расследованием, а срок уведомления уже идет? Для части компаний ответ заранее прописан в обязательных процедурах. В дискуссии упоминались ГосСОПКА, ФСБ и Роскомнадзор. Где-то взаимодействие ограничивается передачей информации, где-то специалисты ведомств помогают разбирать техническую сторону инцидента. В регулируемых отраслях такой контакт вообще давно встроен в обычную работу.
Но отправить уведомление — это только половина дела. В нем придется объяснить, что произошло, когда обнаружили проблему, какие системы пострадали и что компания уже успела сделать. Если команда в первые часы ничего не фиксировала, ответы приходится собирать задним числом.
Есть еще одна польза от внешнего взгляда. К собственной инфраструктуре привыкают. Какие-то странности годами воспринимаются как данность, неудобные места перестают замечать просто потому, что все знают, как их обходить. В дискуссии это назвали «зашоренностью» — состоянием, когда внутренняя команда настолько хорошо знает свою систему, что иногда уже не видит ее слабых мест.
Человек со стороны таких привычек не имеет. Регулятор в таком случае оказывается не только адресатом обязательного сообщения. При нормальном рабочем взаимодействии он может указать на то, что сама компания давно перестала считать проблемой.
Разумеется, в первые часы никто не ждет, что внешняя структура придет и разберется со всем вместо собственной команды. Но и модель «мы сначала все починим, а потом кому-нибудь расскажем» плохо уживается со сроками уведомлений и длинными расследованиями.
Поэтому у кризисной команды две параллельные работы. Одни восстанавливают и проверяют системы, другие следят, чтобы по дороге не потерялись факты, сроки и обязательные сообщения. Через сутки выяснять по памяти, во сколько отключили сервер, и кто отдал команду, — занятие уже совсем непростое.
Windows 7 и линия за $100 млн
Можно ли считать компанию готовой к инциденту, если в инфраструктуре до сих пор живут Windows 7, Windows XP или даже DOS?
Для страховщика ответ очевиден. Система с давно известными уязвимостями заметно увеличивает риск, а значит. Александр Терехов привел пример крупного регионального клиента, который хотел застраховать бизнес от киберрисков. При проверке выяснилось, что часть инфраструктуры работает на устаревшей системе: «Мы рекомендовали клиенту обновить операционную систему до более современной, чтобы мы могли взять их на страхование».
ИТ-директора с таким подходом не спорят, но добавляют производственную реальность. «Есть очень много производственных индустриальных систем, которые не работают ни на чем, кроме Windows 7. И вот есть два выбора: либо заменить линию за 100 миллионов долларов, либо держать Windows 7», — говорит Иван Козлов (Группа Латео).
На практике старое оборудование приходится обкладывать компенсирующими мерами. Изоляция, микросегментация, ограничение привилегий, закрытый контур, физическое отключение сети. Иногда проще действительно выдернуть шнур. Но полностью убрать риск все равно не получится. Даже в закрытом контуре остается человек с флешкой.
Производственные системы вообще живут по другому календарю. Оборудование может работать десятилетиями, а программное обеспечение привязано к нему намертво.
В аэропортовой инфраструктуре, по словам Сергея Савченко, ситуация похожая: часть систем нельзя обновить не потому, что ИТ-служба не хочет, а потому, что новая платформа пока не поддерживает нужные функции или не соответствует отраслевым требованиям. Риск приходится принимать, одновременно применяя компенсирующие меры там, где это возможно.
Учения заканчиваются там, где начинается вода
Тридцать сантиметров воды на полу серверного помещения — довольно убедительный способ проверить план аварийного восстановления.
У Романа Цыганкова (Автозавод Санкт-Петербург) был такой случай после сильных дождей. Серверы уцелели во многом благодаря опыту предыдущей аварии. «Мы уже имели подобный инцидент в прошлом и наше серверное помещение подняли примерно на этот уровень выше», - говорит Роман. Теперь мощность насосов собираются увеличивать. При проектировании резервной серверной тоже решили учитывать высоту размещения — ее хотим разнести по уровню с основной площадкой.
Похожий случай помешал одному из московских гостей приехать на форум: у него как раз залило серверную. Так что даже проверенный на учениях план в реальной аварии начинает выглядеть иначе. «Когда ты реально из воды вытаскиваешь серверы и пытаешься что-то где-то запустить на выкатной площадке, все совсем по-другому, чем это описано», — добавляет Иван Козлов.
По словам Станислава Юдинских (Контур), нетипичный случай после первого раза уже перестает быть нетипичным — его добавляют в план реагирования. Правда, запас неизвестных на этом не заканчивается. Следующая авария почти наверняка принесет что-нибудь свое.
Именно поэтому документ, который ни разу не менялся после реального инцидента, вызывает вопросы. Хороший разбор оставляет следы не только в новой версии регламента. Иногда их видно по высоте серверной стойки.
Что делать и чего не делать в первые 72 часа
«Перестаньте писать бумажки, которые не работают», — уверена Анастасия Гайнетдинова (Whoosh). Документация может отличаться от комплекта, который показывают на аудите. Главное, чтобы дежурный действительно понимал, что делать первым, вторым и третьим шагом — и чтобы это понял даже джун.
С сообщениями наверх участники были почти единодушны. Не надо ждать, пока подозрение превратится в доказанный инцидент. Не надо бояться разбудить руководителя зря. И уж точно не стоит несколько часов самостоятельно выяснять, достойна ли проблема чужого внимания.
Сергей Савченко советует прежде всего рассчитывать на подготовленную команду. А Иван Козлов — не надеяться на себя: «Не стараться сначала разобраться, а потом сообщить. Сначала сообщить, а потом начинать разбираться. Потому что вот это “сначала разобраться” может растянуться и на 72, и на больше часов».
На самом деле здесь нет противоречия. Команда должна уметь действовать сама, но героическое желание решить все в одиночку может дорого обойтись компании.
Страх тоже оказывается вполне самостоятельным фактором риска. Боится джун, который не решается эскалировать тревогу. Боится инженер, которому по инструкции надо отключить систему. Боится охранник, держащий в руках кабель от дорогого оборудования. А рядом с ними — руководители, которым приходится принимать решение об остановке процесса, еще не имея полной картины.
Поэтому совет «не паниковать» звучит банально только до первой настоящей аварии. Паника мешает слышать друг друга, заставляет метаться между версиями и отнимает время. Станислав Юдинских (Контур) именно ее называет ошибкой, от которой стоит избавиться в первую очередь.
Есть вещи, которые все равно придется узнать только на практике. Где инструкция слишком длинная. Кто испугается нажать кнопку. Как поведет себя подрядчик. Сколько продержится команда без сна. Хватит ли насоса, если серверную снова зальет. После этого план перепишут, кабель покрасят в красный, оборудование поднимут выше, а в чек-листе появится еще одна строчка. Универсального плана первых 72 часов не существует. Каждый серьезный инцидент приносит собственный набор неприятностей. Но чужой опыт позволяет хотя бы часть из них встретить не впервые.
В финале модератор Алексей Лукацкий завершил дискуссию пожеланием, чтобы эти 72 часа никогда не наступили. Пожалуй, лучший способ приблизиться к этому пожеланию — все-таки готовиться так, будто однажды они наступят.
Опубликовано 27.08.2026
