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

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

Назначение

Данный регламент описывает действия репортеров 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
• 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, aria
• 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 "Аутентификация с защищенной обратной связью"».

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

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

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

1. Создает баг в багзилле для каждого продукта, в котором найдена уязвимость
2. В баге указывается код уязвимости (в поле ROSA Vulnerability identifier), продукт, компонент и приоритет исправления
3. Через рассылку отслеживает изменение состояния бага, при необходимости давая дополнительную информацию и меняя приоритеты
4. После сборки проверяет исправление уязвимости и, при успешной проверке, меняет информацию на бюллетене в вики и ставит в багзилле статус "VERIFIED"

Порядок работы собрания Security Team

(Вариант Володи Потапова)

1. Команда SecurityTeam собирается раз в неделю, по вторникам
2. На собрание выносится общий список не исправленных за предыдущее время багов. Он формируется автоматически по запросу из багзиллы
3. По каждому запросу выносится решение, назначаются приоритеты и ответственные

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

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

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

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

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

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

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