Архив рубрики: Регуляторика

Vulnerability Management чек-лист для финансовых организаций от Positive Technologies

2 комментария

Vulnerability Management чек-лист для финансовых организаций от Positive Technologies. Статья вышла в BIS Journal 22 февраля, но я только сейчас её увидел. Мне в целом, импонирует подход PT к VM процессу. Особенно то, что Евгений Полян и Анастасия Зуева транслируют в своих выступлениях. Поэтому мимо их совместной статьи пройти никак не мог. Собрал краткую выжимку, за деталями рекомендую обратиться к исходной статье.

1. ИТ и ИБ должны дружить и вместе работать над исправлением уязвимостей, иначе ничего не получится.

2. Если не исправлять уязвимости, это может привести к серьезным инцидентам и недопустимым событиям для бизнеса.

3. Разрабатываете/внедряете новую систему? Проверьте, что в ТЗ учтены:
3.1. Технологические окна для регулярных обновлений
3.2. Возможность сканирования (от меня: лучше даже шире - проверить, что есть средство детектирования уязвимостей для системы)
3.3. План реагирования на появление новых опасных уязвимостей для ИТ и ИБ

4. Пока не убрали уязвимости, новую систему в промышленную эксплуатацию не берем. Как взяли - продолжаем поддерживать уровень безопасности.

5. Три шага к организации процесса управления уязвимостями:
5.1. Определить перечень недопустимых для организации событий c бизнесом и ТОПами
5.2. Определить риск-рейтинг активов
5.3. Составить регламент работы и обслуживания каждого типа активов, согласовать с бизнесом и IT

6. Зафиксируйте роли подразделений:
6.1. Руководство компании - приоритеты и перечень недопустимых событий
6.2. Топ-менеджмент - перечень наиболее важных сервисов
6.3. ИТ-подразделение - обновление в соответствии с SLA
6.4. ИБ-подразделение - приоритеты устранения уязвимостей, критерии эффективности процессов ИБ, контроль уровня защищенности, определение ключевых активов

7. Определение сроков обновления систем и регламента обновлений:
7.1. Выделить ключевые активы (контроллеры домена, серверы Exchange, системы управления виртуализацией, рабочие станции администраторов и т.д.)
7.2. Установить регламенты по обновлению, определить SLA (и что делать если SLA будет нарушаться)
7.3. Для зарубежного ПО использовать алгоритм НКЦКИ и результаты тестирования обновлений ПО от ФСТЭК

Что мне нравится в этой статье: большой акцент на регулярных обновлениях. Ситуация когда месяцами-годами системы не патчатся и все ждут ИБ-шников, которые должны просканить и поставить задачу на обновление - это не норма. IT-шник, если есть обновление безопасности - иди ставь! ИБшник (VM-щик) нужен для того, чтобы удостовериться, что все хорошо и по регламенту работает, а не для того, чтобы всех пушить постоянно. Ну и для того, чтобы бить в рынду, когда появляется что-то реально критичное.

Что не особо нравится: "три шага" к организации процесса управления уязвимостями это, конечно, что-то из серии научной фантастики. Просто прекрасно, если где-то это действительно без оговорок запустилось, но это скорее не рекомендация к команде ИБ, а реклама крутого консалтинга, который такие штуки делать умеет. Про планирование новых проектов с требованиями по VM тоже все правильно, но отстаивать эти требования также будет ох как не просто. Наиболее практически полезной кажется идея, что наводить порядок нужно с ключевых активов и разгребаться дальше насколько ресурсов хватит.

Управление уязвимостями в новых реалиях

Добавить комментарий

Управление уязвимостями в новых реалиях. Крутой доклад по VM-ной теме с недавно прошедшего Инфофорума. Представлял доклад Андрей Никонов, старший инженер-программист из Фродекс (Vulns.io). Видео в паблике не нашел, но есть даже лучше - слайды с текстом выступления.

Выписал тезисно:

