Регламент по устранению уязвимостей
Содержание
- 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%20CENOS-based%20products&f1=cf_security_code&list_id=43890&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 собирается раз в неделю, по вторникам
- На собрание выносится общий список не исправленных за предыдущее время багов. Он формируется автоматически по запросу из багзиллы
- По каждому запросу выносится решение, назначаются приоритеты и ответственные
Публикация информации об обновлениях
Каждую пятницу публикуется бюллетень с планируемыми обновлениями. В нем указываются ссылки на исправленные баги, в том числе связанные с исправлениями уязвимостей.