ИБ-эксперт Григорий Слинкин — о том, как должна быть устроена ИБ-служба крупной компании и проблемах с российскими ИБ-продуктами

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

Сейчас у ИБ достаточно много интересных инструментов, которые могут помочь с защитой данных, например такой класс решений, как системы инвентаризации и защиты данных DCAP (Data-Centric Audit and Protection). Данный класс решений примечателен тем, что такие решения помогают не просто найти данные в инфраструктуре, но и систематизировать их и помочь тем самым в вопросах снижения уровня рисков в части защиты конфиденциальной информации. Сформировать прозрачную и понятную для пользователей матрицу доступа к ресурсам. Автоматизировать обработку и анализ большого объема данных: события системы, действия пользователей, операции с файлами. Обеспечить автоматизированный контроль.

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

Григорий Слинкин: Третья задача — это повышение киберграмотности сотрудников или как сейчас модно говорить киберкультура (awareness). Человеческий фактор остается одной из главных причин инцидентов. СИБ должна проводить обучение, тестировать сотрудников на уязвимость к фишингу и другим атакам, а также внедрять политики безопасного поведения.

Хочу рассказать про один очень интересный проект, который мы осуществили с коллегами в одной из российских компаний. Это повышение уровня киберкультуры через детей работников. Мы разработали курсы и мероприятия для детей работников компании по информационной безопасности (ИБ), где в простом формате рассказывали, что такое ИБ, как мы работаем и почему то, что иногда не очень удобно, является необходимым. Мы снимали видео, скетчи. Делали стикерпаки и многое другое, но, самое главное, мы приглашали детей на киберучения, реализовывали с ними различные атаки. Пытались поймать родителей на удочку социальной инженерии. И, знаете, результат этой деятельности просто поразил. Дети стали учить родителей быть осмотрительнее в киберпространстве. Начали не просто помогать родителям установить второй фактор в телеграмме, но интересоваться, как можно обезопасить себя и не ущемлять себя в удовольствиях интернета. Вишенкой кейса стала просьба от ребят посетить музей криптографии. Кстати, читателям очень рекомендую туда сходить и в особенности пройти вместе с экскурсоводом.

Григорий Слинкин: Четвертая задача — это мониторинг и предотвращение кибератак. СИБ должна круглосуточно отслеживать сетевую активность, выявлять подозрительные действия и оперативно реагировать на инциденты. Это включает в себя использование систем предотвращения вторжений (IPS), антивирусов, анализа трафика и других инструментов.

В больших компаниях функцию мониторинга обычно выполняет отраслевой оперативный центр по безопасности — SOC (Security Operation Center). В основном это касается холдингов. Обычно же компании прибегают к внешним услугам, в частности, по MSSP модели. Они также могут использовать решения для защиты внешнего периметра сами, например, продавая услуги внутри группы компаний. В России в меньшей степени, но в мире такая практика успешно применяется. Не все могут себе позволить содержать SOC с тремя–четырьмя линиями круглосуточной поддержки. А учитывая специфику защиты, например, АСУ ТП или финтеха, может встать еще и вопрос кадров. Гид по системам SOAR: 9 наиболее заметных продуктов, доступных на российском рынке 10.3 т

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

Кстати, иногда предприятия совмещают SOC и службы мониторинга ИТ-инфраструктуры. Это очень круто, но в тоже время тяжело. Плюс в том, что время реагирования и разбора события уменьшается в разы.

Хотел бы отметить, что многие компании начали все чаще использовать платформы коммерческого поиска уязвимостей (bug bounty) – это полезно и очень продуктивно для повышения уровня безопасности. А если у вас есть еще и команда внутренних тестировщиков («Red Team»), то это уже путь к полноценному конвейеру безопасности. К сожалению, пока не все компании могут себе такое позволить. Но все ближе и ближе к этому, что не может не радовать.

Григорий Слинкин: Пятая задача — это реагирование на инциденты и восстановление. СИБ должна иметь четкий план действий на случай атаки: как быстро локализовать угрозу, минимизировать ущерб и восстановить нормальную работу систем. Это также включает анализ инцидентов для предотвращения подобных ситуаций в будущем.

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

Григорий Слинкин: Сложная, но выполнимая задача — это поддержка цифровой трансформации. СИБ должна не только защищать, но и способствовать внедрению новых технологий, таких как «интернет вещей» (IoT), облачные сервисы или большие данные, обеспечивая их безопасность. Это помогает предприятию оставаться конкурентоспособным, не подвергаясь дополнительным рискам. Конечно же, стоит использовать и ИИ, но все должно быть в меру. Модели мощные — умеют помогать, но, как мы видим, они уже помогают и темной стороне.

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