1. Зарубежные VM-вендоры ушли - нет детектов, IT-вендоры ушли - нет обновлений.
2. Атаки на российские компаний множатся, утечки ПД и оборотные штрафы.
3. Рост отечественного ПО -> рост проблемы анализа защищенности этого ПО -> "VM-решения должны уметь работать с операционными системами и программами российского происхождения".
4. В достаточной степени отечественные VM-решения поддерживают отечественное ПО? Непонятно. "Никто открыто не публикует списки поддерживаемых ПО и не дает внятных ответов по степени покрытия российского софта".
5. Необходимы данные об уязвимостях отечественного ПО.
5.1. Западные компании "публикуют уязвимости, найденные в своих продуктах, причем эти данные являются общедоступными, несмотря на то, что большая часть ПО является коммерческим".
5.2. "Данные NVD также являются общедоступными, содержат огромное количество уязвимостей, но для проведения точного аудита годятся мало. В основном из-за того, что они используют собственный формат данных, и в них не указаны правила, по которым можно определить, является ПО уязвимым или нет". -> Ага, детект по CPE-шкам это зло.
5.3. Все ли вендоры одинаково описывают свои уязвимости? Далеко не все. OVAL стал довольно популярным. Но этого недостаточно.
5.4. У нас хорошие источники это БДУ ФСТЭК и OVAL RedOS. "Остальные вендоры, если и публикуют свои данные, то в намного более расслабленном режиме – обычно это выглядит как лента новостей или запись в блоге. Это очень сильно усложняет их обработку. Более того, не все вендоры публикуют данные открыто, хотя некоторые из них готовы предоставить данные по запросу или в случае приобретения сертификата на техническую поддержку."
5.5. Для прикладного ПО из 65 вендоров в базе ФСТЭК 3 публикуют данные об уязвимостях. А в реестре российского ПО 16000 программных продуктов!
5.6. Одной БДУ ФСТЭК недостаточно, т.к. "не указываются правила применимости той или иной уязвимости, для сканирования использовать эти данные проблематично". Данные в БДУ могут добавляться с запаздыванием, данные не всегда актуальны. Напрямую от вендора было бы быстрее.
6. Итог: "обратить внимание разработчиков российского ПО на важность поиска уязвимостей в своих продуктах, и выпуска обновлений безопасности".
Просьбы к регулятору:
"- принять единый стандарт описания уязвимостей или разработать собственный
- обязать разработчиков ОС и ПО вести базы данных уязвимостей в соответствии с принятым стандартом
- оказывать содействие компаниям при организации мероприятий Bug Bounty при условии публикаций найденных уязвимостей в базу ФСТЭК"

В целом, огонь! 🔥 Как раз такие доклады от VM-вендора и хочется видеть. Конкретно про детект уязвимостей и как делать его лучше. Очень сильно перекликается с моими собственными мыслями по этому поводу. Хочется надеяться, что регулятор прислушается.

Бесплатный сканер уязвимостей для Linux от ФСТЭК + OVAL контент для Linux

2 комментария

Бесплатный сканер уязвимостей для Linux от ФСТЭК + OVAL контент для Linux. Продолжаю обозревать крутые штуки от ФСТЭК.

У меня в декабре был пост, что если бы я был регулятор, то обязал бы вендоров сертифицированных Linux-ов привести в порядок бюллетени безопасности, а идеально было бы OVAL контент предоставлять. Так как это делает RedOS. И в каком-то виде это осуществилось. 🤩 Ну не силами Linux-вендоров, а силами ИБ-вендора и регулятора. И с существенными ограничениями. Но факт - вот тебе OVAL-контент для сертифицированных Linux-ов в паблике и бесплатный сканер, который с ним работает.

На сайте ФСТЭК-а выложили бесплатный локальный сканер уязвимостей ScanOVAL в версиях под Linux (раньше был только под Windows). И OVAL-контент к нему. В трёх вариантах:

