РБПО-xxx. Третий доклад
Появился третий устный доклад про РБПО. В нём обзорно рассмотрены процессы с 1 по 10. Постепенно я разберу их здесь более обстоятельно и снабжу различными отсылками. Доклад же предназначен для общего быстрого знакомства с темой.

Процессы РБПО 5.1-5.10 в ГОСТ Р 56939-2024.

РБПО-032. Процесс 2 — Обучение сотрудников (часть 1/4)
Если сотрудники не заботятся о безопасности, так как просто не знают, что это означает, не понимают, что пишут уязвимый код, то все остальные меры малоэффективны. Процессы РБПО требуют от команды определённой зрелости, осознанности решений и знаний инструментов/практик.

Малополезно просить сотрудника разработать правила кодирования (регламент оформления исходного кода и безопасного кодирования), если он понятия не имеет, что это такое, и не читал такие книги, как "Совершенный код" Стива Макконнелла и "Как написать безопасный код на C++, Java, Perl, PHP, ASP . NET" Ховарда М., Лебланка Д, Виега Д. Ну или хотя-бы "Веревка достаточной длины, чтобы выстрелить себе в ногу" Алена Голуба. Впрочем, именно эта книга мне не нравится, но это лучше, чем ничего.

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

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

Условно обучение сотрудников можно разделить на два типа: самообразование и внешнее обучение. Собственно, это указано и в примечании ГОСТ Р 56939-2024 (п. 5.2.):

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

Быть может, достаточно просто положиться на самообразование, выделив сотрудникам определённое время на чтение книг, просмотр записей докладов и т.п.? Соблазнительный по простоте вариант, но, к сожалению, недостаточен.

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

Во-вторых, может быть необходимо подтверждать компетенции сотрудников не только для себя. В случае сертификации необходимо предоставить соответствующие артефакты. Например (п.5.2.3.3):

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

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

Сегодня предлагаю вашему вниманию запись совместного с Axiom JDK вебинара на тему РБПО в мире Java. О Libercat, OpenIDE и т.д.

При построении РБПО не требуются сертификаты ФСТЭК для статических анализаторов и других инструментов разработки

Выдержка из эфира AM Live «Разработка безопасного программного обеспечения (РБПО)». Смотрите в vkvideo начиная с 1:54:10. На rutube начало в 2:06:58.

Дмитрий Пономарев. Сотрудник НТЦ Фобос-НТ / ИСП РАН / МГТУ им. Н. Э. Баумана ИУ10:

Какие требования к инструментам РБПО предъявляет ФСТЭК России? Сразу объясню почему его (вопрос) включили. В очередной раз, оказываясь в большой крупной организации на 6000 только разработчиков… Вопрос, а нам ИБ сказала, что ФСТЭК люто требует чтобы все анализаторы статические, фаззеры и прочие должны с быть с сертификатом ФСТЭК, иначе не считается.

Я знаю лично знаю, что некоторые компании даже бизнес модель отстроили по продажи инструментов, в которых может не всё так хорошо, но есть сертификат ФСТЭК.

Ирина Сергеевна, так всё-таки нужен сертификат ФСТЭК для фаззера и статического анализатора? Или не нужен? Или когда нужен?

Ирина Гефнер. Заместитель начальника Управления ФСТЭК России:

Не нужен сертификат ФСТЭК на инструмент разработки безопасного ПО.

Не нужны (сертификаты). Единственное, что мы требуем от инструментов, чтобы с точки зрения безопасности, как общей системной вещи, чтобы вы понимали, что там находится. Т.е. чтобы инструменты были отечественными, чтобы вы понимали кто стоит за их разработкой и т.д.

И open-source – пожалуйста. Главное, чтобы инструмент позволял выполнять все требования и те виды тестирования и испытания кода, которые мы декларируем в своих документах. В ГОСТ-ах в частности. Если мы касаемся вопросов сертификации, то это методика выявления уязвимостей и НДВ, требования по безопасности информации. Это одно из основных правил и требований.
…

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

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

Первое. Обсуждалась тема доверенных компиляторов, и меня просили подсказать номер стандарта. Вот он: ГОСТ Р 71206-2024 «Защита информации. Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования». Примеры компиляторов: SAFEC (на основе GCC) и Safelang (на основе Clang). Подробнее.

Второе. Я говорил, что в презентацию вкралась опечатка — там, где я рассматривал ошибку в функции сравнения. Мне не давал этот момент покоя, т.к. я не понимал, почему там такой код, хотя я вроде его не правил имена переменных и не перенабирал что-то. В общем, сейчас посмотрел и разобрался. Я допустил сopy-paste ошибку :)

Я запутался в двух похожих фрагментах с ошибками и скрестил их в презентации :)

Итак, на самом деле в нашей коллекции ошибок выписаны два разных случая:

Проект IronPython. Предупреждение PVS-Studio: V3021 There are two 'if' statements with identical conditional expressions. The first 'if' statement contains method return. This means that the second 'if' statement is senseless. SourceLocation.cs 156

