Итак, вы решили начать разработку своего Vulnerability Management решения. Часть 2. А может лучше специализироваться?

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

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

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

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

1. Сканирования сетевого периметра без аутентификации. Тот самый EASM. Периметр у любой организации есть. Легко продавать как облачный сервис. Хорошо и для старта, и для дальнейшего развития в облачный VM (при желании). Из решений с российскими корнями можно посмотреть Metascan, ScanFactory. Из нероссийских ImmuniWeb. У Vulners есть бета такого сервиса, можете тоже заценить. 😉
2. Детектирование уязвимостей Linux-хостов по бюллетеням. Linux-овой инфраструктуры сейчас в компаниях много, будет ещё больше. Задача более-менее подъемная. Для каждого Linux дистриба необходимо разобраться с бюллетенями безопасности, научиться корректно сравнивать версии. Инвентаризацию хостов можно делать самим, а можно оставить самим клиентам и предоставить только API для проверки. Как пример Vulners Linux API и Vulns.io VM.
3. Сканирование сетевых устройств. Linux хосты можно проверять по пакетам, Windows хосты можно проверять дополнительной функциональностью, реализуемой в антивирусах (у Kaspersky например). А что делать с устройствами на которые агента не поставишь? Тут либо полноценный VM брать, либо самим что-то писать, либо брать решение специализирующееся на сетевых устройстах. С этого начинали Газинформсервис с продуктом Efros Config Inspector. Давно их не смотрел, сейчас, судя по описанию, они стали полноценным VM решением.
4. Сканирование ERP и других систем критически важных для бизнеса. Чем сложнее ПО, тем выше вероятность, что VM-решения не будут поддерживать его в достаточной мере. Взять например SAP. Из полноценных VM решений его только MaxPatrol 8 умеет сканировать, а TOP-3 мировых VM вендора нет и им норм. Поэтому и есть ниша, для специализированных решений, например ERPScan. Пример очень эффектной фишечки в ERPScan это возможность проэксплуатировать некоторые найденные уязвимости проямо из интерфейса.
5. Приоритизация уязвимостей. Существует масса решений, которые даже не пытаются сами детектировать уязвимости, а занимаются только агррегацией уязвимостей из сторонних продуктов-сканеров и последующей их приоритизацией. Как пример Kenna Security (теперь Cisco). Можно глянуть Faraday Security, у них есть бесплатная опенсурсная версия.
6. Фиды по уязвимостям. Каждый Vulnerability Management продукт это база уязвимостей + правила детектирования. Собрать хорошую базу уязвимостей, обогащенную данными об эксплоитах (и их зрелости), малварях и признаках эксплуатации вживую совсем не просто. Тут можно отметить платные фиды Vulners, Kaspersky, Vuldb, Risk Based Security VulnDB.

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

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

@avleonovrus #VM #VMvendors