1. ScanOVAL для ОС Astra Linux 1.6 SE - тестовая версия сканера и OVAL-контент
2. ScanOVAL для ОС Альт 9 - тестовая версия сканера и OVAL-контент
3. ScanOVAL для ОС Роса «Кобальт» - тестовая версия сканера (OVAL-контент пока недоступен)

ScanOVAL это, конечно, не вполне полноценный сканер. Он может сканировать только локалхост. Штатно запускается только в графическом режиме. Т.е. использовать его, чтобы вручную валидировать уязвимости на хостах получится, а приспособить для регулярного сканирования всей инфры скорее всего нет. Понятно зачем сделано, этот продукт не должен рушить бизнес VM-вендорам.

Другой вопрос, который естественно возникает, когда видишь OVAL-контент в паблике, а можно ли его использовать не в составе ScanOVAL? 😏 Например, OpenSCAP-у скормить, свой OVAL сканер написать или интерпретировать во что-нибудь? Ответ: технически реально, а юридически нельзя, т.к. EULA для ScanOVAL это отдельно оговаривает:

"Не допускается осуществлять следующие действия:
…
использовать ПО и (или) описания проверок (включая любые их фрагменты), применяемые в ее составе, с целью создания баз данных или кода, предназначенных для предотвращения угроз безопасности информации;
публиковать, а также распространять от своего имени любые фрагменты описаний проверок, применяемых в составе ПО;
…"

Тоже понятно почему. Идентификаторы дефинишенов, такие как "oval:ru.altx-soft.nix:def:156318", не оставляют сомнений в происхождении контента и понятно, что рушить свой бизнес коммерческому VM вендору совсем не нужно.

Поэтому,
1. Круто, что появилась возможность сканировать сертифицированные отечественные Linux-ы бесплатным решением. Даже если использовать его только в ручном режиме как эталонный сканер, это более чем полезно.
2. Потребность в OVAL-контенте (или просто бюллетенях хотя бы) от Linux-вендора это не снимает, т.к. EULA конечно полноценно использовать контент для ScanOVAL не позволяет, к сожалению.

Методические рекомендации по безопасной настройке Linux систем от ФСТЭК

2 комментария

Методические рекомендации по безопасной настройке Linux систем от ФСТЭК. Что? 😳 ДА! 🎉Теперь можно ссылаться не на CIS, не на DISA STIGs, не на BSI IT-Grundschutz, а на технические требования нашего отечественного регулятора. Ну круть же! Скачать можно на сайте ФСТЭК.

1. Документ очень компактный, всего 7 страниц. CIS Benchmark для Ubuntu Linux 20.04 LTS, для сравнения, занимает 531 страницу.
2. Рекомендации подлежат реализации в государственных информационных системах (ГИС) и на объектах критической информационной инфраструктуры (КИИ).
3. Рекомендации распространяются на настройку НЕсертифицированных ОС (как раз Debian, Ubuntu, CentOS Stream, Alma Linux, Rocky Linux, openSUSE и прочего) "до их замены на сертифицированные отечественные операционные системы". Т.е. мейнстримные Linux дистрибутивы из КИИ и ГИС придется выносить, если они есть. Сертифицированные же Linux-ы должны настраиваться "в соответствии с эксплуатационной документацией разработчиков".
4. Рекомендации касаются именно настройки. Пример: "2.1.2. Обеспечить отключение входа суперпользователя в систему по протоколу SSH путём установки для параметра PermitRootLogin значения no в файле /etc/ssh/sshd_config." Как проверять не расписывается.
5. Сложность реализации настроек и проверок соответствия по пунктам из этих рекомендаций зависит от конкретности рекомендаций. Часть рекомендаций выглядят достаточно конкретными, часть нет, например "2.3.8. Установить корректные права доступа к исполняемым файлам и библиотекам операционной системы путём анализа корректности прав доступа к утилитам и системным библиотекам, расположенным по стандартным путям (, /usr/bin, , и другим путям), а также к модулям ядра (для Linux: /lib/modules/версия-текущего-ядра)". Понятно, что конкретные настройки могут зависеть от конкретного дистрибутива, но все же хотелось бы большей однозначности, что нужно делать.
6. В некоторых пунктах приводится обоснование зачем это настройка нужна, например "в противном случае это может привести к выполнению произвольного кода от имени владельца задания cron". Но для большей части рекомендаций этого нет. А тоже хотелось бы.