Григорий Слинкин: В СИБ важно выделить несколько ключевых ролей, которые будут охватывать все аспекты защиты ресурсов. Сразу скажу, что можно, а иногда даже нужно, совмещать обязанности и брать на себя одну или несколько ролей – это нормально. Например, специалист по осведомленности может также быть аналитиком и работать с DCAP или DLP (Data Loss Prevention). Все зависит конечно же от задач. Идеальная модель, которой стоит придерживаться, думаю, будет выглядеть так:

1. Руководитель СИБ (CISO). Это стратегическая роль. Руководитель отвечает за разработку политик, стратегии безопасности, управление бюджетом и взаимодействие с топ-менеджментом. Он также координирует работу всех подразделений СИБ.
2. Аналитики по киберугрозам. Эти специалисты занимаются мониторингом угроз, анализом уязвимостей и прогнозированием возможных атак. Они работают с системами SIEM (Security Information and Event Management) и другими инструментами для сбора и анализа данных.
3. Специалисты по защите данных. Их задача — обеспечить конфиденциальность, целостность и доступность данных. Они занимаются шифрованием, управлением доступом, DLP-системами и соблюдением требований GDPR, PCI DSS и других стандартов.
4. Инженеры по безопасности сетей и инфраструктуры. Эти специалисты отвечают за защиту сетевого периметра, настройку межсетевых экранов, VPN, IDS/IPS (системы обнаружения и предотвращения вторжений), а также за безопасность облачных сервисов и виртуальных сред.
5. Специалисты по безопасности промышленных систем (ICS/SCADA). В холдингах с производственными активами эта роль критически важна. Они занимаются защитой систем управления технологическими процессами, чтобы предотвратить аварии и простои.
6. Специалисты по реагированию на инциденты (SOC-аналитики). Они работают в оперативных центрах безопасности и занимаются выявлением, анализом и устранением инцидентов. Их задача — минимизировать ущерб от атак.
7. Аудиторы и специалисты по исполнению законодательных требований (compliance). Эти сотрудники следят за соблюдением нормативных требований, проводят внутренние аудиты и готовят отчеты для регуляторов.
8. Специалисты по обучению и осведомленности. Они отвечают за повышение киберграмотности сотрудников холдинга, проводят тренинги и тестируют устойчивость к фишингу и другим атакам с помощью социальной инженерии.

Григорий Слинкин: Распределение должно быть основано на принципе «разделения обязанностей» (SoD — Separation of Duties). Например можно структурировать так:

• Руководитель СИБ координирует все процессы, ставит задачи и контролирует их выполнение.
• Аналитики по киберугрозам и SOC-аналитики работают вместе: первые выявляют угрозы, вторые — оперативно на них реагируют.
• Специалисты по защите данных и инженеры по безопасности сетей взаимодействуют для обеспечения комплексной защиты: от уровня данных до уровня инфраструктуры.
• Специалисты по ICS/SCADA работают в тесной связке с производственными подразделениями, чтобы не нарушать технологические процессы.
• Аудиторы и compliance-специалисты проверяют выполнение требований всеми подразделениями.
• Специалисты по обучению взаимодействуют с HR и всеми сотрудниками холдинга.

Григорий Слинкин: В крупных холдингах с филиалами можно использовать модель «централизованного управления с делегированием». Центральная СИБ разрабатывает единые политики и стандарты, а в каждом филиале назначается локальный ответственный за ИБ. Он внедряет эти стандарты на месте и отчитывается перед центральной СИБ.

ФИО: Да, это вполне оправданно. Например, можно привлекать внешних специалистов для тестов на проникновение (пентестов), аудитов или реализации сложных проектов, таких как внедрение SOC. Однако ключевые функции, такие как управление доступом или реагирование на инциденты, лучше оставить внутри компании.

Григорий Слинкин: ИТ-отделы в каждой компании свои. Это параллельная служба, которая работает через CRM-систему и использует модель жизненного цикла ПО (SDLC) при создании новых продуктов – через систему заявок и выстроенный процесс обслуживания внутренних потребителей. ИТ что-то придумывает и реализует, а руководство это контролирует. Серьезных конфликтов нет, потому что процесс понятный, все видят, что происходит и что нужно делать. Есть только гибкое взаимодействие. Конечно, бывают какие-то недопонимания с обеих сторон, например, при проектировании и внедрении новых информационных систем, но они все решаются в рабочем порядке – это наша жизнь. Мы все в одной лодке, и нужно всегда искать компромиссы, иначе конечный пользователь и бизнес будут нести потери, а этого нельзя допустить.

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

Организаторами новых проектов, как правило, выступает ИТ-служба, которая собирает заявки, и взаимодействует с ИБ по реализации требований по информационной безопасности. Аналогично и со стороны информационной безопасности. Если ИБ-службе что-то необходимо, то она выступает организатором процесса, приходит в ИТ и запускает тот же конвейер, но уже со своей стороны. Аналогичное взаимодействие может быть выстроено и в рамках АСУ на основе того же конвейера.

