За окном 2026 год, а компании по-прежнему взламывают через незакрытые уязвимости. При этом управление уязвимостями часто сводится к нерегулярному скану и надежде, что «пронесёт».
Но не пронесёт. Особенно если внутри работает Jenkins с уязвимостью на чтение произвольных файлов, а наружу торчит GitLab, через который до обновления можно было сбросить пароль к любой учётке.
Привет, Хабр! Я Виктор Бобыльков, директор по кибербезопасности МТС Web Services Cloud, где помогаю строить нашу собственную платформу и делать Security-процесс прозрачным и удобным.
В этой статье разбираю, почему стандартных практик сканирования недостаточно для обеспечения безопасности и что вообще значит «управлять уязвимостями». Я разложу процесс по полочкам: чтобы было понятно, на что обращать внимание, как подступиться к теме и как внедрять процесс в жизнь.
Мы пройдём по пяти уровням зрелости — от базового сканирования до автоматизации, whitebox-подхода и специфики KPI. Размер компании не имеет значения — подойдёт как для небольшой команды, так и для бигтеха. Заодно вы сможете свериться, где находитесь сейчас и какие шаги впереди.
Что такое уязвимости и откуда они берутся
Согласно отчёту Positive Technologies, уязвимости стали точкой входа для 33% атак. В большинстве случаев о них было известно заранее — их просто не успели или не смогли устранить.
Часто управление уязвимостями сводится к нерегулярному сканированию и надежде на «пронесёт».
Однако управление уязвимостями — это не разовое событие, которое нужно устранять раз в месяц или перед аудитом. И на практике, управление уязвимостями в компаниях выглядит как набор каких-то действий. Но это постоянный процесс, в который вовлечены другие системы и процессы.
В этой статье я попробую описать, как выглядит эволюция управления уязвимостями — от полного хаоса до управляемой и автоматизированной системы — и по каким признакам можно понять, на каком этапе вы находитесь сейчас. И как мы в МТС Web Services Cloud смогли выстроить этот процесс и как его улучшаем.
Если упростить, уязвимости — слабые места в приложениях, системном ПО, инфраструктуре или сетях, через которые злоумышленник может получить доступ, нарушить работу систем, украсть данные.
Чаще всего они появляются по трём причинам:
1. Ошибкам в настройках: открытым портам, доступам без VPN и непродуманным управлениям доступом, слабым паролям.
2. Ошибкам в коде и бизнес-логике: баги есть даже в хорошем коде, от SQL и XSS до логических ошибок и забытых настроек.
3. Устаревшим компонентам или ПО: забытым и давно не обновляемым сервисам.
Рано или поздно почти все найденные уязвимости попадут в базу CVE (базу общеизвестных уязвимостей).
Примеры громких уязвимостей
На практике взломы начинаются с того, что доступно извне, — почтовых серверов, панелей управления — или через внутренние сервисы, которые оказались случайно доступными из интернета.
Например:
Уязвимость удалённого выполнения кода в FortiWeb
CVE-2025-64446, Scoring CVSS: 9.4 — уязвимость, позволяющая создавать учётную запись с правами администратора, что приводит к полной компрометации системы.
Выполнение произвольного SQL-запроса
CVE-2025-64459, Scoring CVSS: 9.1 — уязвимость в Django позволяет злоумышленнику, не прошедшему аутентификацию, выполнить произвольный SQL-запрос.
RCE в React Server Component
CVE-2025-55182 Scoring CVSS: 10 — уязвимость позволяет выполнить код на сервере с помощью HTTP-запроса без авторизации и удалённо.
RCE в Windows Server (WSUS)
CVE-2025-59287, Scoring CVSS: 9.8 — уязвимость позволяет выполнить код на сервере с помощью специального события.
Ошибка в компоненте Object Linking and Embedding (OLE) Microsoft Outlook
CVE-2025-21298 Scoring CVSS: 9.8 — уязвимость позволяет удалённо выполнить любой код при открытии специального письма.
Повышение привилегий sudo
CVE-2025-32463, Scoring CVSS: 9.3 — уязвимость в функции chroot, позволяющая повысить права до уровня суперпользователя.
Загрузка вредоносных файлов в SAP NetWeaver
CVE-2025-31324 Scoring CVSS: 10 — уязвимость позволяет неограниченно загружать исполняемые файлы, что приводит к удалённому выполнению кода.
Десе��иализация данных в Microsoft SharePoint Server
CVE-2025-53770, Scoring CVSS: 9.8 — уязвимость позволяет без авторизации загрузить на сервер сериализованный объект .NET.
Сброс пароля на произвольную учётку в GitLab (User account password reset emails could be delivered to an unverified email address
CVE-2023-7028, Scoring 10 по CVSS — широко обсуждаемая уязвимость, когда можно было привязать второй почтовый ящик и через него получить письмо для сброса пароля на любую учётную запись в GitLab. Неприятная история — надеюсь, вы свой GitLab уже обновили.
Все эти примеры говорят о том, что лазейки находят там, где про них забыли или ещё не дошли руки для устранения. Именно поэтому важно выстроить процесс управления уязвимостями системно.
Процесс управления уязвимостями
Стандартная схема процесса предполагает, что сначала уязвимость нужно как-то найти и замониторить. Дальше — оценить, выставить приоритет и рекомендации по устранению. После этого приходим к айтишникам и говорим: «Ай-ай-ай, не надо использовать Windows Server 2003 — обнови, пожалуйста, до 2019-го».
В идеале айтишники устраняют уязвимость. Но важно помнить: everybody lies — это ещё доктор Хаус сказал. Поэтому нужно обязательно проверить, действительно ли сделали или просто поставили галочку.
Ну и в финале — смотрим на процесс целиком, анализируем его эффективность и ищем, что улучшить.
Но это скучная теория, мне самому не нравится. Поэтому ��егодня посмотрим на процесс под другим углом.
Методология измерения
IT, безопасность, да и в целом всё, что мы делаем, — это, по сути, часть бизнеса. Но уже давно придумали CMMI — Capability Maturity Model Integration — модель зрелости бизнес-процессов. Она описывает, как измерить текущий уровень зрелости и что сделать, чтобы перейти на следующий. Своего рода игра про прокачку процессов, где каждый уровень открывает новые возможности.
Я решил взглянуть на процесс управления уязвимостями именно через призму CMMI. Потому что цель у неё простая и универсальная: улучшить любые процессы внутри компании.
Модель состоит из пяти уровней зрелости:
1. Начальный
Процесс не формализован и постоянно меняется. Характерна хаотичность, реактивность, непредсказуемость. Это большой чёрный ящик: что происходит внутри — непонятно. Всё работает по принципу: «А что, надо пойти сделать?»
2. Преимущественно стандартный
Процесс описан и повторяем, но всё ещё немного реактивен. Требования определены, но контроль слабый. Реальное видение ситуации присутствует на промежуточных этапах. По сути, это уже не один, а несколько маленьких «чёрных ящиков» — где-то уже включили свет и стало прозрачно, а где-то ещё темно, надо доработать.
3. Стандартный
Процесс чётко определён, описан на уровне стандартов внутри компании. Есть взаимосвязи, автоматизация, все понимают, кто что делает. «Чёрные ящики» побелели — всё прозрачно, управляемо и предсказуемо.
4. Выше среднего
Появляются метрики контроля процесса — количественные и качественные. Появляется предсказуемость: мы понимаем, как процесс работает, как на него влиять и где узкие места.
Это уже очень крутой уровень, ближе к инженерному счастью.
5. Высокий
Процесс постоянно улучшается: появляются точные характеристики оценки эффективности, новые практики, оптимизации и всё внедряется безболезненно.
Этот уровень я называю нереальным, даже утопичным, потому что на практике до него почти никто не добирается.
Уровень 0. Отсутствующий
На этом уровне процесс управления уязвимостями ещё даже не начался. Нам только предстоит понять, чем мы вообще владеем и с чего начать.
По моему опыту — а я общался с десятками компаний, — айтишники в большинстве случаев не знают свою собственную инфраструктуру: из чего она состоит, сколько хостов, какие сети. А ещё чаще начинают придумывать то, чего у них на самом деле нет. И с этим надо что-то делать.
На нулевом уровне самое важное:
Понять, есть ли у нас CMDB (Configuration Management Database) или хотя бы план по созданию системы инвентаризации.
Определить этапы процесса и команды, которые будут вовлечены.
Выбрать инструменты для сканирования — откуда мы вообще будем получать данные об уязвимостях.
Процесс управления уязвимостями разделяется на две ветки: внешний периметр — то, что доступно извне, и внутрянку.
Что делать на внешнем периметре:
Собрать автономные системы, домены верхнего уровня, сети.
Понять, какие средства защиты стоят на периметре и могут ли они мешать сканированию.
Например, если вы натравите на NGFW 100 тысяч соединений, он, к сожалению, упадёт, потому что не умеет столько обрабатывать. И вместе с ним упадёт вся компания.
Произвести категоризацию активов.
Что размещено в периметре компании и что живёт на внешних хостингах. Например, многие хостинг-провайдеры запрещают сканирование shared-хостингов — для этого нужны отдельные VPS.
В типичной компании активы разбросаны: часть в одном облаке, часть в другом, что-то on-prem. Всё перемешано, и никто толком не понимает, как это взаимодействует. В итоге безопаснику дают список «наших» серверов в on-prem, а всё остальное — «ну это не наше, это где-то там, в облаке». Но так не работает. Если у вас есть сайты у стороннего хостера — это тоже ваша зона ответственности. Их нужно учитывать и включать в инвентаризацию.
Определить белый список служб, которые можно выставлять в интернет.
Проанализировать, что действительно должно быть доступно снаружи, а что лучше спрятать. Если у вас 22-й порт открыт вовне — это уже повод задуматься.
Что делать по внутрянке:
Собрать информацию о допустимом технологическом стеке (всевозможные Active Directory, FreeIPA и так далее).
Собрать внутреннюю адресацию и карты сетей, а также понять, какие внутренние активы доступны из сети Интернет.
Иногда даже неосознанно — вроде бы сервер стоит в DMZ, а порт открыт наружу.
Оценить критичность активов и приоритизировать сканирование.
Если вы решите сканировать всю 10.0.0.0/8, то результаты получите где-нибудь в 2027 году. Слона надо есть по частям: что критично — в первую очередь, что не критично — можно потом.
Определить цели сканирования: что включаем, а что сознательно исключаем.
Определить узкие места в сети — где требуются более низкие рейты для сканирования.
Выявить активы, которые потенциально могут не пережить сканирование.
Мы как-то пошли сканировать инфраструктуру. Внутри торчали какие-то флешки для 1С. Когда сканер до них добрался, они умерли. В результате клиенты не смогли ничего подписать, процесс остановился. Оказалось, что флешки просто не пережили сканирование.
И таких примеров в инфраструктуре много. Поэтому следует смотреть внимательно, установить rate-лимиты, чтобы не потушить всю сетку от какого-нибудь сканирования с помощью Masscan.
Выбор сканера
Следом встаёт вопрос: каким инструментом сканировать? Есть два подхода:
Open-source инструменты, на которые нужно докручивать автоматизацию.
Проприетарные сканеры, разработанные вендорами.
Вот базовый набор open source сканеров, с которых можно начать инвентаризацию внешнего периметра и поиск уязвимостей, с примерами скриптов:
Subfinder — поиск поддоменов для TLD.
subfinder -d example.com -vMasscan — поиск живых IP-адресов и открытых портов.
masscan 10.0.0.0/8 -p- --rate 15000Nmap + Vulners — обнаружение доступных служб на открытых портах + поиск уязвимостей по баннеру службы.
nmap -p- -Pn -T4 --max-retries 2 -sV --script=vulners 10.0.0.0/24Nuclei — сканер уязвимостей на шаблонах (можно писать свои).
nuclei -u 176.109.74.3 -s medium,high,critical,unknown -rl 150Ffuf — фаззер, брутит директории в п��исках потенциально опасных доступных директорий. Также можно использовать для поиска сабдоменов.
ffuf -w ./wordlist/path.txt -u https://example.ru/FUZZ -t 35 -c -ac -recursion -recursion-depth 3
Если смотреть на проприетарные решения, то в России можно выделить несколько продуктов, которые чаще всего встречаются:
CICADA8.
ScanFactory.
MetaScan.
Bizone CPT.
Обычно они доступны в двух вариантах: on-premise или облачной инсталляции (SaaS).
Что умеют стандартные коммерческие сканеры:
Поиск поддоменов, resolve доменов в IP-адреса.
Сбор живых IP/доменов, поиск открытых портов и обнаруженных сервисов, скриншоты главной страницы веб-ресурсов.
Поиск уязвимостей — собственно, главная цель.
Ведение статистики по доступным сервисам и обнаруженным уязвимостям, генерация отчётов.
Поиск утечек логинов и паролей пользователей.
Некоторые сканеры умеют находить утечки информации, логинов и паролей, которые можно пробовать в формах авторизации. Если у вас на периметре открыт SSH по логину/паролю, стандартное поведение — это Ubuntu, Ubuntu. Это мой вредный совет.
На что обращать внимание, если выбираете проприетарный сканер для внутрянки:
1. Скорость сканирования, всевозможные rate-лимиты.
Если у вас, как у меня, наружу торчит 400+ сетей, это всё будет очень-очень долго.
2. Гибкая система настроек/шаблонов сканирования, формирования белых списков, добавления/исключения активов из сканирования и так далее.
Хорошо, если есть поддержка регулярных выражений.
3. Наличие полно��енного VM-функционала (статусы уязвимостей, возможность оставлять комментарии, пометки FP).
Очень полезно знать статус новых уязвимостей, чтобы повторно по ним не бегать, делать пометки False Positive, потому что метод всё равно вероятностный. Понятно, что есть детерминированные, точно уже понятные CVE, но случаются примеры из серии «надо бы тут посмотреть, протыкать».
4. Возможность отключать не интересующие сработки, например по TLS/SSL.
Когда пойдёте сканировать сеть, получите гору «уязвимостей» TLS v1.0 и v1.1. Для внутрянки это нормально. Когда писали Windows Server 2012, подключение к нему было по RDP, а про TLS 1.2 вообще ещё не слышали. В ответ ваше legacy может сказать: «Что нам делать с этой тысячей уязвимостей TLS 1.0?» Остаётся только принять этот риск, пока мы не обновим всю нашу End-Of-Life инфраструктуру.
5. Удобный UI — наличие фильтрации, сортировки, группировки активов и обнаруженных уязвимостей. Смотреть без этого портянку в большой инфре — плохая затея.
6. Полнота описания уязвимости. В идеале — текст описания, рекомендации, команды для перепроверки и output для сработавшей проверки.
7. Функциональность API для автоматизаций/интеграций.
8. Управление временем и возможность указания не только времени старта сканирования, но и ограничения. Например, останавливать сканы после 9 утра.
9. Покрытие стека.
10. Удобство формирования различных отчётов и настроек дашбордов.
11. Удобство горизонтального масштабирования для on-premise решений, для внешних или внутренних сканеров.
Уровень 1. Начальный
Методы получения уязвимостей: только vulnerability scanning.
Команда: один человек.
Единственный способ выявления уязвимостей на этом уровне — это простое сканирование.
Признаки первого уровня:
Нерегулярное сканирование.
Сегодня просканировали, потом забыли. Вспомнили вдруг 26 мая, потом снова — только 30 сентября, когда третий квартал почти закончился. Потом — тишина до 2027-го и так далее.
Закрываем только High/Critical-уязвимости, на Medium и Low даже не смотрим.
Приоритизация основывается только на оценке самого сканера.
Здесь нужно проверять, что всё помеченное как Critical/High действительно является таковым. Принцип простой: лучше закрыть одну критичную, чем десять низкоприоритетных. Потому что в реальности ломают через Critical, а Low требуют сложной Kill Chain и специфических условий.
Сканирование на уязвимости — только blackbox.
Внутрь никто не заглядывает, никуда не логинится — просто смотрим снаружи.
На данном этапе выявляются ShadowIT и legacy-инфраструктура.
При сканировании внешнего периметра в первую очередь стоить уделить особое внимание на такие параметры:
Доступные административные порты.
RDP, SSH, BMC/IMPI — всё это должно быть спрятано за VPN.
Доступные веб-приложения.
Проверяем, нет ли открытых админпанелей и свободного доступа к ним, и формируем белый список порталов, которые действительно должны быть доступны извне. Остальное — за VPN.
Наличие почтовых шлюзов без авторизации.
Если SMTP работает без авторизации, когда на вашу почту можно послать письмо от имени генерального директора, — это прямой путь к фишингу. Кто-то пошлёт письмо «от CEO», и всем покажется, что так и должно быть.
Ещё один вредный совет: к фишингу тоже надо быть готовым — особенно, если он от начальства.
Во внутреннем периметре в первую очередь сканируются:
административные сегменты,
всё, что связано с Active Directory,
DMZ — демилитаризованная зона, если она у вас выделена.
Уровень 2. Управляемый
Методы получения уязвимостей: к обычному vulnerability scanning добавляются пентесты и RedTeam-активности.
Команда: минимум 2–3 человека фултайм, с возможностью привлечения проектного менеджера и команд разработки и инфраструктуры.
Бонус: можно собирать отчёты для руководства (это уже метрика зрелости).
Что нужно, чтобы честно сказать, что мы достигли второго уровня:
100% покрытие скоупа — вы должны точно знать, что сканируете и кто за что отвечает.
Регулярная инвентаризация, а также внешнее и внутреннее сканирование раз в месяц или квартал.
Наличие источника информации о сканируемых активах, ответственных за устранение уязвимостей.
Если найдена уязвимость — кто её должен закрыть? На кого эскалировать, если ответственный ничего не делает или отвечает «это не моё»? Здесь уже должен быть CMDB или что-то похожее.
Как принимать решения об устранении:
На этом уровне стоит разработать свою методику приоритизации, которая учитывает среду, внешний или внутренний периметр, важность систем, наличие эксплойта, реальную эксплуатацию, потенциальный ущерб и т. д.
Дальше — определить, что действительно надо устранять и как это регистрировать. Например, перейти на систему тикетов или воспользоваться методом агрегации этих уязвимостей.
Как в примере TLS v1.0/v1.1 — одна и та же уязвимость может всплыть на сотнях хостов. А если у вас ещё где-то не закрытая EternalBlue — держитесь. Возможно, это системная проблема, которую лучше решить централизованно или пересмотреть архитектуру, особенно если нет лицензионной поддержки от вендора. В таких случаях не надо заводить тысячу тикетов. Лучше один тикет или проект, который закроет всю проблему.
Например, в случае отключения аутентификации на уровне сети — Network Level Authentication (NLA), проблема для доменных хостов решается настройками в GPO. А для EOL-систем (Windows Server 2012, Oracle 10g, Java и т. д.) эффективнее завести проект, в рамках которого «пропушат» централизованный отказ от EOL.
Помочь IT с уходом с EOL-систем и с забытыми/неучтёнными хостами.
Благодаря этому сканированию вы поймёте, какие у вас End-Of-Life системы, на что обратить внимание и как выглядит инфраструктура, про которую, скорее всего, сама IT-команда уже забыла.
На этом уровне стоит переходить к трекеру задач — будь то Jira, SimpleOne или любой другой. Главное — чтобы у всех был системный, прозрачный и понятный workflow.
Может возникнуть вопрос, как регистрировать: «один тикет = одна уязвимость» или «один тикет = один сервер»? Всё подряд не нужно, лучше работает агрегация.
Как попасть на второй уровень
Я считаю, что если вы ещё не устранили хотя бы 50% найденного, то на управляемый уровень точно не перейдёте. Вот что может помочь такому устранению:
Добавить проектного менеджера.
PM — это половина успеха. Это управление сроками, нормальный трекинг и поддержка инициативы, которая поможет убрать значительную часть проблем.
Синхронизация сканирования с установкой обновлений.
Сначала ставим патчи, а уже потом сканируем. Иначе вы найдёте кучу багов, и потом окажется, что всё закрыто во вчерашнем Patch Tuesday от Microsoft.
Консультации при устранении и поддержка руководства.
Уровень 3. Определённый
Интеграция с Task Tracker для регистрации дефектов.
Команда: минимум три человека плюс активное вовлечение IT.
Интеграция с Task Tracker становится обязательной — всё, что касается уязвимостей, должно быть формализовано в тикетах:
Хорошо отлаженный workflow по работе с тикетами.
Боты для нотификации, цель которых — напоминать и эскалировать, если задача зависла.
Что можно автоматизировать (на примере Jira):
Поиск исполнителя/группы и установка сроков
Как только создаётся тикет — система автоматически назначает ответственного и due date, когда уязвимость надо устранить. Вся информация тянется из CMDB: либо это конкретный человек, либо группа — например, L2 DevOps или L2-команда.
Автопереходы по статусам при эскалации (триггер по времени).
Если в течение месяца ничего не меняется, тикет автоматом должен перейти на техлида исполнителя или дальше на CTO. А бот должен пушить нотификации в стиле: «Парень, давай-ка ты эту уязвимость закроешь».
Автопереназначения при переходе по статусам.
Боты для нотификации.
Автопроверки и автозакрытия тикетов.
Бывает, что работа по тикету уже сделана — Ansible прошёлся, патчи накатили, часть нод удалили, но тикет в Jira так и висит в статусе «Открыт». Так я за год работы над процессом устранения уязвимостей удалил 30% собственной внутренней инфраструктуры в одной из облачных платформ.
Интеграция с CMDB по обогащению активов (владелец, критичность и т. д.).
Построение дифотчётов по итогам инвентаризации.
Чтобы можно было самому посмотреть, сколько хорошего вы привнесли в здоровье вашей составляющей.
Взаимодействие с SOC, если нет CRQ на ввод/вывод.
Как попасть на третий уровень
На третьем уровне устранение уязвимостей должно быть выше 75%. Что поможет этого добиться:
Простое и понятное описание уязвимости, рекомендации по её устранению, а также прозрачный и удобный workflow.
Исполнитель должен сразу понимать: что сломано, в чём баг и что с ним делать. Если написана огромная портянка текста с описанием, что плохого в CVE, никто это читать не будет и подумает: «Ой, разберёмся в 2026-м».
Нормальный UX.
Чем меньше кликов, тем лучше. Все банковские приложения между собой соревнуются, чтобы пользовательский путь был удобный. Процесс устранения уязвимостей ничем не отличается. Да, им пользуются не миллионы, а максимум 50 человек, но, если вы заставите их 50 раз кликать, они просто перестанут это делать.
Показательные примеры по эксплуатации.
Автоматизация большинства операций и сокращение рутины.
Дашборд с адекватной визуализацией.
Вот, например, что можно туда вынести: сколько уязвимостей всего, разбивку по статусам и severity (в работе / закрыты / на ревью у безопасности), методы обнаружения (Pentest, RedTeam, Vulnerability Scanner, Vulnerability Intelligence, Bug Bounty).
Vulnerability Intelligence — это про реагирование на новые уязвимости, пока они ещё не в сканере. Допустим, надо обновить VMware из-за какой-то опасной баги — вы не ждёте, когда это будет внесено в сканер, а проактивно устраняете. Здесь можно тоже заводить тикет. Более зрелые компании выходят на Bug Bounty. От Bug Hunters можно тоже получать интересные тикеты и тоже закрывать уязвимости.
Быстрые переходы из дашборда в Task Tracker, чтобы сразу открыть нужный тикет.
Динамика устранения уязвимостей: по неделям, месяцам, кварталам, всего.
Уровень 4. Измеряемый
Сканирование: переходим к полноценному whitebox-режиму.
Процесс: всё уже автоматизировано (да-да, такое бывает).
Команда: 4–5 человек, минимум один разработчик.
Режим Whitebox — это метод сканирования, когда сканер уже ходит с учётной записью и заходит напрямую на Windows-ноду и Unix-ноду. На Windows-ноде получаем KB-патчи, которые надо дополнительно поставить, на Unix-ноде — какие пакеты обновить.
На что обратить внимание:
Какие права у учётной записи.
Как управляется жизненный цикл учётной записи.
Где и как хранятся пароли и приватные ключи.
Поскольку сканер уже ходит с какой-то учёткой, все эти пункты должны быть прописаны, автоматизированы и зрелы.
«Вкусности» на четвёртом уровне:
Автокорректировка скоупа для сканирования.
Добавление новых хостов, удаление выведенных из эксплуатации. Как только новый IP засветился на периметре — сразу добавляем его на сканер, чтобы понять, какие сервисы на нём живут.
Регулярный пересмотр рисков.
Регулярный пересмотр выставленной критичности.
Регулярный пересмотр принятого исключения или рисков.
Бывает, что сегодня уязвимость суперкритичная, мы приняли митигирующие меры — а она уже стала Medium.
Собственная методика подсчёта критичности, основанная на риск-подходе, Known Exploited Vulnerabilities (KEV) и подключении vuln intelligence для понимания релевантности.
Дашборды, доступ к уязвимостям и сканированиям у исполнителей.
Интеграция с Security Operation Center (SOC) для проверки эксплуатации потенциальными хакерами, если найдена уязвимость.
Ключевое на этом уровне — связка с SOC. Если уязвимость найдена, нужно не только её закрыть, но и проверить по логам: не успел ли кто-то ей воспользоваться? Ведь если уязвимость закрыта, хакер может сидеть у вас внутри. В таком случае безопасность переходит на другой уровень, и тут без SOC не обойтись.
Кроме перечисленного, на этом уровне также доступны всевозможные ключевые показатели эффективности KPI и SLA.
КРI по процессу:
Выполнение SLA.
Процент покрытия скоупа и т. д.
SLA — соглашения об уровне обслуживания. Я делю их на три части:
SLA для IT-команды.
SLA для ИБ-команды, когда они всевозможные уязвимости находят или делают ревью.
SLA для самоуязвимости или SLA по процессу:
Время взятия в работу (с момента регистрации задачи на устранение).
Время устранения.
Время, затраченное на подтверждение.
Время с момента обнаружения до момента подтверждения закрытия (сумма первых трёх) и т. д.
Пример: год назад уязвимость жила у нас в среднем 64 дня, а сейчас — 26 дней. Значит, мы стали круче работать.
На этом уровне всё должно быть автоматизировано: тикеты заводятся автоматически, статус трекается, метрики собираются, дашборды обновляются сами.
Уровень 5. Оптимизируемый
Это уже уровень, на котором всё работает само, никто не забывает тикеты, SLA не просто выполняются, KPI достигаются и не превышают порогов. Да и вообще — уровень нереальный, такого не бывает.
Как этот процесс работает в MWS
Расскажу, как эта система работает у нас в продакшене. Сейчас мы устойчиво держимся на третьем уровне зрелости, подбираясь к четвёртому.
Что реализовано:
Мы понимаем 100% скоупа.
Провели множество инвентаризаций.
Есть свои Pentest и Red Team, которые регулярно снабжают нас багами.
Всё интегрировано с Jira.
Есть свой workflow и всевозможные интеграции с CMDB.
Мы используем Netbox и ещё один самописный инструмент.
По итогам инвентаризации регулярно строим дифотчёты.
Обязательно сканируем всё, что должно выходить в продакшен.
Что не сделано:
На третьем уровне не сделана своя методика подсчёта критичности — пока пользуемся стандартной.
Ещё не вышли на BugBounty.
На четвёртом уровне работаем над двумя треками:
SLA, чтобы всё правильно считалось.
Трекинг времени жизни уязвимости (сколько времени тратит IT-команда, сколько времени тратим на ревью мы сами и так далее).
До пятого уровня ещё далеко.
Что мы используем
Для внешнего периметра продукт CICADA8. Для внутреннего — трофейный сканер на букву N. Кто знает — тот знает. А дальше — кастомные решения. У нас своя самописная Vulnerability Management Platform, где мы храним:
Информацию об активах.
Статусы хостов.
Историю и статус сканирований.
Политики сканирования.
Уязвимости и их жизненный цикл.
И интеграции:
Прямая интеграция с Jira — тикеты заводятся автоматически.
В нашей платформе уязвимостей намного больше, чем мы реально отдаём в тикеты в Jira. И чтобы не забрасывать IT-департамент всевозможным мусором, мы регистрируем только тикеты, которые реально прошли через нашу экспертизу и должны быть закрыты.
Интеграции с инвентаризационными системами (Netbox, etc.).
Поддержка и сканирование IPv6, Kubernetes.
Наша новая облачная платформа строится исключительно на IPv6, поэтому научились сканировать и его тоже. Сканируем кластеры Kubernetes, бегаем по namespaces, смотрим, какие там живут сервисы, сканируем — и, если что-то не так, регистрируем уязвимость.
Все уязвимости, прошедшие фильтр, разливаются в Jira. У нас там свой рабочий workflow. Вот как он выглядит:
На примере выше — старенькая уязвимость, на VMware есть исполнитель. Здесь тип — не уязвимость, а ошибка. Установлен приоритет и указано, какие используем метки (CVE такие-то и такие-то). Ключевое — это IP-адрес, на котором найдена уязвимость, и рекомендация, что обновить и до какой версии. Дальше — due date, или когда создано, обновлено, когда закрыто. Это всё поможет для SLA.
Конечно, у нас есть дашборд, и он удобный. Можно посмотреть, сколько всего заведено тикетов и процент закрытия.
Тут я немного лукавлю: в процент закрытия входят не только реально закрытые, но и отправленные на ревью. Из ревью обычно возвращается только 2–3% уязвимостей — чаще всего по пентесту, где что-то забыли или не доделали.
Можно провалиться в любой тикет. Справа — большой список. Внизу — распределение по методу обнаружения уязвимостей. Но в основном мы сейчас пока используем три метода:
Vulnerability scanner.
Pentest/RedTeam.
Vulnerability Intelligence.
Вкладка по SLA есть, но пока неактивна. Мы туда ещё не добрались.
Следующее внизу — распределение по критичности (severity). В основном регистрируем уязвимости как High, чуть меньше Medium, еще меньше Critical и совсем мало Low.
В правом нижнем углу — динамика по закрытию уязвимостей.
Сколько людей занимается FTE
В этот процесс вовлечена вся наша IT-организация, все закрывают уязвимости. Но есть наша команда наступательной безопасности, в которой есть подкоманда управления уязвимостями. Вся наступательная безопасность состоит из восьми человек:
Руководитель.
Три пентестера и редтимер, которые регулярно ищут уязвимости.
Два VM-специалиста и разработчик, которые непосредственно занимаются Vulnerability Management.
Секрет небольшой команды довольно простой — дисциплина и управление. В этой работе всё должно быть чётко, понятно и прозрачно, тогда в процессе не будет никаких сюрпризов.
Итоги
В этой статье мы прошлись по шкале зрелости процесса управления уязвимостями — от самого базового, когда кто-то раз в год нажимает кнопку сканера, до полной автоматизации, whitebox-сканирования, интеграций с CMDB и прозрачных KPI.
Я выделил пять уровней, несмотря на то что самый последний — едва ли достижим. Мы прошли этот путь сами. У нас работает VM-платформа, собственные сканеры, интеграция с Jira и Netbox, автоматизация тикетов, регулярные инвентаризации, своя команда Pentest и RedTeam. И самое важное — мы не просто сканируем, а реально устраняем уязвимости. И ещё есть что можно улучшить. А про наш подход в MWS Cloud Platform можно прочитать в разделе «Безопасность».
Если вы только начинаете выстраивать VM или хотите понять, что тормозит устранение уязвимостей в вашей компании, — этот материал поможет найти идеи, как оптимизировать процесс, автоматизировать рутину и не утонуть в тикетах.