Блоки рекомендаций:
1. Настройка авторизации в операционной системе.
2. Ограничение механизмов получения привилегий.
3. Настройка прав доступа к объектам файловой системы.
4. Настройка механизмов защиты ядра Linux.
5. Уменьшение периметра атаки ядра Linux.
6. Настройка средств защиты пользовательского пространства со стороны ядра Linux.

В целом, инициатива очень крутая, но к такому документу нужны ещё дополнительные конкретизирующие документы с настройками/проверками для конкретных ОС и обоснованиями почему каждая настройка важна и что может сделать злоумышленник в случае, если рекомендации по настройке не будут применены.

Результаты тестирования обновлений безопасности

2 комментария

Результаты тестирования обновлений безопасностиРезультаты тестирования обновлений безопасности

Результаты тестирования обновлений безопасности уже доступны на сайте БДУ ФСТЭК. Вкладка Уязвимости -> Тестирование обновлений. Пишут, что "в настоящее время проводится опытная эксплуатация раздела". Это результаты работ по той самой госзакупке? Не знаю, но судя по таймингу тестирований вполне возможно.

1. Всего 112 обновлений протестировано.
2. Скачать весь фид целиком похоже пока нельзя. По кнопке "скачать" скачивается только текущая страница.
3. Первое тестирование от 28.08.2022, последнее тестирование от 24.12.2022.
4. Похоже, что обновления пока только Microsoft-овские.
5. Для обновления доступно его наименование, ссылка на описание, ссылка на файл-обновления, хеши, дата выпуска обновления, вендор, ПО, версии уязвимого ПО, версии тестируемого ПО, идентификаторы БДУ, идентификаторы CVE, вердикт.
6. Возможные значения для вердикта: "Влияние на инфраструктуру отсутствует", "Может оказать некритичное влияние на инфраструктуру", "Выявлено деструктивное воздействие на инфраструктуру".
7. Пока для всех тестов вердикт "Влияние на инфраструктуру отсутствует".

Теперь перед раскаткой обновления можно/нужно поглядывать на его вердикт в БДУ. Как это делать удобно и автоматизированно пока не особо понятно, но какой-то ручной процесс уже можно выстраивать. И это несоизмеримо проще, чем делать полноценное тестирование обновлений своими силами по методике. Ура!

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском

Добавить комментарий

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском. На русском было тут.

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

Добавить комментарий

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей. И американским регуляторам, включая CISA, видимо наплевать.

Mozilla Foundation Security Advisory 2022-09
Announced March 5, 2022
CVE-2022-26486: Use-after-free in WebGPU IPC Framework

Эта уязвимость есть в CISA Known Exploited Vulnerabilities Catalog. Значит эта критичная уязвимость эксплуатируется в реальных атаках.

Но если вы попробуете перейти по ссылке на CVE-2022-26486, например из той же CISA KEV, на сайт на NVD, то вы увидете "CVE ID Not Found". В MITRE аналогично: "RESERVED". Статус 9 месяцев не менялся (и видимо не поменяется). Что-то где-то пошло не так.

Могли бы CISA попушить NIST, MITRE или Mozilla, чтобы с этой критичной CVE навели порядок? Запросто. Но они это не делают. Им видимо норм ссылаться в никуда.

А вот в БДУ ФСТЭК для CVE-2022-26486 видим вполне адекватное описание с CVSS и всем, что нужно. ФСТЭК молодцы. 👍