ЕДИНАЯ ЦИФРОВАЯ ПЛАТФОРМА РОССИЙСКОЙ ФЕДЕРАЦИИ «ГОСТЕХ» ДЛЯ СОЗДАНИЯ, РАЗВИТИЯ И ЭКСПЛУАТАЦИИ ГОСУДАРСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ

ПО ОБЕСПЕЧЕНИЮ БЕЗОПАСНОСТИ ПРИ РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ С ИСПОЛЬЗОВАНИЕМ КОМПОНЕНТОВ ЕДИНОЙ ЦИФРОВОЙ ПЛАТФОРМЫ РОССИЙСКОЙ ФЕДЕРАЦИИ «ГосТех»

1. Ссылки, термины и определения

В настоящих методических рекомендациях использованы ссылки на следующие нормативно-правовые акты и стандарты:

Таблица 1

Правовые акты и стандарты

В настоящих методических рекомендациях применены следующие термины и сокращения с соответствующими определениями:

Таблица 2

Термины, сокращения и определения

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

Методические рекомендации по обеспечению безопасности при разработке ПО с использованием компонентов единой цифровой платформы Российской Федерации «ГосТех» (далее — Методические рекомендации) разработаны в целях реализации положений «Концепции создания и функционирования единой цифровой платформы Российской Федерации „ГосТех“.»

Методические рекомендации направлены на обеспечение необходимого уровня защиты информации, обрабатываемой ГИС на Платформе «ГосТех», посредством реализации мер, минимизирующих количество уязвимостей и недостатков программ на всех этапах жизненного цикла ПО.

Настоящий документ содержит рекомендации по реализации требований по разработке БПО на Платформе «ГосТех», установленных ГОСТ Р 56939.

При выявлении подтвержденных уязвимостей и недостатков программ критического и высокого уровня влияния во вновь создаваемом ПО при проведении его тестирования инструментальными средствами запрещается перевод такого ПО в продуктивную среду функционирования ГИС на Платформе «ГосТех».

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

Использование заимствованных компонентов (библиотек, фреймворков, интерпретируемых скриптов и др.) сторонних разработчиков допускается только при наличии текстов исходного кода данных компонентов, кроме компонентов, включенных в состав Платформы «ГосТех» в соответствии с настоящим документом и «Методическими рекомендации по включению сервисов в единую цифровую платформу Российской Федерации „ГосТех“.»

Графическое описание организации рекомендуемого процесса разработки БПО на Платформе «ГосТех» приведено в приложении № 1.

3. Область применения

Методические рекомендации предназначены для использования Заказчиками при разработке технических заданий, на создание, развитие, эксплуатацию ГИС на Платформе «ГосТех» и Разработчиками ПО, выполняющими работы по созданию, развитию и эксплуатации ПО ГИС на Платформе «ГосТех» в рамках заключенных государственных контрактов (договоров, соглашений).

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

Методические рекомендации не применяются при разработке ПО средств защиты информации и средств криптографической защиты информации. Такого типа ПО должно разрабатываться в строгом соответствии с требованиями законодательства Российской Федерации.

4. Анализ и формирование требований к разрабатываемому ПО

4.1. Разработка требований по безопасности

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

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

Для формирования требований Заказчику необходимо собрать информацию об области применения разрабатываемого ПО, составе планируемой к обработке информации, факте отнесения обрабатываемой информации в ГИС к категории информации ограниченного доступа и классе защищенности ГИС.

На основании полученных данных Заказчику необходимо выполнить:

• предварительный анализ потенциальных угроз безопасности информации ПО в соответствии с рекомендациями пункта 4.2 данного документа;
• идентифицировать и сформулировать цели защиты информации, достижение которых должно обеспечиваться разрабатываемым ПО;
• сформулировать и задокументировать требования по безопасности в форме функциональных и нефункциональных требований <1>.

<1> Функциональные требования по безопасности: описывают действия, которые должно выполнять ПО в целях нейтрализации угроз безопасности информации, а нефункциональные требования описывают свойства и параметры ПО, имеющие отношение к нейтрализации угроз безопасности информации.

Требования по безопасности в зависимости от их назначения рекомендуется описывать в подразделах «Требования к надежности» и/или «Требования к функциональным характеристикам» раздела «Требования к программе или программному изделию» технического задания, разрабатываемого в соответствии с ГОСТ 19.201 или в отдельном разделе технического задания на создание или развитие ГИС на Платформе «ГосТех».

Техническое задание на создание, развитие ГИС на ЕЦП «ГосТех» должно быть согласовано Заказчиком с федеральным органом исполнительной власти в области обеспечения безопасности и федеральным органом исполнительной власти, уполномоченным в области противодействия техническим разведкам и технической защиты информации, в пределах их полномочий в части требований о защите информации, в соответствии с Постановление Правительства РФ от 6 июля 2015 г. № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».

Пример требований по безопасности к разрабатываемому ПО:

• все поступающие в ПО входные данные должны подлежать контролю целостности, полноты и аутентичности;
• в ПО должна быть реализована обработка исключительных ситуаций, возникающих в процессе функционирования программы;
• информационные сообщения пользователю ГИС на Платформе «ГосТех» не должны содержать информацию о наименовании программных технических средств, использующихся в среде функционирования ПО и их версиях.