public static int Compare(SourceLocation left,
                          SourceLocation right) {
  if (left < right) return -1;
  if (right > left) return 1;
  return 0;
}

Здесь как раз местами поменяны операнды и изменён оператор сравнения на противоположный. В результате два условия на самом деле оказались идентичными.

Рассмотренный пример смешался с этим:

Проект Samba. Предупреждение PVS-Studio: V501 There are identical sub-expressions to the left and to the right of the '>' operator: i2->pid > i2->pid brlock.c 1901

static int compare_procids(const void *p1, const void *p2)
{
  const struct server_id *i1 = (struct server_id *)p1;
  const struct server_id *i2 = (struct server_id *)p2;

  if (i1->pid < i2->pid) return -1;
  if (i2->pid > i2->pid) return 1;
  return 0;
}

Код похожий, но здесь другой тип ошибки. Переменная сравнивается сама с собой: i2->pid > i2->pid.

Никто не защищён от опечаток и сopy-paste ошибок. Даже я :) Используйте статический анализатор кода PVS-Studio как дополнительную пару глаз для обзоров кода :)

Третье. Условия получения бесплатных вариантов лицензий PVS-Studio:
- Бесплатное использование PVS-Studio студентами и преподавателями.
- Бесплатная лицензия PVS-Studio для Open Source.

РБПО-033. Процесс 2 — Обучение сотрудников (часть 2/4)
Давайте попробуем составить список задач и ссылок, на основе которого можно реализовать в компании процесс обучение сотрудников разработке безопасного ПО. Для этого оттолкнёмся от списка артефактов, приведённых в ГОСТ Р 56939-2024 в п. 5.2.3. Пройдусь по пунктам этого раздела, по возможности комментируя их.

5.2.3.1 Результаты анализа существующих (доступных для анализа) практик, документов, обучающих курсов и тренингов по разработке безопасного ПО с точки зрения их применимости для обучения сотрудников разработчика.

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

Из книг могу предложить:
• Ховард М., Лебланк Д, Виега Д. Как написать безопасный код на C++, Java, Perl, PHP, ASP.NET. - М.: ДМК Пресс, 2014. - 288 с.: ил.
• Макконнелл С. Совершенный код. Мастер-класс / Пер. с англ. - М. : Издательско-торговый дом "Русская редакция"; СПб.: Питер, 2005. - 896 стр.: ил. (Книга не про РБПО как таковое, но хорошо описывает подходы к написанию качественного кода в целом. Книга будет полезна для общего повышения культуры написания кода и даст пищу для размышлений при разработке регламента оформления кода (правил кодирования) — см. п. 5.8.)

Касательно курсов могу предложить заглянуть на сайт учебного центра МАСКОМ. Мы с ними знакомы, проводили совместные мероприятия, а сейчас планируем цикл вебинаров "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024". Приглашаю регистрироваться. Кстати, если один из разбираемых РБПО процессов вам близок и вам есть что рассказать, вы можете стать гостем одного из вебинаров. Мы открыты к сотрудничеству, пишите нам.

Я отвлёкся. Итак, у УЦ МАСКОМ есть следующие курсы по БРПО. Почему БРПО, а не РБПО? В одном из предыдущих постов я писал, что это синонимы, и используются оба сокращения. Вот как раз такой случай.
• М БРПО-Спец. Специалист по процессам разработки безопасного программного обеспечения. 200 часов / 20 дней.
• М БРПО-01. Внедрение процессов разработки безопасного программного обеспечения в организации (для руководителей и ответственных). 40 часов / 4 дня
• М БРПО-02. Внедрение процессов разработки безопасного программного обеспечения для специалистов по информационной безопасности. 50 часов / 5 дней.
• М БРПО-03. Сертификационные испытания с учётом требований по разработке безопасного программного обеспечения для экспертов органов по сертификации (испытательных лабораторий) различных систем сертификации средств защиты информации. 140 часов / 14 дней.
• М БРПО-04. Формирование практических навыков по разработке безопасного программного обеспечения для разработчиков и программистов. 140 часов / 14 дней
• М БРПО-05. Методология подготовки предприятия к сертификации процессов безопасной разработки программного обеспечения средств защиты информации в соответствии с требованиями ФСТЭК России. 30 часов / 3 дня.

РБПО-034. Процесс 2 — Обучение сотрудников (часть 3/4)

Стоит ли читать описания потенциальных уязвимостей?
Имеются такие подборки, как как CWE (Common Weakness Enumeration), OWASP Application Security Verification Standard (ASVS), SEI CERT Coding Standard.

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

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

Примечание. Статический анализатор PVS-Studio может выявить многие дефекты безопасности, описанные в этих стандартах. Для удобства можно включить показ соответствующих идентификаторов согласно классификации CWE, OWASP, SEI CERT. Однако это не означает, что можно игнорировать обзоры кода с привлечением специалистов безопасности, которые могут выявить не только ошибки в коде, но и наличие высокоуровневых проблем проектирования и реализации алгоритмов.

