10 новостей об оценке защищенности

Сегодня я хотел написать другую заметку, посвященную SOCам, но как-то так все сложилось, что за последние несколько дней тема оценки защищенности заиграла новыми красками и набралось целых семь новостей по этой теме, которые я бы и хотел свести в рамках одной заметки.

Началось все с сообщения ФСТЭК России об утверждении двух методик:

• оценки уровня критичности уязвимостей программных, программно-аппаратных средств
• тестирования обновлений безопасности программных, программно-аппаратных средств.

Первая методика не очень большая по объему, но мне показалось, что она не очень проста в своей реализации, так как она не просто отталкивается от CVSS, а предлагает чуть более сложный алгоритм расчета уровня критичности. Оно вроде и понятно — CVSS давно вызывает критику, а как показывает серия отчетов института Cyentia «Measuring and Minimizing Exploitability» использование CVSS не сильно отличается от случайного устранения выявленных уязвимостей. Поэтому-то на смену CVSS уже было предложено несколько иных методик оценки и приоритизации уязвимостей:

• EPSS (Exploit Prediction Scoring System), которая поддерживается FIRST,
• SSVC (Stakeholder-Specific Vulnerability Categorization), которая поддерживается институтом инжиниринга ПО Университета Карнеги-Меллона,
• Truly Risk-Centered Approach, который поддерживается The Record Future,
• VPR (Vulnerability Priority Rating), который поддерживается Tenable,
• Risk Score, который поддерживается Kenna (сейчас часть Cisco).

Как видно из формулы, ФСТЭК предлагает, используя калькулятор с сайта БДУ, определить показатель Icvss (а это потребует множества кликов), а потом определить Iinfr, характеризующий влияние уязвимости на функционирования информационной системы, которое зависит от типа актива, массовости уязвимости, доступности из Интернет и т.д. Само по себе это все неплохо и разумно, но если подумать, что такое надо проделывать для каждой уязвимости, коих насчитывается дофига… Есть подозрение, что в этом году будет зарегистрировано 25 тысяч CVE, то есть по 65 уязвимостей в день. В общем, надо подумать над автоматизацией этой задачи. Но в целом не могу не отметить, что движение регулятора в сторону методологической поддержки своих подопечных — это хорошо. Главное, чтобы проверяющие на местах не стали требовать жесткого применения этого документа, носящего рекомендательный характер, как видно из его названия.

Результатом работы методики является рейтинг уязвимости, от которого зависит срочность установки обновления и способ его проверки, что регулируется уже второй методикой ФСТЭК. Помните, в апреле НКЦКИ выпустил свои рекомендации по обновлению критичного ПО, не относящегося к open source? ФСТЭК подошла к вопросу более методически — они описали некоторые индикаторы вредоносности обновления, на которые стоит обратить внимание. Там и обращение к файловой системе, и характерные для вредоносного ПО системные вызовы, и работа с внешними Интернет-ресурсами, и отключение средств защиты, и т.п. Это, конечно, далеко не все индикаторы, но лучше, чем просто ориентироваться на «свой/чужой». В конце концов, тестирование обновлений — сама по себе нетривиальная задача и вы никогда не сможете со 100%-й вероятностью утверждать, что полученное обновление не имеет недокументированных возможностей; особенно, если они работают с задержкой.

Хотя с начала СВО так и не было ни одного примера получения вредоносного функционала в ПО от крупных разработчиков, покинувших Россию (если не брать вредоносный функционал в некоторых open source компонентах типа NPM-модуля node-ipc или показа проукраинских баннеров в ПО от небольших компаний).

Для самих обновлений предлагается 6 способов тестирования — от условного SBOM и применения антивируса до использования песочницы и ручного анализа. Тут тоже надо сказать, что большинство компаний будет не в состоянии реализовать это все самостоятельно. Поэтому есть надежда, что эту задачу возьмут на себя либо ИБ-компании, либо сама ФСТЭК. Тем более, что регулятор размещал конкурс на «Выполнение работ по разработке инфраструктуры, обеспечивающей проведение тестирования обновлений безопасности программного обеспечения зарубежных разработчиков».

Но ФСТЭК не ограничилась этими двумя методиками. На SOC Forum были анонсированы проекты еще двух методик. Первая касается оценки защищенности уже не ПО, как две предыдущие, а целой информационной системы:

Второй проект поднимается еще выше и предназначен для оценки защищенности целой организации. Вторая методика похожа по своей структуре на оценку зрелости организации по широкому кругу вопросов ИБ. Пока по обеим методикам говорить что-то рано — кроме слайдов регулятор ничего не представил, но судя по пометкам на предыдущей картинке, эксперты по проекту хотя бы одной методики уже работают.

Рассказ про движение ФСТЭК в сторону оценки защищенности дополню перечисление ГОСТов, которые готовит регулятор, и которые можно отнести к теме сегодняшней заметки (буду их считать за одну новость 🤠):

