Хочется ли вам, чтобы покупаемые вами продукты были результативными? Наверное, да. Всегда хочется похвастаться тем, что используемое решение дает некий результат, а значит мы не сделали ошибки, выбрав то или иное решение; Даже если оно бесплатное и open source. Но что такое результативность продукта? В чем она измеряется. Я тут готовился к выступлению, где как раз поднимал эту тему и сейчас хотел бы поделиться своими мыслями. Не претендую на полноту, но мне показалось, что логика в моих рассуждениях есть.
Итак, если мы говорим о результате всей ИБ, тот тут все просто. Это может быть, например, недопущение недопустимых событий. Но как измерить результат конкретного решения, например, средства управления уязвимостями? Что является мерилом для этого класса защитных средств?
Мерилом для кого?
Это очень правильный вопрос, так как не ответив на него, мы не получим того, что нам хочется. Очевидно, что у тех, кто продает и у тех, кто использует средство управления уязвимостями, будут разные взгляды на то, что такое результат. И у тех, кто покупает и тех, кто использует тоже разные. Поэтому сначала надо определиться с тем, кто задает вопрос о результативности.
У Positive Technologies ключевая концепция, вокруг которой сейчас строится многое с технологической точки зрения, звучит очень просто:
TTA > TTR или TTR < TTA, где TTA — это Time to Attack (время атаки), а TTR — это Time to Response (время реагирования, включающее в себя и TTD, то есть Time to Detect).
При кажущейся тождественности этих двух формул, в реальности за ними скрываются совершенно разные смыслы и задачи. В первом случае нам надо сделать так, что время движения злоумышленника к цели было долгим, чтобы успеть его обнаружить и среагировать. Но ключевое — это увеличение времени хакера. А во второй формуле фокус идет на снижение времени реагирования.
Вот и в управлении уязвимостями я бы отталкивался от схожей идеи. То есть у нас TTN должен быть меньше TTX (TTN < TTX), где
- TTN — это Time to Notify, то есть время на уведомление о найденных уязвимостях,
- TTX — это Time to eXploit, то есть время на ее эксплуатацию хакерами.
Первый показатель более просто в измерении и оценке. Производитель прекрасно знает, как его измерять, но у каждого он будет разный. Но так как уязвимости все разной критичности, то и оценивать их надо по-разному. Поэтому у Positive Technologies есть такое понятие как «трендовая уязвимость», информация о которой попадает в PT VM в течение 12 часов. Иными словами, TTN равен 12 часам. У ФСТЭК, в методике управления уязвимостями, уязвимости делятся на большее число уровней опасностей — критический, высокий, средний и низкий. Для каждого из них установлены свои сроки устранения, то есть TTP (Time to Patch).
Вот тут мы уже видим, что для VM-вендора, решение которого может только выявлять уязвимости, результативность будет определяться в первую очередь показателем TTN, а для заказчика более интересен показатель TTP.
И это отличие, кстати, также показывает отличие между продуктом и процессом. Потребителя не очень интересует просто применение продукта, даже самого классного; его интересует устранение уязвимости, а не просто ее обнаружение. А вендор, с другой стороны, не может отвечать за процесс устранения, если его продукт только обнаруживает дыры; пусть и очень оперативно. И надо сказать, что недостатки процесса выявления уязвимостей можно нивелировать (иногда) процессом устранения, и наоборот, даже самое оперативное обнаружения дыр не поможет, если они вовремя не устраняются.
В терминологические споры об отличиях vulnerability management, patch management и asset management (что является частью чего или это просто пересекающиеся множества) я вдаваться сейчас не буду!
Выше я упомянул Time to Patch, но это не совсем корректно. Все-таки устранить уязвимость можно не только путем установки патча, что находится в ведении ИТ-службы (и тогда это будет, да, TTP). Но можно же использовать технологию виртуального патчинга в WAF или временное блокирование доступа к уязвимому приложению на ACL или в NGFW. А можно поиграться с конфигом приложения через соответствующий инструментарий. И все это уже может делать служба ИБ, а не ИТ. В этом случае можно говорить не о TTP, а о TTE, то есть Time to Eliminate, частью которого является параметр TTP.
В зависимости от того, в чьем ведении находится процесс устранения уязвимостей, мерилом его результативности может быть как параметр TTP, так и TTE.
И это, как по мне, так основные показатели для оценки результата от VM-решения/процесса. В качестве второстепенных можно называть и множество других, которые хоть и влияют на конечный результат, но вряд ли могут считаться тем единственным показателем, на который стоило бы ориентироваться. Например, параметр Time to Orchestrate / Ticketing показывает, насколько вообще процесс уведомления ИТ о наличии уязвимостей автоматизирован. Ведь если мы можем оооочень быстро выявлять дыры, но не способны вовремя сообщить об этом в ИТ (или внешнему аутсорсеру), которые и устранять выявленные уязвимости, то грош цена всему нашему процессу.
Другой параметр, Coverage of key assets, показывает, насколько внедренное VM-решение покрывает все целевые и ключевые системы, на которые обычно и нацеливается хакер. Даже если ваше решение по управлению уязвимостями не способно найти уязвимости на всех ваших узлах, то это не значит, что оно плохо. Главное, чтобы оно это могло делать там, куда направляют свои усилия плохие парни.
А как же показатели «уязвимость активов», «активы с SLA», «просроченные уязвимости», «среднее время жизни уязвимости», «среднее число уязвимостей на актив», «новые уязвимости» и множество других, часто используемых при описании эффективности процесса управления уязвимостями? Они, безусловно, важны для оценки различных аспектов самого процесса, но не определяют его результативность.
Например, что мне даст знание % активов, содержащих критические уязвимости? Этот показатель меня ни к чему не побуждает. Да, я буду знать, насколько все плохо. И что? Где эти критические уязвимости найдены? На целевых системах или вообще? Но даже если на целевых, то что? Меня, как потребителя, интересует не число уязвимостей, а их устранение — в этом кроется результат работы решений vulnerability management.
Дискуссионный вопрос, конечно. Но я и не предлагаю решение в заметке, скорее рассуждаю.
Выше я привел формулу TTN < TTX (кстати, вариант TTX > TTN тоже имеет право на жизнь). Но как измерить TTX (Time to Exploit), кроме очевидного «спросить у VM-вендора или пентестеров/RedTeam» или «подсмотреть в TI-отчетах»? Это очень интересный вопрос и я попробую подискутировать о нем в следующий раз; там тоже есть о чем порассуждать. Но знать этот параметр стоит; он, как и TTA (Time to Attack), частью которого он является, будет определять эффективность всей построенной вами системы обнаружения и реагирования. А затем уже от того, будет TTA больше TTR или меньше, будет зависеть результативность всей ИБ.
Кстати, часто, у менеджеров есть такое понятие как критические факторы успеха (Critical Success Factors) при реализации того или иного проекта. Нередко оно неразрывно связано с результативностью и может подсказать, что будет результатом для тех, с кем вы общаетесь.
