Регламент по устранению уязвимостей

Материал из Rosalab Wiki
Версия от 10:32, 29 мая 2018; Vladimir.potapov (обсуждение | вклад) (Порядок действий репортера)

Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск

Содержание

Назначение

Данный регламент описывает действия репортеров SecTeam, связанные с устранением уязвимостей в продуктах, выпускаемых ООО "НТЦ ИТ РОСА" и сообществом разработчиков ОС РОСА Fresh.

Общая схема работы по уязвимостям:

 Поиск -> Определение локализации и критичности -> Документирование -> Исправление -> Проверка -> Публикация

Поиск уязвимостей

Поиск уязвимостей производится в общедоступных базах данных уязвимостей, с помощью сканера уязвимостей и антивируса, в иных источниках а также сканером устаревшего и вредоносного ПО.

Поиск в общедоступных базах данных уязвимостей

  1. В базе данных уязвимостей в составе банка данных угроз безопасности информации (www.bdu.fstec.ru);
  2. В иных источниках и средствах массовой информации (cve.mitre.org, nvd.nist.gov, www.cvedetails.com, www.securitylab.ru).

В качестве идентификаторов для поиска известных (подтвержденных) уязвимостей использовались: название, версия, архитектура ОС семейства РОСА; наименование компании-разработчика (ООО «НТЦ ИТ РОСА»). Для поиска известных (подтвержденных) уязвимостей изделия выполняются запросы вида:

  • «уязвимости ОС РОСА»;
  • «уязвимости НЦТ ИТ РОСА»;
  • «vulnerability Rosa».

Для поиска потенциальных уязвимостей изделия выполнялись запросы вида:

  • «уязвимости ОС Linux»;
  • «уязвимости ядра Linux»;
  • «Linux kernel vulnerability»;

и т.п.

Проверка сканером уязвимостей

Проверка осуществляется сканером уязвимостей OpenVAS с подключенными модулями следующих БД уязвимостей:

  • NVT;
  • CVE;
  • CPE;
  • OVAL Definitions;
  • CERT-Bund advisores;
  • DFN-CERT advisores.

Обновление БД уязвимостей производится регулярно (не реже раза в неделю).

Проверка с помощью антивируса

  1. Проверка осуществляется программой clamav, перед проверкой производится полное обновление доступных баз данных командой freshclam
  2. Изделие проверяется в варианте установки «по умолчанию»; также проверяются все файлы, расположенные на установочном носителе (носителях) изделия.
  3. Обновление баз средства АВЗ производится не реже 1 раза в неделю.

Поиск вредоносного и устаревшего ПО

