ИБ как управляемый процесс
С чего начинается управляемость
Сделать ИБ процессной функцией трудно там, где сама компания живет вне процессной логики. В понимании Анастасии Гайнетдиновой (Security Leader Whoosh) зрелость начинается с самых базовых вещей и должна расти вместе со зрелостью компании. На начальном этапе процессы сводятся к базовым: управление доступами, идентификацией и мониторингом. Важен не только сам процесс (например, выдача прав), но и полная прослеживаемость всей цепочки (кто кому что и зачем выдал), понятный порядок согласования (в какие системы чье согласование нужно) и скорость исполнения заявки. Иначе безопасность либо превращается в ручное администрирование, либо начинает тормозить бизнес. «Для меня принципиально важно, чтобы информационная безопасность не тормозила бизнес. Если согласование со стороны ИБ задерживает выдачу доступа на сутки, двое или трое, это уже показатель того, что процесс выстроен неудачно», — отмечает Анастасия.
Управляемость начинается там, где безопасность перестает быть набором отдельных мер и превращается в повторяемый цикл — с оценкой, внедрением, измерением и улучшением. Само наличие средств защиты или формальное соответствие требованиям еще не означает зрелости. Простой практический тест — понять, что произойдет, если из контура уйдет конкретный человек. «Если мы говорим об управляемости, нужно показать переход от набора инструментов к процессу. Это непрерывный цикл: оценка, внедрение, измерение, улучшение — и затем новый виток этого цикла. Только в таком случае можно говорить об управляемом процессе», — подчеркивает Константин Анисимов, заместитель генерального директора Astra Cloud (входит в «Группу Астра»).
Зрелая ИБ не существует отдельно от бизнеса. По словам Веры Орловой, начальника отдела мониторинга и реагирования на инциденты ИБ «Русагро тех», безопасность должна быть встроена во все процессы, где возникают риски, — от HR до запуска новых проектов. Не после внедрения, когда приходится латать уязвимости, а заранее, как понятная и прозрачная часть общей работы.
С близкой позиции смотрит на тему Михаил Бачинский, исполнительный директор САЛД. В его трактовке управляемая ИБ — это не набор разрозненных действий, а целостный проект, который включает технические, программные и административные меры. Такая логика снижает зависимость от конкретных исполнителей и делает защиту воспроизводимой практикой, а не совокупностью ручных решений.
Управляемость нужно уметь показать
ИБ становится управляемой тогда, когда ее результат виден не только самой функции, но и руководству. Речь идет не о количестве атак или внедренных решений как таковых, а о понятной связи между мерами защиты, рисками и теми потерями, которых компания смогла избежать. При этом зрелость процесса определяется не только способностью предотвратить или выявить нарушение. Так, сама система реагирования тоже может порождать новые проблемы — например, судебные споры, претензии регуляторов или нагрузку на смежные функции. «ИБ может справиться с риском внутреннего нарушителя, но в том же процессе компания способна породить и новый риск. Поэтому зрелый ИБ-процесс — это еще и защита от вторичных последствий собственных действий», — подчеркивает Илья Башкиров, юрист по информационной безопасности и консультант ГК InfoWatch.
Наконец, никакая формализация не работает без нормального взаимодействия с ИТ и поддержки бизнеса. «Если ИБ пытается выстроить процесс, а ИТ этому сопротивляется, результата не будет. Поэтому здесь необходимы и поддержка ИТ-специалистов, и поддержка бизнеса», — говорит Сергей Савченко, начальник службы по обеспечению информационной безопасности «Воздушные Ворота Северной Столицы».
Можно сказать, что управляемая ИБ — это не просто набор защитных мер и не только выполнение требований регулятора. Это функция, встроенная в основные процессы компании, не завязанная критически на отдельных людей, понятная руководству и способная сочетать контроль со скоростью работы.
Что в ИБ считать результатом
Процессное управление в ИБ имеет смысл только тогда, когда понятно, что именно считается результатом. По сути, именно этот вопрос модератор Иван Козлов и вынес в центр разговора: какие показатели действительно помогают понять, как работает безопасность, а какие лишь создают эффект убедительной, но мало что объясняющей отчетности. Пока функция измеряет себя количеством атак, инцидентов, срабатываний или найденных уязвимостей, она остается внутри собственного профессионального контура. Для команды безопасности такие показатели могут быть полезны, но на уровне бизнеса они слишком часто превращаются в шум. Цифры впечатляют, но плохо объясняют, что происходит с компанией и как работа ИБ влияет на ее устойчивость.
В вопросе метрик все зависит от того, кому именно они адресованы. Один и тот же показатель по-разному воспринимается внутри ИБ-команды и на уровне руководства, поэтому технические цифры сами по себе редко работают как доказательство результата. Для первого лица компании важны не отчеты о событиях как таковые, а их связь с деньгами, потерями и предотвращенным ущербом. «Если мы говорим о разговоре с CEO, то владельцу бизнеса важны деньги. Для него метрикой будет то, что можно выразить в деньгах — сколько компания могла потерять и не потеряла, сколько удалось сэкономить, не допустив определенных рисков или митигировав их заранее», — говорит Анастасия Гайнетдинова (Whoosh).
На уровне руководства разговор об эффективности ИБ не сводится только к деньгам. Не менее важен и другой вопрос — как меняется риск для бизнеса, какие сценарии остаются для компании неприемлемыми и насколько защитные меры действительно влияют на устойчивость. Поэтому внутри ИБ могут работать одни показатели, а для генерального директора важнее уже более интегральная картина. «Если вы приходите к CEO и говорите, что у нас произошло пятьсот инцидентов, он вправе спросить: и что дальше? Но если вы говорите, что благодаря определенным мерам риск для бизнеса снизился, условно, с тридцати процентов до одного, это уже понятный показатель», — дополняет Константин Анисимов (Astra Cloud).
Даже заметное снижение числа атак само по себе еще не объясняет, зачем бизнесу понадобились вложения в безопасность и что именно они изменили. Такая динамика может выглядеть убедительно, но оставаться слишком поверхностной для управленческого решения. В реальном разговоре с руководством больший вес получает и регуляторный контур — особенно там, где последствия нарушений прямо выражены в штрафах и ответственности. «Если атак было сто тысяч, а стало пятьдесят тысяч, это еще не та метрика, которая что-то по-настоящему объясняет. Такая статистика сама по себе не показывает, зачем были приняты те или иные меры и какой эффект они дали», — делится Инна Сенчугова, директор по ИТ Михайловского театра.
Наиболее практичная точка сборки между языком денег и языком рисков появляется, когда компания начинает оцифровывать сам риск и выражать его стоимость. В этом случае уже можно сопоставить цену защитной меры и те потери, которые она помогает предотвратить, а значит — перевести разговор из абстрактной плоскости в управленческую. «Очень полезно, когда появляется понимание стоимости риска. ИБ может не только сформировать карту рисков, но и выразить их в деньгах. Тогда становится видно, как конкретная мера влияет на снижение риска и на те потери, которые с ним связаны», — отмечает Вера Орлова («Русагро тех»).
Итак, складывается довольно оформленный вывод: ложной метрика становится не потому, что она техническая, а потому, что живет отдельно от решения. Количество атак, инцидентов или уязвимостей может быть полезно внутри функции, но на уровне бизнеса работает только то, что помогает увидеть последствия, сопоставить риск со стоимостью мер и понять, делает ли безопасность компанию устойчивее.
Как процессы ИБ превращаются в план работы
Планирование в ИБ редко строится по одной универсальной схеме. В одних компаниях оно сильнее завязано на регуляторные требования, в других — на риски, в-третьих — на результаты аудита и текущее состояние инфраструктуры. Но в любом случае речь идет не о наборе отвлеченных правильных процессов, а о попытке собрать в рабочую систему то, что действительно требует изменений.
У части компаний такая работа оформлена как среднесрочный план с формальными обязательствами и регулярной отчетностью. «У нас есть план стратегического развития ИБ, который мы согласуем с ФСТЭК. Он рассчитан на три года, и мы ежегодно отчитываемся, что выполнено, а что нет», — говорит Сергей Савченко («Воздушные Ворота Северной Столицы»).
При этом сам процессный подход не стоит понимать как красивую схему, которую сначала придумывают на бумаге, а потом пытаются внедрить. Гораздо чаще процессы в ИБ возникают как ответ на конкретные риски, инциденты и типовые сценарии, с которыми компании действительно приходится работать. Такой же практический подход виден и там, где план ИБ вырастает из результатов проверки. Сначала фиксируются пробелы в документах, технической части и текущих процедурах, затем формируется перечень задач, определяется, что можно сделать своими силами, где понадобятся дополнительные ресурсы и какие шаги становятся приоритетными. «План у нас родился после проведения аудита информационной безопасности. По его итогам мы определяем, что нужно сделать в документационной части, что — в технической, что можно выполнить своими силами, а где нужны дополнительные ресурсы, и дальше расставляем приоритеты», — говорит Инна Сенчугова (Михайловский театр).
Более осторожный взгляд связан с риском увлечься самой процессной логикой и начать описывать процессы ради процессов. В этом случае безопасность может потерять видение и понимание реальных угроз и постепенно уйти в бюрократию. «Мне ближе олдскульный подход, когда есть модель нарушителя и есть соответствующие меры защиты, которые надо реализовывать. Потому что иначе можно прийти к процессу ради самого процесса — и уже не очень понятно, где он заканчивается и есть ли у него хотя бы промежуточный результат», — подчеркивает Дмитрий Сатанин, директор по информационной безопасности «Группы Астра».
В итоге рабочий план ИБ складывается не из абстрактного набора правильных схем, а из требований регулятора, результатов аудита, выявленных уязвимостей, критичных активов и реальных рисков. Процессный подход здесь работает только тогда, когда остается связанным с угрозами и задачами бизнеса, а не превращается в самодостаточное описание функции.
На какой срок можно планировать ИБ
Где заканчивается стратегия и начинается тактика? У компании может быть долгосрочное видение, список обязательных направлений развития и накопленный технический долг, но это еще не означает, что безопасность можно одинаково уверенно планировать на год, на три и тем более на пять лет вперед. В коммерческой среде длинный тактический горизонт часто оказывается слишком хрупким: слишком быстро меняются и регуляторные требования, и технологии, и сами приоритеты бизнеса. Поэтому точкой отсчета здесь становится не формальный пятилетний план, а текущие задачи компании и те риски, которые сопровождают новые продукты, сервисы и изменения.
В то же время сам по себе длинный горизонт не обязательно становится проблемой, если не пытаться заранее расписать каждый шаг. В этом случае план нужен скорее как ориентир — для понимания направления движения, будущих потребностей и ресурсной рамки, а не как жесткая программа действий.
По сути, здесь важно развести два уровня. Стратегия в ИБ возможна и нужна как рамка приоритетов и допустимого риска. Тактика же живет на гораздо более коротком горизонте и почти неизбежно пересматривается по мере изменения вводных. Поэтому управляемость определяется не длиной плана, а способностью вовремя его перестраивать без потери логики и контроля.
Что дает регулятор, а что остается самой компании
Насколько сильно на управляемость ИБ влияет регулятор? Судя по опыту участников дискуссии, его роль важна, но ограничена. Он задает обязательную рамку, дисциплинирует процесс, заставляет компании оформлять меры и подтверждать их на проверках. Но довести организацию до зрелой модели управления одной только регуляторикой невозможно.
Например, применительно к информационным системам, которые относятся к критической информационной инфраструктуре, регуляторные изменения не приходят неожиданно. ФСТЭК России достаточно последовательно обозначает направления нормотворчества и заранее показывает, как будут усиливаться уже существующие требования. «На протяжении лет пятнадцати представители ФСТЭК России на крупных тематических мероприятиях достаточно четко высказываются о своих планах нормотворческой деятельности. В целом есть определенный набор мер по защите информации, а вопрос идет об их докручивании, усилении и дополнении», отмечает Дмитрий Сатанин («Группа Астра»).
Но сама по себе эта рамка еще не равна зрелому управлению. Задача регулятора — подтянуть бизнес до обязательного минимума, ниже которого компания уже создает риск не только для себя, но и для окружающей среды. Все, что выше этой планки, остается зоной ответственности самой организации. Практическое подтверждение этой границы дала Инна Сенчугова (Михайловский театр). По ее словам, в реальной проверке речь шла не об оценке зрелости как таковой, а о гораздо более формализованной логике: выполнено требование или нет, есть документ или нет, закрыт нужный пункт или нет.
Как выстраивать процесс реагирования на инциденты
Реагирование на инциденты — один из самых наглядных критериев зрелости ИБ. Именно здесь обычно видно, есть ли у компании не только набор защитных средств, но и реальный порядок действий: кто принимает решения, кто восстанавливает сервисы, кто информирует руководство и клиентов, а кто отвечает за техническую часть.
Инциденты в той или иной форме неизбежны, поэтому ключевым становится не только сам факт атаки, но и то, как компания действует дальше: как информирует руководство, как выстраивает коммуникацию с клиентами и в какие сроки восстанавливает сервисы.
При этом нижний, обязательный слой такого процесса — организационная готовность. Даже в не самой зрелой компании можно заранее определить группу реагирования, контакты, правила эскалации, ответственных и типовые сценарии. «Все, что касается организационной зрелости в части управления инцидентами, можно сделать практически в любой компании: группа реагирования, понимание ответственных, контактная карта, принцип эскалации, плейбуки на типовые виды инцидентов», — отмечает Вера Орлова («Русагро тех»).
С практической точки зрения именно на эту часть и стоит делать упор в первую очередь. Конечно регламенты, плейбуки и тренировки не гарантируют, что реальный инцидент полностью совпадет с отработанным сценарием, но помогают пройти его без проблем и быстрее вернуться к работе.
Сами по себе инструкции еще не означают, что процесс действительно выстроен. Реагирование нельзя считать первым и главным контуром, если у компании нет фундамента: мониторинга, логирования, управления доступами и базового понимания того, что вообще считать отклонением. Эту же мысль, но жестче, можно сформулировать так: тяжелый инцидент уже сам по себе означает, что где-то раньше защита не сработала или не увидела подготовку к атаке вовремя. «Когда инцидент произошел, это уже прокол системы безопасности», — комментирует Михаил Бачинский (САЛД).
При этом сама по себе профилактика не отменяет необходимости быть готовыми к восстановлению. Ключевым условием устойчивости остаются базовые меры, прежде всего резервное копирование, организованное действительно надежно.
Процесс реагирования на инциденты — один из обязательных контуров зрелой ИБ, но он работает только тогда, когда опирается на основу. Организационные меры можно выстраивать довольно рано, однако полноценным такой процесс становится лишь там, где уже есть мониторинг, журналы событий, резервное копирование, понятные роли и общая дисциплина в инфраструктуре.
Где проходит граница ответственности
Для многих компаний давно стала нормой ситуация, в которой часть инфраструктуры находится у внешнего провайдера, подрядчики получают доступ во внутренний контур, а граница ответственности размывается. В такой модели ИБ уже не может ограничиться защитой только собственных систем — ей приходится управлять стыками между компанией, облаком и внешними исполнителями.
С технической точки зрения базовый принцип здесь остается классическим: внешнему пользователю нельзя давать больше прав, чем требуется для конкретной задачи. Но одним разграничением полномочий вопрос не исчерпывается. В облачной модели безопасность неизбежно становится двусторонней задачей — так провайдер защищает не только конкретного клиента, но и собственную платформу, и других клиентов, которые могут пострадать из-за чужого скомпрометированного ресурса.
С точки зрения заказчика такая схема все равно не дает полного контроля над внешним контуром. Именно поэтому значительная часть защиты строится через договор — через распределение ответственности и фиксацию того, кто отвечает за последствия инцидента. «Мы на уровне договора стараемся максимально переложить риски на хостеров, которые предоставляют площадку и отвечают за защиту сайта», — говорит Инна Сенчугова (Михайловский театр).
Но и договор важен не только как юридическая формальность. По словам Ильи Башкирова (ГК InfoWatch), он задает и модель экономического поведения сторон: когда риск и ответственность заранее распределены, подрядчик иначе относится к своим обязательствам и к возможным последствиям инцидента: «Договор важен не как бумага, а как соглашение об экономических процессах, потому что, распределяя риск в договоре, вы фактически распределяете и финансовый риск, который организация может понести в будущем».
Защита на стыке с облаком и подрядчиками не сводится ни к техническим мерам, ни к одним только договорам. Рабочая модель возникает там, где сочетаются минимально необходимые права, понятное разграничение ответственности, договорное распределение рисков и собственные меры контроля со стороны заказчика.
Что требовать от контрагента
Отдельная зона риска возникает там, где компания зависит не только от собственной инфраструктуры, но и от поставщиков, подрядчиков и других участников цепочки поставок. Иван Козлов привел показательный пример из практики ретейла: «Одна из крупных сетей включает в договор требование, чтобы подрядчик подтвердил наличие процесса реагирования на инциденты информационной безопасности и обязался сообщать о проблеме через заранее определенный канал». Такой подход, по мнению Константина Анисимова (Astra Cloud), вполне оправдан, ведь если у заказчика высокий уровень требований к безопасности, он вправе ожидать сопоставимого отношения и от тех, кто подключен к его системам или влияет на его процессы.
Но сама по себе такая оговорка в договоре не дает полной гарантии. Например, подрядчик может просто не знать, что его инфраструктура уже скомпрометирована, а значит, и уведомить вовремя не сможет. Поэтому договорное уведомление не работает как самодостаточная мера. Его приходится дополнять пересмотром доступов, дополнительной аутентификацией, контролем учетных записей и другими техническими и организационными мерами на стороне заказчика.
Особое внимание нужно уделять юридической стороне вопроса. Так, в договоре важно закреплять не только саму обязанность сообщить об инциденте, но и весь порядок совместных действий после него: кто реагирует, как стороны взаимодействуют и как продолжают исполнение обязательств, если основной цифровой контур остановился.
Требование к подрядчику иметь процесс реагирования на инциденты — мера правильная, но недостаточная сама по себе. Рабочая модель возникает там, где договор фиксирует не только уведомление, но и распределение ответственности, порядок совместных действий и резервный способ продолжать работу, а со стороны заказчика эта рамка поддерживается собственными мерами контроля.
Что ИИ меняет в ИБ уже сейчас
Искусственный интеллект пока только обрастает практикой и регулированием, но уже заметно меняет контур безопасности. Причем речь идет не только о будущих требованиях, а о вполне прикладных вещах: как ИИ усиливает старые угрозы, где создает новые и в каких задачах может помочь самой ИБ.
Одной из самых заметных зон риска остается социальная инженерия. Если раньше корпоративное мошенничество строилось в основном на письмах, звонках и подмене адресов, то теперь в дело все активнее входят голосовые дипфейки и имитация руководителей. При этом ИИ одновременно снижает порог входа для злоумышленника и дает новые инструменты защитнику. С одной стороны, он ускоряет массовые автоматизированные атаки, с другой — помогает работать с большими массивами данных, мониторингом и безопасной разработкой. «ИИ хорошо работает с большими данными, и применение этому можно найти в самой ИБ — от покрытия мониторинга до SSDLC и код-ревью», — говорит Анастасия Гайнетдинова (Whoosh).
Еще один риск связан уже не с внешним атакующим, а с повседневной практикой самих сотрудников. Чувствительная информация все чаще попадает во внешние ИИ-сервисы просто потому, что пользователи не считают это нарушением. Так сотрудники, пользуясь ИИ-сервисами, нередко просто сливают туда без анонимизации информацию, которая может оказаться крайне чувствительной для компании.
На этом фоне некоторые компании уже идут по самому консервативному пути — максимально ограничивают использование внешних ИИ-сервисов средствами DLP и внутренними правилами. Но обсуждение показало, что простого запрета надолго не хватит. ИИ слишком быстро становится обычным рабочим инструментом, а значит, бизнесу придется не только закрывать доступ, но и заново выстраивать правила обращения с данными, обучения сотрудников и контроля новых каналов утечки.
И наконец, отдельная опасность состоит в том, что ИИ начинают встраивать уже в сами средства защиты — в анализ инцидентов, в автоматизацию реагирования, в SOAR-контуры. Проблема здесь, как отмечает Вера Орлова («Русагро тех»), не только в технической новизне, но и в цене ошибки: неточный вывод или ложная классификация могут привести не к пропущенной атаке, а к некорректной блокировке реальных бизнес-процессов: «Огромная опасная зона — это false positive при реагировании через ИИ, когда неправильные выводы влекут некорректное реагирование и блокировки для бизнеса».
С ней согласен Дмитрий Сатанин («Группа Астра»): «Крайне аккуратно нужно использовать искусственный интеллект для решения задач информационной безопасности, потому что доверенных моделей у нас на данный момент нет».
В заключение можно отметить, что ИИ не приносит в ИБ одну новую угрозу, а сразу усиливает несколько старых и добавляет несколько новых. Он ускоряет социальную инженерию, расширяет каналы утечки, усложняет автоматическое реагирование и одновременно дает защитникам новые инструменты для анализа, мониторинга и разработки. Поэтому главный вопрос уже не в том, опасен ли ИИ сам по себе, а в том, насколько быстро компании научатся встраивать его в свои процессы.