Регламент отслеживания и исправления обнаруженных ошибок по и уязвимостей программы

Обновлено: 04.07.2024

Пришлось столкнуться с новым стандартом по разработке безопасного - ГОСТ Р 56939-2016.

Документ получился интересный, поэтому полезно провести его небольшой анализ.

Стандарт был принят прошедшим летом, но вступит в силу только через год – с 1 июля 2017 года. Разработчиком стандарта является ЗАО «НПО «ЭШЕЛОН». Целевой аудиторией стандарта являются разработчики ПО, а также организации, выполняющие оценку соответствия.

В стандарте можно выделить следующие ключевые моменты:

  • Стандарт устанавливает общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного ПО. Детали соответствующих процессов в стандартом не регламентируются.
  • Меры по разработке безопасного ПО применяются в течение всего жизненного цикла ПО. Есть связь с процессами, описанными в ИСО/МЭК 12207-2010.
  • Стандартом вводится базовый набор мер по разработке безопасного ПО. При невозможности реализации в среде разработки ПО отдельных мер из базового набора, разработчик имеет право реализовать компенсирующие меры.
  • В стандарте предусмотрено целых 6 видов испытаний ПО: статический анализ и экспертиза кода, функциональное тестирование программы, тестирование на проникновение, динамический анализ кода и фаззинг-тестирование.
  • Учитывается необходимость защиты инфраструктуры среды разработки ПО.
  • Учитывается необходимость обеспечения конфиденциальности информации, получаемой в ходе анализа кода и тестирования ПО

Всего в стандарте описано 23 меры. По каждой мере четко описаны цели, результат реализации, а также требования к реализации меры (т.е. что именно нужно сделать). Радует, что все меры описаны достаточно однозначно.
"Базовый набор мер" по ГОСТ Р 56939-2016 выглядит следующим образом:

1. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении анализа требований к программному обеспечению:

1.1. При выполнении анализа требований к ПО разработчик ПО должен определить требования по безопасности, предъявляемые к разрабатываемому ПО.

2. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении проектирования архитектуры программы:

2.2. Уточнение проекта архитектуры программы с учетом результатов моделирования угроз безопасности информации.

3. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении конструирования и комплексирования программного обеспечения:

3.1. Использование при разработке ПО идентифицированных инструментальных средств.

3.2. Создание программы на основе уточненного проекта архитектуры программы.

3.3. Создание (выбор) и использование при создании программы порядка оформления исходного кода программы.

4. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении квалификационного тестирования программного обеспечения:

5. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении инсталляции программы и поддержки приемки программного обеспечения:

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

5.2. Поставка пользователю эксплуатационных документов.

6. Меры по разработке безопасного программного обеспечения, реализуемые при решении проблем в программном обеспечении в процессе эксплуатации:

6.1. Реализация и использование процедуры отслеживания и исправления обнаруженных ошибок ПО и уязвимостей программы.

7. Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента документацией и конфигурацией программы:

7.1. Реализация и использование процедуры уникальной маркировки каждой версии ПО.

7.2. Использование системы управления конфигурацией ПО.

8. Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента инфраструктурой среды разработки программного обеспечения:

8.1. Защита от несанкционированного доступа к элементам конфигурации.

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

Какие дефекты присутствуют в ПО и все ли они одинаковы? На этот вопрос можно отвечать по-разному, строя различные теории их классификации. Здесь мы приведем разделение дефектов программного обеспечения на классы с точки зрения различий в управлении ими в процессе повышения качества ПО в соответствии с требованиями информационной безопасности.

Самый распространенный дефект – это ошибки программистов при разработке кода. Зачастую причиной их появления является дефицит времени или потеря внимания во время работы. Например, программист разрабатывает код, который в определенных условиях должен выполнять одни действия, а во всех остальных случаях – другие. Программист уделяет большое внимание разработке кода, который будет выполняться в 90% случаях исполнения ПО. Когда же дело доходит до обработки альтернативы, он устает, его внимание рассеивается, и какие-то важные аспекты, такие как оператор, определяющий выполнение данного фрагмента кода, только если условие выполнения основного фрагмента не выполнилось, теряются.

Другая характерная причина появления ошибок в программном коде – внесение в него изменений. Разработчик меняет один кусок кода, который может влиять на функциональность другого фрагмента программы. Тогда та функциональность, трансформация которой не предполагалась, становится измененной.

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

