Итак, вы решили начать разработку своего 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 решение, собрав его из того, что есть в паблике.