• Руководство по оценке безопасности разработки программного обеспечения
• Руководство по проведению статического анализа программного обеспечения
• Руководство по проведению динамического анализа программного обеспечения
• Тестирование на проникновение. Общие требования
• Статический анализ исходных текстов. Требования к документированию порядка применения и результатов работы инструментальных средств
• Поиск уязвимостей программного обеспечения на этапе эксплуатации и выпуск обновлений безопасности. Общие требования
• Тестирование безопасного программного обеспечения. Требование к документированию порядка применения результатов
• Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель (Идентичный на основе 180/1ЕС 15408-1:2021)
• Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности (Идентичный на основе 180/1ЕС 15408-2:2021)
• Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности (Идентичный на основе 180/1ЕС 15408-3:2021)
• Методология оценки безопасности информационных технологий (Идентичный на основе 180/1ЕС 18045:2021).

Солидный перечень работ, не так ли?

Шестой новостью могу назвать свою обзорную статью про различные варианты оценки защищенности, опубликованную в «ИТ-Менеджере». Каких-то секретов и глубоких глубин нет, но я попробовал описать возможные варианты оценки уровня ИБ, не ограниченные привычными пентестами или запуском сканеров безопасности.

Помимо предельно конкретных методологий и стандартов от ФСТЭК на днях общественности было предложено еще три нормативных документа:

• Постановление Правительства Российской Федерации от 14.11.2022 №2051 «Об утверждении Правил обращения со сведениями о результатах проведенной оценки уязвимости объектов транспортной инфраструктуры, судов ледокольного флота, используемых для проводки по морским путям, судов, в отношении которых применяются правила торгового мореплавания и требования в области охраны судов и портовых средств, установленные международными договорами Российской Федерации, а также со сведениями, содержащимися в планах и паспортах обеспечения транспортной безопасности объектов транспортной инфраструктуры и (или) транспортных средств, которые являются информацией ограниченного доступа, и признании утратившими силу некоторых актов Правительства Российской Федерации». Оно в меньшей степени про оценку защищенности, а скорее про то, что такая информация относится к сведениям ограниченного доступа, работа с которыми должна регламентировать (о чем и пишет ПП-2051).
• 4 ноября этого года ФСБ выпустила приказ №547 «Об утверждении перечня сведений в области военной, военно-технической деятельности, которые, при их получении иностранным источниками могут быть использованы против безопасности РФ», в котором сведения о результатах анализа защищенности государственных информационных систем и объектов КИИ (причем любых, включая незначимые) отнесены к сведениям… (ну и далее из заголовка нормативного акта). По мне так это перебор (особенно, если читать весь приказ), но с этим уже ничего не поделаешь — мы вступили в эпоху бездумного засекречивания всего и вся. А этот приказ хоть ничего и не засекречивает, но теперь десять раз подумаешь, что говорить или писать публично, а что не стоит «во избежание». Интересно, «анализ защищенности» и «оценка защищенности» — это одно и тоже?..
• ФСБ подготовила проект приказа «Об утверждении Порядка осуществления мониторинга защищенности информационных ресурсов, принадлежащих федеральным органам исполнительной власти, высшим исполнительным органам государственной власти субъектов Российской Федерации, государственным фондам, государственным корпорациям (компаниям), иным организациям, созданным на основании федеральных законов, стратегическим предприятиям, стратегическим акционерным обществам и системообразующим организациям российской экономики, юридическим лицам, являющимся субъектами критической информационной инфраструктуры Российской Федерации либо используемых ими», который подготовлен во исполнение 250-го Указа Президента.

У нас теперь оценкой защищенности занимаются (регулируют) ФСТЭК, ФСБ и Минцифры (ну и ЦБ до кучи, для финансовых организаций). И каждый регулятор выпускает свои нормативные требования. Перебор какой-то 🙁

Последний приказ от ФСБ определяет, что мониторинг защищенности осуществляется непрерывно 8-м Центром ФСБ и включает в себя следующие мероприятия:

• сбор и анализ сведений и документов о принадлежащих и используемых организациями информационных ресурсах;
• выявление функционирующих сервисов и обнаружение уязвимостей в информационных ресурсах организаций;
• оценка защищенности информационных ресурсов организаций.

Возможно, перекрестный анализ (своими силами по методичкам ФСТЭК и силами 8-го Центра) поднимет уровень защищенности отечественных организаций, но придется им, конечно, не сладко. Не привыкли они к результативной ИБ, одним из этапов реализации которой является непрерывный мониторинг своей инфраструктуры как на сетевом, так и на прикладном уровне.

Десятой новостью, оставленной мной «на закуску», является методика оценки критичности уязвимостей, выпущенная американским CISA (ее руководительница на днях была внесена МИДом в наш санкционный список). На самом деле CISA не стала придумывать ничего нового, а взяла за основу методику SSVC от Университета Карнеги-Меллона, которую я упомянул выше (один из конкурентов CVSS, EPSS и др.). Эта, обязательная для американских госов, муниципалов и КИИ методика, представляет собой просто дерево принятия решений относительно выявляемых уязвимостей и действий с ними. Основной атрибут, от которого отталкивается CISA, — эксплуатация уязвимости «в дикой природе» (активно, есть POC, нет), в зависимости от значения которого и ветвится дерево и принимаются соответствующие решения. В этом, наверное, ключевое отличие методики ФСТЭК от своей американской «коллеги».

Вот такая насыщенная заметка получилась. И все про оценку защищенности, с которой начинается построение системы ИБ предприятия, и которой она заканчивается, чтобы подтвердить, что все мероприятия выполнены корректно.