Сложности и результаты. От простого сканирования к управлению уязвимостями

BIS Journal №2(45)/2022

3 мая, 2022

Сложности и результаты. От простого сканирования к управлению уязвимостями

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

В 2021 году мы провели анализ защищённости банков, чтобы проверить, можно ли получить доступ к критически значимым для банков системам (АРМ казначейства, серверам обмена платёжными поручениями) и вывести денежные средства с корпоративных счетов. Интересно то, что во всех тестовых проектах заявленные риски удалось реализовать. Кроме того, получилось выполнить ряд действий, способных нарушить бизнес-процессы банка и повлиять на качество оказываемых услуг. В каждой организации были выявлены множественные уязвимости, позволявшие внешнему нарушителю проникнуть во внутреннюю сеть компании.

Чтобы узнать, насколько хорошо защищена финтех-организация, специалисты по ИБ исследуют ИT-инфраструктуру и код (Infrastructure-as-Code – инфраструктура как код) на предмет уязвимостей. Для первого подходят сканеры оборудования и программного обеспечения. К ним относятся инструменты для проверки сети и системы анализа защищённости, некоммерческие инструменты. Для второй задачи предназначены сканеры кода, которые находят в нём ошибки с помощью статического и динамического анализа, а также проверяют уже запущенное приложение в интерактивном режиме.

Давайте рассмотрим, в каких случаях классических сетевых сканеров будет недостаточно бизнесу, когда ему стоит задуматься о построении процесса vulnerability management (VM – управление уязвимостями), а также с какими сложностями сталкиваются специалисты по ИБ при организации этого процесса.

 

КАК СЕЙЧАС ПРОВОДЯТ АНАЛИЗ

По данным нашего опроса о процессе VM в российских компаниях, 26% специалистов по ИБ используют некоммерческие утилиты для сканирования сети. Такие инструменты подходят для проверки портов и служб на периметре, однако не дают информации о составе сети, об уязвимостях ПО, баз данных, а также не выявляют ошибки конфигураций. Коммерческими системами анализа защищённости пользуются 63% опрошенных компаний. Такие системы обычно поддерживают сканирование в режиме белого ящика (audit) и чёрного ящика (pentest) и обеспечивают более качественную и полную проверку. В отличие от сканеров и утилит, они позволяют оценить общее состояние защищённости инфраструктуры и направлены на то, чтобы облегчить процесс устранения уязвимостей. Коммерческие системы дают возможность построить в компании полноценный процесс vulnerability management за счёт автоматизированной работы с активами и найденными уязвимостями, а также за счёт экспертизы вендоров.

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

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

 

КАКИЕ МОГУТ БЫТЬ СЛОЖНОСТИ

Сложность № 1. Нет регламента взаимодействия ИT и ИБ

Ещё до внедрения системы управления уязвимостями важно, чтобы ожидания от неё совпадали у обеих команд. Когда всё прозрачно и понятно, участники процесса работают продуктивней.

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

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

В свою очередь, системы управления уязвимостями должны регистрировать такие договорённости и показывать отклонения. Так ИБ сможет контролировать актуальность данных об активах и соблюдение сроков патч-менеджмента, а ИT будет видеть фронт работ и понимать, что нужно делать. Всё становится прозрачно и понятно, количество вопросов у обеих служб друг к другу сводится к минимуму. Проблема длинных непонятных для ИT отчётов исчезает. При таком контроле со стороны средств защиты подразделения могут договориться об оптимальных сроках патч-менеджмента, отслеживать возникающие трудности и при необходимости проводить ревизию сроков или самого процесса.

 

Сложность № 2. У команд нет общей задачи

Какие задачи ИT и ИБ выполняют в тандеме? Оба подразделения служат общей важной цели бизнеса ― обеспечению стабильности и защищённости инфраструктуры. При построении процесса управления уязвимостями об этом не стоит забывать. KPI департамента ИБ завязан на то, чтобы не допустить реализации неприемлемых сценариев. У ИT-службы свой KPI, который зависит только от выполнения SLA по доступности инфраструктуры. Сделать компанию устойчивой к киберугрозам оба подразделения могут только сообща. При этом специфика компании отходит на второй план. Для формирования общей задачи нужно:

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

Сделать это с помощью сканеров можно, если попытаться собрать узлы в группы, но здесь есть два момента.

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

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

В системах управления уязвимостями, как правило, уже есть необходимый набор функций, способный сформировать общую задачу для ИT и ИБ. Решение такого класса способно собрать всю информацию об активе и классифицировать её по степени важности для бизнеса. MaxPatrol VM, например, показывает, какие конкретно уязвимости в данный момент актуальны для компании. Это возможно за счёт полного покрытия инфраструктуры сканированием, сбора и хранения информации об активе и его изменениях, а также импорта дополнительных данных о нём из сторонних источников. Полная информация важна каждой из команд: ИT не всегда знает актуальное состояние инфраструктуры, а ИБ это необходимо для поиска уязвимостей и запуска процесса vulnerability management на всей инфраструктуре. Если задача понятна каждому подразделению, выполнять её гораздо проще.

 

Сложность № 3. Нет единого интерфейса для команд

Система vulnerability management может служить единым окном для специалистов ИT и ИБ. Для контроля зафиксированных и обоснованных сроков на патчинг специалисты могут настраивать дашборды системы под себя. Так ИБ будет проводить мониторинг, а ИT ― следить за соблюдением дедлайнов.