Другие дефекты, которые в большей степени интересуют специалистов по информационной безопасности, нежели разработчиков, – это уязвимости. Уязвимость – ошибка разработчика, которая потенциально может эксплуатироваться злоумышленниками с целью получения несанкционированного доступа к управлению программным приложением. Уязвимость – это код, который выполняет правильные действия с точки зрения требуемого функционала, но его исполнение имеет побочный эффект, о наличии которого программист зачастую может не знать. Наличие таких фрагментов кода не является следствием усталости, невнимательности или отсутствия достаточного времени на тестирование у разработчика, как в случае ошибки. Нередко причиной появления уязвимостей является незнание программистов о наличии побочных возможностей тех языковых конструкций, которые они используют для реализации задуманного функционала.

Уязвимости выявляют эксперты в области анализа кода, знающие о наличии побочных эффектов у тех или иных языковых конструкций. Также многие уязвимости можно обнаруживать в результате тестирования ПО по требованиям информационной безопасности специальными тестами на проникновение. Однако более эффективный метод их обнаружения – это полуавтоматический статический анализ кода, который выполняется экспертами с применением специальных инструментальных средств.

Самые неприятные с точки зрения возможности обнаружения дефекты – недекларированные возможности ПО (НДВ). Недекларированные возможности – это правильный код с точки зрения и функциональности, и информационной безопасности, поэтому его трудно обнаружить автоматическими методами. Однако этот код реализует функциональность, которая не была задумана заказчиком – ее для своих целей привнес разработчик. Обычно НДВ разделяют на закладки и секретный вход (back door).

Закладка – это функциональность, которая выполняется при наступлении определенных условий и выполняет действия, задуманные разработчиком. Часто закладки используются для того чтобы неявно манипулировать программным обеспечением. Один из наиболее известных случаев наличия закладки – история разработчика City Bank. Программист не знал, что делать с разницей, возникающей при округлении результатов арифметических операций при начислении процентов на вклады клиентов, и не придумал ничего лучше, чем накапливать ее на своем персональном счете.

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

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

Откуда берутся дефекты в программном коде?

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

Зачастую требования к программному обеспечению меняются быстрее, чем ИТ-команда успевает их реализовывать. Дается одно техническое задание, оно прорабатывается архитектором, конструкторами и передается в работу. Но в процессе заказчик разработки понимает: новые условия рынка требуют, чтобы разрабатываемое ПО выполняло другой функционал. Несмотря на возражения ИТ-команды, вносятся изменения в проектную документацию, а зачастую и непосредственно в код, ломая при этом проработанную архитектуру.

Другой причиной появления ошибок и уязвимостей является сложность технологий, использующихся в современной ИТ-индустрии.

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

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

Можно ли контролировать наличие дефектов в программном коде?

  • Самостоятельная разработка – это ПО, которое разрабатывается либо силами своей ИТ-команды, либо сторонним разработчиком по выданному заказчиком техническому заданию.
  • Стандартное ПО, разработанное российским производителем, возможно, настроенное и адаптированное под бизнес.
  • ПО, разработанное небольшим иностранным производителем.
  • ПО, разработанное мировым ИТ-гигантом и поставляемое в виде набора готовых модулей.

На сегодняшний день на рынке представлено несколько инструментальных систем анализа кода, как статического (по исходному коду методом «белого ящика»), так и динамического (без исходного кода методом «черного ящика»). Помимо этого, ведущие инструментальные системы анализа кода от таких производителей, как HP и IBM, предлагают комбинированный статический и динамический анализ, который позволяет отображать результаты динамического анализа на исходный код. Можно сказать, что в настоящее время наиболее эффективным инструментальным средством анализа кода, которое предлагает статический, динамический, а также гибридный анализ в сочетании с удобным интерфейсом и хорошей библиотекой правил поиска уязвимостей, является инструментальное средство HP Fortify.

Если программное обеспечение разрабатывается на заказ, то при приемке оно обязательно должно подвергаться проверке на наличие дефектов. Это может сделать внутренняя команда по контролю качества программных продуктов в части функциональности и требований информационной безопасности. Проверка также может быть сторонней, что подразумевает привлечение независимых экспертов.

Контролировать уязвимости в программном обеспечении, которое поставляется на заказ, сложно, так как информация о наличии дефектов проходит долгий путь проверок, а затем следует не менее длительный процесс их устранения. Однако это не значит, что такое ПО не нужно проверять и стоит эксплуатировать как «кота в мешке». Рекомендуется выполнять контроль уязвимостей посредством правильной настройки защиты периметра эксплуатации.

