По итогам выступления на Positive Customer Day. Всё прошло вполне удачно. Спасибо большое коллегам из Positive Technologies за приглашение! Кажется это был мой первый доклад на "бумажную" тему. Хоть я, в основном, делал акценты на технические сложности при реализации методик, но всё равно. Оказалось, что у "бумажных" докладов своя специфика. Были вопросы в духе: почему регулятор написал документ так, а не иначе? Почему он что-то учёл, а что-то решил не учитывать? Зачем регулятор вообще выпустил тот или иной документ? Раньше я с таким не сталкивался и даже впал в лёгкий ступор. Можно, конечно, что-то фантазировать на эту тему, но такие вопросы явно не по адресу. 😅
В целом же, по итогам Q&A для себя сформулировал следующее:
1. В методику оценки критичности уязвимостей неплохо было бы добавить учёт использования уязвимости в реальных атаках (аналог CISA KEV) и вероятности появления эксплоита для неё (аналог EPSS)
2. В руководство по построению процесса управления уязвимостями было бы неплохо добавить:
2.1. Требования к актуальности данных об обнаруженных уязвимостях, например максимально допустимую периодичность сканирования. Не должно быть возможности сканировать раз в квартал и делать какие-то выводы на основе этого.
2.2. Требования к полноте покрытия активов. Не должно быть активов (хостов, софтов, сетевых устройств и т.д.), которые не покрываются средствами детектирования уязвимостей. Должен быть какой-то процесс подтверждения, что VM-решение умеет детектировать уязвимости для всех активов в организации. Если есть какой-то актив, для которого автоматическое детектирование уязвимостей не производится, нужно с этим что-то делать. Как минимум подсветить.
2.3. Требования к оценке качества детектирования уязвимостей. Ситуация, когда несколько средств детектирования анализируют один и тот же актив и выдают совершенно разные наборы уязвимостей ненормальная. Если так происходит, значит в каких-то решениях реализована неправильная логика и такие решения нельзя использовать в процессе управления уязвимостями ("мусор на входе - мусор на выходе"). Следует ли из этого, что должен быть процесс сертификации средств детектирования уязвимостей, такой как для PCI ASV или SCAP сканеров? Возможно.
Ещё в выступлении я, среди прочего, позволил себе предположить, что подход Positive Technologies к VM-у (который я лично всячески поддерживаю), предполагающий процесс регулярного безусловного патчинга инфраструктуры не особенно сочетается с руководством ФСТЭК по построению процесса управления уязвимостями, т.к. это руководство требует тестирования обновлений для open-source и нероссийского софта по методике ФСТЭК перед установкой. Т.е. процесс регулярного безусловного патчинга может и быть, но кажется момент с тестированием обновлений должен быть определен: тестируем/не тестируем, если тестируем, то чьими силами и в каком объёме.
Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно прочитать здесь. Приглашаю подписаться на мой канал в Telegram @avleonovrus. Я обновляю его чаще, чем этот сайт. Вы можете обсудить мои посты или задать вопросы в @avleonovchat или в группе ВКонтакте.
And I invite all English-speaking people to another telegram channel @avleonovcom.