Те, кто привык работать с тикетницами, могут настроить интеграцию с системами анализа защищённости через API. Главное, чтобы заявка падала не по каждой выявленной уязвимости, а выставление приоритетности не отдавалось на откуп ИT.

 

Сложность № 4. Непонятно, как приоритизировать уязвимости

Как понять, какие уязвимости самые опасные для компании? У сетевых сканеров и утилит по анализу защищённости ответа на этот вопрос нет. Максимум — такие решения проставляют оценку по метрике CVSS. Но она даёт лишь отдалённое представление об опасности. Логично, что оценка 10.0 по метрике CVSS говорит о большей опасности, чем оценка 5.5. Но не всё так просто. Опираясь только на метрику CVSS, сложно, а порой и невозможно определить минимальную оценку, при которой стоит устранять уязвимость максимально быстро. Работая только с метрикой CVSS, специалисты по ИБ могут получить вопросы от ИT. Почему именно эта уязвимость с оценкой 9.5 самая опасная? А что делать с уязвимостями с оценкой 9.0 и 8.5? Где доказательства, что уязвимость действительно опасна? После таких вопросов ибэшник может долго думать над ответами. Такое взаимодействие непродуктивно.

Некоторые производители систем анализа защищённости прибегают к самостоятельной оценке уязвимостей. Каждая метрика имеет довольно понятную формулу. В неё входят такие значения, как срок существования уязвимости, наличие эксплойта, упоминание в СМИ и других источниках, данные о вредоносном ПО. Часто мы видим, что все уязвимости просто пересчитываются по метрике вендора, и результат ничем не отличается от оценки по CVSS, а иногда может только всё усложнять. Например, уязвимость имеет оценку 9.5 по CVSS, а производитель назначает ей низкий уровень опасности.

В MaxPatrol VM есть понятие «трендовые уязвимости». Это уязвимости, которые используются злоумышленниками в реальных атаках на бизнес. Для ИБ они имеют высокий приоритет. Как правило, их количество невелико ― не более 100. Такое ограничение даёт возможность ИT успеть устранить их все, главное — договориться о дополнительном регламенте, чтобы такие уязвимости обрабатывались вне очереди. Разобравшись с трендовыми уязвимостями, ИT-команда может переходить к обычному циклу патч-менеджмента, который контролируется системой и отслеживается командой ИБ.

 

Сложность № 5. Искать уязвимости — это долго

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

Для поиска уязвимостей нужно проводить регулярное сканирование инфраструктуры. Запустить его можно не всегда. Нужно выбрать технологическое окно, проверить доступы к узлам, а после сканирования обработать его результаты. Если инфраструктура небольшая (до 1000 узлов), обычного сканера хватит, то есть он сможет проанализировать такой пул за один раз либо за отведённое, оптимальное для процессов компании, время. Но если компания большая, у неё несколько физических площадок и её инфраструктура динамическая, а количество активов постоянно меняется, то сканирование может занять несколько дней. При этом не стоит забывать и о пользователях сервисов кредитно-финансовых организаций. В пик высоких нагрузок никто не разрешит проводить сканирование инфраструктурными сканерами.

Эту ситуацию классические сканеры безопасности решают тремя способами:

  • сканируют не все узлы или только небольшие группы узлов;
  • ищут определённые уязвимости;
  • горизонтально масштабируются.

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

MaxPatrol VM может выявить уязвимости без повторного сканирования. Что это означает? Система анализа защищённости в автоматическом режиме пересчитывает применимость уязвимостей к узлам сети при обновлении базы знаний либо при изменении параметров активов. При этом сканеру не нужно активно взаимодействовать с каждым узлом. Система должна уметь собирать и хранить информацию обо всех активах сети (о конфигурации железа, об операционных системах и установленном ПО), а также уметь в процессе пассивного сканирования получать информацию о новых активах, брать информацию о них из других источников, например из решений SIEM и NDR/NTA. Также важной является корректная идентификация или «склейка» активов, которая позволяет избежать дублирования систем.

Помимо этого, MaxPatrol VM умеет делать точечные проверки или проверки на группу уязвимостей, что существенно снижает время сканирования.

При выборе систем анализа защищённости нужно понимать, какие задачи стоят перед компанией, смогут ли службы ИT и ИБ грамотно использовать внедряемые инструменты и позволит ли новая система решить основные задачи процесса vulnerability management:

  • установить прозрачное взаимодействие служб ИT и ИБ;
  • выстроить чёткие приоритеты: что устранять вне очереди, а что стандартным патч-менеджментом;
  • быстро выявлять уязвимости.

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

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

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

28.11.2022
В США запретили продажу телеком-харда из Китая
28.11.2022
Минцифры: Россия обречена на то, чтобы сделать необходимый прорыв в ИТ
28.11.2022
«… нанесёт России непоправимый вред». Майнеры недовольны новым проектом закона о майнинге
25.11.2022
Кибердружинники получат юридический статус?
25.11.2022
Стилеры атакуют пользователей Steam, Amazon и PayPal
25.11.2022
Минцифры хочет ввести систему компенсаций для жертв утечек
25.11.2022
Китайские геймеры укладываются в три часа
24.11.2022
Минцифры наметило перестановки в номенклатуре ПО
24.11.2022
Банк России привёл цифры третьего квартала: сколько скамеров заблокировано, сколько похищенных средств возвращено
24.11.2022
Жуки и альтруизм. Российские вендоры обсуждают с властями «госбагбаунти»

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

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