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

Версия 10:11, 10 апреля 2018

Назначение

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

1. отслеживания уязвимости (уязвимостей)
2. определения применимости уязвимости для конкретных продуктов, выпускаемых ООО "НТЦ ИТ РОСА" и сообществом разработчиков ОС РОСА Fresh
3. оценки критичности уязвимости (уязвимостей) для конкретных продуктов, выпускаемых ООО "НТЦ ИТ РОСА" и сообществом разработчиков ОС РОСА Fresh
4. размещению информации о найденных и подтвержденных уязвимостях на публичных ресурсах компании ООО "НТЦ ИТ РОСА"
5. проведение действий по устранению для найденных и подтвержденных уязвимостей
6. проведение действий по нейтрализации для найденных и подтвержденных уязвимостей
7. доведение до пользователей информации об обновлениях (устранениях, нейтрализации)

А также для:

1. определении ответственных лиц, отвечающих за проведение каждой конкретной процедуры жизненного цикла
2. определении порядка информирования и отчетности внутри компании и сообщества разработчиков о необходимости процедур устранения и собственно устранению (нейтрализации) уязвимостей

Применимость

Настоящий регламент описывает порядок добавления и исправления пакетов в дистрибутивах ROSA Linux Fresh при взаимодействии пяти команд:

1. Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов (Олег Михайлов? для RELS/Кобальт и RV, Светлана Савельева? для Fresh/RED)
2. Команды сборщиков, собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей (Андрей Лукошко? для RELS/Кобальт и RV, Андрей Бондров? для Fresh/RED)
3. Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления (Владимир Потапов?)
4. Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками (Олег Михайлов?/Кирилл Ожерельев? для RELS/Кобальт, Адрей Гайдуков? для RV, Владимир Потапов? для Fresh/RED)
5. Публикатор, задача которого - доступность исправленных пакетов на зеркалах дистрибутива (Михайлов/Ожерельев/Савельева - в бюллетени безопасности, в реп - надо подумать)

Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества (contrib) где контроль качества не производится.

Общий порядок обновления

1. Общий порядок адресации каждого запроса на обновление - Репортеры -> Cборщики -> QA & Secteam -> Публикатор
2. Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их.
3. Репортер-сборщик, отслеживающий обновления необходимого ему пакета и самостоятельно собирающий его, называется сопровождающим (мейнтейнером) и прописывается на abf.

Репортеры

1. Репортеры заводят в на 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». Для поиска потенциальных уязвимостей изделия выполнялись запросы вида: «уязвимости ОС Linux»; «уязвимости ядра Linux»; «Linux kernel vulnerability»; и т.п.

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

Проверка осуществляется сканером уязвимостей OpenVAS с подключенными модулями следующих БД уязвимостей: NVT; CVE; CPE; OVAL Definitions; CERT-Bund advisores; DFN-CERT advisores. Обновление БД уязвимостей производится регулярно (не реже раза в неделю).

Проверка средством АВЗ

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

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

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

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

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

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

I. Базовые пакеты системы glibc kernel systemd

II. Аутентификация, Авторизация, Аудит; Управление сетевым разграничением; Криптография; Загружаемые модели ядра;Некоторые другие компоненты повышенной важности PAM kerberos initscripts openssl audit-libs network/NetworkManager, iptables, acl, bind, dhcp Загружаемые модули ядра cracklib grub parted kmod

III. Пакеты, содержащие демоны, предоставляющие сетевой доступ к ресурсам системы и связанные с ними пакеты библиотек; Пакеты с необходимым (условно) для работы в системе функционалом; Модули PAM. rpm, yum, urpmi openssh/sftp samba openvpn nfs X11 Модули PAM bash, coreutils curl, wget dbus udev CUPS

IV. Браузеры, файловые менеджеры, эмуляторы терминала, офисные средства

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

Процедура размещения информации о найденных и подтвержденных уязвимостях на публичных ресурсах компании ООО "НТЦ ИТ РОСА"

Информация о выявленном недостатке с его описанием публикуется в виде информационного бюллетеня безопасности на общедоступных ресурсах предприятия разработчика по адресам:

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. Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.
2. Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.

Сборщики

1. Сборщики получают информацию о багах от репортеров через рассылку багзиллы
2. Пакеты обновляются на основании заведенного в багзилле бага с заголовком [UPDATE REQUEST <платформа>] называемого запросом на обновление
3. В комментариях к запросу на обновления указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)
4. После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"

Команда контроля качества (QA)

1. Команда QA получается запросы с установленным сборщиками флажком qa_verified
2. Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam
3. После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.
4. При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"

Команда контроля уязвимостей (SecTeam)

1. Список уязвимостей ведется на странице вики Список уязвимостей командой SecTeam.
2. Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг или пул-реквест
3. Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam

Публикатор

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