1.2. Регламент определяет порядок взаимодействия ФАУ "ГНИИИ ПТЗИ ФСТЭК России", обеспечивающего функционирование банка данных угроз безопасности информации (далее - Оператор), с разработчиками и производителями программного обеспечения и программно-аппаратных средств (далее - изготовители), с организациями и специалистами, которые выявляют (обнаруживают) уязвимости программного обеспечения и программно-аппаратных средств (далее - исследователи), при включении информации об уязвимостях программного обеспечения и программно-аппаратных средств (далее - уязвимости) в банк данных угроз безопасности информации ФСТЭК России (далее - Банк данных угроз).

1.3. В рамках взаимодействия Оператор может заключить с изготовителем соглашение о неразглашении информации об уязвимостях, поступающей от изготовителя, с учетом положений настоящего Регламента.

2. ПОЛУЧЕНИЕ ИНФОРМАЦИИ ОБ УЯЗВИМОСТЯХ

2.1. Сведения об уязвимостях могут быть получены Оператором:

при поступлении информации об уязвимостях от изготовителей;

при поступлении информации об уязвимостях от исследователей;

при выполнении исследований по заданию ФСТЭК России.

наименование уязвимости и ее описание;

наименование и версии уязвимого программного обеспечения или программно-аппаратного средства;

разработчик/производитель (вендор) уязвимого программного обеспечения или программно-аппаратного средства (при наличии);

тип и идентификатор ошибки в соответствии с общим перечнем ошибок CWE;

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

базовый вектор и степень опасности "1" уязвимости в соответствии с CVSS v.3.0;

"1" В соответствии с ГОСТ Р 56545-2015 степень опасности уязвимости может принимать одно из четырех значений; критический (оценка по CVSS - 10), высокий (оценка по CVSS - 7 - 9,9), средний (оценка по CVSS - 4 - 6,9), низкий (оценка по CVSS - 0 - 3,9).

порядок проверки уязвимости и подтверждающие материалы (PoC-код, видеодемонстрация или иные);

контактные данные изготовителя (наименование организации и адрес места ее нахождения, должность, фамилию, имя, отчество (при наличии) руководителя организации, наименование подразделения, ответственного за устранение уязвимостей, номер телефона, адрес электронной почты) или исследователя (имя, адрес электронной почты и (или) номер телефона).

2.3. Информация об уязвимости может направляться с использованием PGP-ключей, размещенных в разделе "Обратная связь" Банка данных угроз.

3. ОБРАБОТКА ИНФОРМАЦИИ ОБ УЯЗВИМОСТЯХ

3.1. Обработка информации об уязвимостях, поступившей

3.1.1. Изготовитель при выявлении уязвимости в своем программном обеспечении или программно-аппаратном средстве направляет информацию выявленной уязвимости в Банк данных угроз в соответствии с пунктом 2.2 настоящего Регламента в течение 3 рабочих дней с даты ее выявления.

В случае если изготовитель получил информацию об имеющейся в его программном обеспечении (программно-аппаратном средстве) потенциальной уязвимости из внешнего источника (в том числе от исследователей в соответствии с пунктом 3.2.1 настоящего Регламента), то информация об уязвимости направляется изготовителем в Банк данных угроз после предварительной проверки и оценки степени опасности данной потенциальной уязвимости. Информация об уязвимости, полученная от исследователя, направляется с указанием контактных данных исследователя, выявившего уязвимость, для учета при определении рейтинга исследователя в соответствии с пунктом 4.3 настоящего Регламента (при наличии согласия исследователя на предоставление таких данных).

Рекомендуемый срок предварительной проверки и оценки степени опасности потенциальной уязвимости не должен превышать 5 рабочих дней с даты получения (опубликования) информации о наличии потенциальной уязвимости.

3.1.2. При получении от изготовителя информации об уязвимости или потенциальной уязвимости Оператор в срок не более 3 рабочих дней проверяет наличие сведений о ней в Банке данных угроз, а также в иных базах данных уязвимостей и общедоступных источниках и в случае отсутствия в них информации резервирует для уязвимости (потенциальной уязвимости) временный идентификатор (BDU-Z-XXXX-xxxxx) Банка данных угроз.