Григорий Слинкин: В основном ИИ на базе ML-модели для решения очень частных задач. Если говорить про SOC, то многие начали работать с ML-моделями и искусственным интеллектом в составе SOC. Мне довелось разрабатывать большой проект в части математического моделирования, где были предложения использовать искусственный интеллект для реагирования на инциденты. Из-за большого объема обрабатываемых данных мы хотели уменьшить нагрузку на работников за счет автоматизации обработки первичных данных. Она позволила бы создать решение, которое может на основе всех данных из источников, которые поступают в SOC компании, предсказать появление инцидентов. ML-модели собирает данные из SIEM, проводит расчеты и при помощи ИИ выявляет сегменты сети, где может возникнуть инцидент или с какой долей вероятности может произойти реализация уязвимости. Интерес всей системы в том, что можно брать не просто данные с межсетевых экранов, EDR (Endpoint Detection and Response), VM (Vulnerability Management) и других источников, но и с платформ awareness. На основе этих данных мы можем выявить группы риска, как среди бизнес-пользователей, так и технических специалистов.

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

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

Сейчас люди все больше доверяют искусственному интеллекту и где-то — расслабляться. Если искусственный интеллект что-то сказал, то они считают — он не может ошибиться, его рекомендации – правда в последней инстанции. К сожалению, пока это не всегда так. Мы наблюдали случаи, когда ИИ не обнаруживал опасной уязвимости или, наоборот, ошибка была выявлена, но искусственный интеллект помечал ее как некритичную. В результате таких ошибок, могут случиться опасные внутренние инциденты. И тут стоит отметить важность специалистов по безопасности ИИ (AI Security). И самое важное, как мне кажется, не стоит использовать ИИ или ML, если ты не знаешь, что у него под капотом. Должен быть такой же подход как в процессе безопасной разработки.

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

Григорий Слинкин: Конечно. Сейчас, мне кажется, все их используют это уже как правило хорошего тона. Более того, я считаю необходимо развивать набор MSSP-услуг в отраслевых центрах безопасности, с помощью которых компании в составе холдинга или отрасли, которые по тем или иным причинам не могут себе позволить самостоятельно приобрести PAM-системы, будут приобретать их как услугу и при этом не выходить за пределы контура. У меня был опыт по осуществлению и контролю уже работающих PAM-систем.

Я работал в SOC, где составляли матмодель с интегрированным искусственным интеллектом, в который собирались все события для мониторинга и реагирования. Модель объединяла все данные и коррелировала их. В результате, для определенных сегментов – мы могли понять какое событие и где может произойти. Это технология предреагирования, которую мы только начали в этом проекте создавать. В этом направлении у нас были определенные успехи. При этом VM у нас является основным поставщиком информации об уязвимостях, о проблемах сегментов сети.

Григорий Слинкин: Ключом должна быть система управления уязвимостями – можно использовать коммерческое решение, можно собрать свое. Также в компании может быть свой «Red Team». Его специалисты проводят общий анализ на защищенность у случайно выбранного участника холдинга и пытаются пробить его защиту. Это можно назвать внутренним bug bounty.

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

Григорий Слинкин: Обычно в АСУ ТП очень мало облачных технологий – только для каких-то внешних проектов. Промышленные предприятия традиционно не сторонники внешней облачной инфраструктуры, что логично. Частные облака – да. Внутри предприятий холдинга можно допустить частные облака и работу с контейнерами – от нее никуда не деться. Также необходимо обеспечивать безопасность данных в облачной конфигурации и обеспечивать проверку контейнеров на безопасность.

Также не стоит забывать о рисках и вообще о риск-ориентированном подходе. Я бы выделил на мой взгляд наиболее критичные:

1. Совместная ответственность. В облаках используется модель shared responsibility, где провайдер отвечает за безопасность инфраструктуры, а клиент — за данные и доступ. Непонимание этой модели может привести к пробелам в защите.
2. Соответствие требованиям. Хранение данных в облаке может вызывать сложности с соблюдением нормативных требований, таких как GDPR или PCI DSS (особенно в финансовой сфере).
3. Атаки на интерфейсы управления. Облачные сервисы часто управляются через веб-интерфейсы или API, которые могут стать мишенью для атак.

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