Другие ссылки:
• AppSec Table Top: методология безопасной разработки от Positive Technologies.
• Раздел "Информационная безопасность" на сайте Нabr. Там много фонового шума, но встречаются и хорошие полезные публикации, например от ИСП РАН.
• Telegram ресурсы под эгидой Центра компетенций ФСТЭК России и ИСП РАН.

Напоминаю, что сегодня состоится первая встреча из цикла "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024". Регистрируйтесь. Приглашённый гость: Виталий Вареница. Он откроет вебинар докладом "История создания стандарта БРПО в России. Актуальное состояние БРПО сегодня".

Начало в 16:00 по МСК

Напоминаю про вебинар! Время заварить чай и подключаться! :)

РБПО-035. Процесс 2 — Обучение сотрудников (часть 4/4)
Закончим рассматривать артефакты процесса обучения, перечисленные в ГОСТ Р 56939-2024.

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

Перечисленное говорит само за себя, но не забывайте, что речь идёт про процесс, а не про разовую акцию повышения квалификации сотрудников, которые трудятся в компании на данный момент. Есть смысл "вшить" это в матрицы компетенций. Это будет помогать адаптировать (обучать) как новых сотрудников, так и постепенно повышать уровень компетенций опытных членов команды. Заодно естественным образом разделится, что должен изучать программист, а что — специалист ИБ. У них будут разные матрицы компетенций.

Тема матриц компетенций интересная, но большая и выходит за рамки этого цикла публикаций. Думаю, на эту тему можно многое почерпнуть из записей докладов конференций TeamLead Conf и подобных (например 1, 2, 3). Ещё добавлю, что мы её внедрили и довольны результатами.

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

Когда вас условно (или буквально) посетит команда аудиторов, вам должно быть, что ей показать :) Начинайте централизовано собирать отчётную информацию и, видимо, есть смысл назначить кого-то ответственным за эти процесс. Иначе в нужный момент вспомнить всё, что было, и предоставить подтверждающие документы будет сложно.

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

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

И последний пункт артефактов:

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

Пока здесь я постепенно прохожу по каждому процессу ГОСТ Р 56939-2024, параллельно выкладываем обзорные доклады про этот стандарт. Четвёртый из пяти:
Процессы РБПО 5.11-5.25 в ГОСТ Р 56939-2024
(рекомендую смотреть на скорости 1,25 - 1,5)

В программе:
Андрей Карпов: Типовые паттерны опечаток и как их избежать.
Марк Шевченко: Верификация программ и доказательство корректности .NET-кода.
Роман Гапонов: Все о Code Review: лучшие практики и анти-паттерны.

РБПО-036. Процесс 3 — Формирование и предъявление требований безопасности к программному обеспечению

Обеспечение безопасности ПО посредством предъявления к нему требований и управления требованиями в процессе изменения (разработки) ПО. (ГОСТ Р 56939—2024, п. 5.3.1.1)

Этот процесс я понимаю так: необходимо спланировать и разработать регламент, как будет ставиться ТЗ для внутренних/внешних команд и контролироваться ход выполнения работ. Управление процессом рекомендуется осуществлять с использованием средств автоматизации: системы управления изменениями, системы управления задачами и т. д.

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

Оговаривается состав команды, чтобы не было такого, что в начале обсуждают команду высокооплачиваемых квалифицированных специалистов, а затем передают стажёрам на полставки :))

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

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

О, в нас верят :)

ФСТЭК России объявила о начале масштабных испытаний статических анализаторов

На встрече обсудили цели и задачи испытаний, критерии оценок, инфраструктуру, сроки, состав жюри и тесты для испытаний. Было принято решение провести мероприятие на базе кафедры ИУ10 «Защита информации» МГТУ им. Н. Э. Баумана в два этапа: «домашнее задание» (завершается 15 мая) и основной этап испытаний (июль-октябрь). Итогом станет аналитический доклад от ФСТЭК России на Открытой конференции по результатам испытаний (декабрь 2025 г.).

Делайте ставки, господа!

Мой прогноз такой:

- Svace и PVS-Studio поделят первое и второе место
- Третье место будет у Clang Static Analyzer
- Synopsys Coverity - техническое поражение из-за неявки
- `cppcheck` - почётное последнее место

via

Да, данные получились сложные для восприятия. Точно придётся пояснительную бригаду вызывать статью написать. Делаю этот вывод, например, из такого комментария в одном из чатов:

Комментарий не соответствует картинке. Авторы картинки считают что TN 41.5% это плохо. Ну и абстрактно звучит плохо. 41.5% разыменований нулевых указателей не обнаружено, если я правильно понял метрику

TN - это насколько верно, что нет предупреждений, где нет ошибок. Неудачная метрика :) Но раз надо было предоставить, то вот. По простому: это обратная метрика к FP (ложноположительным срабатываниям).

Обнаружен 81,5% (TP) нулевых указателей в тестах, где надо было их обнаружить. Т.е. в тестах выявляется 81,5% имеющихся там ошибок.

И это разные наборы тестов. Первый набор тестов используется для подсчёта TP (и FN). А второй набор тестов для FP (и TN).

Ещё были тесты дополнительного набора, но это уже другая история.