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

Версия 08:30, 2 мая 2018

Назначение

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

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

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

Анализ уязвимостей производится по следующей методике:

1. Проверка наличия уязвимостей на основании информации из общедоступных баз данных уязвимостей;
2. Проверка наличия уязвимостей в автоматизированном режиме при помощи сканера уязвимостей;
3. Проверка средством антивирусной защиты (АВЗ);
4. Проверка программным средством поиска руткитов, вредоносного и устаревшего ПО (rootkit, malware and outdated web software scanner);

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

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
• openssl
• audit-libs
• network/NetworkManager, iptables, acl, bind, dhcp

Загружаемые модули ядра

• cracklib
• grub
• parted
• kmod

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

• rpm, yum, urpmi
• openssh/sftp
• samba
• openvpn
• nfs
• X11
• Модули PAM
• bash, coreutils
• curl, wget
• dbus
• udev
• CUPS
• браузеры

Часто используемые программы

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

Прочее

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

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

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

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