Алексей Морозков: как оценить реальную защищенность бизнеса и правильно расставить приоритеты в ИБ

7 часов назад

Аудит информационной безопасности давно перестал быть только способом проверить соответствие требованиям регуляторов. Для бизнеса все важнее понимать, насколько реальная защищенность совпадает с представлением о ней внутри компании, какие уязвимости действительно создают риск и где находятся «слепые зоны» инфраструктуры. Одновременно меняются и сами задачи ИБ: распространение генеративного ИИ создает новые каналы утечек, управление тысячами уязвимостей требует риск-ориентированного подхода, а часть операционных функций компании все чаще передают внешним командам. Руководитель центра ИБ-экспертизы ICL Services Алексей Морозков ответил на вопросы RUБЕЖ и после каждого ответа выделил практические аспекты, на которые компаниям стоит обратить особое внимание.

RUБЕЖ: Что сегодня чаще всего становится причиной для проведения аудита ИБ: требования регуляторов, произошедший инцидент, изменения инфраструктуры или желание компании понять реальное состояние защиты?

Алексей Морозков: Мы бы не выделяли одну универсальную причину. На практике аудит можно инициировать по любым причинам, ведь ключевая цель получить независимую оценку текущего уровня защиты и как она соотносится с тем, что должно быть (целевая картина). Мы всегда делаем акцент на то, что проводить аудит нужно не только ради того, чтобы «пройти» потенциальную проверку от регулятора и т.д., а для того чтобы понять, насколько реальная защищенность совпадает с тем, как ее ощущают внутри компании.

На что стоит обратить внимание:

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

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

RUБЕЖ: В каких случаях компании сегодня действительно необходим полноценный аудит ИБ и что он должен показать помимо соответствия требованиям регуляторов?

Алексей М.: Мы считаем, что полноценный аудит, учитывающий добротное количество контролей для проверки, следует проводить тогда, когда для компании недостаточно ответа «соответствуем мы требованиям или нет». Такой аудит должен показать реальное состояние защиты: какие активы являются критичными, какие вектора атак являются высоковероятными, насколько эффективны действующие меры и средства защиты и что нужно исправить в первую очередь, чтобы действительно снизить риски ИБ, которые могут серьезно нарушить деятельность компании. В нашей практике результатом такой работы становятся не только найденные несоответствия и уязвимые области, но и рекомендации по краткосрочным, среднесрочным и стратегическим мерам и дальнейшему развитию безопасности ИТ-инфраструктуры.

На что стоит обратить внимание:

• Полноценный аудит должен охватывать не только технические средства защиты, но и архитектуру, все процессы ИБ (управление доступом, управление активами, управление уязвимостями, управление инцидентами и т.д.), документацию и организационные меры.
• Особенно он необходим после серьезных изменений инфраструктуры, крупного инцидента, перед запуском критичной системы или если у компании давно не было независимой всесторонней оценки защищенности.
• Важно установить связь между техническим недостатком и бизнес-риском. Десятки замечаний без понимания возможных последствий мало помогают руководству принимать решения.
• Отдельная задача – обнаружение «слепых зон»: неучтенных систем, устаревших компонентов инфраструктуры, забытых внешних ресурсов, забытых учетных записей и доступов.
• Итогом должна быть не только фиксация текущего состояния, но и понятная программа дальнейших действий с разделением по приоритетам.

RUБЕЖ: По опыту проектов ICL Services, с какими ожиданиями заказчики чаще всего приходят на аудит и что для них оказывается неожиданным по его итогам?

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

На что стоит обратить внимание:

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

Утечки и корпоративные риски

RUБЕЖ: Какие каналы утечки корпоративных данных сегодня требуют наибольшего внимания? Как на эту картину повлияло распространение генеративного ИИ и внешних облачных сервисов?

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

Если говорить о цифрах, то 50,5% случаев упомянуто в одном из отраслевых исследований 2026 года: из 102 российских компаний 42,4% сообщили о подозрениях на утечки конфиденциальной информации через ИИ-инструменты без подтвержденных случаев, а 8,1% – о зафиксированных инцидентах. Поэтому уместно предположить, что 50,5% компаний либо подозревают такие утечки, либо уже фиксировали их, но не о том, что половина компаний столкнулась с подтвержденными утечками.

На что стоит обратить внимание:

