2022-08-24 13:36:58
Итак, вы решили начать разработку своего Vulnerability Management решения. Часть 1. Подводные камни.
Где-то с периодичностью раз в полгода ко мне приходят из какой-нибудь компании и говорят: "мы хотим разрабатывать свое решение по Управлению Уязвимостями как у ZZZ, расскажи что как и не хочешь ли поучаствовать?" Я на это обычно не то, чтобы отговариваю, но стараюсь подсветить сложности. Кажется пора уже это сформулировать в виде текста. Думаю будет полезно и тем, кто хочет запилить самописный VM в конкретной организации.
1. Основная сложность для вката в VMный рынок в устоявшемся ожидании, что VM решения должны детектировать уязвимости вообще во всем: все ОС (Linux дистрибы, Unix-ы, Windows, MacOS), все third-party софты для этих ОС, ERP, базы данных, разнообразнейшие сетевые устройства, любые технологии виртуализации и прочее. Все, что может встретиться у заказчика должно быть покрыто этим VM решением. Причем не только при сканировании с аутентификацией, но и без. И желательно ещё и смежные области тоже зацепить: AppSec DAST/SAST, DevOps, облака, IOT, SCADA, встраиваемые системы. Это даже не конкурентные преимущества, это база, нижняя планка для входа в рынок, что-то само собой разумеющееся.
2. Естественно абсолютного покрытия быть не может. Но если ожидания клиентов не будут биться с реальностью, если это будет
заметно, особенно если в результате расследования инцидента, то маркетинговая иллюзия рухнет. Как и позиции вендора. Поэтому VM вендоры очень стараются соответствовать. Хотя бы для текущих и потенциальных заказчиков.
3. Необходимость покрытия всего значит, что вам, новому игроку, придется скопировать кадровую структуру больших VM вендоров. То есть под каждое направление из п.1. завести отдел как минимум из 2-3 человек. Они будут на фулл-тайме ресерчить где можно получить данные по уязвимостям для конкретных систем, как для этих систем устроен патчинг, будут писать проверки и автоматические генераторы проверок, тестить, что ничего не отъехало, дорабатывать при необходимости. Работа непростая, специфическая. Сам года 3 этим занимался. Людей под это нужно много ещё и с учётом того, что нужно догнать существующих VM вендоров с их десятками и сотнями тысяч проверок.
4. Всех этих людей нужно кормить. Откуда денег столько взять? Это подводит нас к тому, что конечное решение будет стоить дорого. Невозможно поддерживать такое хозяйство продавая безлимитный а-ля Nessus Professional за $3k в год. Это уже из серии демпинга. Вот продавая а-ля Tenable SC крупным компаниям с лицензированием по хостам - уже можно жить.
5. Такие продукты сами себя не продают. Поэтому также придется завести армию сейлов, пресейлов и маркетологов. А работа последних во многом и привела к ситуации из п.1, когда все с покерфейсом пытаются соответствовать невыполнимым требованиям при этом отмахиваясь, что качество детектирования это ерунда, не нужно на это обращать внимание, лучше на дашборды наши посмотрите.
В общем, невероятный вывод: чтобы делать полноценный VM нужно обладать командой и ресурсами как у Tenable, Qualys, Rapid7, Positive Technologies. Ну или хотя бы как у Altx-soft, Secpod, Outpost24, F-Secure.
Или же следует переформулировать задачу. Если пост зайдет по лайкам и репостам, то в следующих частях рассмотрим на примерах как именно можно переформулировать задачу, чтобы успешно вкатиться в около-VMный рынок со сравнительно небольшими ресурсами и на чем в VM-е можно попробовать срезать углы.
@avleonovrus #VM #VMvendors
71 views10:36
A