Рекомендованные требования по безопасности к разрабатываемому ПО в составе ГИС на Платформе «ГосТех» для различных классов защищенности, в соответствии с приказом ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», приведены в Приложении № 2.

4.2. Моделирование угроз безопасности информации

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

Проектирование архитектуры должно удовлетворять следующим принципам:

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

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

3. полноты перекрытия: реализация механизма обеспечения безопасности должна иметь сквозной характер (охватывать все структурные элементы ПО);

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

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

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

7. эшелонированной защиты: наличие множественной защиты, в частности — в виде уровней, с целью предотвращения или сдерживания угроз безопасности информации;

8. трудозатрат: стоимость защиты не должна превосходить стоимость потенциальных потерь в случае успешного внешнего воздействия на ПО;

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

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

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

Процедура моделирования угроз должна быть проведена для выявления потенциальных угроз безопасности информации, обоснования требований по безопасности, предъявляемых к разрабатываемому ПО в составе ГИС на Платформе «ГосТех», и выработки возможных мер по нейтрализации актуальных угроз безопасности информации.

В процессе моделирования должны быть рассмотрены угрозы безопасности информации, которые могут возникать в процессах разработки и использования ПО в составе ГИС на Платформе «ГосТех».

Для формирования перечня и описания угроз безопасности информации, которые могут возникать в процессах разработки ПО, следует использовать ГОСТ Р 58412 «Защита информации. Разработка безопасного ПО. Угрозы безопасности информации при разработке ПО».

Для формирования перечня и описания угроз безопасности информации, которые могут возникать при использовании ПО в составе ГИС на Платформе «ГосТех», Разработчику ПО необходимо использовать:

