Версия 09:08, 29 мая 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. Через почтовую рассылку отслеживает изменение состояния бага, при необходимости давая дополнительную информацию и меняя приоритеты
4. После сборки (получив флажок 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. По каждому запросу выносится решение, назначаются приоритеты и ответственные

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

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