РБПО-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).

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

РБПО-037. Процесс 4 — Управление конфигурацией программного обеспечения
Цели четвёртого процесса по ГОСТ Р 56939-2024:

5.4.1.1 Осуществление уникальной идентификации ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).
5.4.1.2 Контроль реализации изменений ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).

Для небольших компаний с одним-двумя проектами под одну платформу первый пункт может смотреться избыточным. Нумеруем релизы и всё. Что ещё нужно?

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

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

При разработке регламента идентификации ПО (версий ПО, модулей ПО) можно оттолкнуться от ГОСТ 19.103-77. Единая система программной документации. Обозначение программ и программных документов.

ГОСТ Р 56939-2024 даёт следующее определение управлению конфигурацией программного обеспечения:

3.19 управление конфигурацией программного обеспечения: Скоординированные действия, направленные на формирование и контроль конфигурации программного обеспечения.

Если честно, это определение мало что даёт :) Поэтому вот дополнительные ссылки:
• Управление конфигурацией.
• Конфигурационное управление.

Запись второй встречи цикла «Вокруг РБПО за 25 вебинаров. ГОСТ Р 56939-2024». Процесс N2: Обучение сотрудников.