Итак, вы решили начать разработку своего Vul­ner­a­bil­i­ty Man­age­ment решения. Часть 2. А может лучше специализироваться?

Первая часть зашла хорошо, так что продолжим. Если мы говорим, что полноценному VM вендору придется создавать отделы под

* поддержку разных видов таргетов (все ОС, все third-par­ty софты для этих ОС, ERP, базы данных, разнообразнейшие сетевые устройства, любые технологии виртуализации и прочее)
* разработку конкретные фич ("пентест-сканирование" без аутентификации, визуализация и приоритизация уязвимостей и прочее)

то может лучше не замахиваться на все сразу, а взять конкретный кусочек функциональности полноценного VM-продукта и выпустить специализированное решение? Если в большом VM вендоре кусочек функциональности пилит команда из 3–4 человек, то и для стартапа команда разработчиков понадобится примерно сопоставимая. И возможно за счёт фокусирования, конечный результат будет даже лучше.

Давайте на примерах:

1. Сканирования сетевого периметра без аутентификации. Тот самый EASM. Периметр у любой организации есть. Легко продавать как облачный сервис. Хорошо и для старта, и для дальнейшего развития в облачный VM (при желании). Из решений с российскими корнями можно посмотреть Metas­can, Scan­Fac­to­ry. Из нероссийских Immu­ni­Web. У Vul­ners есть бета такого сервиса, можете тоже заценить. 😉
2. Детектирование уязвимостей Lin­ux-хостов по бюллетеням. Lin­ux-овой инфраструктуры сейчас в компаниях много, будет ещё больше. Задача более-менее подъемная. Для каждого Lin­ux дистриба необходимо разобраться с бюллетенями безопасности, научиться корректно сравнивать версии. Инвентаризацию хостов можно делать самим, а можно оставить самим клиентам и предоставить только API для проверки. Как пример Vul­ners Lin­ux API и Vulns.io VM.
3. Сканирование сетевых устройств. Lin­ux хосты можно проверять по пакетам, Win­dows хосты можно проверять дополнительной функциональностью, реализуемой в антивирусах (у Kasper­sky например). А что делать с устройствами на которые агента не поставишь? Тут либо полноценный VM брать, либо самим что-то писать, либо брать решение специализирующееся на сетевых устройстах. С этого начинали Газинформсервис с продуктом Efros Con­fig Inspec­tor. Давно их не смотрел, сейчас, судя по описанию, они стали полноценным VM решением.
4. Сканирование ERP и других систем критически важных для бизнеса. Чем сложнее ПО, тем выше вероятность, что VM-решения не будут поддерживать его в достаточной мере. Взять например SAP. Из полноценных VM решений его только Max­Pa­trol 8 умеет сканировать, а TOP‑3 мировых VM вендора нет и им норм. Поэтому и есть ниша, для специализированных решений, например ERP­Scan. Пример очень эффектной фишечки в ERP­Scan это возможность проэксплуатировать некоторые найденные уязвимости проямо из интерфейса.
5. Приоритизация уязвимостей. Существует масса решений, которые даже не пытаются сами детектировать уязвимости, а занимаются только агррегацией уязвимостей из сторонних продуктов-сканеров и последующей их приоритизацией. Как пример Ken­na Secu­ri­ty (теперь Cis­co). Можно глянуть Fara­day Secu­ri­ty, у них есть бесплатная опенсурсная версия.
6. Фиды по уязвимостям. Каждый Vul­ner­a­bil­i­ty Man­age­ment продукт это база уязвимостей + правила детектирования. Собрать хорошую базу уязвимостей, обогащенную данными об эксплоитах (и их зрелости), малварях и признаках эксплуатации вживую совсем не просто. Тут можно отметить платные фиды Vul­ners, Kasper­sky, Vuldb, Risk Based Secu­ri­ty Vul­nDB.

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

Если эта часть хорошо зайдет по лайкам и репостам, следующая будет про то как по-быстрому сделать (или сымитировать 😉) VM решение, собрав его из того, что есть в паблике.

Итак, вы решили начать разработку своего Vul­ner­a­bil­i­ty Man­age­ment решения. Часть 1. Подводные камни.

Где-то с периодичностью раз в полгода ко мне приходят из какой-нибудь компании и говорят: "мы хотим разрабатывать свое решение по Управлению Уязвимостями как у ZZZ, расскажи что как и не хочешь ли поучаствовать?" Я на это обычно не то, чтобы отговариваю, но стараюсь подсветить сложности. Кажется пора уже это сформулировать в виде текста. Думаю будет полезно и тем, кто хочет запилить самописный VM в конкретной организации.

1. Основная сложность для вката в VMный рынок в устоявшемся ожидании, что VM решения должны детектировать уязвимости вообще во всем: все ОС (Lin­ux дистрибы, Unix‑ы, Win­dows, MacOS), все third-par­ty софты для этих ОС, ERP, базы данных, разнообразнейшие сетевые устройства, любые технологии виртуализации и прочее. Все, что может встретиться у заказчика должно быть покрыто этим VM решением. Причем не только при сканировании с аутентификацией, но и без. И желательно ещё и смежные области тоже зацепить: AppSec DAST/SAST, DevOps, облака, IOT, SCADA, встраиваемые системы. Это даже не конкурентные преимущества, это база, нижняя планка для входа в рынок, что-то само собой разумеющееся.
2. Естественно абсолютного покрытия быть не может. Но если ожидания клиентов не будут биться с реальностью, если это будет заметно, особенно если в результате расследования инцидента, то маркетинговая иллюзия рухнет. Как и позиции вендора. Поэтому VM вендоры очень стараются соответствовать. Хотя бы для текущих и потенциальных заказчиков.
3. Необходимость покрытия всего значит, что вам, новому игроку, придется скопировать кадровую структуру больших VM вендоров. То есть под каждое направление из п.1. завести отдел как минимум из 2–3 человек. Они будут на фулл-тайме ресерчить где можно получить данные по уязвимостям для конкретных систем, как для этих систем устроен патчинг, будут писать проверки и автоматические генераторы проверок, тестить, что ничего не отъехало, дорабатывать при необходимости. Работа непростая, специфическая. Сам года 3 этим занимался. Людей под это нужно много ещё и с учётом того, что нужно догнать существующих VM вендоров с их десятками и сотнями тысяч проверок.
4. Всех этих людей нужно кормить. Откуда денег столько взять? Это подводит нас к тому, что конечное решение будет стоить дорого. Невозможно поддерживать такое хозяйство продавая безлимитный а‑ля Nes­sus Pro­fes­sion­al за $3k в год. Это уже из серии демпинга. Вот продавая а‑ля Ten­able SC крупным компаниям с лицензированием по хостам — уже можно жить.
5. Такие продукты сами себя не продают. Поэтому также придется завести армию сейлов, пресейлов и маркетологов. А работа последних во многом и привела к ситуации из п.1, когда все с покерфейсом пытаются соответствовать невыполнимым требованиям при этом отмахиваясь, что качество детектирования это ерунда, не нужно на это обращать внимание, лучше на дашборды наши посмотрите. 🙂

В общем, невероятный вывод: чтобы делать полноценный VM нужно обладать командой и ресурсами как у Ten­able, Qualys, Rapid7, Pos­i­tive Tech­nolo­gies. 🙂 Ну или хотя бы как у Altx-soft, Sec­pod, Outpost24, F‑Secure.

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