Информация о зарезервированном временном идентификаторе для уязвимости (потенциальной уязвимости) направляется изготовителю на указанный им адрес электронной почты.

При наличии информации об уязвимости (потенциальной уязвимости) в Банке данных угроз Оператор информирует об этом изготовителя и при необходимости уточняет описание уязвимости в Банке данных угроз. В случае наличия информации об уязвимости (потенциальной уязвимости) в других общедоступных базах данных уязвимостей или источниках Оператор в течение 3 рабочих дней присваивает уязвимости постоянный идентификатор (BDU-XXXX-xxxxx), во взаимодействии с изготовителем формирует описание уязвимости, образец которого приведен в приложении N 1 к настоящему Регламенту, и размещает его в Банке данных угроз.

3.1.3. Изготовитель в отношении уязвимости, для которой Оператором зарезервирован временный идентификатор, разрабатывает меры, обеспечивающие устранение этой уязвимости (например, разработка патча, выпуск новой версии), или принимает правовые, организационные, технические меры, снижающие возможность эксплуатации уязвимости нарушителем (далее - меры по устранению уязвимости).

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

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

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

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

3.1.4. После разработки мер по устранению уязвимости в соответствии с пунктом 3.1.3 настоящего Регламента изготовитель направляет уточненную информацию об уязвимости, для которой зарезервирован временный идентификатор, и состав мер по устранению уязвимости в Банк данных угроз.

Оператор при получении уточненной информации об уязвимости от изготовителя формирует описание уязвимости, образец которого приведен в приложении N 1 к настоящему Регламенту, согласовывает описание уязвимости с изготовителем, после чего размещает описание уязвимости в Банке данных угроз с присвоением постоянного идентификатора (BDU-XXXX-xxxxx).

Описание уязвимости критического или высокого уровня опасности размещается в Банке данных угроз не позднее 5 рабочих дней с момента получения информации об уязвимости от изготовителя.

Описание уязвимостей среднего или низкого уровня опасности размещается в Банке данных угроз не позднее 7 рабочих дней с момента получения информации об уязвимости от изготовителя.

3.2. Обработка информации об уязвимостях, поступившей

от исследователей "2"

"2" Информация об уязвимостях, выявленных исследователями на основании заданий заказчиков, может быть представлена в Банк данных угроз только по согласованию с соответствующими заказчиками.

3.2.1. При выявлении уязвимости исследователем информацию о ней рекомендуется направлять изготовителю программного обеспечения или программно-аппаратного средства, в котором выявлена эта уязвимость, для ее проверки и принятия мер по устранению.

Одновременно с направлением информации об уязвимости изготовителю она может быть направлена в Банк данных угроз в соответствии с пунктом 2.2 настоящего Регламента.

При этом непринятием мер по устранению уязвимости считается:

отсутствие в течение 5 рабочих дней ответа на повторное уведомление об уязвимости или на иной последующий запрос, направленный изготовителю;

отказ от взаимодействия по подтверждению или устранению уязвимости, выраженный в устной или письменной форме;

отсутствие опубликованных в Банке данных угроз мер по устранению уязвимости в течение 60 рабочих дней с момента предоставления информации исследователем.

3.2.3. При поступлении информации об уязвимости от исследователя Оператор в срок не более 3 рабочих дней в отношении уязвимости критического или высокого уровня опасности и 5 рабочих дней в отношении уязвимости среднего или низкого уровня опасности проверяет наличие сведений о выявленной уязвимости в Банке данных угроз, а также в иных общедоступных базах данных уязвимостей и источниках.

При наличии информации о выявленной уязвимости в Банке данных угроз Оператор информирует об этом исследователя и при необходимости уточняет описание уязвимости в Банке данных угроз. В случае наличия информации об уязвимости в других общедоступных базах данных уязвимостей или источниках Оператор информирует об этом исследователя, присваивает уязвимости постоянный идентификатор (BDU-XXXX-xxxxx), формирует описание уязвимости и размещает его в Банке данных угроз.

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

В случае отсутствия ответа в течение 5 рабочих дней Оператор повторно направляет уведомление об уязвимости изготовителю.

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

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

3.2.5. Изготовитель при получении информации об уязвимости от Оператора проверяет ее и в случае подтверждения наличия такой уязвимости направляет уточненную информацию Оператору.

3.2.6. Оператор при получении подтверждения об уязвимости от изготовителя резервирует для уязвимости временный идентификатор (BDU-Z-XXXX-xxxxx), о чем информирует изготовителя.

