Если говорить честно, у информационной безопасности есть неприятная особенность: атакующему часто достаточно относительно небольших вложений, а защищающейся компании приходится тратить миллионы. И это не повод махнуть рукой. Это повод наконец перестать обсуждать ИБ как абстрактную строку расходов.
В 26-м выпуске «Belyaev_Podcast» мы с Борисом Евдокимовым, директором по информационной безопасности сети аптек «АСНА», и Вячеславом Касимовым, CISO Точка Банка, разбирали вопрос, который рано или поздно приходит к каждому руководителю ИБ: как объяснить бизнесу, за что он платит и что именно получает взамен.
Главный тезис простой: безопасность нельзя оценивать по количеству купленных средств защиты или отсутствию новостей об утечках. Её нужно оценивать через риск, последствия, вероятность и способность компании продолжать работать, когда что то всё же идёт не по плану.
Атака дешевле защиты
Парадокс кибербезопасности в том, что стоимость входа для атакующего снижается, а сложность защиты растёт. В разговоре Вячеслав Касимов обратил внимание: атакующему могут быть доступны облачные сервисы, вычислительные мощности, инфраструктура для сокрытия действий и автоматизация. Для небольшой компании этого иногда достаточно, чтобы начать массовый поиск слабых мест или попытаться провести целевую атаку.
Я бы здесь не зацикливался на конкретной сумме. Цифра сама по себе быстро устаревает и всегда зависит от сценария. Важнее другое: цена попытки атаки и цена последствий для бизнеса живут в разных реальностях.
Компания может годами инвестировать в сетевую защиту, мониторинг, резервное копирование, средства защиты рабочих станций и обучение. Но одна критическая уязвимость на внешнем периметре, неактуальный доступ подрядчика или ошибка в настройке могут обесценить значительную часть этих вложений.
Проблема не в том, что технологии бесполезны. Проблема в ожидании, будто дорогой продукт сам по себе создаёт защищённость.
На практике защита складывается из нескольких вещей:
Понимания критичных бизнес процессов и активов.
Контроля доступов, особенно привилегированных.
Регулярной проверки внешнего периметра и внутренней инфраструктуры.
Наблюдаемости: логов, мониторинга, корреляции событий, реагирования.
Подготовленной команды, которая умеет не только увидеть сигнал, но и принять решение.
Проверяемых резервных копий и понятного плана восстановления.
Можно купить хороший инструмент. Но нельзя купить вместо команды способность видеть контекст, расставлять приоритеты и отвечать за решение.
Отсутствие утечек не равно защищённости
Фраза «у нас не было утечек» звучит успокаивающе. Но как практик я всегда уточняю: а откуда вы это знаете?
Вячеслав Касимов в разговоре справедливо отметил, что отсутствие известных инцидентов может означать совершенно разные вещи. Возможно, компания действительно хорошо защищена. Возможно, инцидент не был обнаружен. Возможно, признаки компрометации были, но их не связали между собой. Возможно, данные уже оказались за пределами компании, но ещё не попали в публичное поле.
Борис Евдокимов добавил важный практический вопрос: утечки надо не только фиксировать постфактум, но и мониторить. Публичные публикации, сообщения в закрытых каналах, компиляции старых баз, фейки, повторные продажи данных, всё это создаёт шум. Но отсутствие мониторинга не делает проблему менее реальной.
Важно не путать отсутствие громкого инцидента с отсутствием инцидента вообще.
У зрелой компании должен быть хотя бы базовый ответ на несколько вопросов:
Какие данные для нас критичны?
Где они хранятся и кто имеет к ним доступ?
Какие признаки утечки или компрометации мы умеем видеть?
Кто и как проверяет внешние сигналы об утечках?
Как мы отличаем достоверную информацию от фейка или старой скомпонованной базы?
Что мы делаем в первые часы после подтверждения инцидента?
Самое опасное здесь не в самой утечке как техническом событии. Самое опасное, когда компания узнаёт о ней слишком поздно, не понимает масштаб и начинает принимать решения вслепую.
ИБ не должна быть оператором шлагбаума
Почему бизнес часто воспринимает безопасность как тормоз? Потому что ИБ слишком часто говорит только «нет».
Вячеслав Касимов сформулировал это жёстко, но точно: специалист, который не понимает последствий решения и не может предложить безопасный путь реализации, превращается в оператора шлагбаума. Он либо запрещает инициативу, либо уводит её на бесконечные согласования, потому что не готов принять риск на себя.
Но бизнес не перестанет запускать продукты, менять архитектуру, подключать подрядчиков, внедрять автоматизацию и искать новые каналы продаж. Если ИБ в этот момент умеет только блокировать, её рано или поздно начнут обходить.
На мой взгляд, задача безопасности не в том, чтобы согласовать или не согласовать проект. Задача в том, чтобы помочь бизнесу принять осознанное решение.
Иногда правильный ответ действительно будет: «Сейчас нельзя, потому что риск неприемлем». Но за этим должно следовать продолжение: что именно опасно, какие последствия возможны, какие компенсирующие меры доступны, сколько они стоят, сколько времени займут и какой риск останется после их внедрения.
Борис Евдокимов обратил внимание на базовую, но часто потерянную мысль: безопасность защищает способность компании зарабатывать. Когда ИБ без объяснения блокирует запуск, она может создавать прямые потери для продаж, маркетинга и клиентов. Но когда она помогает запустить инициативу с понятными ограничениями и контролями, она защищает и выручку, и устойчивость бизнеса.
В Точка Банке, как рассказал Вячеслав, приоритет в разговоре с командами смещается не только к деньгам, но и к клиентскому эффекту. Этот подход мне близок. Деньги важны, но клиент часто лучше объясняет команде, зачем нужно искать безопасное решение, а не выбирать между запретом и бездумным запуском.
Как считать ценность безопасности
Финансовый директор вправе спросить: «Хорошо, вы просите бюджет. Какой будет возврат?»
Уходить от этого вопроса нельзя. Но и обещать простую формулу окупаемости, как в маркетинге, тоже не стоит. Безопасность редко создаёт выручку напрямую. Её ценность обычно проявляется через предотвращённые потери, снижение вероятности инцидента, уменьшение масштаба ущерба и повышение устойчивости процессов.
Вячеслав Касимов предложил смотреть на ИБ через риск: есть сценарий, есть вероятность, есть потенциальный ущерб, есть стоимость мер контроля. Если меры снижают вероятность или последствия реализации сценария, их ценность можно обсуждать на языке бизнеса.
Борис Евдокимов рассказал о практическом подходе, при котором значимые расходы оформляются как проекты с паспортом рисков. Это полезная дисциплина. Она заставляет ИБ не просто просить деньги на лицензию, а объяснять:
Какой риск закрывается.
Какой актив или процесс может пострадать.
Каковы возможные последствия.
Что произойдёт, если ничего не делать.
Какие есть альтернативы.
Во что обойдётся реализация и поддержка.
Как будет проверяться эффект.
Вероятность, конечно, остаётся сложной частью модели. Особенно там, где мало собственной статистики. В этом случае, как отметил Вячеслав, можно опираться на три источника: накопленные данные по похожим инцидентам, наблюдаемые отраслевые тренды и экспертную оценку с участием тех, кому доверяют руководители и совет директоров.
Это не делает модель идеальной. Но бизнесу не нужна иллюзия математической точности. Ему нужна честная, прозрачная и воспроизводимая логика принятия решений.
Искусственный интеллект не отменяет ответственность
Отдельная часть разговора была посвящена искусственному интеллекту в SOC, антифроде и реагировании на инциденты. Вопрос здесь всегда звучит одинаково: можно ли доверить модели решение, если цена ошибки, это деньги клиентов, доступность сервиса и безопасность инфраструктуры?
Позиция Вячеслава Касимова довольно практичная: автоматизацию можно использовать там, где скорость реакции критична, а человек физически становится узким местом. Например, на этапе первичной квалификации событий, запуска процедуры реагирования или блокировки очевидно опасной активности.
Я с этим согласен, но с важной оговоркой. Вопрос не в том, использовать ли AI или не использовать. Вопрос в границах полномочий, сценариях автоматизации, проверках и ответственности.
Любая система, которой мы дали права в инфраструктуре, становится частью поверхности атаки. Неважно, речь о SIEM, EDR, сканере уязвимостей, платформе управления доступом или AI агенте с подключением к инструментам автоматизации.
Вячеслав привёл важную мысль: любой механизм надо тестировать. Если не проверять его работу, он может не увидеть атаку, принять неверное решение или сам стать точкой входа. В случае с языковыми моделями добавляются отдельные риски: ошибочные ответы, манипуляция через входные данные, небезопасные интеграции, избыточные права и уязвимости в цепочке поставки.
Поэтому для AI в ИБ я бы применял несколько обязательных принципов:
Не давать модели больше прав, чем необходимо для конкретного сценария.
Разделять анализ, принятие решения и исполнение критичных действий.
Логировать действия, запросы, решения и последствия автоматизации.
Тестировать модель и интеграции до вывода в продуктивную среду.
Проверять сторонние компоненты, модели, библиотеки и обновления.
Оставлять человеку контроль над действиями с необратимыми последствиями, пока риск не измерен и не принят.
Назначать владельца решения, который отвечает не за «галлюцинацию модели», а за то, что этот инструмент был допущен в инфраструктуру.
Нельзя делегировать ответственность алгоритму. Ответственность всегда остаётся у владельца процесса и у компании, которая дала системе доступ.
Дороже всего обходится потеря доверия
В финале мы обсуждали, что для компании тяжелее: сам факт взлома, простой, утечка данных или потеря доверия клиентов.
Вячеслав Касимов считает, что самым дорогим последствием становится именно потеря доверия. Я разделяю эту позицию. Технический инцидент может быть тяжёлым. Бизнес может потерять данные, деньги, доступность сервисов, время команды. Но если клиенты перестают верить, что компания умеет обращаться с их деньгами, данными и ожиданиями, последствия становятся долгими и плохо прогнозируемыми.
При этом доверие теряется не только из за самого инцидента. Его можно потерять из за попытки скрыть проблему, молчания, противоречивых комментариев, отсутствия понятного плана восстановления и ощущения, что компания не контролирует ситуацию.
Инцидент нельзя отменить задним числом. Но можно определить, как компания будет действовать после него.
Нужны заранее подготовленные сценарии:
Кто принимает решения и отвечает за коммуникации.
Какой минимум фактов нужно подтвердить до первого публичного сообщения.
Как компания информирует клиентов, партнёров и сотрудников.
Как поддержка отвечает на вопросы.
Какие компенсационные или защитные меры доступны пострадавшим.
Как фиксируются решения, действия и доказательства.
Как после восстановления компания объясняет, что именно было изменено.
Если говорить честно, кризисная коммуникация не заменяет техническую защиту. Но она определяет, останется ли у компании шанс сохранить отношения с клиентами, когда защита всё же не сработала.
Практический вывод
Безопасность не должна доказывать, что она способна остановить любую атаку. Это обещание никто не может дать честно.
Она должна показывать бизнесу другое:
Какие риски для компании действительно существенны.
Сколько может стоить их реализация.
Какие меры уменьшают вероятность или ущерб.
Как быстро организация заметит проблему.
Как она будет реагировать и восстанавливаться.
Кто принимает риск, если меры не внедряются.
Зрелая ИБ, это не витрина из дорогих продуктов и не отчёт, в котором всё зелёное. Это способность принимать неприятные решения до инцидента, а не объяснять их необходимость после него.
Вопрос к профессиональному сообществу: в какой момент в вашей компании безопасность перестала быть непонятной статьёй расходов и стала инструментом управления риском?
[YouTube] [Тизер] [VK Video] [Яндекс.Музыка] [Telegram] [RuTube] [Другие платформы]
