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

Материал из Rosalab Wiki
Перейти к: навигация, поиск
(Порядок действий репортера)
 
(не показано 25 промежуточных версий этого же участника)
Строка 1: Строка 1:
  
=== Назначение ===
+
= Назначение =
Данный регламент предназначен для определения порядка действий при проведении следующих процедур жизненного цикла:
+
Данный регламент описывает действия репортеров SecTeam, связанные с устранением уязвимостей в продуктах, выпускаемых ООО "НТЦ ИТ РОСА" и сообществом разработчиков ОС РОСА Fresh.
  
# отслеживания уязвимости (уязвимостей)
+
Общая схема работы по уязвимостям:
# определения применимости уязвимости для конкретных продуктов, выпускаемых ООО "НТЦ ИТ РОСА" и сообществом разработчиков ОС РОСА Fresh
+
  Поиск -> Определение локализации и критичности -> Документирование -> Исправление -> Проверка -> Публикация
# оценки критичности уязвимости (уязвимостей) для конкретных продуктов, выпускаемых ООО "НТЦ ИТ РОСА" и сообществом разработчиков ОС РОСА Fresh
+
# размещению информации о найденных и подтвержденных уязвимостях на публичных ресурсах компании ООО "НТЦ ИТ РОСА"
+
# проведение действий по устранению для найденных и подтвержденных уязвимостей
+
# доведение до пользователей информации об обновлениях (устранениях, нейтрализации)
+
  
А также для:
+
= Поиск уязвимостей =
 +
Поиск уязвимостей производится в общедоступных базах данных уязвимостей, с помощью сканера уязвимостей и антивируса, в иных источниках а также сканером устаревшего и вредоносного ПО.
  
# определении ответственных лиц, отвечающих за проведение каждой конкретной процедуры жизненного цикла
+
== Поиск в общедоступных базах данных уязвимостей ==
# определении порядка информирования и отчетности внутри компании и сообщества разработчиков о необходимости процедур устранения и собственно устранению (нейтрализации) уязвимостей
+
# В базе данных уязвимостей в составе банка данных угроз безопасности информации (www.bdu.fstec.ru);  
 
+
# В иных источниках и средствах массовой информации (cve.mitre.org, nvd.nist.gov, www.cvedetails.com, www.securitylab.ru).
=== Применимость ===
+
Настоящий регламент описывает порядок добавления и исправления пакетов в дистрибутивах ROSA Linux Fresh при взаимодействии пяти команд:
+
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов (Олег Михайлов? для RELS/Кобальт и RV, Светлана Савельева? для Fresh/RED)
+
# Команды сборщиков, собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей (Андрей Лукошко? для RELS/Кобальт и RV, Андрей Бондров? для Fresh/RED)
+
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления (Владимир Потапов?)
+
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками (Олег Михайлов?/Кирилл Ожерельев? для RELS/Кобальт, Адрей Гайдуков? для RV, Владимир Потапов? для Fresh/RED)
+
# Публикатор, задача которого  - доступность исправленных пакетов на зеркалах дистрибутива (Михайлов/Ожерельев/Савельева - в бюллетени безопасности, в реп - надо подумать)
+
 
+
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества (contrib) где контроль качества не производится.
+
 
+
=== Общий порядок обновления ===
+
# Общий порядок адресации каждого запроса на обновление - Репортеры -> Cборщики -> QA & Secteam -> Публикатор
+
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их.
+
# Репортер-сборщик, отслеживающий обновления необходимого ему пакета и самостоятельно собирающий его, называется сопровождающим (мейнтейнером) и прописывается на abf.
+
 
+
=== Репортеры ===
+
# Репортеры заводят в на wiki(в багзиле? в редмайне?), обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.
+
 
+
===== Методика проверки уязвимостей (процедура отслеживания уязвимостей) для репортеров: =====
+
 
+
Анализ уязвимостей производится по следующей методике:
+
* проверка наличия уязвимостей на основании информации из общедоступных баз данных уязвимостей;
+
* проверка наличия уязвимостей в автоматизированном режиме при помощи сканера уязвимостей;
+
* проверка средством антивирусной защиты (АВЗ);
+
* проверка программным средством поиска руткитов, вредоносного и устаревшего ПО (rootkit, malware and outdated web software scanner);
+
 