Дальнейшее взаимодействие Оператора и изготовителя осуществляется в соответствии с пунктами 3.1.2 - 3.1.5 настоящего Регламента.

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

При этом непринятием мер по устранению уязвимости считается:

отсутствие в течение 5 рабочих дней ответа на повторное уведомление об уязвимости или на иной последующий запрос, направленный Оператором;

отказ от взаимодействия с Оператором в соответствии с пунктами 3.1.2 - 3.1.5 настоящего Регламента.

Срок проведения Оператором исследований уязвимости не должен превышать 60 рабочих дней с даты получения информации от исследователя. В зависимости от сложности уязвимого программного обеспечения или программно-аппаратного средства указанный срок может быть продлен по согласованию с ФСТЭК России.

Исследования могут проводиться во взаимодействии с исследователем, направившим информацию об уязвимости.

Для проведения исследований Оператором на основе соглашения могут привлекаться экспертные организации, которые являются участниками ведения Банка данных угроз (организации - участники Банка данных угроз) "3". Информация об уязвимости, исследуемой организацией-участником Банка данных угроз, не подлежит раскрытию.

3.2.8. При подтверждении по результатам исследований, проведенных в соответствии с пунктом 3.2.7 настоящего Регламента, наличия уязвимости в программном обеспечении или программно-аппаратном средстве Оператор присваивает уязвимости постоянный идентификатор, во взаимодействии с исследователем, направившим информацию об уязвимости, формирует описание уязвимости, образец которого приведен в приложении N 1 к настоящему Регламенту, и размещает его в Банке данных угроз.

4. РАСКРЫТИЕ ИНФОРМАЦИИ ОБ УЯЗВИМОСТЯХ

4.1. Раскрытие информации об уязвимости осуществляется путем размещения Оператором описания уязвимости в Банке данных угроз.

4.2. Раскрытие информации об уязвимости в Банке данных угроз осуществляется в случае, если:

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

информации об уязвимости и мерах по ее устранению получена от изготовителя в соответствии с настоящим Регламентом;

изготовитель не принимает меры по устранению уязвимости в соответствии с настоящим Регламентом;

отсутствуют контактные данные изготовителя или его службы технической поддержки.

4.3. Оператор на основании информации об уязвимостях, представленных исследователями, ведет рейтинг исследователей ("доску почета") и размещает его на сайте Банка данных угроз (в случае наличия согласия исследователей размещение такой информации). Рейтинг определяется в соответствии с приложением N 2 к настоящему Регламенту путем расчета баллов, присвоенных исследователю за предоставленную информацию о не известных ранее уязвимостях и опубликованную в Банке данных угроз.

4.4. Исследователям, выявившим уязвимость, не рекомендуется раскрывать информацию об уязвимостях без согласования с изготовителем или Оператором.

к Регламенту включения информации

об уязвимостях программного обеспечения

и программно-аппаратных средств в банк

данных угроз безопасности информации

Описание уязвимости для размещения в Банке данных угроз

BDU: XXXX-xxxxx: Наименование уязвимости

Наименование уязвимого программного обеспечения

Версия уязвимого программного обеспечения

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

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

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

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

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

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

  • «уязвимости ОС РОСА»;
  • «уязвимости НЦТ ИТ РОСА»;
  • «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 раза в неделю.

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

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

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

  • Информацию из общедоступных баз данных уязвимости по номерам версий и иным идентификаторам уязвимостей (формальной источник)
  • Наличие эксплойта и его применимость
  • Информацию о критичности уязвимости, на основе данных из общедоступных баз по уязвимостям
  • Информацию о критичности, в привязке к приоритетности компонентов ПО. Предложенный порядок критичности ниже, то есть наши критерии оценки важности (требует обсуждения и уточнения):

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

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

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

  • 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

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

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

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

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

Прочее

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

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

Формат публикации

Каждый такой бюллетень безопасности имеет уникальный идентификатор вида: 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. Список всех багов с установленным 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. Публикатор отслеживает собранные и проверенные пакеты с исправлениями уязвимостей, направленные на публикацию по наличию флажка publishied
  2. Он обеспечивает публикацию пакетов в репозиториях или другие методы доведения исправленных пакетов до пользователей системы
  3. После успешной публикации он устанавливает флажок publishied в '+', при невозможности по каким-то причинам публикации, флажок устанавливается в '-'

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

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

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

Читайте также: