Тренды корпоративной ИБ: как меняются запросы бизнеса в условиях импортозамещения
Рост числа атак и параллельный курс на технологический суверенитет меняют логику построения защиты в компаниях. Бизнесу приходится тщательно продумывать, как усилить контур, выбрать оптимального поставщика, избежать простоев и инцидентов и при этом не выйти за рамки бюджета. О том, как изменились запросы компаний в сфере информбезопасности, рассказывает Иван Чернов, директор по продуктовой стратегии UserGate.
Сдвиг приоритетов ИБ
Подходы бизнеса к информационной безопасности сейчас в основном определяются двумя факторами. Во-первых, это постоянный рост числа атак, и во-вторых – курс на технологический суверенитет. Вместе оба этих момента меняют подход к защите в целом. Раньше заказчики ограничивались базовым контуром, куда входили антивирус, сетевой экран и система резервного копирования. Этот набор закрывал основную массу типовых угроз и позволял считать, что защита выстроена на приемлемом уровне.
На фоне роста атак произошли два принципиальных изменения. Во-первых, расширилась аудитория, на которую направлены атаки. Еще несколько лет назад логика «наша компания никому не интересна, поэтому в развитие контура можно особо не вкладываться» в целом работала. Теперь автоматизированные инструменты атаки позволяют действовать без разбора. Сканирование, поиск уязвимостей и потенциальных жертв запускаются массово, а уже после попыток эксплуатации подключаются злоумышленники, оценивающие, что можно получить от каждой конкретной цели. Поэтому тезис «мы не представляем выгоды для хакеров, поэтому нас не будут атаковать» перестал быть актуальным. Это приводит к необходимости наращивать базовый слой защиты и не ограничиваться только классическими средствами. Как следствие, наблюдается тренд на комплексную защиту вместо точечного закрытия брешей, что, в свою очередь, вызывает рост бюджетов на ИБ.
Второй фактор связан с технологическим суверенитетом. Регуляторы требуют от бизнеса использования отечественных средств защиты. Накладываются и санкционные моменты, поскольку ряд некогда привычных решений сегодня не поставляются в Россию, а доступность софтвера уже не означает, что к нему автоматически прилагается сервисное обслуживание. На практике это привело к тому, что требования к качеству средств защиты повышаются, а предложение на рынке сужается. Такое сочетание заставляет пересматривать фундаментальные подходы к построению инфраструктуры и контура безопасности: выбирать приходится из меньшего числа вариантов, но при этом необходимо находить среди них лучшие.
Импортозамещение и выбор поставщиков
Критерии выбора поставщиков также изменились. Раньше рынок был понятнее, поскольку существовали признанные лидеры. Теперь заказчику часто не вполне очевидно, к кому обращаться, и процесс становится более избирательным. Как следствие, приходится тратить больше времени на тестирование, сравнение и пилотирование. Это и неудивительно: рост угроз усиливает запрос на более качественные решения, предложение достаточно ограничено, и лучше потратить больше времени на проверку, чем приобретать недешевого кота в мешке. На этом фоне вырос спрос на независимые сравнения и исследования, а также на лаборатории интеграторов, которые помогают увидеть различия между решениями.
Есть и еще один важный сдвиг. Раньше поставщики нередко были комплексными и закрывали широкий спектр задач в рамках одного бренда. Заказчик мог работать с одним-двумя вендорами и выстраивать контур вокруг них. Сегодня предложение сузилось, и бизнес вынужден собирать набор продуктов от более широкого круга поставщиков. Их число растет, что может восприниматься как неудобство – управлять несколькими вендорами сложнее, контур становится более разношерстным.
Ключевое требование к поставщику также продиктовано временем. Сейчас на первом месте стоит соответствие регуляторным требованиям и нормативной базе: сертификация ФСТЭК России, сертификация ФСБ России, присутствие в реестре отечественного ПО. Во вторую очередь заказчик смотрит, есть ли у вендора крупные внедрения, поскольку ему важно видеть, как решение работает в реальной практике других организаций. Нередко запрашиваются референс-знакомства с другими клиентами, а также прямое общение с разработчиком. В этом есть заметное отличие от прежней практики. В случае с зарубежными производителями подобные встречи были доступны ограниченному кругу очень крупных заказчиков, тогда как с отечественным разработчиком это стало проще реализовать с организационной точки зрения. Усилилось и внимание к финансовой устойчивости поставщика. Заказчики опасаются, что компания с небольшими оборотами и ограниченной командой не сможет поддерживать решения долгие годы, поэтому репутация вендора также выступает важным критерием выбора.
Вам также может быть интересен материал Клуба ИТ-лидеров Global CIO:
Переход на российское ПО: обмен опытом
ИТ-директора обсудили реальный опыт миграции с Oracle на PostgreSQL, критерии выбора российских продуктов и выбор между SaaS и развёртыванием в контуре. В материале — координация ИТ и ИБ при управлении сотнями настроек безопасности и честный разговор о главных препятствиях: нехватке квалификации и сложности интеграций.
От скепсиса к сотрудничеству
В процессе миграции на отечественные решения заказчика не в последнюю очередь интересуют их слабые стороны. Очевидно, что у каждого набора продуктов есть собственный набор уязвимостей. Мировые поставщики – не исключение, но список их уязвимостей давно изучен и находится в публичном доступе, то есть сюрпризы для бизнеса сводились к минимуму. Российские решения гораздо новее, а потому изучены не так глубоко. К тому же не все компании стремятся рассказывать об уязвимостях публично. Да и система поиска уязвимостей в отечественных реалиях пока еще развита не так хорошо, как хотелось бы, особенно у небольших компаний. В результате клиентов могут ждать неприятные сюрпризы в процессе интеграции или эксплуатации.
При этом из-за изменения ландшафта на периметре организации, когда одни решения заменяются другими, перестраивается карта рисков и уязвимостей. Фундаментально меняются предпосылки, данные о возможных обходах и ограничениях, поэтому перенести старую логику контроля на новый набор отечественных продуктов зачастую невозможно. Требуется заново выстроить оценку и управление рисками. На этом фоне сертификация и практики безопасной разработки воспринимаются как индикатор, снижающий риск получить проблемы из-за использования ПО.
Параллельно развивается осторожный, но заметный сдвиг в сторону сервисных моделей. Например, SOC как сервис – построить собственный центр мониторинга 24/7 могут позволить себе только очень крупные компании, поскольку для круглосуточной работы требуется значительный штат. И даже если на это есть бюджет, то в реалиях дефицита кадров не всегда получится набрать команду с желаемой экспертизой. Выходом становится использование модели SECaaS, которая позволяет ее получить извне.
Наконец, меняется отношение бизнеса к отечественным платформам и решениям. Скепсис вытесняется сотрудничеством, а заказчики все лучше понимают, что зрелость решений будет достигаться через совместную работу с поставщиком. Диалог принимает более открытые формы: обсуждаются недостатки отечественных решений, направления развития и приоритеты. Это ускоряет обмен информацией и помогает разработчикам точнее понимать, чего пока еще не хватает российским продуктам и как это реализовать.