• Сотрудники, не осознавая последствий, могут загружать во внешние ИИ-сервисы исходный код, конфигурации, журналы ошибок, договоры, клиентскую и финансовую информацию, персональные данные и внутренние документы.
• Возникает отдельная проблема неконтролируемого использования ИИ-сервисов: сотрудники могут применять инструменты, которые компания официально не внедряла и не контролирует.
• С точки зрения пользователя сценарий выглядит безопасно: «попросил ИИ проверить код» или «сделать краткое содержание договора». С точки зрения ИБ чувствительная информация при этом может покинуть контролируемый периметр.
• Облачные сервисы в целом увеличивают количество внешних сервисов, которые сотрудники вполне законно используют в работе, поэтому простой контроль по признаку «данные ушли наружу» уже недостаточен.
• В том же отраслевом исследовании 2026 года 63,6% компаний указали на нехватку обучения сотрудников и внутренних политик безопасного использования ИИ. Это дополнительно показывает, что проблема не решается только техническими средствами.
• Полный запрет новых инструментов может привести к тому, что сотрудники просто начнут использовать личные или несогласованные сервисы. Более устойчивый вариант – определить разрешенные сервисы, допустимые сценарии и категории информации, которую передавать нельзя.

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

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

На что стоит обратить внимание:

• Сначала нужно понять бизнес-сценарий и ценность данных, а уже затем выбирать механизм контроля и защиты.
• Разные категории информации требуют разных ограничений. Одинаковые ограничения для публичных материалов и коммерческой тайны будут либо слишком слабыми для одного случая, либо избыточными для другого.
• Мы предпочитаем модель «разрешено при определенных условиях» вместо тотального запрета там, где технология действительно нужна бизнесу и не несет серьезных рисков.
• Для ИИ это может быть перечень разрешенных инструментов и отдельные правила для исходного кода, персональных данных, финансовой информации, коммерческой тайны и других чувствительных категорий.
• В идеале контроль должен быть встроен в обычный рабочий процесс и не заставлять сотрудника каждый раз искать обходной путь.
• Один из признаков того, что ограничения стали контрпродуктивными, – массовое использование личной почты, мессенджеров, несанкционированных облачных и других внешних сервисов для выполнения обычных рабочих задач.
• ИБ при этом должна сохранять возможность остановить операцию, если возможный ущерб несопоставим с пользой, которую получает бизнес.

RUБЕЖ: Что сегодня эффективнее в борьбе с утечками: технические средства защиты или работа с процессами и поведением сотрудников? Как эти подходы должны сочетаться?

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

На что стоит обратить внимание:

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

Как управлять уязвимостями

RUБЕЖ: В инфраструктуре крупной компании могут одновременно находиться тысячи уязвимостей. Как определить, какие из них действительно создают риск для бизнеса и требуют устранения в первую очередь?

Алексей М.: Я думаю, не для кого не секрет, что приоритизацию давно уже не строят только на CVSS оценке, и даже в комбинациях с KEV и EPSS. Техническая оценка критичности – важный сигнал, но при оценке риска мы смотрим сразу на несколько факторов: критичность актива для бизнеса, доступность уязвимого компонента для атакующего, вероятность эксплуатации, механизмы противодействия, последствия компрометации и действующие компенсирующие меры. В итоге одна и та же уязвимость на двух разных системах может иметь совершенно разный приоритет.

На что стоит обратить внимание:

• В первую очередь нужно понимать сам актив: какую функцию он выполняет и какой ущерб возникнет при его компрометации.
• Доступный из интернета сервис в обязательном порядке требует особого внимания, чем изолированный второстепенный хост с тем же набором уязвимостей. Нужно обязательно учитывать наличие публичного эксплойта, возможности повышения привилегий и дальнейшего перемещения внутри скомпрометированной инфраструктуры.
• Один из наиболее серьезных сигналов для специалиста ИБ – подтверждение того, что конкретная уязвимость уже эксплуатируется в реальных атаках (например, KEV– Known Exploited Vulnerabilities).
• Дополнительным фактором может быть статистическая вероятность эксплуатации уязвимости в ближайшем будущем, но такой показатель нельзя воспринимать как готовую оценку риска без контекста конкретной организации.
• Компенсирующие меры также меняют приоритет: сегментация, фильтрация трафика, средства защиты конечных точек, ограничения доступа или отсутствие уязвимой функции могут существенно снижать практический риск.
• В конечном счете вопрос должен звучать не «Какой CVSS у этой CVE?», а «Что реально сможет сделать атакующий, если эксплуатирует ее именно в нашей инфраструктуре и с нашими защитными мерами?».

RUБЕЖ: Где на практике чаще возникают проблемы в управлении уязвимостями: при обнаружении, определении приоритетов, устранении или последующем контроле?

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

На что стоит обратить внимание:

