Содержание

Назначение

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

Общая схема работы по уязвимостям:

 Поиск -> Определение локализации и критичности -> Документирование -> Исправление -> Проверка -> Публикация

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

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

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

  1. В базе данных уязвимостей в составе банка данных угроз безопасности информации (www.bdu.fstec.ru);
  2. В иных источниках и средствах массовой информации (cve.mitre.org, nvd.nist.gov, www.cvedetails.com, www.securitylab.ru).

В качестве идентификаторов для поиска известных (подтвержденных) уязвимостей использовались: название, версия, архитектура ОС семейства РОСА; наименование компании-разработчика (ООО «НТЦ ИТ РОСА»). Для поиска известных (подтвержденных) уязвимостей изделия выполняются запросы вида:

Для поиска потенциальных уязвимостей изделия выполнялись запросы вида:

и т.п.

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

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

Обновление БД уязвимостей производится регулярно (не реже раза в неделю).

Проверка с помощью антивируса

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

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

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

Определение критичности уязвимости

Общие положения

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

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

При определении критичности найденной уязвимостей необходимо использовать следующие приоритеты (от высшего к низшему):

Базовые пакеты системы, обеспечивающие загрузку и авторизацию в консольном режиме

Уязвимости, характерные для конкретной аппаратной конфигурации и драйверов для нее

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

Авторизация и работа в графическом окружении, скрипты

Предустановленные в образе программы

Программы из репозиториев

Программы, которые пользователь ставит из репозиториев - уязвимость распространяется только на тех, кто установил программу

Прочее

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

Размещение информации о подтвержденных уязвимостях

Адреса публикации

Информация о выявленном недостатке с его описанием публикуется в виде информационного бюллетеня безопасности на общедоступных ресурсах предприятия разработчика по адресам: 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, разделенной дефисами и точкой. где:

При описании недостатка учитывается и публикуется следующее:

входа в ОС менеджер входа lightdm.»;

требуется. При аутентификации пользователя в менеджере входа GDM, либо при срабатывании механизма аутентификации для переключения контекста учетной записи в графическом окружении GNOME3 существует возможность компрометации аутентификационной информации (пароля). Для эксплуатации уязвимости в ОС РОСА КОБАЛЬТ с версией пакета ниже чем gnome-shell-3.14.4-53.res7.4.x86_64 с помощью ПКМ возможно вывести на экран вводимую в поле пароля информацию. Уязвимость нарушает требование ИТ.ОС.А4.ПЗ FIA_UAU.7 "Аутентификация с защищенной обратной связью"».

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

Порядок действий репортера

Ответственность репортера - нахождение и документирование уязвимостей, а также проверка их исправления сборщиком. В процессе исправления уязвимостей репортер:

  1. Создает баг в багзилле для каждого продукта, в котором найдена уязвимость
  2. В баге указывается код уязвимости (в поле ROSA Vulnerability identifier), продукт, компонент и приоритет исправления
  3. Список всех багов с установленным RVI можно получить запросом https://bugzilla.rosalinux.ru/buglist.cgi?classification=ROSA%20CENTOS-based%20products&f1=cf_security_code&list_id=44039&o1=notequals&query_format=advanced
  4. Через почтовую рассылку отслеживает изменение состояния бага, при необходимости давая дополнительную информацию и меняя приоритеты
  5. После сборки (получив флажок 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. По каждому запросу выносится решение, назначаются приоритеты и ответственные

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

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