+
'''Проверка наличия уязвимостей на основании информации из общедоступных баз данных уязвимостей'''
+
 
+
Проверка наличия уязвимостей на основании информации из общедоступных баз данных уязвимостей предполагает поиск информации об уязвимостях конкретной ОС семейства РОСА «КОБАЛЬТ» и аналогичных ОС в следующих источниках:
+
в базе данных уязвимостей в составе банка данных угроз безопасности информации (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 раза в неделю.
  
Проверка осуществляется средством АВЗ — программой clamav.
+
== Поиск вредоносного и устаревшего ПО ==
При этом перед проверкой производится полное обновление доступных баз средства АВЗ.
+
Проверка осуществляется коммерческим программным средством с открытым исходным кодом Cisofy Lynis (https://cisofy.com/lynis/)
Изделие проверяется в варианте установки «по умолчанию»; также проверяются все файлы, расположенные на установочном носителе (носителях) изделия.
+
(Может быть, ISPProtect, может быть, и тем , и тем, может еще что-то есть?)
Обновление баз средства АВЗ производится не реже 1 раза в неделю.
+
 
+
'''Проверка программным средством поиска, вредоносного и устаревшего ПО'''
+
 
+
Проверка осуществляется коммерческим программным средством с открытым исходным кодом Cisofy Lynis (https://cisofy.com/lynis/)???
+
Может быть, ISPProtect, может быть, и тем , и тем, может еще что-то есть?
+
 
+
==== Процедура определения применимости уязвимости для конкретных продуктов, выпускаемых ООО "НТЦ ИТ РОСА" и сообществом разработчиков ОС РОСА Fresh ====
+
  
 +
= Определение критичности уязвимости =
 +
== Общие положения ==
 
Для определения применимости той или иной уязвимости для того или иного изделия следует учитывать следующее:
 
Для определения применимости той или иной уязвимости для того или иного изделия следует учитывать следующее:
 
 
* Информацию из общедоступных баз данных уязвимости по номерам версий и иным идентификаторам уязвимостей (формальной источник)
 
* Информацию из общедоступных баз данных уязвимости по номерам версий и иным идентификаторам уязвимостей (формальной источник)
 
* Наличие эксплойта и его применимость
 
* Наличие эксплойта и его применимость
Строка 89: Строка 50:
 
* Информацию о критичности, в привязке к приоритетности компонентов ПО. Предложенный порядок критичности ниже, то есть наши критерии оценки важности (требует обсуждения и уточнения):
 
* Информацию о критичности, в привязке к приоритетности компонентов ПО. Предложенный порядок критичности ниже, то есть наши критерии оценки важности (требует обсуждения и уточнения):
  
I. Базовые пакеты системы
+
== Приоритет критичности уязвимостей ==
glibc
+
При определении критичности найденной уязвимостей необходимо использовать следующие приоритеты (от высшего к низшему):
kernel
+
=== Базовые пакеты системы, обеспечивающие загрузку и авторизацию в консольном режиме ===
systemd
+
* glibc
 +
* kernel
 +
* systemd
 +
* PAM
 +
* kerberos
 +
* initscripts
 +
* cracklib
 +
* grub
 +
* parted
 +
* kmod
 +
* audit-libs
 +
* Загружаемые модули ядра
  
II. Аутентификация, Авторизация, Аудит; Управление сетевым
+
=== Уязвимости, характерные для конкретной аппаратной конфигурации и драйверов для нее ===
разграничением; Криптография; Загружаемые модели ядра;Некоторые другие
+
* Проприетарные драйвера для видеокарт
компоненты повышенной важности
+
* Драйвера wifi, сканеров, принтеров.
PAM
+
kerberos
+
initscripts
+
openssl
+
audit-libs
+
network/NetworkManager, iptables, acl, bind, dhcp
+
Загружаемые модули ядра
+
cracklib
+
grub
+
parted
+
kmod
+
  
III. Пакеты, содержащие демоны, предоставляющие сетевой доступ к
+
=== Сетевой доступ к ресурсам и связанные пакеты ===
ресурсам системы и связанные с ними пакеты библиотек; Пакеты с
+
* network/NetworkManager, iptables, acl, bind, dhcp
необходимым (условно) для работы в системе функционалом; Модули PAM.
+
* rpm, yum, urpmi
rpm, yum, urpmi
+
* openssl
openssh/sftp
+
* openssh/sftp
samba
+
* samba
openvpn
+
* openvpn
nfs
+
* nfs
X11
+
* X11
Модули PAM
+
* bash, coreutils
bash, coreutils
+
* curl, wget, aria
curl, wget
+
* dbus
dbus
+
* udev
udev
+
* CUPS
CUPS
+
  
IV.
+
=== Авторизация и работа в графическом окружении, скрипты ===
Браузеры, файловые менеджеры, эмуляторы терминала, офисные средства
+
* Х-ы
 +
* Менеджеры входа
 +
* perl, python
  
V.
+
=== Предустановленные в образе программы ===
Опциональные пакеты программ, не использующих сетевое взаимодействие и не запускающих собственные демоны.
+
* Браузеры
 +
* Файловые менеджеры
 +
* Эмуляторы терминала
 +
* Офисные программы
 +
* Мультимедиа - проигрыватели
  
==== Процедура размещения информации о найденных и подтвержденных уязвимостях на публичных ресурсах компании ООО "НТЦ ИТ РОСА" ====
+
=== Программы из репозиториев ===
 +
Программы, которые пользователь ставит из репозиториев - уязвимость распространяется только на тех, кто установил программу
  
 +
=== Прочее ===
 +
Низший приоритет для программ, не использующих сетевое взаимодействие и не запускающих собственные сервисы.
 +
 +
= Размещение информации о подтвержденных уязвимостях  =
 +
== Адреса публикации ==
 
Информация о выявленном недостатке с его описанием публикуется в виде информационного бюллетеня безопасности на общедоступных ресурсах предприятия разработчика по адресам:  
 
Информация о выявленном недостатке с его описанием публикуется в виде информационного бюллетеня безопасности на общедоступных ресурсах предприятия разработчика по адресам:  
 
 
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 идентифицируют разработчика;
- первые 4 буквы ROSA идентифицируют разработчика;
+
* вторые 2 буквы SA идентифицируют тип публикации - бюллетень безопасности (Security Advisory);  
 
+
* первая последовательность цифр содержат год публикации (после 2000 года);  
- вторые 2 буквы SA идентифицируют тип публикации - бюллетень безопасности (Security Advisory);  
+
* вторая последовательность цифр указывает на месяц года;  
 
+
* третья последовательность цифр указывает на день (число);
- первая последовательность цифр содержат год публикации (после 2000 года);  
+
* после точки нумеруется по порядку конкретный бюллетень за конкретное число (в случае необходимости, если выявлено несколько недостатков за конкретную дату).
 
+
- вторая последовательность цифр указывает на месяц года;  
+
 
+
- третья последовательность цифр указывает на день (число);
+
 
+
- после точки нумеруется по порядку конкретный бюллетень за конкретное число (в случае необходимости, если выявлено несколько недостатков за конкретную дату).
+
  
 
При описании недостатка учитывается и публикуется следующее:
 
При описании недостатка учитывается и публикуется следующее:
 
+
* уникальный идентификатор (номер) бюллетеня безопасности вида «ROSA-SA-17-12-23.001»;
- уникальный идентификатор (номер) бюллетеня безопасности вида «ROSA-SA-17-12-23.001»;
+
* категория статьи на ресурсе, указывающая, что это бюллетень безопасности (неизменна);
 
+
* приводится описание уязвимости (недостатка) вида: «Возможность компрометации аутентификационной информации пользователя при прохождении аутентификации в графическом интерфейсе (GDM/GNOME3)»;
- категория статьи на ресурсе, указывающая, что это бюллетень безопасности (неизменна);
+
* приводится перечень продукции (программного обеспечения) разработчика, к которой относится недостаток (уязвимость), вида: «ОС РОСА КОБАЛЬТ»;
 
+
* приводится степень критичности недостатка (уязвимости) с точки зрения разработчика. Всего 5 степеней - от наиболее значимой к наименее: «Критическая», «Высокая», «Средняя», «Низкая», «Незначительная»;
- приводится описание уязвимости (недостатка) вида: «Возможность компрометации аутентификационной информации пользователя при прохождении аутентификации в графическом интерфейсе (GDM/GNOME3)»;
+
* приводится текущий статус уязвимости (недостатка), позволяющий оперативно отслеживать информацию о степени устранения недостатка (уязвимости). Всего 5 степеней: «Устранена», «Нейтрализована», «Информация проверяется», «Ведутся работы по устранению (нейтрализации)», «Не устранена»;
 
+
* приводится список ПО (пакетов, образов, файлов), необходимое к установке, в случае устранения уязвимости (недостатка) вида: «gnome-shell-3.14.4-53.res7c.4.x86_64.rpm»;
- приводится перечень продукции (программного обеспечения) разработчика, к которой относится недостаток (уязвимость), вида: «ОС РОСА КОБАЛЬТ»;
+
* приводится перечень мероприятий и рекомендаций по нейтрализации уязвимости (если применимо), в случае, если устранение по каким-либо причинам невозможно, либо у потребителя (пользователя) нет оперативной необходимости устранять уязвимость. Например: «Использовать в качестве менеджера  
 
+
- приводится степень критичности недостатка (уязвимости) с точки зрения разработчика. Всего 5 степеней - от наиболее значимой к наименее: «Критическая», «Высокая», «Средняя», «Низкая», «Незначительная»;
+
 
+
- приводится текущий статус уязвимости (недостатка), позволяющий оперативно отслеживать информацию о степени устранения недостатка (уязвимости). Всего 5 степеней: «Устранена», «Нейтрализована», «Информация проверяется», «Ведутся работы по устранению (нейтрализации)», «Не устранена»;
+
 
+
- приводится список ПО (пакетов, образов, файлов), необходимое к установке, в случае устранения уязвимости (недостатка) вида: «gnome-shell-3.14.4-53.res7c.4.x86_64.rpm»;
+
 
+
- приводится перечень мероприятий и рекомендаций по нейтрализации уязвимости (если применимо), в случае, если устранение по каким-либо причинам невозможно, либо у потребителя (пользователя) нет оперативной необходимости устранять уязвимость. Например: «Использовать в качестве менеджера  
+
 
входа в ОС менеджер входа lightdm.»;
 
входа в ОС менеджер входа lightdm.»;
 
+
* приводятся данные (в виде гиперссылок) о наличии информации об уязвимости (недостатке) в общедоступных базах данных уязвимостей (если применимо), вида: «BDU:2016-01584» или «CVE-2013-0221» и т.п.;
- приводятся данные (в виде гиперссылок) о наличии информации об уязвимости (недостатке) в общедоступных базах данных уязвимостей (если применимо), вида: «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
Репортеры готовят черновик бюллетеня безопасности и публикуют его в соответствующий проект на корпоративный redmine.
+
# Через почтовую рассылку отслеживает изменение состояния бага, при необходимости давая дополнительную информацию и меняя приоритеты
Обновременно с этим, репортеры публикуют краткое описание уязвимости в багзиллу (баг-трекер), и там же, в описании на баг-трекере приводят ссылку на redmine.
+
# После сборки (получив флажок ''secteam_verified'' в "?" ) проверяет исправление уязвимости и, при успешной проверке, меняет информацию на бюллетене в вики и ставит в багзилле статус "VERIFIED" и флажок ''secteam_verified'' в "+" а при неуспешной сборке ''secteam_verified'' в "-", таким образом направляя запрос на повторную сборку
 
+
Комитет ROSA Security Team один раз в неделю (допускается один раз в две недели) осуществляет общий сбор, на который выносится полный перечень найденных уязвимостей за отчетный период по всем продуктам. Председатель комитета или его заместитель осуществляет подготовку такого перечня, и выносит его на комитет. Комитет подвергает каждую найденную из перечня уязвимостей экспертной оценке, подтверждает её наличие, а так же подтверждает (либо уточняет) ее критичность, а так же предлагает черновое концептуальное решение по её устранению либо нейтрализации. Кроме того, соответствующие члены комитета (как правило, мантейнеры) примерно оценивают время, которое требуется на устранение уязвимости либо ее нейтрализации. Результатом этой работы является оформление протокола заседания комитета ROSA Security Team. В протоколе по каждой вынесенной на комитет уязвимости указывается:
+
- описание уязвимости и тип ошибки;
+
- подтверждение наличия с перечнем продуктов, которые она затрагивает;
+
- требуются ли дальнейщие действия по уточнению наличия уязвимости и ответственый за них (в случае необходимости);
+
- утонения по критичности уязвимости (в случае необходимости);
+
- перечень рекомендуемых действий по устранию или нейтрализации;
+
- примерный срок устранения (нейтрализации);
+
- ответственный за устранение (нейтрализацию);
+
- определяет необходимость заведения соответствующей задачи (подзадачи) в redmine и/или баг-трекере;
+
- необходимость оформления соответствующего бюллетеня безопасности и его публикации;
+
- оформляется общий отчет по уязвимостям (столько-то обнаружено, столько-то устранено (нейтрализовано), столько то возвращено на повторную доработку и т.п.).
+
Протокол заседания публикуется в redmine.
+
 
+
После предполагаемого устранения (нейтрализации) уязвимости, ответственный за проверку уязвимостей по соответствующей платформе осуществляет независимую проверку устранения (нейтрализации) уязвимости и подтверждает устранение (нейтрализацию). О чем делается соответствующая запись на redmine и задача (подзадача) закрывается.
+
В случае, если ответственный за проверку устранения не может вынести заключения об устранении, то уязвимость повторно выносится на следующее заседание комитета. О чем делается соответствующая запись на redmine и задача (подзадача) не закрывается.
+
 
+
После устранения или нейтрализации уязвимости и закрытия задачи на redmine репортер создает (изменяет) соответствующий бюллетень безопасности.
+
 
+
Требуется принять решение о уязвимостях типа Zero-day.
+
 
+
==== доведение до пользователей информации об обновлениях (устранениях, нейтрализации) =====
+
В целом аналогична процедуре по размещению информации.
+
 
+
 
+
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.
+
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.
+
  
=== Сборщики ===
+
== Порядок действий сборщика ==
# Сборщики получают информацию о багах от репортеров через рассылку багзиллы
+
Ответственность сборщика - сборка пакетов с исправлением уязвимостей по запросам репортера
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага с заголовком [UPDATE REQUEST <платформа>] называемого запросом на обновление
+
# Сборщик получает информацию о уязвимости через рассылку bugs@rosalinux.ru - незакрытые баги с установленным кодом RVI
# В комментариях к запросу на обновления указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)
+
# Собирает и указывает в баге контейнеры с исправленными пакетами
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"
+
# Устанавливает флажки в знак вопроса (''secteam_verified'' и, при наличии для его платформы QA, ''qa_verified'') таким образом давая команду на проверку собранного.
  
=== Команда контроля качества (QA) ===
+
== Порядок действий публикатора ==
# Команда QA получается запросы с установленным сборщиками флажком qa_verified
+
Ответственность публикатора - доведение пакетов с исправлениями до конечного пользователя
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam
+
# Публикатор отслеживает собранные и проверенные пакеты с исправлениями уязвимостей, направленные на публикацию по наличию флажка ''publishied''
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.
+
# Он обеспечивает публикацию пакетов в репозиториях или другие методы доведения исправленных пакетов до пользователей системы
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"
+
# После успешной публикации он устанавливает флажок ''publishied'' в '+', при невозможности по каким-то причинам публикации, флажок устанавливается в '-'
  
=== Команда контроля уязвимостей (SecTeam) ===
+
== Порядок работы собрания Security Team ==
# Список уязвимостей ведется на странице вики [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 Список уязвимостей] командой SecTeam.
+
# Команда SecurityTeam собирается раз в неделю, по вторникам
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг или пул-реквест
+
# На собрание выносится общий список не исправленных за предыдущее время багов. Он формируется автоматически по запросу из багзиллы
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam
+
# По каждому запросу выносится решение, назначаются приоритеты и ответственные
  
=== Публикатор ===
+
= Публикация информации об обновлениях =
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam
+
Каждую пятницу публикуется бюллетень с планируемыми обновлениями. В нем указываются ссылки на исправленные баги, в том числе связанные с исправлениями уязвимостей.
# Публикатор обеспечивает появление пакетов обновлений в репозиториях и непротиворечивость репозиториев после публикации.
+
# После успешной публикации  флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.
+
  
 
[[Категория:Регламенты ROSA]]
 
[[Категория:Регламенты ROSA]]

Текущая версия на 11:07, 5 июня 2018

Содержание

Назначение

Данный регламент описывает действия репортеров 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%20CENTOS-based%20products&f1=cf_security_code&list_id=44039&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. По каждому запросу выносится решение, назначаются приоритеты и ответственные

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

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