• В крупной инфраструктуре средства анализа могут находить больше уязвимостей, чем команды реально способны устранить имеющимися силами и в разумные сроки.
• Поэтому первое узкое место – приоритезация. Без риск-ориентированного подхода команда начинает работать с длинным списком технических рейтингов, а не с реальными рисками.
• Вторая типичная проблема – закрепление ответственности. Если неизвестно, кто отвечает за конкретный актив или приложение, устранение просто зависает между подразделениями.
• Далее появляются эксплуатационные ограничения: обновление нужно протестировать, согласовать окно работ, проверить совместимость и иметь возможность откатиться назад, в случае форс мажоров.
• Устаревшие системы усложняют задачу еще сильнее: исправление может требовать обновления приложения, операционной системы, библиотек или даже полной замены компонента, а это как правило нетривиальная задача.
• Наконец, процесс не заканчивается сообщением администратора «обновление установлено». Необходима в дальнейшем подтвердить, что уязвимость действительно была устранена.

RUБЕЖ: Можно ли сегодня выстроить управление уязвимостями как непрерывный процесс и что для этого должно измениться во взаимодействии ИТ- и ИБ-команд?

Алексей М.: Да, и для крупной постоянно меняющейся инфраструктуры мы считаем такой подход наиболее оправданным. Но непрерывное управление уязвимостями – это не просто регулярный запуск сканера, это все-таки цикличный, всесторонний процесс от актуальной инвентаризации активов и обнаружения уязвимости до ее приоритезации, согласования и постановки задачи ответственному лицу, устранения и подтверждения результата, и что самое важно это эффективное синергичное взаимодействие между ИТ и ИБ, где коллеги, находят общие пути решения проблем, с учетом всех аспектов и бизнес рисков, вместо того, чтобы директивно ставить задачи и не менее виртуозно их отклонять по причинам мнения «нецелесообразности» только с одной стороны.

На что стоит обратить внимание:

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

Что можно передать внешней команде

RUБЕЖ: Как за последние два-три года изменились запросы заказчиков ICL Services в области ИБ? Какие задачи компании стали чаще передавать внешним специалистам?

Алексей М.: Мы видим, что заказчики постепенно переходят от точечных задач по отдельным средствам защиты к более комплексной сервисной модели, покрывающей не только СЗИ, но и работу с процессами. После 2022 года отдельным большим направлением стала перестройка технологического стека и локализация ИБ-инфраструктуры. Параллельно все больше внимания уделяется не только внедрению средств защиты, но и их дальнейшей эксплуатации, мониторингу и реагированию на инциденты ИБ силами MSSP провайдеров. В нашей практике этот переход происходит достаточно часто с повышением уровня зрелости: от сопровождения отдельных СЗИ мы далее плавно переходим к подключению к SOC, более проактивной защите и комплексным управляемым сервисам, закрывающим основные домены ИБ и вектора атак. Если говорить об основных задачах, то это безусловно и SOC, и работа с такими СЗИ и технологиями как EDR/XDR, VM, PAM, NGFW, SD-WAN, защита электронной почты, мобильных устройств, работа с повышением осведомленности сотрудников.

На что стоит обратить внимание:

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

RUБЕЖ: В какой момент компании становится рациональнее передать часть задач по ИБ внешней команде, чем продолжать наращивать собственный штат и компетенции?

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

На что стоит обратить внимание:

• Первый критерий – режим работы. Построить полноценную функцию 24/7 значительно сложнее и дороже. Сервис провайдеры в этом плане предоставляют более выгодные условия.
• Второй – дефицит компетенций. Для некоторых задач нужны сразу несколько узкопрофильных специалистов, при этом внутри небольшой или средней компании для них может просто не быть постоянного объема работы и встает вопрос о целесообразности затрат против потенциальных рисков и потерь.
• Третий – стоимость технологии и инфраструктуры. В сервисной модели часть капитальных вложений заменяется прогнозируемыми операционными затратами.
• Четвертый – возможность масштабирования. Внешняя команда обычно может быстрее нарастить ресурсы при всплеске нагрузки.
• Пятый – приоритеты собственной команды. Иногда выгоднее сохранить внутри архитекторов и владельцев процессов, а операционную работу передать внешней команде.
• Для нас сигнал к обсуждению аутсорсинга – когда внутренняя команда большую часть времени поддерживает работу средств защиты и не успевает заниматься развитием ИБ.

RUБЕЖ: Что на практике представляет собой модель ИБ "все включено"? Какие функции можно передать провайдеру, а какие компании лучше сохранить внутри?

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

Сервис-провайдеру можно передать часть операционных функций ИБ:

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

Внутри компании мы бы сохраняли:

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

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

RUБЕЖ: Были ли в практике ICL Services ситуации, когда вы, наоборот, рекомендовали заказчику оставить определенные функции ИБ внутри компании? От чего зависит такое решение?

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

На что стоит обратить внимание:

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

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

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

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

RUБЕЖ: Есть ли подход к информационной безопасности, который несколько лет назад казался вам правильным, но практика заставила пересмотреть свое мнение?

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

На что стоит обратить внимание:

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

Читайте также: Защита ИИ: как предприятиям защитить данные и инфраструктуру в эпоху искусственного интеллекта