На сайте ФСТЭК выложили финальную версию "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что изменилось по сравнению с драфтом в части Управления Уязвимостями?

🔻 Поправили опечатку "их сети Интернет".
🔻 В обоих пунктах появилась приписка "или в отношении таких уязвимостей реализованы компенсирующие меры".

Понятно почему появилась приписка про компенсирующие меры - не всегда уязвимости можно исправить обновлением. Но есть опасность, что этим будут злоупотреблять, т.к. не указано какие меры можно считать компенсирующими. Возможно толкование, что компенсирующие меры могут выбираться произвольно. В духе "на десктопе есть EDR, значит все уязвимости на нём скомпенсированы". 🤪 Но даже если меры будут браться строго от вендора или из БДУ непонятно как контролировать, то что они были корректно применены, а главное, что эти меры действительно препятствуют эксплуатации уязвимости. На практике это будет выглядеть так: сканер детектирует уязвимости, а IT/ИБ с покерфейсом говорят "а у нас всё скомпенсировано". 😐 Так что моё мнение - без приписки было лучше, не нужно было создавать такую лазейку.

Также остался вопрос с "датой публикации обновления (компенсирующих мер по устранению)". Такой даты нет в БДУ (равно как и в других базах уязвимостей). Непонятно откуда её массово забирать, чтобы автоматически отслеживать, что организация укладывается в сроки. Вряд ли источник с датами появится, так что видимо на практике в VM-решениях будут использовать какую-то другую дату (например дату заведения уязвимости). А в случае инцидента это будет повод для лишних разбирательств. Имхо, зря это сразу не прояснили.

На эту же тему может быть интересная ситуация: допустим выходит обновление в котором вендор втихую исправляет уязвимость критического уровня опасности. А о существовании этой уязвимости становится известно, допустим, через полгода. В момент публикации данных об этой уязвимости у организации сразу получается просрочка. 🤷‍♂️ Просто потому, что используется дата, привязанная к обновлению, а не к уязвимости. Надумана ли такая ситуация? Да нет, "silent patches" проблема достаточно распространенная.

В этом, правда, есть и позитивный момент. Чтобы не попасть в такую ситуацию организации придётся выстраивать Patch Management процесс независящий от уязвимостей. И с неплохими требованиями регулярности обновлений: 30 дней для хостов на периметре, 90 дней для десктопов и серверов. 😏

PS: Также pdf-документ выпустили как-то странно, так что по нему не работает поиск. По odt-документу поиск работает нормально.

Вышел драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что там с Управлением Уязвимостями?

Есть 2 показателя безопасности, зависящие от оперативности устранения уязвимостей:

🔸 3.2. "На устройствах и интерфейсах, доступных их сети Интернет, отсутствуют уязвимости критического уровня опасности с датой публикации обновлений (компенсирующих мер по устранению) в банке данных угроз ФСТЭК России, на официальных сайтах разработчиков, иных открытых источниках более 30 дней"

🔸 3.3 "На пользовательских устройствах и серверах отсутствуют уязвимости критического уровня с датой публикации обновления (компенсирующих мер по устранению) более 90 дней (не менее 90% устройств и серверов)"

❓Во втором случае не указано откуда дату публикации обновления брать. Наверное нужно сделать единообразно.
❓"доступных их сети Интернет" - опечаточка, "из".

Из пунктов следует, что нужно:

🔻 покрывать все активы детектами уязвимостей
🔻 понимать какие именно активы опубликованы в Интернет
🔻 уметь оценивать критичность уязвимостей по методике ФСТЭК
🔻 отслеживать дату публикации обновления (а не дату публикации самой уязвимости!) в разных источниках 😲

Последнее выглядит как нетривиальная задача, т.к. общего реестра данных по обновлениям не наблюдается, получается ведение такого реестра и наполнение его ляжет на организацию. На практике, скорее всего, придется ориентироваться именно на дату публикации уязвимости, т.к. её гораздо проще определять (непосредственно в NVD/BDU) и, по идее, она должна быть всегда более ранней или равной дате публикации обновления. 🤔 Поэтому, возможно, имеет смысл подкрутить формулировочку, например на "дата публикации уязвимости или обновления (компенсирующих мер по устранению)". И сделать пометочку, что допустимо взять наибольшую из имеющихся дат.

И, в идеале, хотелось бы ещё видеть аналог CISA KEV с непосредственно указанными датами, когда конкретные уязвимости должны быть исправлены.