• сведения о предполагаемых компонентах программы;
• сведения об интерфейсах компонентов программ;
• сведения о предполагаемых алгоритмах, методах и протоколах взаимодействия компонентов программы;
• сведения о вариантах и методах конфигурирования программы, ее компонентов, а также планируемой среды функционирования ПО;
• информацию о заимствованных компонентах сторонних разработчиков;
• информацию из банка данных угроз безопасности информации ФСТЭК России (https://bdu.fstec.ru).

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

Моделирование угроз рекомендуется проводить в рамках следующих этапов:

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

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

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

Диаграмма потоков данных должна содержать и описывать следующие компоненты программы:

• внешние элементы;
• внутренние элементы;
• процессы;
• хранилище данных;
• потоки данных.

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

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

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

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

	Входные и выходные данные
	Внешний элемент
	Процесс
	Хранилище данных
	Поток данных
	Поток критических данных

Рекомендуемое графическое изображение на диаграмме потоков данных компонентов программы представлено на рисунке 1. Пример диаграммы потоков данных программы, составленный с учетом рекомендации настоящего документа представлен на рисунке 2.

Рисунок 2. Пример диаграммы потоков данных программы

Итоговый перечень актуальных угроз безопасности информации должен быть составлен в формате таблицы № 3.

Таблица 3

Перечень актуальных угроз безопасности информации

5. Конструирование и комплексирование ПО

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

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

Для каждого используемого при разработке в составе ГИС на Платформе «ГосТех» инструментального средства Разработчику ПО необходимо определить и зафиксировать следующую информацию:

Таблица 4

Перечень инструментальных средств, используемых в процессе разработки

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

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

Документирование архитектуры программы рекомендуется выполнять с использованием следующих нотаций и в соответствии с положениями документа «Методические рекомендации по проектированию и утверждению целевой архитектуры домена с использованием Платформы „ГосТех“:»

• DFD (Data Flow Diagram) — диаграмма потоков данных.
• Диаграммы, используемые в методологиях группы IDEF, ArchiMate и C4;
• UML-диаграммы.

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

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

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

Пример разметки исходного кода программы на языке программирования C++ для проекта архитектуры программы, представленной в формате диаграммы потоков данных (рисунок № 2), для обеспечения прослеживаемости:

**/// Функция 1.1 RegUserProcedure (Краткое описание)**
**/*!**
  **Регистрация пользователей в системе (Подробное описание)**
*/

function RegUserProcedure($vars) {}

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

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

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

5.3. Порядок оформления исходного кода программы

В целях снижения вероятности появления недостатков при создании программы, увеличения вероятности обнаружения недостатков программы и уменьшения количества ресурсов, на устранение недостатков Разработчик ПО при создании программы должен использовать рекомендованный данным документом перечень правил и рекомендаций оформления исходного кода, направленных на устранение недостатков программ в составе ГИС на Платформе «ГосТех» (потенциально уязвимых конструкций) в исходном коде.

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

Основные правила и рекомендации по оформлению исходного кода программ определяются для каждого из языков программирования, разрешенных к использованию для разработки ПО в составе ГИС на Платформе «ГосТех».

Примеры правил и рекомендаций оформления исходного кода для языков C#, JavaScript, Java представлены в Приложении № 3 настоящего документа и являются рекомендованными к применению при разработке ПО на Платформе «ГосТех».

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

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

5.4. Статический анализ исходного кода программы

• ошибки, связанные с безопасностью программы;
• остаточный отладочный код.

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

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

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

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

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

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

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

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

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

Результаты проведенного статического анализа и факт устранения выявленных недостатков программы в отношении финальной версии ПО должны быть отражены в проектной документации на создание (развитие) ГИС на Платформе «ГосТех». Форма представления результатов приведена в таблице № 5. Допускается в процессе разработки ПО использовать электронные отчеты в формате, формируемом средствами статического анализа.

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

Таблица 5

Сведения о результатах проведения статического анализа исходного кода

Общие рекомендации по организации процесса статического анализа исходного кода программы представлены на рисунке № 3.

Рисунок 3. Организация процесса проведения статического анализа

5.5. Экспертиза исходного кода программы

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

Экспертиза исходного кода всех компонентов, входящих в состав разрабатываемого ПО должна быть проведена до перевода ПО в продуктивную среду функционирования, с привлечением сторонней организации, обладающей компетенцией в области выявления уязвимостей программ, при этом в целях сокращения временного периода на создание (развитие) ГИС на Платформе «ГосТех» Разработчик ПО должен обеспечить проведение экспертизы исходного кода добавленных или измененных частей ПО после каждого внесенного изменения.

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

Для проведения экспертизы исходного кода рекомендуется использовать инструментальные средства.

Инструментальные средства для проведения экспертизы исходного кода рекомендуется выбирать исходя из следующих параметров и характеристик:

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

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

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

Результаты экспертизы и факт устранения выявленных недостатков программы должны быть представлены в виде протокола.

Общие рекомендации по организации процесса проведения экспертизы исходного кода программы представлены на рисунке № 4.

Рисунок 4. Организация процесса проведения экспертизы исходного кода программы

6. Квалификационное тестирование ПО

6.1 Функциональное тестирование программы

Для подтверждения выполнения требований по безопасности, предъявляемых к разрабатываемому ПО в составе ГИС на Платформе «ГосТех», должно проводиться функциональное тестирование программы.

Функциональное тестирование всех компонентов, входящих в состав разрабатываемого ПО должно быть проведено до перевода ПО в продуктивную среду функционирования, с привлечением сторонней организации, обладающей компетенцией в области выявления уязвимостей программ, при этом в целях сокращения временного периода на создание (развитие) ГИС на Платформе «ГосТех» Разработчик ПО должен обеспечить проведение функционального тестирования добавленных или измененных частей ПО после каждого внесенного изменения.

Методика функционального тестирования по проверке требований по безопасности к ПО должна быть включена в программу и методику испытаний на создание (развитие) ГИС на Платформе «ГосТех».

Оформление программы и методики испытаний должно осуществляться в соответствии с ГОСТ 19.301.

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

Рекомендованный формат описания процедуры тестирования представлен в таблице № 6.

Таблица 6

Описание процедуры функционального тестирования ПО

Все используемые инструментальные средства должны быть идентифицированными в соответствии с рекомендациями п. 5.1 данного документа.

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

Рекомендуемый формат оформления результатов функционального тестирования ПО представлен в таблице № 7.

Таблица 7

Результаты функционального тестирования ПО

Все выявленные недостатки программы критического и высокого уровня влияния должны быть устранены Разработчиком ПО до момента ввода ГИС на Платформе «ГосТех» в эксплуатацию.

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

Рисунок 5. Организация процесса проведения функционального тестирования

6.2 Фаззинг-тестирование программы

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

Фаззинг-тестирование должно быть проведено до перевода ПО в продуктивную среду функционирования, с привлечением сторонней организации, обладающей компетенцией в области выявления уязвимостей программ, при этом в целях сокращения временного периода на создание (развитие) ГИС на Платформе «ГосТех» Разработчик ПО должен обеспечить проведение фаззинг-тестирования добавленных или измененных частей ПО после каждого внесенного изменения.

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

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

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

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

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

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

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

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

Результаты фаззинг-тестирования должны быть представлены в виде протокола.

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

Общие рекомендации по организации процесса проведения фаззинг-тестирования приведены на Рисунке № 6.

Рисунок 6. Организация процесса проведения фаззинг-тестирования

6.3 Динамический анализ кода программы

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

- анализ помеченных данных;

- снятие трассы, выявление пути распространения ошибки.

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

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

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

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

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

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

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

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

Общие рекомендации по организации процесса проведения динамического анализа приведены на Рисунке № 7.

6.4 Тестирование на проникновение

• результатов динамического анализа кода программы;
• фаззинг-тестирования.

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

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

• Penetration Testing Execution Standard (PTES);
• Open Source Security Testing Methodology Manual (OSSTMM);
• Open Web Application Security Project (OWASP) Testing Guide;
• Common Vulnerability Scoring System (CVSS).

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

• внешнее тестирование на проникновение, состоящее из анализа защищенности сетевого периметра среды функционирования ПО, направленное на получение доступа к ПО через элементы среды функционирования и дальнейшее развитие атаки через эти элементы;

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

7. Инсталляция программы и поддержка приемки ПО

7.1. Обеспечение защиты ПО в процессе его передачи Заказчику

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

Средство контрольного суммирования должно соответствовать требованиям документов ФСТЭК России и ФСБ России и обеспечивать:

• вычисление контрольных сумм, заданных файлов/директорий по алгоритмам ГОСТ Р 34.11-2012;
• совместимость с операционными системами семейства Linux;
• возможность выгрузки результатов в структурированном формате, например CSV;
• возможность сравнения контрольных сумм заданных файлов/директорий в соответствии со списком.

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

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

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

В комплекте эксплуатационных документов следует включить описание действий Заказчика, позволяющие выполнить проверку целостности упаковки, проверке электронных подписей и контрольных сумм экземпляров ПО.

Данные рекомендации должны применяться в совокупности с рекомендациями, представленными в документе «Методические рекомендации по включению сервисов в единую цифровую платформу Российской Федерации „ГосТех“.»

7.2. Поставка Заказчику эксплуатационных документов

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

Руководство пользователя должно содержать описание:

• режимов работы средства;
• принципов безопасной работы средства;
• функций и интерфейсов функций средства, доступных каждой роли пользователей;
• параметров (настроек) безопасности средства, доступных каждой роли пользователей, и их безопасных значений;

При развертывании ПО и его компонентов должна использоваться эталонная безопасная конфигурация.

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

Данные рекомендации должны применяться в совокупности с «Методическими рекомендациями по включению сервисов в единую цифровую платформу Российской Федерации „ГосТех“.»

8. Решение проблем в процессе эксплуатации

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

Целью отслеживания и исправления обнаруженных недостатков и уязвимостей является сокращение негативного влияния недостатков программы на процессы Заказчика, которые автоматизируются ГИС на Платформе «ГосТех».

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

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

Документация Разработчика ПО должна содержать:

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

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

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

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

<2> К экстренным ситуациям относятся: выявление недостатков программы или уязвимостей или заимствованных компонентов в составе ПО, которые могут привести к нарушению свойств защиты информации, обрабатываемой ПО в составе ГИС на Платформе «ГосТех».

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

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

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

Идентификатор — это уникальное значение, которое позволяет отличить один отчет от другого.

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

Отчет о недостатках рекомендуется дополнять по мере изменения текущего состояния недостатка.

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

- завершение процесса устранения недостатка;

- устранение недостатка отложено;

- устранение недостатка не планируется.

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

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

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

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

8.2. Систематический поиск уязвимостей программы

В целях контроля и анализа защищенности ПО в составе ГИС на Платформе «ГосТех» должен проводиться систематический поиск уязвимостей.

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

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

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

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

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

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

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

9. Управление документацией и конфигурацией программы

9.1. Уникальная маркировка каждой версии ПО

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

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

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

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

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

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

Рекомендуемый список элементов конфигурации разрабатываемого ПО определен в Приложении 4.

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

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

10. Управление инфраструктурой среды разработки ПО

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

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

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

Разработчику ПО рекомендуется включать в состав документации на ПО, связанной с реализацией меры по разработке безопасного ПО, документы Разработчика ПО, соответствующие требованиям п. 5.8.3.1 ГОСТ Р 56939.

10.2. Резервное копирование элементов конфигурации

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

Резервное копирование рекомендуется осуществлять в отношении всех элементов конфигурации ПО.

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

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

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

Реализацию мер по резервному копированию и восстановлению элементов конфигурации следует осуществлять в соответствии с ГОСТ Р ИСО/МЭК 27002.

10.3 Регистрация событий, связанных с фактами изменения элементов конфигурации

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

Рекомендуется осуществлять регистрацию следующей информации:

• инициатор изменения;
• идентификатор элемента конфигурации;

Реализацию мер, обеспечивающих регистрацию всех событий, связанных с фактами изменения элементов конфигурации, в журналах регистрации событий следует осуществлять в соответствии с ГОСТ Р ИСО/МЭК 27002.

11. Обучение работников и периодический анализ программы обучения

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

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

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

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

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

Приложение № 1

СХЕМА ОРГАНИЗАЦИИ ПРОЦЕССА РАЗРАБОТКИ БЕЗОПАСНОГО ПО НА ПЛАТФОРМЕ «ГосТех»

Приложение № 2

РЕКОМЕНДОВАННЫЕ ТРЕБОВАНИЯ ПО БЕЗОПАСНОСТИ К РАЗРАБАТЫВАЕМОМУ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ В СОСТАВЕ ГИС НА ПЛАТФОРМЕ «ГосТех»

1. Требования к архитектуре и моделированию угроз

1.1. Требования к жизненному циклу безопасной разработки ПО

1.2. Требования к архитектуре аутентификации

1.3 Требования к архитектуре контроля доступа

1.4. Требования к архитектуре ввода-вывода

1.5. Регистрация ошибок и ведение журнала

1.6. Требования к архитектуре защиты данных

<3> П. 2, ст. 5 Федерального закона от 27.06.2006 N 149-ФЗ.

1.7. Требования к архитектуре связи

1.8. Требования к реализации мониторинга событий разработки ПО

1.9. Требования к архитектуре бизнес-логики

1.10. Требования к архитектуре безопасной загрузки файлов

1.11. Требования к архитектуре конфигурации

2. Требования к аутентификации

2.1. Требования к проведению процедуры восстановления учетных данных

2.2. Требования к проведению процедуры служебной аутентификации

3. Требования к управлению сессиями (Session Management)

3.1. Основы безопасности управления сессии

3.2. Требования к привязке к сессии

3.5. Требования к процедуре управления сессиями на основе токенов

3.6. Требования к интегрированному управлению аутентификацией

3.7. Требования к процессу защиты от эксплойтов в процессе управления сессиями

4. Требования к контролю доступа

4.1. Требования к общей архитектуре контроля доступа

4.2. Требования к контролю доступа на эксплуатационном уровне

5. Требования к валидации, очистке и кодированию

5.1. Требования к проверке входных данных

5.2. Требования к очистке и изоляции вводимых данных

5.3. Требования к кодированию выходных данных и предотвращению заражения

N	Описание	К3	К2	К1
5.3.1	Кодировка вывода соответствует требуемому интерпретатору и контексту. Например, используйте кодировщики специально для значений HTML, атрибутов HTML, JavaScript, параметров URL, заголовков HTTP, SMTP и других, как того требует контекст, особенно для ненадежных входных данных (например, имен с Юникод или апострофом, таких как или О'Хара).	x	x	x
5.3.2	Кодировка вывода сохраняет выбранный пользователем набор символов и языковой стандарт, так что любая точка символа Юникод важна и безопасно обрабатывается	x	x	x
5.3.3	Для защиты от отраженных, сохраненных и основанных на DOM XSS должно быть реализовано автоматизированное контекстно зависимое экранирование вывода	x	x	x
5.3.4	Запросы к базе данных (например, SQL, HQL, ORM, NoSQL) должны быть защищены от атак типа "Внедрение SQL-кода" при помощи параметризованных запросов, ORM, entity framework и т.д.	x	x	x
5.3.5	При отсутствии параметризованных запросов или более безопасных механизмов запросов к базе данных для защиты от атак типа "Внедрение SQL-кода" используется контекстно зависимая кодировка вывода, например экранирование SQL	x	x	x
5.3.6	Приложение защищает от атак с использованием JSON, атак с использованием JSON eval и вычисления выражений JavaScript	x	x	x
5.3.7	Приложение защищает от уязвимостей, связанных с внедрением LDAP, или реализованы специальные средства безопасности для предотвращения внедрения LDAP	x	x	x
5.3.8	Приложение защищает от внедрения команд операционной системы, вызовы операционной системы используют параметризованные запросы операционной системы или используют контекстную кодировку вывода командной строки	x	x	x
5.3.9	Приложение защищает от атак локального включения файлов (LFI) или удаленного включения файлов (RFI)	x	x	x
5.3.10	Приложение защищает от атак с использованием XPath или XML-инъекций	x	x	x

5.4. Требование к памяти, срокам и неуправляемому коду

5.5. Требования к процессу предотвращения десериализации

6. Требования к обработке ошибок и ведению журнала

6.1. Требования к содержимому журнала

6.2. Требования к обработке журнала

6.3. Требования к защите журнала

6.4. Требования к обработке ошибок

7. Требования к защите данных

7.1. Общие требования к защите данных

7.2. Требования к передаче и обработке информации ограниченного доступа

7.3. Требования к информации ограниченного доступа (персональные данные)

8. Требования к каналам связи

8.1. Общие требования к коммуникации

9. Требования к защите от вредоносного воздействия

9.1. Требования к целостности кода

9.2. Требования к поиску вредоносного кода

9.3. Требования к целостности приложения

10. Требования к бизнес-логике

10.1. Требования к процедуре обеспечения безопасности бизнес-логики

11. Требования к файлам и ресурсам

11.1. Требования к передаче файлов

11.2. Требования к целостности файла

11.3. Требования к выполнению файла

11.4. Требования к хранилищу файлов

11.5. Требования к скачиванию файлов

11.6. Требования к защите от SSRF

12. Требования к API и веб-сервисам

12.1. Общие требования к безопасности веб-сервисов

12.2 Требования к REST-реализации

12.3. Требования к SOAP-реализации

12.4. Требования к реализации GraphQL

13. Требования к конфигурации

13.1. Требования к сборке и развертыванию

13.2. Требования к зависимостям

13.3. Действия по предотвращению непреднамеренного раскрытия информации о безопасности

13.4. Требования к безопасности заголовков HTTP

13.5. Требования к проверке заголовка HTTP-запроса

Приложение N 3

ПРИМЕР ПРАВИЛ И РЕКОМЕНДАЦИЙ ОФОРМЛЕНИЯ ИСХОДНОГО КОДА

Язык программирования C#

1. Именование переменных

1.1 Pascal casing

Описываются имена:

• всех определений типов, в том числе пользовательских классов, перечислений, событий, делегатов и структур;
• значения перечислений;
• readonly полей и констант;
• интерфейсов;
• методов;
• пространств имен (namespace);
• свойств;
• публичных полей;

1.2 Camel casing

Описываются имена:

• локальных переменных;
• аргументов методов;
• защищенных (protected) полей.

1.3 Суффиксы и префиксы

Применяются следующие суффиксы и префиксы:

• имена пользовательских классов исключений всегда заканчиваются суффиксом Exception;
• имена интерфейсов всегда начинаются с префикса "I";
• имена пользовательских атрибутов всегда заканчиваются суффиксом "Attribute";
• имена делегатов обработчиков событий всегда оканчиваются суффиксом EventHandler, имена классов-наследников от EventArgs всегда заканчиваются суффиксом EventArgs.

1.4 Аббревиатуры

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

Например: namespace Sample.IO, class HttpUtil

2. Именование методов

Используйте конструкцию "глагол-объект" для именования методов. В частном случае, для методов, которые возвращают значение, используйте в паре "глагол-объект" для глагола Get, а для объекта - описание возвращаемого значения.

Например: ShowUserID(), GetUserID()

3. Именование переменных, полей и свойств.

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

Например: txtSample.

Имена закрытых полей всегда начинаются с префикса "_" остальная часть имени описывается с помощью Camel Casing.

Например: private int_samplePrivateField;

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

4. Оформление кода

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

Располагайте открывающие и закрывающие фигурные скобки на новой строке. Используйте фигурные скобки для выражения if, даже когда в выражение входит только одна строка кода.

Используйте промежуточную переменную для передачи bool-значения результата функции в условное выражение if;

Например:

bool boolVariable = GetBoolValue();

if (boolVariable)

{

}

Ставьте пробелы вокруг операторов (= +-*/) и после запятой.

5. Объем кода

Избегайте файлов с более чем 500 строками кода.

Избегайте методов с более чем 200 строками кода.

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

Одна строка кода не должна иметь длину более 120 символов.

Язык программирования JavaScript

1. Именование переменных

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

2. Оформление логических операций

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

Например:

bool boolVariable = GetBoolValue();

if (boolVariable)

{

}

3. Оформление операторов

Всегда заканчивайте простой оператор точкой с запятой.

Правила для сложных операторов:

• поместите открывающую скобку в конец первой линии;
• используйте один пробел перед открывающей скобкой;
• поместите закрывающую скобку на новую линию без пробелов;
• не заканчивайте сложный оператор точкой с запятой.

Например:

Функция: function divideByTwo(number) { return (number / 2); }

Петля: for (i = 0; i <2; i++) { x += i; }

Условие: if (time <5) { mark = "5"; } else { mark = "4"; }

4. Общие правила для определений объектов:

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

Пример: var person = { firstName: "John", lastName: "Doe", age: 50, eyeColor: "blue" };

Короткие объекты могут быть записаны сжатыми, на одной линии, используя пробелы только между свойствами, как это:

var person = {firstName:"John", lastName:"Doe", age:50, eyeColor:"blue"};

5. Отступы

Ставьте пробелы вокруг операторов (= +-*/) и после запятой. Используйте 4 пробела для отступа блоков кода. Не используйте вкладки (таблицы) для отступа.

6. Объем кода

Избегайте строк длиной более 80 символов.

Если инструкция JavaScript не умещается на одной строке, нужно разбить ее после оператора или запятой.

Например: document.getElementById("demo").innerHTML = "Hello Dolly.";

7. Загрузка JavaScript в HTML

Используйте простой синтаксис для загрузки внешних скриптов (атрибут Type не нужен):

<script src="myscript.js"></script>

Язык Java

1. Именование переменных, классов и интерфейсов

Рекомендуется использовать одно объявление на строку, так как это облегчает комментирование.

int level;

int size;

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

    int    level;    // уровень отступа
    int    size;    // размер таблицы
    Object    currentEntry; // текущий выделенный экземпляр таблицы

2. Объявление классов и интерфейсов

Методы должны быть сгруппированы по функциональности, а не по области или доступности. Для примера метод класса private может находиться между двумя public методами экземпляра.

3. Оформление кода

Размещайте объявления только в начале блоков (блоком является любой код, заключенный в фигурные скобки "{" и "}"). Не ждите объявления переменных до их первого использования; void MyMethod() { int int1; if (условие) { int int2; ... } }

Единственным исключением являются индексы циклов for, которые в Java могут быть объявлены в операторе for:

for (int i = 0; i < maxLoops; i++) { ...

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

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

При написании Java классов и интерфейсов необходимо соблюдать следующие правила форматирования:

• не ставьте пробел между именем метода и скобкой "(" внутри которой указывается список его параметров;

• открывающая скобка "{" ставится в конце той же строки, где указан оператор объявления класса или интерфейса;

• закрывающая скобка "}" ставится на отдельной строке с тем же отступом, что и у соответствующего ему открывающего оператора, кроме случаев, когда имеем пустой оператор, то "}" должна появиться сразу после "{" class Sample extends Object { int ivar1; int ivar2;

  Sample(int i, int j) {
    ivar1 = i;
    ivar2 = j;
  }
  
  int emptyMethod() {}
  
  ...
  

  }

• между методами должна быть одна пустая строка.

В качестве единицы отступов следует использовать 4 пробела. Табуляция должна быть установлена ровно каждые 8 пробелов (а не 4). Избегайте строк длиннее 80 символов.

Если выражение не помещается на одной строке, разбейте его в соответствии со следующими принципами:

• перенос осуществляется после запятой;
• перенос осуществляется перед оператором;
• предпочитайте переносы более высокого уровня для переноса нижнего уровня (вложенном уровне);
• выравнивайте новую строку выражения так, чтобы его начало было на том же уровне, как и в предыдущей строке;
• если приведенные выше правила приводят к запутанному (плохо читающемуся) коду или коду, который сжимается с правым краем, просто введите 8 пробелов вместо этого.

Пример: function(longExpression1, longExpression2, longExpression3, longExpression4, longExpression5);

var = function1(longExpression1,
        function2(longExpression2,
            longExpression3));

longName1 = longName2 * (longName3 + longName4 - longName5)
      + 4 * longname6;

Отступы в строках с оператором if следует применить по правилу 8 пробелов, так как если использовать стандартные 4 пробела, то поиск тела оператора будет затруднителен.

Пример: if ((condition1 && condition2) || (condition3 && condition4) ||!(condition5 && condition6)) { doSomethingAboutIt(); }

Способы форматирования тернарных выражений: alpha = (aLongBooleanExpression) ? beta : gamma; alpha = (aLongBooleanExpression) ? beta : gamma; alpha = (aLongBooleanExpression) ? beta : gamma;

4. Организация файлов

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

5. Файлы с исходным кодом Java

Каждый файл с исходным кодом Java содержит один class с ключевым словом public или интерфейс. Когда классы с ключевым словом private и интерфейсы связанны с public-классом, то их можно поместить в тот же файл с исходным кодом, что и public-класс. Класс с ключевым словом public должен быть размещен как первый класс или интерфейс в файле.

Файлы с исходным кодом Java имеют следующий порядок:

Начальный комментарий

Операторы package и import

Объявления классов и интерфейсов

6. Начальный комментарий

Все файлы с исходным кодом должны начинаться с комментария в стиле языка C, в котором перечислены авторы программы, дата, сведения об авторских правах, а также краткое описание того, что делает программа. Например:

/*

• Имя класса

*

• Информация о версии

*

• Информация об авторском праве

*/

7. Операторы

7.1 Простые операторы

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

7.2 Составные операторы

Составные операторы — это операторы, содержащие списки операторов, заключенные в фигурные скобки «{ операторы }». Вложенные операторы должны иметь отступ на один уровень больше, чем составной оператор. Открывающая скобка должна быть в конце той строки, с которой начинается составной оператор; закрывающая скобка должна начинаться с новой строки и с отступом, соответствующим началу составного оператора.

Скобки используются во всех операторах, даже в одиночных, когда они входят в состав управляющей структуры, таких, как оператор if-else или for. Это необходимо, чтобы избежать ошибок в случае добавления новых операторов, когда забыли указать фигурные скобки (если фигурных скобок нет, то управляющая конструкция типа if будет выполнять только одну строку после нее до знака «;»).

7.3 Оператор return

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

Например:

return;

return myDisk.size();

return (size ? size : defaultSize);

7.4 Операторы if, if-else, if-else-if-else

Операторы if всегда должны использоваться с фигурными скобками «{ }».

Группа операторов (как и единичное использование) if-else должна иметь следующий вид: if (условие) { операторы; }

if (условие) {
  операторы;
} else {
  операторы;
}

if (условие) {
  операторы;
} else if (условие) {
  операторы;
} else if (условие) {
  операторы;
}

7.5 Оператор цикла for

Оператор цикла for должен иметь следующий вид: for (инициализация; условие; итерация) { операторы; }

Пустой оператор цикла for (тот, в котором вся работа выполняется в инициализации, условии и итерации) должен иметь следующий вид:

for (инициализация; условие; итерация);

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

7.6 Оператор цикла while

Оператор цикла while должен иметь следующий вид: while (условие) { операторы; }

Пустой оператор цикла while должен иметь следующий вид:

while (условие)

7.7 Оператор цикла do-while

Оператор цикла do-while должен иметь следующий вид: do { операторы; } while (условие)

7.8 Оператор switch

Оператор switch должен иметь следующую форму: switch (условие) { case ABC: операторы;

  /* провал */<br>
case DEF:<br>
  операторы;

  break;

case XYZ:
  операторы;
  break;
default:
  операторы;
  break;
}

Каждый раз, когда выбор проваливается (не включая оператор break), добавьте комментарий, где обычно находится оператор break. Это показано в предыдущем примере кода с комментарием /* провал */.

Каждый оператор switch должен включать выбор по умолчанию (default). Оператор break в выборе по умолчанию лишний, но он предотвращает возникновение ошибки, если позже еще один выбор добавится.

7.9 Оператор try-catch

Оператор try-catch должен иметь следующий формат: try { операторы; } catch (ExceptionClass e) { операторы; }

8. Отступы

8.1 Пустые строки

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

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

• между секциями в файле исходного кода;
• между определениями классов и интерфейсов.

Одна пустая строка всегда должна использоваться в следующих случаях:

• между методами;
• между локальными переменными метода и его первым оператором;
• перед блочным или однострочным комментарием;
• между логическими участками кода внутри метода для улучшения читабельности.

8.2 Расстановка пробелов

Разделяющие пробелы должны ставиться при следующих обстоятельствах.

• Ключевое слово, за которым следует скобка, должны быть разделены пробелом. Например: while (true) { ... }

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

• Разделяющий пробел должен появляться после запятой в списке аргументов.

• Все бинарные операторы кроме «.» должны быть отделены от своих операндов пробелами. Пробелом никогда не должны разделяться операнды и их унарные операторы, такие как унарный минус, инкремент («++») и декремент «--») от их операндов. Например: a += c + d; a = (a + b) / (c * d);

  while (d++ = s++) { n++; } prints(«size is» + foo + «\n»).

• Выражения в операторе цикла for должны быть разделены пробелами. Например:

for (expr1; expr2; expr3)

• За приведением типа должен следовать пробел. Например: myMethod((byte) aNum, (Object) x); myFunc((int) (cp + 5), ((int) (i + 3)) + 1);

Язык разметки документов HTML

1.1 Тип документа

Всегда объявляйте тип документа в качестве первой строки в документе:

Если требуется согласованность с тегами нижнего регистра, можно использовать:

Рекомендуется использовать имена элементов нижнего регистра.

2.1 Закрытие всех элементов HTML

Рекомендуется закрыть все элементы HTML.

3.1 Закрытие пустых элементов HTML

В HTML5 необязательно закрывать пустые элементы.

Разрешены:

Также разрешено:

Однако в XHTML и XML требуется закрывающая косая черта (/).

4.1 Использовать имена атрибутов нижнего регистра

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

5.1 Атрибуты изображения

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

6.1 Пробелы и знаки равенства

Не ставьте пробелы вокруг знака равенства.

Старайтесь избегать строк кода длиной более 80 символов.

7.1 Пустые строки и отступы

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

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

Для удобочитаемости добавьте 2 пробела отступа. Не используйте клавишу TAB.

Не используйте ненужные пустые строки и отступы. Нет необходимости отступить каждый элемент:

Famous Cities

Tokyo

Tokyo is the capital of Japan, the center of the Greater Tokyo Area,

and the most populous metropolitan area in the world.

It is the seat of the Japanese government and the Imperial Palace,

and the home of the Japanese Imperial Family.

Пример таблицы:

Пример списка:

1. London
2. Paris
3. Tokyo

8.1 Пропуск , ,

Не рекомендуется опускать тег .

Не рекомендуется опускать , , .

Элемент является корнем документа. Это рекомендуемое место для указания языка страницы:

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

Пропуск или может аварийно завершить работу DOM и XML ПО.

Пропуск может привести к ошибкам в старых браузерах (IE9).

9.1 Метаданные

Элемент <title> необходим в HTML5. Сделайте название как можно более осмысленным:

<title>HTML5 Syntax and Coding Style</title>

Чтобы обеспечить правильную интерпретацию и правильную индексацию поисковых систем, как язык, так и кодировка символов должны быть определены как можно раньше в документе: <title>HTML5 Syntax and Coding Style</title>

10.1 Комментарии в формате HTML

Краткие комментарии должны быть написаны на одной строке, как это:

Комментарии, охватывающие более одной строки, должны быть написаны так:

Длинные комментарии легче заметить, если они имеют отступ двух пробелов.

11.1 Таблицы стилей

Используйте простой синтаксис для связывания с таблицами стилей (атрибут Type не требуется):

Короткие правила могут быть записаны сжатыми на одной строке:

p.intro {font-family: Verdana; font-size: 16em;}

Длинные правила должны быть написаны на несколько строк: body { background-color: lightgrey; font-family: «Arial Black», Helvetica, sans-serif; font-size: 16em; color: black; }

• поместите открывающую скобку на ту же линию, что и селектор;

12.1 Загрузка JavaScript в HTML

Приложение № 4

РЕКОМЕНДУЕМЫЙ СПИСОК ЭЛЕМЕНТОВ КОНФИГУРАЦИИ РАЗРАБАТЫВАЕМОГО ПО

1. Программа (дистрибутив программы) и эталонные конфигурации.

2. Рекомендуемые схемы размещения элементов ПО для сред его функционирования (диаграммы развертывания).

3. Инструкция по установке ПО и его компонентов.

4. Руководство по обеспечению безопасности.

5. Программные и эксплуатационные документы.

6. Исходный код программы.

7. Среда функционирования и развертывания для разрабатываемого ПО.

8. Любая информация об изменениях элементов конфигурации, включая обновления ПО и устранения уязвимостей.

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

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

11. Безопасные, тестовые, технологические конфигурации ПО (например, файлы cfg, ini или описание этих настроек для каждого сценария).

12. Документация на систему управления конфигурацией и ее элементы.

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

14. Средства разработки и их опции, применяемых при разработке конкретного экземпляра ПО.

Дополнительно в список элементов конфигурации рекомендуется включать следующее:

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

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

документ, содержащий сведения о проекте архитектуры программы;

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

документ, содержащий информацию о прослеживаемости исходного кода программы к проекту архитектуры программы;

документ, содержащий порядок оформления исходного кода программы;

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

документ, содержащий сведения о результатах проведения экспертизы исходного кода программы;

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

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

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

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

документ, содержащий описание процедуры передачи ПО Заказчику;

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

документ, содержащий описание процедуры поиска Разработчиком ПО уязвимостей программы;

документ, описывающий реализацию и использование процедуры уникальной маркировки каждой версии ПО;

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

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

документ, содержащий сведения об обучении работников.

Вложения

• 825723.PDF