Регламент по устранению уязвимостей — различия между версиями
Материал из Rosalab Wiki
(→Назначение) |
(→Порядок действий репортера) |
||
| (не показаны 23 промежуточные версии этого же участника) | |||
| Строка 1: | Строка 1: | ||
| − | + | = Назначение = | |
| − | Данный регламент | + | Данный регламент описывает действия репортеров SecTeam, связанные с устранением уязвимостей в продуктах, выпускаемых ООО "НТЦ ИТ РОСА" и сообществом разработчиков ОС РОСА Fresh. |
| − | + | Общая схема работы по уязвимостям: | |
| − | + | Поиск -> Определение локализации и критичности -> Документирование -> Исправление -> Проверка -> Публикация | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | = | + | = Поиск уязвимостей = |
| − | + | Поиск уязвимостей производится в общедоступных базах данных уязвимостей, с помощью сканера уязвимостей и антивируса, в иных источниках а также сканером устаревшего и вредоносного ПО. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | == Поиск в общедоступных базах данных уязвимостей == | |
| − | + | # В базе данных уязвимостей в составе банка данных угроз безопасности информации (www.bdu.fstec.ru); | |
| − | == | + | # В иных источниках и средствах массовой информации (cve.mitre.org, nvd.nist.gov, www.cvedetails.com, www.securitylab.ru). |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
В качестве идентификаторов для поиска известных (подтвержденных) уязвимостей использовались: название, версия, архитектура ОС семейства РОСА; наименование компании-разработчика (ООО «НТЦ ИТ РОСА»). | В качестве идентификаторов для поиска известных (подтвержденных) уязвимостей использовались: название, версия, архитектура ОС семейства РОСА; наименование компании-разработчика (ООО «НТЦ ИТ РОСА»). | ||
Для поиска известных (подтвержденных) уязвимостей изделия выполняются запросы вида: | Для поиска известных (подтвержденных) уязвимостей изделия выполняются запросы вида: | ||
| − | «уязвимости ОС РОСА»; | + | * «уязвимости ОС РОСА»; |
| − | «уязвимости НЦТ ИТ РОСА»; | + | * «уязвимости НЦТ ИТ РОСА»; |
| − | «vulnerability Rosa». | + | * «vulnerability Rosa». |
Для поиска потенциальных уязвимостей изделия выполнялись запросы вида: | Для поиска потенциальных уязвимостей изделия выполнялись запросы вида: | ||
| − | «уязвимости ОС Linux»; | + | * «уязвимости ОС Linux»; |
| − | «уязвимости ядра Linux»; | + | * «уязвимости ядра Linux»; |
| − | «Linux kernel vulnerability»; | + | * «Linux kernel vulnerability»; |
и т.п. | и т.п. | ||
| − | + | == Проверка сканером уязвимостей == | |
| − | + | ||
Проверка осуществляется сканером уязвимостей OpenVAS с подключенными модулями следующих БД уязвимостей: | Проверка осуществляется сканером уязвимостей OpenVAS с подключенными модулями следующих БД уязвимостей: | ||
| − | NVT; | + | * NVT; |
| − | CVE; | + | * CVE; |
| − | CPE; | + | * CPE; |
| − | OVAL Definitions; | + | * OVAL Definitions; |
| − | CERT-Bund advisores; | + | * CERT-Bund advisores; |
| − | DFN-CERT advisores. | + | * DFN-CERT advisores. |
Обновление БД уязвимостей производится регулярно (не реже раза в неделю). | Обновление БД уязвимостей производится регулярно (не реже раза в неделю). | ||
| − | ''' | + | == Проверка с помощью антивируса == |
| + | # Проверка осуществляется программой clamav, перед проверкой производится полное обновление доступных баз данных командой '''freshclam''' | ||
| + | # Изделие проверяется в варианте установки «по умолчанию»; также проверяются все файлы, расположенные на установочном носителе (носителях) изделия. | ||
| + | # Обновление баз средства АВЗ производится не реже 1 раза в неделю. | ||
| − | + | == Поиск вредоносного и устаревшего ПО == | |
| − | + | Проверка осуществляется коммерческим программным средством с открытым исходным кодом Cisofy Lynis (https://cisofy.com/lynis/) | |
| − | + | (Может быть, ISPProtect, может быть, и тем , и тем, может еще что-то есть?) | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | Проверка осуществляется коммерческим программным средством с открытым исходным кодом Cisofy Lynis (https://cisofy.com/lynis/) | + | |
| − | Может быть, ISPProtect, может быть, и тем , и тем, может еще что-то есть? | + | |
| − | + | ||
| − | + | ||
| + | = Определение критичности уязвимости = | ||
| + | == Общие положения == | ||
Для определения применимости той или иной уязвимости для того или иного изделия следует учитывать следующее: | Для определения применимости той или иной уязвимости для того или иного изделия следует учитывать следующее: | ||
| − | |||
* Информацию из общедоступных баз данных уязвимости по номерам версий и иным идентификаторам уязвимостей (формальной источник) | * Информацию из общедоступных баз данных уязвимости по номерам версий и иным идентификаторам уязвимостей (формальной источник) | ||
* Наличие эксплойта и его применимость | * Наличие эксплойта и его применимость | ||
| Строка 83: | Строка 50: | ||
* Информацию о критичности, в привязке к приоритетности компонентов ПО. Предложенный порядок критичности ниже, то есть наши критерии оценки важности (требует обсуждения и уточнения): | * Информацию о критичности, в привязке к приоритетности компонентов ПО. Предложенный порядок критичности ниже, то есть наши критерии оценки важности (требует обсуждения и уточнения): | ||
| − | + | == Приоритет критичности уязвимостей == | |
| − | glibc | + | При определении критичности найденной уязвимостей необходимо использовать следующие приоритеты (от высшего к низшему): |
| − | kernel | + | === Базовые пакеты системы, обеспечивающие загрузку и авторизацию в консольном режиме === |
| − | systemd | + | * glibc |
| + | * kernel | ||
| + | * systemd | ||
| + | * PAM | ||
| + | * kerberos | ||
| + | * initscripts | ||
| + | * cracklib | ||
| + | * grub | ||
| + | * parted | ||
| + | * kmod | ||
| + | * audit-libs | ||
| + | * Загружаемые модули ядра | ||
| − | + | === Уязвимости, характерные для конкретной аппаратной конфигурации и драйверов для нее === | |
| − | + | * Проприетарные драйвера для видеокарт | |
| − | + | * Драйвера wifi, сканеров, принтеров. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | === Сетевой доступ к ресурсам и связанные пакеты === | |
| − | ресурсам | + | * network/NetworkManager, iptables, acl, bind, dhcp |
| − | + | * rpm, yum, urpmi | |
| − | rpm, yum, urpmi | + | * openssl |
| − | openssh/sftp | + | * openssh/sftp |
| − | samba | + | * samba |
| − | openvpn | + | * openvpn |
| − | nfs | + | * nfs |
| − | X11 | + | * X11 |
| − | + | * bash, coreutils | |
| − | bash, coreutils | + | * curl, wget, aria |
| − | curl, wget | + | * dbus |
| − | dbus | + | * udev |
| − | udev | + | * CUPS |
| − | CUPS | + | |
| − | + | === Авторизация и работа в графическом окружении, скрипты === | |
| − | + | * Х-ы | |
| + | * Менеджеры входа | ||
| + | * perl, python | ||
| − | + | === Предустановленные в образе программы === | |
| − | + | * Браузеры | |
| + | * Файловые менеджеры | ||
| + | * Эмуляторы терминала | ||
| + | * Офисные программы | ||
| + | * Мультимедиа - проигрыватели | ||
| − | === | + | === Программы из репозиториев === |
| + | Программы, которые пользователь ставит из репозиториев - уязвимость распространяется только на тех, кто установил программу | ||
| + | === Прочее === | ||
| + | Низший приоритет для программ, не использующих сетевое взаимодействие и не запускающих собственные сервисы. | ||
| + | |||
| + | = Размещение информации о подтвержденных уязвимостях = | ||
| + | == Адреса публикации == | ||
Информация о выявленном недостатке с его описанием публикуется в виде информационного бюллетеня безопасности на общедоступных ресурсах предприятия разработчика по адресам: | Информация о выявленном недостатке с его описанием публикуется в виде информационного бюллетеня безопасности на общедоступных ресурсах предприятия разработчика по адресам: | ||
| − | |||
http://wiki.rosalab.com/ru/index.php/Security_Bulletin | 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 | 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, разделенной дефисами и точкой. | 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.»; | входа в ОС менеджер входа lightdm.»; | ||
| − | + | * приводятся данные (в виде гиперссылок) о наличии информации об уязвимости (недостатке) в общедоступных базах данных уязвимостей (если применимо), вида: «BDU:2016-01584» или «CVE-2013-0221» и т.п.; | |
| − | + | * может приводиться дополнительная информация, позволяющая классифицировать уязвимость (недостаток) по типу, классу или иная информация, отражающая, например, способ эксплуатации уязвимости (недостатка). А также другая информация, полезная потребителю (пользователю), вида: «Эксплойт не | |
| − | + | ||
| − | + | ||
требуется. При аутентификации пользователя в менеджере входа GDM, либо при срабатывании механизма аутентификации для переключения контекста учетной записи в графическом окружении GNOME3 существует возможность компрометации аутентификационной информации (пароля). Для эксплуатации | требуется. При аутентификации пользователя в менеджере входа GDM, либо при срабатывании механизма аутентификации для переключения контекста учетной записи в графическом окружении GNOME3 существует возможность компрометации аутентификационной информации (пароля). Для эксплуатации | ||
уязвимости в ОС РОСА КОБАЛЬТ с версией пакета ниже чем gnome-shell-3.14.4-53.res7.4.x86_64 с помощью ПКМ возможно вывести на экран вводимую в поле пароля информацию. Уязвимость нарушает требование ИТ.ОС.А4.ПЗ FIA_UAU.7 "Аутентификация с защищенной обратной связью"». | уязвимости в ОС РОСА КОБАЛЬТ с версией пакета ниже чем gnome-shell-3.14.4-53.res7.4.x86_64 с помощью ПКМ возможно вывести на экран вводимую в поле пароля информацию. Уязвимость нарушает требование ИТ.ОС.А4.ПЗ FIA_UAU.7 "Аутентификация с защищенной обратной связью"». | ||
| − | ==== | + | = Исправление уязвимостей = |
| − | + | == Порядок действий репортера == | |
| − | + | Ответственность репортера - нахождение и документирование уязвимостей, а также проверка их исправления сборщиком. | |
| − | + | В процессе исправления уязвимостей репортер: | |
| − | + | # Создает баг в багзилле для каждого продукта, в котором найдена уязвимость | |
| − | + | # В баге указывается код уязвимости (в поле ROSA Vulnerability identifier), продукт, компонент и приоритет исправления | |
| − | В | + | # Список всех багов с установленным RVI можно получить запросом https://bugzilla.rosalinux.ru/buglist.cgi?classification=ROSA%20CENTOS-based%20products&f1=cf_security_code&list_id=44039&o1=notequals&query_format=advanced |
| − | + | # Через почтовую рассылку отслеживает изменение состояния бага, при необходимости давая дополнительную информацию и меняя приоритеты | |
| − | + | # После сборки (получив флажок ''secteam_verified'' в "?" ) проверяет исправление уязвимости и, при успешной проверке, меняет информацию на бюллетене в вики и ставит в багзилле статус "VERIFIED" и флажок ''secteam_verified'' в "+" а при неуспешной сборке ''secteam_verified'' в "-", таким образом направляя запрос на повторную сборку | |
| − | + | ||
| − | + | ||
| − | - | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | == | + | == Порядок действий сборщика == |
| − | # | + | Ответственность сборщика - сборка пакетов с исправлением уязвимостей по запросам репортера |
| − | + | # Сборщик получает информацию о уязвимости через рассылку bugs@rosalinux.ru - незакрытые баги с установленным кодом RVI | |
| − | # | + | # Собирает и указывает в баге контейнеры с исправленными пакетами |
| − | + | # Устанавливает флажки в знак вопроса (''secteam_verified'' и, при наличии для его платформы QA, ''qa_verified'') таким образом давая команду на проверку собранного. | |
| − | == | + | == Порядок действий публикатора == |
| − | + | Ответственность публикатора - доведение пакетов с исправлениями до конечного пользователя | |
| − | # | + | # Публикатор отслеживает собранные и проверенные пакеты с исправлениями уязвимостей, направленные на публикацию по наличию флажка ''publishied'' |
| − | # После | + | # Он обеспечивает публикацию пакетов в репозиториях или другие методы доведения исправленных пакетов до пользователей системы |
| − | + | # После успешной публикации он устанавливает флажок ''publishied'' в '+', при невозможности по каким-то причинам публикации, флажок устанавливается в '-' | |
| − | == | + | == Порядок работы собрания Security Team == |
| − | # | + | # Команда SecurityTeam собирается раз в неделю, по вторникам |
| − | # | + | # На собрание выносится общий список не исправленных за предыдущее время багов. Он формируется автоматически по запросу из багзиллы |
| − | # | + | # По каждому запросу выносится решение, назначаются приоритеты и ответственные |
| − | = | + | = Публикация информации об обновлениях = |
| − | + | Каждую пятницу публикуется бюллетень с планируемыми обновлениями. В нем указываются ссылки на исправленные баги, в том числе связанные с исправлениями уязвимостей. | |
| − | + | ||
| − | + | ||
[[Категория:Регламенты ROSA]] | [[Категория:Регламенты ROSA]] | ||
Текущая версия на 11:07, 5 июня 2018
Содержание
- 1 Назначение
- 2 Поиск уязвимостей
- 3 Определение критичности уязвимости
- 3.1 Общие положения
- 3.2 Приоритет критичности уязвимостей
- 3.2.1 Базовые пакеты системы, обеспечивающие загрузку и авторизацию в консольном режиме
- 3.2.2 Уязвимости, характерные для конкретной аппаратной конфигурации и драйверов для нее
- 3.2.3 Сетевой доступ к ресурсам и связанные пакеты
- 3.2.4 Авторизация и работа в графическом окружении, скрипты
- 3.2.5 Предустановленные в образе программы
- 3.2.6 Программы из репозиториев
- 3.2.7 Прочее
- 4 Размещение информации о подтвержденных уязвимостях
- 5 Исправление уязвимостей
- 6 Публикация информации об обновлениях
Назначение
Данный регламент описывает действия репортеров SecTeam, связанные с устранением уязвимостей в продуктах, выпускаемых ООО "НТЦ ИТ РОСА" и сообществом разработчиков ОС РОСА Fresh.
Общая схема работы по уязвимостям:
Поиск -> Определение локализации и критичности -> Документирование -> Исправление -> Проверка -> Публикация
Поиск уязвимостей
Поиск уязвимостей производится в общедоступных базах данных уязвимостей, с помощью сканера уязвимостей и антивируса, в иных источниках а также сканером устаревшего и вредоносного ПО.
Поиск в общедоступных базах данных уязвимостей
- В базе данных уязвимостей в составе банка данных угроз безопасности информации (www.bdu.fstec.ru);
- В иных источниках и средствах массовой информации (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.
Обновление БД уязвимостей производится регулярно (не реже раза в неделю).
Проверка с помощью антивируса
- Проверка осуществляется программой clamav, перед проверкой производится полное обновление доступных баз данных командой freshclam
- Изделие проверяется в варианте установки «по умолчанию»; также проверяются все файлы, расположенные на установочном носителе (носителях) изделия.
- Обновление баз средства АВЗ производится не реже 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 "Аутентификация с защищенной обратной связью"».
Исправление уязвимостей
Порядок действий репортера
Ответственность репортера - нахождение и документирование уязвимостей, а также проверка их исправления сборщиком. В процессе исправления уязвимостей репортер:
- Создает баг в багзилле для каждого продукта, в котором найдена уязвимость
- В баге указывается код уязвимости (в поле ROSA Vulnerability identifier), продукт, компонент и приоритет исправления
- Список всех багов с установленным RVI можно получить запросом https://bugzilla.rosalinux.ru/buglist.cgi?classification=ROSA%20CENTOS-based%20products&f1=cf_security_code&list_id=44039&o1=notequals&query_format=advanced
- Через почтовую рассылку отслеживает изменение состояния бага, при необходимости давая дополнительную информацию и меняя приоритеты
- После сборки (получив флажок secteam_verified в "?" ) проверяет исправление уязвимости и, при успешной проверке, меняет информацию на бюллетене в вики и ставит в багзилле статус "VERIFIED" и флажок secteam_verified в "+" а при неуспешной сборке secteam_verified в "-", таким образом направляя запрос на повторную сборку
Порядок действий сборщика
Ответственность сборщика - сборка пакетов с исправлением уязвимостей по запросам репортера
- Сборщик получает информацию о уязвимости через рассылку bugs@rosalinux.ru - незакрытые баги с установленным кодом RVI
- Собирает и указывает в баге контейнеры с исправленными пакетами
- Устанавливает флажки в знак вопроса (secteam_verified и, при наличии для его платформы QA, qa_verified) таким образом давая команду на проверку собранного.
Порядок действий публикатора
Ответственность публикатора - доведение пакетов с исправлениями до конечного пользователя
- Публикатор отслеживает собранные и проверенные пакеты с исправлениями уязвимостей, направленные на публикацию по наличию флажка publishied
- Он обеспечивает публикацию пакетов в репозиториях или другие методы доведения исправленных пакетов до пользователей системы
- После успешной публикации он устанавливает флажок publishied в '+', при невозможности по каким-то причинам публикации, флажок устанавливается в '-'
Порядок работы собрания Security Team
- Команда SecurityTeam собирается раз в неделю, по вторникам
- На собрание выносится общий список не исправленных за предыдущее время багов. Он формируется автоматически по запросу из багзиллы
- По каждому запросу выносится решение, назначаются приоритеты и ответственные
Публикация информации об обновлениях
Каждую пятницу публикуется бюллетень с планируемыми обновлениями. В нем указываются ссылки на исправленные баги, в том числе связанные с исправлениями уязвимостей.
