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

Ссылки сюда (2) →

Назначение

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

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 "Аутентификация с защищенной обратной связью"».

Процедура проведение действий по устранению для найденных и подтвержденных уязвимостей

Требуется обсудить и выработать решение

Черновик.

Репортер осуществляют проверку уязвимостей по соотвествующей методике. В случае нахождения уязвимости производят её предварительную оценку, согласно соответствующи описанным критериям. Репортеры готовят черновик бюллетеня безопасности и публикуют его в соответствующий проект на корпоративный redmine. Обновременно с этим, репортеры публикуют краткое описание уязвимости в багзиллу (баг-трекер), и там же, в описании на баг-трекере приводят ссылку на redmine.

Комитет ROSA Security Team один раз в неделю (допускается один раз в две недели) осуществляет общий сбор, на который выносится полный перечень найденных уязвимостей за отчетный период по всем продуктам. Председатель комитета или его заместитель осуществляет подготовку такого перечня, и выносит его на комитет. Комитет подвергает каждую найденную из перечня уязвимостей экспертной оценке и подтверждает (либо уточняет) ее критичность, а так же предлагает черновое концептуальное решение по её устранению либо нейтрализации. Кроме того, соответствующие члены комитета (как правило, мантейнеры) примерно оценивают время, которое требуется на устранение уязвимости либо ее нейтрализации. Результатом этой работы является оформление протокола заседания комитета ROSA Security Team. В протоколе по каждой вынесенной на комитет уязвимости указывается: - описание уязвимости и тип ошибки; - требуются ли дальнейщие действия по уточнению наличия уязвимости и ответственый за них (в случае необходимости); - утонения по критичности уязвимости (в случае необходимости); - перечень рекомендуемых действий по устранию или нейтрализации; - примерный срок устранения (нейтрализации); - ответственный за устранение (нейтрализацию); - определяет необходимость заведения соответствующей задачи (подзадачи) в redmine и/или баг-трекере; - необходимость оформления соответствующего бюллетеня безопасности и его публикации; - оформляется общий отчет по уязвимостям (столько-то обнаружено, столько-то устранено (нейтрализовано), столько то возвращено на повторную доработку и т.п.). Протокол заседания публикуется в redmine.

После предполагаемого устранения (нейтрализации) уязвимости, ответственный за проверку уязвимостей по соответствующей платформе осуществляет независимую проверку устранения (нейтрализации) уязвимости и подтверждает устранение (нейтрализацию). О чем делается соответствующая запись на redmine и задача (подзадача) закрывается. В случае, если ответственный за проверку устранения не может вынести заключения об устранении, то уязвимость повторно выносится на следующее заседание комитета. О чем делается соответствующая запись на redmine и задача (подзадача) не закрывается.

После устранения или нейтрализации уязвимости и закрытия задачи на redmine репортер создает (изменяет) соответствующий бюллетень безопасности.

Требуется принять решение о уязвимостях типа Zero-day.

Процедура проведения действий по нейтрализации для найденных и подтвержденных уязвимостей

Требуется обсудить и выработать решение

доведение до пользователей информации об обновлениях (устранениях, нейтрализации) =

В целом аналогична процедуре по размещению информации.

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" устанавливается в "+" и запрос на обновление считается полностью закрытым.