Отличные новости по моему опенсурсному проекту Scanvus! Теперь вы можете проводить проверки на уязвимости Linux хостов и докер-образов не только с помощью API от Vulners.com, но и с помощью аналогичного API от Vulns.io. Особенно приятно, что весь код для поддержки нового API коллеги из Vulns.io написали и законтрибьютили сами. Оставалось только потестить, что все работает. За это им огромное спасибо!
Чем может быть полезна поддержка двух API детекта уязвимостей в Scanvus?
1. Нет привязки к одному вендору, выбирайте чьи условия вам нравятся больше.
2. Набор поддерживаемых ОС у Vulners.com и Vulns.io различается. Если какой-то Linux дистрибутив не поддерживается у одних, он может поддерживаться у других.
3. Реализации проверок независимые. Если при сканировании одного и того же хоста/образа результаты будут различаться, то будут наглядно видны ошибки/особенности реализации.
4. Scanvus выпускается под лицензией MIT, поэтому вы можете использовать его как пример работы с API Vulners.com и Vulns.io и использовать этот код в своих проектах.
Что дальше?
В настоящий момент поддержка API Vulners.com и Vulns.io реализована в равной степени, но она реализована независимо. Скрипты инвентаризации на bash для каждого из API различаются. Также используются 2 независимые функции репортинга. Скрипты для инвентаризации видится правильным унифицировать, чтобы эти результаты инвентаризации можно было бы проверить и с помощью Vulners.com и Vulns.io. Также напрашивается создание единого формата представления результатов детектирования, к которому можно будет приводить сырые результаты от API, и который можно будет использовать для построения отчетов и дальнейших интеграций. Кажется, что на примере работы Vulners.com и Vulns.io можно отладить схему добавления новых API в Scanvus.
Идея о том, что поддержкой базового Linux дистрибутива должна заниматься российская НКО похоже начинает реализовываться. Посмотрел выступление директора ИСП РАН Арутюна Аветисяна.
1. Open Source сообщество американоцентрично. Это данность.
2. В некоторой степени компенсировать риски может анализ исходного кода с использованием инструментов ИСП РАН. "Безопасность и доверие не то место, где мы должны конкурировать".
3. Первый успешный проект это доверенное ядро Linux 5.10. Постоянно забираются патчи, в автоматическом режиме проводится анализ, выявленные ошибки/уязвимости исправляются, патчи ИСП РАН отдаются международному сообществу. "Получаем доверенное ядро, которое функционально соответствует тому, что находится в США, но находится под нашем контролем".
4. Компании, которые участвуют в проекте доверенного ядра Linux, войдут в новый "Консорциум доверенного ПО". ИСП РАН может стать апстримом для отечественных дистрибов не только по ядру, но и по критичному системному ПО.
Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями? Если б я был регулятор. 🙂
1) Обновления безопасности должны быть. Критичная общелинуксовая уязвимость, должна быть пофикшена и в отечественном дистрибе. Или должно быть опубликовано обоснование, почему она неэксплуатируема.
2) Бюллетени безопасности должны быть. Клиенты должны как-то узнавать какую версию пакета нужно поставить, чтобы избавиться от критичной уязвимости.
3) Бюллетени безопасности должны быть публично доступны. Cпорный момент. Зависит от отношения к "security through obscurity". По мне закрытие доступ к бюллетеням усложняет жизнь исследователям, а злоумышленники все равно их получат через любого клиента.
4) Бюллетени безопасности должны быть доступны в машиночитаемом виде. Желательно в формате OVAL, раз уж он так распространен (RHEL, Suse, Ubuntu, Debian и даже отечественный RedOS)
Кстати узнал, что для RedOS есть официальный OVAL-контент (XML, 1.1 мб). И даже есть статья на русском как его использовать для детектирования уязвимостей на хостах при помощи OpenSCAP. VM-щикам сканеристам теперь можно удобно обновлять свои базы знаний, забирая данные из этой публично доступной XML-ки в стандартном формате. А не возиться с черти как оформленными бюллетеньками, которые ещё и не факт, что вообще есть. Нужно ли говорить, что в моём личном рейтинге отечественных операционных систем RedOS теперь взлетела в самый-самый топ. 😍 Молодцы 👍
Чем ответит купечество, т.е. остальные вендоры российских Linux-ов? 🙂
Весной-летом я толкал речи на тему как Vulnerability Management поменялся в 2022 году. Пришла зима, скоро уже новый год, есть повод порефлексировать и скорректировать видение.
Что сканировать?
1) Оценка "стабильности" IT-вендоров похоже оказалась не особо востребованной и в итоге свелась к переходу на отечественное. Тут и позиция регуляторов направляет, и нежелание зарубежных вендоров подставляться лишний раз под вторичные санкции. Пока выглядит так, что новые IT и ИБ решения будут в основном российские (пусть даже они будут функционально хуже).
2) С другой стороны массового выпиливания продуктов Microsoft пока не наблюдается. MS пока не нагнетают. Позиция регуляторов достаточно умеренная и сводится к требованию контроля обновлений. Видима зависимость настолько велика, что требовать чего-то другого не реалистично.
3) Массового отказа от мейнстримных Linux дистрибутивов тоже не наблюдается. Пока не было громких кейсов с активным участием западных вендоров Linux дистрибутивов. Миграция c Ubuntu/Debian/CentOS Stream/Alma/Rocky на российские дистрибы связана с техническими сложностями и значительными финансовыми затратами. В целом, в ширнармассах пока не ощущается понимание зачем это нужно (за исключением случаев когда это прямое указание регулятора).
Чем сканировать?
Какого-то значимого изменения ландшафта на рынке VM-решений пока не видится.
1) Кто-то продолжает использовать западные решения с помощью разного рода ухищрений.
2) Кто-то активнее переходит на продукты традиционных отечественных VM вендоров (Positive Technologies, Алтэкс-Софт, Эшелон, Газинформсервис).
3) Есть некоторая активность от нового игрока Vulns.io.
4) Есть развитие у периметровых сервисов Metascan и ScanFactory.
5) Интересно развитие VM как доп. функциональности у Kaspersky: если все равно антивирус заменять, удобно получить в результате и агент детектирующий уязвимости. Win-win в духе Microsoft Defender for Endpoint. Выглядит как перспективная тема для агентного сканирования.
6) Достаточно много больших российских компаний приняли решение пилить свои VM решения, т.к. доступные коммерческие дороги и/или чем-то не устраивают. Есть вероятность появления таких решений на рынке.
Про Linux-ы хорошо заходит. 🙂 К предыдущему посту набралось много комментариев в VK. К сожалению, у меня создалось такое впечатление, что со многими комментаторами мы не сошлись во мнении из-за того, что писали о разных вещах. Поэтому ещё раз переформулирую почему я считаю, что свободный бесплатный базовый российский Linux дистрибутив нам нужен и делать его видимо лучше независимо от существующих вендоров коммерческих Linux дистрибутивов.
Я на это дело смотрю несколько со стороны. Я не CTO, не системный архитектор и даже не сисадмин. Я безопасник. Мне так-то все равно на чем строится инфраструктура. Не считаю выбор конкретных решений своей зоной ответственности. Хоть на Windows, хоть на Linux платном или бесплатном, хоть на BSD, хоть на AIX и HPUX, хоть на KasperskyOS. Я могу что-то там высказать со своей колокольни, но бизнесу и IT безусловно виднее. Моё дело разбираться как контролировать уязвимости для всего этого безобразия, как его обновлять и харденить. Есть бюллетени безопасности? Класс. Они ещё и в машиночитаемом виде? Супер! Поддерживается сканером уязвимостей? Совсем здорово!
Вместе с тем сложно не замечать тот факт, что инфраструктура больших российских (и естественно не только российских) компаний в настоящий момент по большей части состоит из Linux серверов как железных, так и виртуальных. И используемые Linux дистрибутивы по большей части бесплатные. То есть это как раз-таки Debian, CentOS (Alma/Rocky), Ubuntu. Вопрос в следующем: а на что будут заменяться конкретно эти сервера к 2025 году? Такой конкретный вопрос, остальное импортозамещение в расчет не берем.
И тут видятся следующие варианты:
1. Они вообще не будут заменяться. И тогда зависимость от, по факту, западных решений останется с понятными рисками. И регулятору в виде ФСТЭК такой вариант видимо не особо нравится, см. предыдущий пост про Методику оценки критичности уязвимостей, а конкретно про тестирование патчей для опенсурса.
2. Они будут заменяться на отечественные коммерческие сертифицированные Linux-ы со $100 за лицензию. Про сто баксов это условно, т.к. там есть конкуренция (пока) и на объемах в тысячи и десятки тысяч хостов стоимость будет пониже. Но в любом случае дополнительные затраты будут ощутимые. И это будет уже не вполне тот Linux, который мы любим, ценим и везде используем, в том числе, и из-за возможности за лицензию не платить и разворачивать столько хостов, сколько потребуется.
3. Они будут заменены бесплатным отечественным базовым Linux дистрибутивом. Как раз-таки аналогом "Debian, CentOS (Alma/Rocky), Ubuntu" в том числе и по свободности и бесплатности, но разрабатываемым в России и контролируемым из России. Могут ли российские вендоры коммерческих Linux-ов сделать и поддерживать такой дистриб, включив его в реестр российского ПО, чтобы у компаний и частных лиц была такая опция для импортозамещения? Да конечно могут. Легко! А делают они это? Нет, потому что зачем вредить своему основному бизнесу на торговле лицензиями. Если я здесь не прав и такой вендор и дистриб есть, то назовите его и "свободный бесплатный базовый российский Linux дистрибутив" это будет вот он, сам же буду за него ратовать.
Но пока выглядит, что у государства один интерес - максимально снизить зависимость в том числе от "Debian, CentOS (Alma/Rocky), Ubuntu". А у существующих вендоров коммерческих Linux-ов другой - заработать и выжить на конкурентном рынке. Интересы и цели разные.
Поэтому и приходят в голову идеи, что заниматься разработкой и поддержкой бесплатного базового Linux дистрибутива должны вообще не они, а крупные российские окологосударственные IT компании в интересах государства. Но что-то каких подвижек в эту сторону не видно и по всей видимости будет реализовываться либо вариант 1, либо вариант 2, что мне не особо нравится… Но опять же, см. второй абзац этого поста. 🙂
На эту тему можно ещё посмотреть в контексте контейнеризации, но об этом как-нибудь в следующий раз.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.