Проверка осуществляется коммерческим программным средством с открытым исходным кодом Cisofy Lynis (https://cisofy.com/lynis/) (Может быть, ISPProtect, может быть, и тем , и тем, может еще что-то есть?)

Определение критичности уязвимости

Общие положения

Для определения применимости той или иной уязвимости для того или иного изделия следует учитывать следующее:

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

Приоритет критичности уязвимостей

При определении критичности найденной уязвимостей необходимо использовать следующие приоритеты (от высшего к низшему):

Базовые пакеты системы, обеспечивающие загрузку и авторизацию в консольном режиме

  • glibc
  • kernel
  • systemd
  • PAM
  • kerberos
  • initscripts
  • cracklib
  • grub
  • parted
  • kmod
  • audit-libs
  • Загружаемые модули ядра

Уязвимости, характерные для конкретной аппаратной конфигурации и драйверов для нее

  • Проприетарные драйвера для видеокарт
  • Драйвера wifi, сканеров, принтеров.

Сетевой доступ к ресурсам и связанные пакеты

  • network/NetworkManager, iptables, acl, bind, dhcp
  • rpm, yum, urpmi
  • openssl
  • openssh/sftp
  • samba
  • openvpn
  • nfs
  • X11
  • bash, coreutils
  • curl, wget, aria
  • dbus
  • udev
  • CUPS

Авторизация и работа в графическом окружении, скрипты

  • Х-ы
  • Менеджеры входа
  • perl, python

Предустановленные в образе программы

  • Браузеры
  • Файловые менеджеры
  • Эмуляторы терминала
  • Офисные программы
  • Мультимедиа - проигрыватели

Программы из репозиториев

Программы, которые пользователь ставит из репозиториев - уязвимость распространяется только на тех, кто установил программу

Прочее

Низший приоритет для программ, не использующих сетевое взаимодействие и не запускающих собственные сервисы.

Размещение информации о подтвержденных уязвимостях

Адреса публикации

Информация о выявленном недостатке с его описанием публикуется в виде информационного бюллетеня безопасности на общедоступных ресурсах предприятия разработчика по адресам: http://wiki.rosalab.com/ru/index.php/Security_Bulletin http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories

Формат публикации

Каждый такой бюллетень безопасности имеет уникальный идентификатор вида: ROSA-SA-01-02-03.456, разделенной дефисами и точкой. где:

  • первые 4 буквы ROSA идентифицируют разработчика;
  • вторые 2 буквы SA идентифицируют тип публикации - бюллетень безопасности (Security Advisory);
  • первая последовательность цифр содержат год публикации (после 2000 года);
  • вторая последовательность цифр указывает на месяц года;
  • третья последовательность цифр указывает на день (число);
  • после точки нумеруется по порядку конкретный бюллетень за конкретное число (в случае необходимости, если выявлено несколько недостатков за конкретную дату).

При описании недостатка учитывается и публикуется следующее:

  • уникальный идентификатор (номер) бюллетеня безопасности вида «ROSA-SA-17-12-23.001»;
  • категория статьи на ресурсе, указывающая, что это бюллетень безопасности (неизменна);
  • приводится описание уязвимости (недостатка) вида: «Возможность компрометации аутентификационной информации пользователя при прохождении аутентификации в графическом интерфейсе (GDM/GNOME3)»;
  • приводится перечень продукции (программного обеспечения) разработчика, к которой относится недостаток (уязвимость), вида: «ОС РОСА КОБАЛЬТ»;
  • приводится степень критичности недостатка (уязвимости) с точки зрения разработчика. Всего 5 степеней - от наиболее значимой к наименее: «Критическая», «Высокая», «Средняя», «Низкая», «Незначительная»;
  • приводится текущий статус уязвимости (недостатка), позволяющий оперативно отслеживать информацию о степени устранения недостатка (уязвимости). Всего 5 степеней: «Устранена», «Нейтрализована», «Информация проверяется», «Ведутся работы по устранению (нейтрализации)», «Не устранена»;
  • приводится список ПО (пакетов, образов, файлов), необходимое к установке, в случае устранения уязвимости (недостатка) вида: «gnome-shell-3.14.4-53.res7c.4.x86_64.rpm»;
  • приводится перечень мероприятий и рекомендаций по нейтрализации уязвимости (если применимо), в случае, если устранение по каким-либо причинам невозможно, либо у потребителя (пользователя) нет оперативной необходимости устранять уязвимость. Например: «Использовать в качестве менеджера

входа в ОС менеджер входа lightdm.»;

  • приводятся данные (в виде гиперссылок) о наличии информации об уязвимости (недостатке) в общедоступных базах данных уязвимостей (если применимо), вида: «BDU:2016-01584» или «CVE-2013-0221» и т.п.;
  • может приводиться дополнительная информация, позволяющая классифицировать уязвимость (недостаток) по типу, классу или иная информация, отражающая, например, способ эксплуатации уязвимости (недостатка). А также другая информация, полезная потребителю (пользователю), вида: «Эксплойт не

требуется. При аутентификации пользователя в менеджере входа GDM, либо при срабатывании механизма аутентификации для переключения контекста учетной записи в графическом окружении GNOME3 существует возможность компрометации аутентификационной информации (пароля). Для эксплуатации уязвимости в ОС РОСА КОБАЛЬТ с версией пакета ниже чем gnome-shell-3.14.4-53.res7.4.x86_64 с помощью ПКМ возможно вывести на экран вводимую в поле пароля информацию. Уязвимость нарушает требование ИТ.ОС.А4.ПЗ FIA_UAU.7 "Аутентификация с защищенной обратной связью"».

Исправление уязвимостей

Порядок действий репортера

Ответственность репортера - нахождение и документирование уязвимостей, а также проверка их исправления сборщиком. В процессе исправления уязвимостей репортер:

  1. Создает баг в багзилле для каждого продукта, в котором найдена уязвимость
  2. В баге указывается код уязвимости (в поле ROSA Vulnerability identifier), продукт, компонент и приоритет исправления
  3. Список всех багов с установленным RVI можно получить запросом https://bugzilla.rosalinux.ru/buglist.cgi?classification=ROSA%20CENOS-based%20products&f1=cf_security_code&list_id=43890&o1=notequals&query_format=advanced
  4. Через почтовую рассылку отслеживает изменение состояния бага, при необходимости давая дополнительную информацию и меняя приоритеты
  5. После сборки (получив флажок secteam_verified в "?" ) проверяет исправление уязвимости и, при успешной проверке, меняет информацию на бюллетене в вики и ставит в багзилле статус "VERIFIED" и флажок secteam_verified в "+" а при неуспешной сборке secteam_verified в "-", таким образом направляя запрос на повторную сборку

Порядок действий сборщика

Ответственность сборщика - сборка пакетов с исправлением уязвимостей по запросам репортера

  1. Сборщик получает информацию о уязвимости через рассылку bugs@rosalinux.ru - незакрытые баги с установленным кодом RVI
  2. Собирает и указывает в баге контейнеры с исправленными пакетами
  3. Устанавливает флажки в знак вопроса (secteam_verified и, при наличии для его платформы QA, qa_verified) таким образом давая команду на проверку собранного.

Порядок действий публикатора

Ответственность публикатора - доведение пакетов с исправлениями до конечного пользователя

  1. Публикатор отслеживает собранные и проверенные пакеты с исправлениями уязвимостей, направленные на публикацию по наличию флажка publishied
  2. Он обеспечивает публикацию пакетов в репозиториях или другие методы доведения исправленных пакетов до пользователей системы
  3. После успешной публикации он устанавливает флажок publishied в '+', при невозможности по каким-то причинам публикации, флажок устанавливается в '-'

Порядок работы собрания Security Team

  1. Команда SecurityTeam собирается раз в неделю, по вторникам
  2. На собрание выносится общий список не исправленных за предыдущее время багов. Он формируется автоматически по запросу из багзиллы
  3. По каждому запросу выносится решение, назначаются приоритеты и ответственные

Публикация информации об обновлениях

Каждую пятницу публикуется бюллетень с планируемыми обновлениями. В нем указываются ссылки на исправленные баги, в том числе связанные с исправлениями уязвимостей.