1. Шифрование данных. Все данные, хранящиеся в облаке, должны быть зашифрованы как при хранении, так и при передаче. Это минимизирует риск утечки даже в случае компрометации.
2. Управление доступом. Использование строгой аутентификации (например, многофакторной — MFA) и принципа наименьших привилегий помогает предотвратить несанкционированный доступ.
3. Мониторинг и анализ угроз. Внедрение решений для мониторинга активности в облаке (например, Cloud Access Security Brokers — CASB) позволяет выявлять подозрительные действия и оперативно реагировать на инциденты.
4. Резервное копирование и восстановление. Регулярное резервное копирование данных и тестирование процедур восстановления помогают минимизировать ущерб от атак, таких как шифровальщики.
5. Совместная ответственность. Важно четко понимать, какие аспекты безопасности обеспечивает провайдер (например, физическая безопасность ЦОДов), а какие — клиент (например, настройка брандмауэров и управление доступом).
6. Соблюдение нормативных требований. Необходимо выбирать облачных провайдеров, которые соответствуют международным стандартам (ISO 27001, SOC 2) и предоставляют инструменты для соблюдения GDPR, HIPAA и других нормативных требований.
7. Защита API. Операторы облачных сервисов предлагают свои API для управления арендованными ресурсами, поэтому они должны быть защищены от атак, таких как DDoS или инъекции. Это включает использование аутентификации, шифрования и мониторинга.
8. 8. Обучение сотрудников. Персонал должен быть обучен правилам работы с облачными сервисами, включая безопасное использование интерфейсов и предотвращение фишинга.

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

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

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

• CASB (Cloud Access Security Broker): для мониторинга и контроля доступа к облачным сервисам.
• SIEM (Security Information and Event Management): для анализа событий безопасности в облаке и локальной инфраструктуре.
• Разработанных для облаков средств защиты (Cloud-native Security): например, AWS GuardDuty, Azure Security Center или Google Cloud Security Command Center, которые предоставляют встроенные инструменты для защиты.
• Шифрования: такие инструменты, как AWS KMS (Key Management Service) или Azure Key Vault, для управления ключами шифрования.

Григорий Слинкин: Конечно же, это назначение ответственных лиц. И лучше когда защитой ПДн занимается не только подразделение безопасности, но и вовлечены HR, юристы и работники договорных направлений. Во многих компаниях сейчас идет большая работа по назначению руководителей по работе с данными (Chief Data Officer – CDO). В большинстве компаний выделяют целые подразделения по защите и работе с персональными данными, которое занимается методологией и собственно защитой. Они объединяют функции защиты ПДн, обработки, анализа и подготовки к обучению. Очень хорошо, когда руководители понимают что осведомленность также является неотъемлемой частью и наделяют подразделения такими полномочиями как повышение осведомленности пользователей по вопросам информационной безопасности – Security Awareness (SA). Это классические задачи по осведомленности и работе с учебными платформами.

Григорий Слинкин: С улыбкой, болью и преодолением сложностей на каждом этапе. Это сейчас больной для всех вопрос. Но это классные кейсы, благодаря которым мы всесторонне можем дополнительно прокачать свои компетенции, навыки и нервы. Особенно когда речь идет про межсетевые экраны нового поколения (NGFW), почтовые системы и ОС. Мне кажется ребята, которые сейчас готовят новые «золотые» образы, прослезились.

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

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

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

Если говорить про централизованное управление всеми СЗИ, то его организовать вряд ли получится – только по каким-то отдельным классам продуктов. Можно сделать единую консоль для SIEM, VM, EDR и антивируса. Это будет удобно для контроля рабочих станций. Но в части сетевой безопасности будет удобнее использовать консоль NGFW и NAC (Network Access Control). Если рассмотреть продукты всеми любимого Cisco или Fortinet, то у них большинство функций и так объединены. И интегрировать их с чем-то ещё — это дело вкуса для каждого. Но кому-то, наоборот, неудобно работать в единой консоли с огромным количеством функций, потому что в ней много всего надо делать, и не всегда понятно где и как найти нужную функцию. Объединение управления стоит делить только по отдельным крупным классам.

Для меня, например, удобно, когда есть единый процесс управления доступом. Мечта, чтобы под единой консолью были объединены решения по многофакторной аутентификации (MFA), PAM и IDM. Отдельно работа с конечными устройствами – это EDR, VM и антивирус. Отдельно работа с событиями – SIEM, SOAR, IRP-система. Такое разделение удобно. Поэтому стоит укрупнять, но больше всего хочется, чтобы между разработчиками было более глубокое взаимодействие. Мы часто сталкиваемся с негласной войной между разработчиками, когда одно решение не очень хорошо поддерживает другое, и от этого страдает не только заказчик, но и вся система безопасности в целом.

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

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

Григорий Слинкин: NAC-решений и систем контроля конфигураций сетевых устройств. По классам мы очень сильно отстаем в разработке NAC. В части сетевой безопасности NAC прямо очень нужен. Я внедрял NAC-решение, но приходилось просить очень много доработок. И опять же – проблемы с поддержкой решений.

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