Привет, Хабр!

Сегодня снова делимся экспертизой Алексея Ахмеева, руководителя Управления информационной безопасности Своего Банка, входящего в финтех-группу СВОЙ.

С 2023 года Алексей отвечает за информационную безопасность всей экосистемы группы. За это время под его руководством в компаниях провели комплексную модернизацию нормативной и технической базы ИБ, внедрили централизованную систему мониторинга инцидентов и запустили проекты по противодействию утечкам данных.

Недавно Алексей выступал на Практическом интенсиве по информационной безопасности для CIO, где затронул тему, с которой рано или поздно может столкнуться любая компания: как действовать, когда инцидент информационной безопасности уже произошел, а руководство ждет ответов.

Алексей с удовольствием поделился материалом с Хабром. Мы собрали основные тезисы его выступления и разобрали десять вопросов, к которым CIO стоит быть готовым в первые часы после инцидента. Без лишней теории – о том, что отвечать и как сохранить контроль над ситуацией.
______________________________________________________________________

Представим ситуацию: в компании произошел серьезный ИБ-инцидент. Ключевые ИТ-системы и сервисы недоступны, часть бизнес-процессов остановлена. CIO срочно вызывают на экстренное совещание с руководством.

В такой ситуации технические вопросы быстро переходят в управленческую плоскость. Сколько продлится простой? Каков масштаб ущерба? Могли ли пострадать данные клиентов? Почему защитные механизмы не помогли предотвратить инцидент? И когда компания сможет вернуться к нормальной работе?

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

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

Что происходит с бизнесом в первые часы после инцидента

Недоступность ключевых ИТ-систем — это не только техническая проблема. Для бизнеса она может обернуться финансовыми потерями, срывом обязательств перед клиентами и партнерами, репутационными последствиями и претензиями со стороны регулятора. Чем дольше продолжается простой, тем дороже компании обходится отсутствие ясности.

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

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

Не оправдываться, а управлять ситуацией

В первые часы после кибератаки то, как компания сообщает о происходящем, не менее важно, чем само техническое реагирование. Неопределенные ответы, неподтвержденные версии и обещания, которые не удается выполнить, только усиливают напряжение. Не лучше выглядит и попытка переложить ответственность на сотрудников или подрядчиков.

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

Если прямо сейчас точного ответа нет, это допустимо при наличии конкретного плана действий. Например, можно сказать, что команда анализирует определенный сегмент инфраструктуры, назвать ответственного и обозначить, когда появятся первые результаты.

Посмотрим, как этот подход работает на десяти вопросах.

Об инциденте

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

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

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

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

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

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

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

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

В первые часы после инцидента ответ на этот вопрос может быть неизвестен. При этом ответ «мы пока не знаем» без пояснений оставляет руководство без понимания масштаба риска.

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

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

Не стоит ни преуменьшать риски, ни заранее объявлять об утечке, которой еще не подтвердили. Руководству нужно понимать, что известно на данный момент и каким образом компания собирается установить остальные обстоятельства.

О сроках и финансовых последствиях

Формулировка «мы работаем над восстановлением» вряд ли устроит руководство. Бизнесу нужно понимать, когда хотя бы частично возобновятся операции и сколько времени потребуется для возвращения к штатному режиму.

Но обещать конкретное время запуска до диагностики систем тоже не стоит. Если названный срок не удастся выдержать, доверие к дальнейшим оценкам снизится.

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

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

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

Даже если точные сроки пока неизвестны, руководство должно понимать последовательность восстановления и условия перехода к следующему этапу.

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

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

• Прямые расходы: расследование инцидента, восстановление инфраструктуры, привлечение внешних специалистов и замена скомпрометированных компонентов.

• Потери от простоя: недополученная выручка, срыв операций, дополнительные расходы на выполнение обязательств перед клиентами и партнерами.

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

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

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

Об ответственности

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

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

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

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

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

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

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

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

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

О коммуникациях и предотвращении повторных инцидентов

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

Задача CIO – оперативно предоставлять проверенную информацию: какие системы затронуты, какие данные могли оказаться под угрозой, что компания делает для устранения последствий и что уже удалось восстановить.

Юристы и комплаенс должны определить применимые требования к уведомлению регуляторов и других заинтересованных сторон, включая сроки и состав раскрываемой информации. PR-служба отвечает за согласование внешних сообщений и взаимодействие со СМИ. Клиентские коммуникации необходимо выстраивать с учетом фактического масштаба инцидента и действующих обязательств компании.

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

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

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

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

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

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

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

Главный управленческий вопрос:

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

Не стоит отвечать, что без вас никто не разберется в инфраструктуре. Такая позиция скорее подчеркнет зависимость компании от одного человека, чем продемонстрирует управленческие качества. Не стоит и безоговорочно признавать собственную вину до завершения расследования или предлагать руководству самостоятельно решать, кто ответственен за произошедшее.

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

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

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

Пять принципов коммуникации во время ИБ-инцидента

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

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

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

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

• Осторожно обращайтесь со сроками. Прогнозы должны сопровождаться условиями, допущениями и временем следующего апдейта.

• Регулярная коммуникация. Руководству необходимо получать информацию по установленному графику, а о существенных изменениях следует сообщать оперативно.

CIO как руководитель кризисного реагирования

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

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

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

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