Инструкция по сборке программного обеспечения гост - Большая энциклопедия инструкций и руководств

Опыт применения ЕСПД

Время на прочтение
11 мин

Количество просмотров 85K

Введение

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

В свое время, когда я только начинал работать программистом, часто приходилось слышать “напиши, пожалуйста, документацию к своей программе”. Я честно все описывал, отдавал начальнику, после чего начинался сеанс черной магии. Начальник через некоторое время меня вызывал и начинал мычать нечленораздельные звуки, мять распечатку моего “самого лучшего” текста в руках, бегая глазами. Общий смысл его мычания заключался в том, что получилось “не то”, “не так”, и “посмотри, как делают другие”. Так как никакого другого ответа из него вытянуть было невозможно, я шел за примерами документов к “другим”. Как правило, это были веселые ребята, смысл речей которых заключался в том, что “вот примеры”, “вообще то по ГОСТу” и “это все никому не нужно”. Так я узнал впервые, что программист может соприкоснуться со страшными ГОСТами.
Поразительно, что среди многих десятков моих коллег, очень неглупых программистов, не было никого, кто бы относился к ГОСТам по другому. Даже те несколько человек, которые их знали и, вроде как, даже умели оформлять документы, относились к ним презрительно-формально. Ситуация, когда даже люди, ответственные за управление разработкой не понимают, зачем нужны ГОСТы и как их применят, встречается на многих предприятиях, сплошь и рядом. Да, были и компании, в которых понимали, чем “Описание программы” отличается от “Описания применения”, но таких было явное меньшинство. В интернете вообще господствует точка зрения, что ГОСТы для программистов — это явный рудимент, и нужны только если “нагибают” под них. Эскизный проект считают “сравнительно честным способом отъемы лишних дензнаков у заказчика”. Вникнуть и разобраться пришлось относительно недавно — в процессе разработки системы управления требованиями, заточенной под отечественную специфику. Документацию которая, разумеется, должна генерировать “по ГОСТу”.

Здесь я хочу сосредоточиться только на одной теме, с которой приходиться иметь дело программисту в отечественных предприятиях, особенно в НИИ — на наборе стандартов ЕСПД. Не считаю себя большим знатоком ЕСПД — есть люди, которые десятки лет по нему работают, и наверняка меня поправят. Статья скорее пытается набросать контуры «дорожной карты» для тех, кто только входит в курс дела.

Стандарты

Рассмотрим кратко, какие бывают стандарты (фокусируясь на ИТ-области).

международные. Отличительный признак — принят международной организацией. Пример такой организации — ISO (международная организация стандартизации). Пример её стандарта: ISO 2382-12:1988 (Переферийное оборудование). Распространены совместные стандарты ISO и международной электротехнической комиссии(IEC, в по русски — МЭК): например, ISO/IEC 12207:2008 (жизненный цикл ПО);
региональные. Отличительный признак — принят региональной комиссией по стандартизации. К примеру, многие советские ГОСТы сейчас являются региональным стандартом, т.к. приняты межгосударственным советом, куда входят некоторые бывшие советские республики. Этим советом принимаются и новые стандарты — и они тоже получают обозначение ГОСТ. Пример: ГОСТ 12.4.240-2013;
стандарты общественных объединений; К примеру, той же МЭК: IEC 60255;
национальные стандарты. Для России в начале таких стандартов — “ГОСТ Р”. Могут быть трех типов:
1. точные копии международных или региональных. Обозначаются неотличимо от “самописных” (национальных, написанных самостоятельно);
2. копии международных или региональных с дополнениями. Обозначаются добавлением к шифру отечественного стандарта шифра международного, который был взят за основу. Например: ГОСТ Р ИСО/МЭК 12207;
3. собственно, национальные стандарты. Например, ГОСТ Р 34.11-94.

Системы обозначений на каждом уровне и в каждой организации свои, для каждого случая придется разбираться отдельно. Чтобы быстро понять, “чей” стандарт перед глазами, можно использовать шпаргалку.

ГОСТ

Итак: стандарты бывают международные, межгосударственные(региональные) и национальные. ГОСТ, как мы выяснили, это региональный стандарт. ГОСТы имеют достаточно запутанную, на мой взгляд, систему обозначений. Полностью она изложена в ГОСТ Р 1.5-2004, я приведу минимум, что бы в ней ориентироваться. Во первых, надо различать обозначение ГОСТа и его классификацию. Обозначение — это, грубо говоря, уникальный идентификатор стандарта. Код по классификатору — это вспомогательный код, помогающий найти стандарт или определить, к какой области знаний он относиться. Классификаторов может быть много, в основном используются два: КГС (классификатор государственных стандартов) и его наследник ОКС (общероссийский классификатор стандартов). Например: “ГОСТ Р 50628—2000“ — это обозначение стандарта.По обозначению понятно только то, что он принят в 2000 году. Он имеет код по ОКС “33.100;35.160”: т.е. “33” — раздел “Телекоммуникации, аудио, видео”, “100” — подраздел “электромагнитная совместимость”. Однако он также входит в ветвь классификатора 35.160. “35” — “Информационные технологии. Машины конторские”, “160” — “Микропроцессорные системы….”. А по КГС он имеет код “Э02”, что означает “Э” — “Электронная техника, радиоэлектроника и связь”, “0” — “Общие правила и нормы по электронной технике, радиоэлектронике и связи”, и т.д.

Если известно обозначение стандарта, то получить его коды по КГС и ОКС можно, к примеру, на вот этом толковом сайте.
Итак, вернемся к обозначениям ГОСТов. Их может быть два варианта:

стандарт относиться к серии стандартов. В этом случае после индекса категории стандарта (например, ГОСТ, ГОСТ Р или ГОСТ РВ) идет код серии, точка и обозначение стандарта внутри серии. Правила обозначения стандартов внутри серии устанавливаются правилами серии. Например: ГОСТ РВ 15.201-2000, ГОСТ Р 22.8.0-99, ГОСТ 19.101-77;
стандарт не относиться к серии стандартов. Тогда после индекса категории идет просто порядковый номер стандарта, тире и год принятия. Например, ГОСТ Р 50628—2000.

Итак, если совсем просто — то обозначение ГОСТа — это либо просто порядковый номер, тире, год, либо номер серии, точка и дальше в зависимости от серии. В реальности все сложнее ( к примеру, можно встретить что то типа ГОСТ 11326.19-79, и это будет вовсе не серия 11326 — но программистам такое нужно очень редко. За подробностями — в ГОСТ Р 1.5-2004).

ЕСПД

ЕСПД — одна из таких серий ГОСТов, номер 19. Т.е. все стандарты, относящиеся к ЕСПД, начинаются с префикса “19.”: например, ГОСТ 19.106-78. Расшифровывается как “Единая система программной документации”. Существуют и другие серии:

ГОСТ ЕСКД (единая система конструкторской документации, префикс “2.”);
ГОСТ ЕСТД (единая система технологической документации, префикс “3.”);
ГОСТ Р, Система разработки и постановки продукции на производство, префикс “15.”;
ГОСТ РВ, Вооружение и военная техника. Система разработки и постановки продукции на производство, префикс “15.”;
ГОСТ, Система технической документации на АСУ, префикс “24.”;
ГОСТ, Комплекс стандартов на автоматизированные системы, префикс “34.”.

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

19.001-77. Общие положения

Описывает правила присвоения обозначений стандартов в серии ЕСПД. В практической жизни не нужен.

19.102-80. Схемы алгоритмов и программ. Правила выполнения.

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

19.003-80. Схемы алгоритмов и программ. Обозначения условные графические

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

19.004-80. Термины и определения.

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

19.005-85. Р-схемы алгоритмов и программ

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

19.101-77. Виды программ и программных документов

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

19.102-77. Стадии разработки

Важный и нужный стандарт, в котором описаны виды документов и приведены коды видов программных документов. Этот стандарт (совместно с 19.103-77) является одним из ключей к “разгадке” обозначений документов подобных АБВГ.10473-01 32 01-1.
В стандарте вводится понятие комплекса и компонента (на ряде предприятий добавляют третий вид — комплект, когда речь идет о несвязанных программных элементах), дается разделение: какие документы эксплуатационные, какие нет.
Следует аккуратно относиться к таблице 4, в которой показано, какой документ на какой стадии разработки выполняется. Стадии разработки обычно регламентируются в стандартах на выполнения ОКР, и там-же указывается, какие документы нужно предъявлять заказчику на каждом этапе.

19.102-77. Стадии разработки

На моей памяти этот стандарт не применялся ни разу: кто что делает на каком этапе и чем отчитывается прописывается в ТТЗ или делается отсылка к ГОСТам, где это прописано более четко (например, ГОСТ РВ 15.203). При этом для новичка он содержит неплохой в своей лаконичности конспект работ на основных этапах ОКР.

19.103-77. Обозначения программ и программных документов

Нужен, в основном, для того, что бы научиться читать обозначения документов подобных приведенному выше. Однако понимание схемы обозначений полезно в случае, когда приходиться выходить за рамки типовых работ: к примеру, помнить, что документы с кодами после 90 — пользовательские, т.е. любые. В моей практике мы выпускали документ 93, который назвали “Ведомость программной документации”, 96 документ — “Инструкция по сборке”.
Распространенное словосочетание “вариант исполнения” в ЕСПД отсутствует, и заменяется “номером редакции”. С одной стороны, это не совсем корректно: номер редакции задумывался для отслеживания эволюции программы: вначале выходит первая редакция, потом, к примеру, после доработки — вторая. Но на практике, когда нужно выпустить версию ПО для нескольких операционных систем (кросс-платформенное ПО), другого выхода нет. Точнее — есть, но неправильный: присвоить версии для каждой операционки свое обозначение — и закладывать в архив несколько дисков с исходниками (по числу операционок), разрабатывать (фактически — копировать) весь комплект документации и т.д… Т.е. чистой воды бестолковая и сбивающая с толку деятельность. Решение в виде присвоения версии под каждую операционку своего номера редакции позволяет часть документов сделать общими.
В ЕСПД используется смущающее многих программистов обозначение исходных текстов программы и результата сборки “документами”. Документ “текст программы”, согласно 19.101-77, имеет обозначение 12. Дальше принято, что исходники обозначаются как 12 01 — т.е. 01(первый) документ вида 12, а бинарники — как 12 02 — т.е. второй документ вида 12. В ряде случаев для сборки программы требуются дополнительные инструментальные средства — компиляторы, генераторы инсталляторов и т.д. Т.е. программы, которые не входят в поставку, но нужны для сборки. Решением может быть их обозначение как 12 03 — т.е. третий документ вида 12.

19.104-78. Основные надписи

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

как было уже сказано, часто предприятие не хочет раскрывать информацию о разработчике. Отделение ЛУ и его “зажатие” позволяет это сделать (штампа, в отличии от ЕСКД, в ЕСПД на листах документа нет, вся информация локализована только в ЛУ);
на ряде предприятий используется смешанный документооборот: подлинники документов хранятся в электронном виде в архиве предприятия, а ЛУ на них (с оригиналами подписей) — в бумажном;

Что касается оформления ЛУ, то сплошь и рядом на предприятиях используется смесь — часть надписей ЛУ оформляется по ЕСПД, часть — по ЕСКД, а часть — по своему. Поэтому лучше всего прежде, чем делать ЛУ самому, поискать, нет ли стандарта предприятия (СТО), или взять пример у местного нормоконтроля.
Также следует помнить, что ЛУ не нумеруется, и первый лист — титульный, а первый лист, на котором ставится номер — следующий за титульным. Но в том случае, если ЛУ больше одного (это бывает, если все подписи не влезли на лист), то ЛУ нумеруются отдельно.

19.105-78. Общие требования к программным документам

Вводится общая структура документа, не зависящая от способа его исполнения. Т.е. еще в 1978 году было заложено в стандарт, что документ может быть не обязательно бумажным. В частности, вводиться понятие содержания для полностью электронных документов. Для бумажного исполнения, распространенного в то время, был принят ГОСТ 19.106-78.
В настоящее время к этому стандарту приходиться обращаться очень редко: разве что забывается порядок следования основных частей документа.

19.106-78. Общие требования к программным документам, выполненным печатным способом

Самый объемный стандарт из ЕСПД, уступающий разве что описанию R-схем. Является основным рабочим стандартом при оформлении документации. Вводит правила оформления текста, элементов структуры документа, изображений, формул и т.д. Однако в отличии от соответствующего 2.106 из ЕСКД, 19.106 существенно менее подробный, что приводит к многочисленным неопределенностям.
Во первых, стандарт фактически не определяет межстрочное расстояние и величину вертикальных отступов между заголовками. Он вводит три правила определения интервала: для машинописного текста, машинного и типографского.
Машинописный текст — это текст, набранный на печатной машинке. Смещение следующей строки относительно предыдущей производилось автоматически при так называемом «переводе каретки» — переходе к печати следующей строки, производимым перемещением специального рычага. Как правило, интервал мог быть вручную скорректирован поворотом вала протяжки бумаги, и имел “настройку”, позволяющую задать величину интервала — одинарный или двойной.
Машинный — это, скорее всего, и есть распечатанный текст. Но для него есть только указание, что результат должен быть пригоден для микрофильмирования. Это неявная ссылка на 13.1.002-2003, в котором, к сожалению, задается межстрочный интервал (и, кстати, минимальная высота шрифта) только для рукописных документов (п.4.2.5).
Типографский — текст, набранный в типографии. Учитывая год принятия стандарта, скорее всего речь идет о
[высокой печати, где межстрочный интервал определялся используемыми литерами. Я не специалист в типографском деле, а информации о методах набора сейчас очень мало.
Какой интервал использовать в итоге часто определяется местным нормоконтролем или СТО. Типичные значения — полуторный интервал и 14 размер шрифта.
Часто вызывает много вопросов способ структурирования документа. 19.106 считает, что весь документ делится на разделы, подразделы, пункты и подпункты. У всех них (кроме раздела и подраздела) заголовок может быть и или не быть. При этом:

“в содержание документа включают номер разделов, подразделов, пунктов и подпунктов, имеющих заголовок” (п. 2.1.4). Это прямое указание на то, что подпункт может иметь заголовок и включаться в оглавление;
“допускается помещать текст между заголовками раздела и подраздела, между заголовками подраздела и пункта”. Важно обратить внимание, что ненумерованный текст может быть только между заголовками, и только на верхних 2х уровнях.

В отличии от ЕСКД, в ЕСПД принят странный способ оформления рисунков: сначала идет название рисунка, потом сам рисунок, потом опциональный “подрисуночный текст”, и потом, на новой строке, “Рис. N”.
Этот стандарт имеет ряд “дыр”, недостказанностей. К примеру, сказано: “иллюстрации, если их в данном документе более одной, нумеруют арабскими цифрами в пределах всего документа. “ Но если иллюстрация одна, то она ненумерованная, и как тогда на нее ссылаться? Аналогично и для таблиц. Для сносок ГОСТ не указывает способ их нумерации — в пределах всего документа или в пределах страницы.
Таблицы. В самом документе дана ссылка на ГОСТ 1.5.68. Судя по первой серии, несложно заключить, что это стандарт на разработку стандартов. Причем тут он, неясно. По смыслу он соответствует правилам оформления таблиц в ЕСКД, с небольшими исключениями. Этот стандарт был отменен, взамен веден, через несколько итераций, 1.5-2012, в котором правила оформления таблицы… просто исчезли. Еще в 1.5-2002 были, а уже в 1.5-2004 исчезли. В реальной жизни мы оформляем таблицы согласно ЕСКД.
Приложения. Стандарт не указывает, попадают ли рисунки, формулы и таблицы из приложений в общий перечень. Аналогично не сказано, нужно ли в оглавлении раскрывать структуру приложения, если оно содержит свои разделы, пункты и т.д. В нашей практике мы не раскрываем внутренности приложений.
Наконец, следует сказать об отступах. Абзацный отступ, равный 5 символам, является общим для:

красной строки;
отступа элемента структуры документа после раздела (подраздел, пункт, подпункт);
элемент перечисления.

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

В следующих частях планирую уже добраться до конца списка стандартов ЕСПД.

Источник

ГОСТ Р 56939-2016

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Защита информации

РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Общие требования

Information protection. Secure software development. General requirements

ОКС 35.020

Дата введения 2017-06-01

Предисловие

1 РАЗРАБОТАН Закрытым акционерным обществом «Научно-производственное объединение «Эшелон» (ЗАО «НПО «Эшелон»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 «Защита информации»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ

приказом Федерального агентства по техническому регулированию и метрологии от 1 июня 2016 г. N 458-ст

4 ВВЕДЕН ВПЕРВЫЕ

5ПЕРЕИЗДАНИЕ. Октябрь 2018 г.

Правила применения настоящего стандарта установлены в

статье 26 Федерального закона от 29 июня 2015 г N 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

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

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

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

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

ГОСТ Р ИСО/МЭК 27034-1 . Настоящий стандарт можно использовать для конкретизации или расширения компонентов доверия из

ГОСТ Р ИСО/МЭК 15408-3 .

2 Нормативные ссылки

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

ГОСТ 2.001 Единая система конструкторской документации. Общие положения

ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов

ГОСТ 19.201 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

ГОСТ 19.402 Единая система программной документации. Описание программы

ГОСТ 19.404 Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению

ГОСТ Р ИСО/МЭК 15408-1- Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель

ГОСТ Р ИСО/МЭК 15408-2 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности

ГОСТ Р ИСО/МЭК 15408-3 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности

ГОСТ Р ИСО 10007 Менеджмент организации. Руководящие указания по управлению конфигурацией

ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

ГОСТ Р ИСО/МЭК 27001 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования

ГОСТ Р ИСО/МЭК 27034-1 Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия

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

3 Термины и определения

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

3.1

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

[

ГОСТ Р 50922-2006 ,

статья 2.4.5 ]

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

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

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

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

3.5

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

[

ГОСТ Р 51904-2002 ,

статья 3.17 ]

3.6

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

[

ГОСТ Р 51275-2006 ,

статья 3.11 ]

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

3.8 объект среды разработки программного обеспечения: Аппаратные средства, программы, программно-аппаратные средства и документы, используемые разработчиком для разработки программного обеспечения.

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

3.10

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

[

ГОСТ 19781-90 , статья 1]

3.11

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

[

ГОСТ 19781-90 , статья 2]

3.12

сетевая атака: Компьютерная атака с использованием протоколов межсетевого взаимодействия.

[

ГОСТ Р 51275-2006 ,

статья 3.12 ]

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

Примечание — Адаптировано из

ГОСТ Р ИСО/МЭК 15408-1 .

3.14

среда разработки программного обеспечения: Интегрированная система, включающая в себя аппаратные средства, программное обеспечение, программно-аппаратные средства, процедуры и документы, необходимые для разработки программного обеспечения.

[

ГОСТ Р 51904-2002 ,

статья 3.62 ]

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

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

3.17

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

[

ГОСТ Р 50922-2006 ,

статья 2.6.1 ]

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

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

ГОСТ Р ИСО 10007 .

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

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

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

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

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

3.23 электронный документ: Документ, выполненный программно-техническим средством на электронном носителе.

Примечание — Адаптировано из

ГОСТ 2.001 .

3.24

элемент конфигурации: Объект конфигурации, выполняющий законченную функцию.

[

ГОСТ Р ИСО 10007-2007 ,

статья 3.5 ]

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

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

ГОСТ Р ИСО/МЭК 12207 .

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

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

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

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

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

4.6 Если разработчик ПО планирует проведение оценки ПО в соответствии с

ГОСТ Р ИСО/МЭК 15408-1 ,

ГОСТ Р ИСО/МЭК 15408-2 ,

ГОСТ Р ИСО/МЭК 15408-3 , то подготовку ПО к оценке можно осуществлять в рамках действующих процессов, в которых реализованы меры по разработке безопасного ПО, путем выполнения дополнительных мер. В таблице А.1 приложения А отображена взаимосвязь мер по разработке безопасного ПО, установленных настоящим стандартом, и требований доверия к безопасности по

ГОСТ Р ИСО/МЭК 15408-3 , которую можно использовать при подготовке ПО к оценке по

ГОСТ Р ИСО/МЭК 15408-1 ,

ГОСТ Р ИСО/МЭК 15408-2 ,

ГОСТ Р ИСО/МЭК 15408-3 .

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

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

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

— несоответствий, выявленных в ходе внутренних проверок;

— изменения целей разработчика ПО в области разработки безопасного ПО.

4.10 Разработчик ПО должен создать руководство по разработке безопасного ПО, содержащее:

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

— цели организации в области создания безопасного ПО;

— перечень и описание мер по разработке безопасного ПО, подлежащих реализации в среде разработки ПО;

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

— перечень документации разработчика ПО, связанной с реализацией мер по разработке безопасного ПО;

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

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

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

— изложение причин исключения меры (мер) по разработке безопасного ПО;

— описание содержания компенсирующих мер по разработке безопасного ПО;

— сравнительный анализ компенсирующих мер по разработке безопасного ПО с мерами, исключаемыми из состава базового набора мер по разработке безопасного ПО;

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

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

— выявленными в ходе внутренних проверок несоответствиями;

— изменениями целей разработчика ПО в области разработки безопасного ПО.

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

— на организацию работ по созданию безопасного ПО, выполняемых в рамках процессов жизненного цикла ПО;

— подтверждение соответствия требованиям настоящего стандарта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Меры по разработке безопасного программного обеспечения

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

5.1.1 Мера по разработке безопасного программного обеспечения, подлежащая реализации

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

5.1.2 Цели и результаты реализации мер по разработке безопасного программного обеспечения

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

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

5.1.3 Требования к реализации мер по разработке безопасного программного обеспечения

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

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

— к обеспечению идентификации и аутентификации;

— обеспечению защиты от несанкционированного доступа к информации;

— обеспечению регистрации событий;

— контролю точности, полноты и правильности данных, поступающих в программу;

— обработке программных ошибок и исключительных ситуаций.

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

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

ГОСТ Р ИСО/МЭК 15408-3 .

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

5.2.1 Меры по разработке безопасного программного обеспечения, подлежащие реализации

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

— моделирование угроз безопасности информации;

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

5.2.2 Цели и результаты реализации мер по разработке безопасного программного обеспечения

Реализация мер способствует достижению следующих целей:

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

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

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

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

— проект архитектуры программы разрабатывают с учетом необходимости выполнения требований по безопасности, предъявляемых к разрабатываемому ПО;

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

5.2.3 Требования к реализации мер по разработке безопасного программного обеспечения

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

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

— список выявленных потенциальных угроз безопасности информации (при выявлении);

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

Примечание — Входными данными для процесса моделирования угроз безопасности информации являются в первую очередь сведения о проекте архитектуры программы (предполагаемых компонентах программы, их интерфейсах и концепции их совместного выполнения), в том числе информация о заимствованных у сторонних разработчиков ПО компонентах и информация из открытых источников [например, из банка данных угроз безопасности информации Федеральной службы по техническому и экспортному контролю (ФСТЭК России)], связанная с типовыми сценариями компьютерных атак и угрозами безопасности информации. Моделирование угроз безопасности информации выполняют с целью выявления потенциальных угроз безопасности информации, которые могут возникнуть вследствие применения ПО, связанных с ее проектными (архитектурными) особенностями на ранней стадии разработки (до начала выполнения процессов конструирования и комплексирования ПО) и уточнения проекта архитектуры программы без доработки исходного кода программы.

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

Примечание — Проект архитектуры программы может быть представлен в описании программы (

ГОСТ 19.402 ) и пояснительной записке (

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

ГОСТ Р ИСО/МЭК 15408-3 .

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

5.3.1 Меры по разработке безопасного программного обеспечения, подлежащие реализации

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

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

— создание программы на основе уточненного проекта архитектуры программы;

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

— статический анализ исходного кода программы;

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

5.3.2 Цели и результаты реализации мер по разработке безопасного программного обеспечения

Реализация мер способствует достижению следующих целей:

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

— выявление и удаление недостатков программы (потенциально уязвимых конструкций) в исходном коде программы;

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

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

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

— в исходном коде программы должны быть выявлены и устранены недостатки программы (потенциально уязвимые конструкции);

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

5.3.3 Требования к реализации мер по разработке безопасного программного обеспечения

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

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

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

— наименование разработчика инструментального средства;

— ссылку на эксплуатационные документы инструментального средства;

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

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

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

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

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

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

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

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

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

— сведения о периодичности проведения статического анализа исходного кода программы;

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

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

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

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

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

— сведения о периодичности проведения экспертизы исходного кода программы;

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

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

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

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

5.4.1 Меры по разработке безопасного программного обеспечения, подлежащие реализации

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

— функциональное тестирование программы;

— тестирование на проникновение;

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

— фаззинг-тестирование программы.

5.4.2 Цели и результаты реализации мер по разработке безопасного программного обеспечения

Реализация мер способствует достижению следующих целей:

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

— устранение уязвимостей программы.

В результате успешной реализации мер должны быть:

— проведены и документально оформлены результаты тестирования ПО и список выявленных несоответствий требованиям безопасности и/или уязвимостей программы (при наличии);

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

5.4.3 Требования к реализации мер по разработке безопасного программного обеспечения

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

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

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

— фактические результаты тестирования;

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

Примечание — Выполняемые тесты должны учитывать состав требований к разрабатываемому ПО и обеспечивать наиболее полную проверку этих требований. Описание плана тестирования и выполняемых тестов можно выполнять непосредственно после формулирования требований к ПО, не дожидаясь окончания разработки. Для эффективного тестирования рекомендуется разделять между специалистами обязанности по созданию программы и ее функциональному тестированию. При наличии в программе функциональных возможностей, обеспечивающих реализацию мер защиты информации, документацию разработчика ПО следует разрабатывать в соответствии с требованиями семейств ATE_COV «Покрытие», ATE_DPT «Глубина», ATE_FUN «Функциональное тестирование» по

ГОСТ Р ИСО/МЭК 15408-3 .

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

— проекта архитектуры программы, в том числе информации о заимствованных у сторонних разработчиков ПО компонентах;

— результатов моделирования угроз безопасности информации (перечень выявленных потенциальных угроз безопасности информации);

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

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

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

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

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

— фактические результаты тестирования на проникновение;

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

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

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

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

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

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

— сведения о периодичности проведения динамического анализа кода программы;

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

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

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

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

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

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

— сведения о периодичности проведения фаззинг-тестирования программы;

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

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

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

5.5.1 Меры по разработке безопасного программного обеспечения, подлежащие реализации

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

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

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

5.5.2 Цели и результаты реализации мер по разработке безопасного программного обеспечения

Реализация мер способствует достижению следующих целей:

— обеспечение соответствия экземпляра ПО, переданного разработчиком, и экземпляра ПО, полученного пользователем;

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

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

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

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

5.5.3 Требования к реализации мер по разработке безопасного программного обеспечения

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

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

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

ГОСТ Р ИСО/МЭК 15408-3 .

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

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

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

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

ГОСТ Р ИСО/МЭК 15408-3 .

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

5.6.1 Меры по разработке безопасного программного обеспечения, подлежащие реализации

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

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

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

5.6.2 Цели и результаты реализации мер по разработке безопасного программного обеспечения

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

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

5.6.3 Требования к реализации мер по разработке безопасного программного обеспечения

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

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

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

— описание методов приема и обработки сообщений от пользователей об ошибках ПО и уязвимостях программы;

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

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

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

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

ГОСТ Р ИСО/МЭК 15408-3 .

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

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

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

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

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

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

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

— статического анализа кода программы;

— экспертизы исходного кода программы;

— функционального тестирования программы,

— тестирования на проникновение;

— динамического анализа кода программы;

— фаззинг-тестирования программы.

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

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

— сведения о периодичности проведения поиска уязвимостей программы;

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

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

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

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

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

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

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

5.7.1 Меры по разработке безопасного программного обеспечения, подлежащие реализации

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

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

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

5.7.2 Цели и результаты реализации мер по разработке безопасного программного обеспечения

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

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

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

— контролируют целостность определенных элементов конфигурации.

5.7.3 Требования к реализации мер по разработке безопасного программного обеспечения

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

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

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

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

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

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

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

— программа (дистрибутив программы);

— программные и эксплуатационные документы;

— исходный код программы;

— программные и загрузочные модули, в том числе модули сторонних разработчиков ПО;

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

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

— перечень выявленных уязвимостей программы.

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

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

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

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

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

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

5.8.1 Меры по разработке безопасного программного обеспечения, подлежащие реализации

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

— защита от несанкционированного доступа к элементам конфигурации;

— резервное копирование элементов конфигурации;

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

5.8.2 Цели и результаты реализации мер по разработке безопасного программного обеспечения

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

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

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

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

5.8.3 Требования к реализации мер по разработке безопасного программного обеспечения

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

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

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

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

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

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

— перечень элементов конфигурации, подлежащих резервному копированию;

— сведения о периодичности резервного копирования;

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

Примечание — Используемые меры направлены на обеспечение конфиденциальности и целостности следующих объектов среды разработки ПО и элементов конфигурации:

— программа (дистрибутив программы);

— программные и эксплуатационные документы;

— исходный код программы;

— программные и загрузочные модули, в том числе модули сторонних разработчиков ПО;

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

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

— перечень выявленных уязвимостей программы.

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

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

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

5.9.1 Меры по разработке безопасного программного обеспечения, подлежащие реализации

В процессе менеджмента людскими ресурсами разработчик ПО должен реализовать следующие меры:

— периодическое обучение сотрудников;

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

5.9.2 Цели и результаты реализации мер по разработке безопасного программного обеспечения

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

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

5.9.3 Требования к реализации мер по разработке безопасного программного обеспечения

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

— правила и программы обучения;

— сведения о периодичности обучения;

— сведения о прохождении сотрудниками обучения.

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

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

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

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

— сведения о корректировке программы обучения сотрудников.

Приложение А

(справочное)

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

ГОСТ Р ИСО/МЭК 15408-3

Таблица А.1 — Взаимосвязь между мерами по разработке безопасного ПО, установленными настоящим стандартом, и требованиями доверия к безопасности по

ГОСТ Р ИСО/МЭК 15408-3


Меры по разработке безопасного программного обеспечения	Семейство (класс) требований доверия к безопасности по ГОСТ Р ИСО/МЭК 15408-3
5.1.3.1	ASE «Оценка задания по безопасности»
5.2.3.1	ADV_ARC «Архитектура безопасности»
5.2.3.2	ADV_FSP «Функциональная спецификация», ADV_TDS «Проект ОО», ADV_ARC «Архитектура безопасности»
5.3.3.1	ALC_TAT «Инструментальные средства и методы»
5.3.3.2	ADV_IMP «Представление реализации»
5.3.3.3	ALC_TAT «Инструментальные средства и методы» (в части ALC_TAT.2)
5.3.3.4	ALC_TAT «Инструментальные средства и методы» ALC_CMC «Возможности управления конфигурацией» (в части ALC_CMC.5)
5.3.3.5	ALC_TAT «Инструментальные средства и методы» (в части ALC_TAT.2), ALC_CMC «Возможности управления конфигурацией» (в части ALC_CMC.5), ALC_CMS «Область управления конфигурацией» (в части ALC_CMS.4)
5.4.3.1	ATE_COV «Покрытие», ATE_DPT «Глубина», ATE_FUN «Функциональное тестирование»
5.4.3.2	AVA_VAN «Анализ уязвимостей»
5.4.3.3	Отсутствует
5.4.3.3	Отсутствует
5.5.3.1	ALC_DEL «Поставка»
5.5.3.2	AGD_OPE «Руководство пользователя по эксплуатации», AGD_PRE «Подготовительные процедуры»
5.6.3.1	ALC_FLR «Устранение недостатков»
5.6.3.2	ALC_FLR «Устранение недостатков» (в части ALC_FLR.2)
5.6.3.3	ALC_FLR «Устранение недостатков» (в части ALC_FLR.2)
5.6.3.4	Отсутствует
5.6.3.5	ALC_TAT «Инструментальные средства и методы», ALC_CMC «Возможности управления конфигурацией», ALC_CMS «Область управления конфигурацией»
5.7.3.1	ALC_CMC «Возможности управления конфигурацией», ALC_CMS «Область управления конфигурацией»
5.7.3.2	ALC_CMC «Возможности управления конфигурацией», ALC_CMS «Область управления конфигурацией»
5.7.3.3	ALC_CMC «Возможности управления конфигурацией»
5.7.3.4	ALC_CMC «Возможности управления конфигурацией»
5.8.3.1	ALC_CMC «Возможности управления конфигурацией»
5.8.3.2	ALC_DVS «Безопасность разработки»
5.8.3.3	ALC_CMC «Возможности управления конфигурацией»
5.9.3.1	Отсутствует
5.9.3.2	Отсутствует


УДК 004.006.354	ОКС 35.020

Ключевые слова: уязвимость программы, безопасное программное обеспечение, требования, защита информации

Источник

Дата введения 2022-01-01

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1 РАЗРАБОТАН Акционерным обществом «Всероссийский научно-исследовательский институт сертификации» (АО «ВНИИС») и Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ)

2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 22 декабря 2020 г. N 58)

За принятие проголосовали:

Краткое наименование страны по МК (ИСО 3166) 004-97	Код страны по МК (ИСО 3166) 004-97	Сокращенное наименование национального органа по стандартизации
Армения	АМ	ЗАО «Национальный орган по стандартизации и метрологии» Республики Армения
Беларусь	ВY	Госстандарт Республики Беларусь
Киргизия	KG	Кыргызстандарт
Россия	RU	Росстандарт
Узбекистан	UZ	Узстандарт
Украина	UA	Минэкономразвития Украины

4 Приказом Федерального агентства по техническому регулированию и метрологии от 19 ноября 2021 г. N 1521-ст межгосударственный стандарт ГОСТ 34.201-2020 введен в действие в качестве национального стандарта Российской Федерации с 1 января 2022 г.

5 ВЗАМЕН ГОСТ 34.201-89

6 ИЗДАНИЕ (март 2022 г.) с Поправкой (ИУС N 3 2022 г.)

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

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

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

2 Нормативные ссылки

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

ГОСТ 2.102 Единая система конструкторской документации. Виды и комплектность конструкторских документов

ГОСТ 2.113-75 Единая система конструкторской документации. Групповые и базовые конструкторские документы

ГОСТ 2.601 Единая система конструкторской документации. Эксплуатационные документы

_______________

¹⁾ В Российской Федерации действует ГОСТ Р 2.601-2019.

ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов

ГОСТ 34.602 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

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

3 Виды и наименование документов

Состав видов документов, разрабатываемых на стадии «Исследование и обоснование создания АС», определяют исходя из требуемых результатов выполнения данной стадии (научно-технический отчет, тактико-техническое задание, технико-экономическое обоснование).

На стадии «Техническое задание» разрабатывают Техническое задание (ТЗ) на создание автоматизированной системы в соответствии с требованиями ГОСТ 34.602.

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

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

Виды документов, разрабатываемых на стадиях «Эскизный проект», «Технический проект», «Рабочая документация», приведены в таблице 1.

Таблица 1 — Виды документов, разрабатываемых на стадиях «Эскизный проект», «Технический проект», «Рабочая документация»

Вид документа	Код документа	Назначение документа
Ведомость	В	Перечисление в систематизированном виде объектов, предметов и т.д.
Схема	С	Графическое изображение форм документов, частей, элементов системы и связей между ними в виде условных обозначений
Инструкция	И	Изложение состава действий и правил их выполнения пользователями и персоналом
Обоснование	Б	Изложение сведений, подтверждающих целесообразность принимаемых решений
Описание	П	Пояснение назначения системы, ее частей, принципов их действия и условий применения
Конструкторский документ	—	По ГОСТ 2.102
Программный документ	—	По ГОСТ 19.101

Виды документов на программные средства, используемые при создании АС (ее частей), — по ГОСТ 19.101.

Виды документов на технические средства, используемые при создании АС (ее частей), — по ГОСТ 2.102 и по ГОСТ 2.601 в части эксплуатационных документов.

Наименования конкретных документов, разрабатываемых при проектировании АС в целом или ее части, приведены в таблице 2.

Таблица 2 — Наименования конкретных документов, разрабатываемых при проектировании АС в целом или ее части

Стадия создания	Наименование документа	Код документа	Часть проекта	Принадлежность к	Дополнительные указания
				проектно- сметной доку- ментации	эксплуа- тационной докумен- тации
ЭП	Ведомость эскизного проекта	ЭП*	ОР	—	—	—
	Пояснительная записка к эскизному проекту	П1	ОР	—	—	—
ЭП	Схема организационной структуры	СО	ОР	—	—	Допускается включать в документ ПЗ или ПВ
ТП	Структурная схема комплекса технических средств	С1*	ТО	Х	—	Допускается включать в документ П9
	Схема функциональной структуры	С2*	ОР	—	—	При разработке документов С0, С1, С2, С3 на стадии ЭП допускается их включение в документ П1
	Перечень заданий на разработку специализированных (новых) технических средств	В9	ТО	Х	—	При разработке на стадии ТП допускается включать в документ П2
	Схема автоматизации	С3*	ТО	Х	—	—
	Технические задания на разработку специализированных (новых) технических средств	—	ТО	—	—	В состав проекта не входят
ТП	Задания на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, подготовительные работы, связанные с созданием системы	—	ТО	Х	—	В состав проекта не входят
	Ведомость технического проекта	ТП*	ОР	—	—	—
	Ведомость покупных изделий	ВП*	ОР	—		—
	Перечень входных данных	В1	ИО	—	—	—
	Перечень выходных данных	В2	ИО	—	—	—
	Перечень заданий на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы	В3	ТО	Х	—	Допускается включать в документ П2
	Пояснительная записка к техническому проекту	П2	ОР	—	—	Включает план мероприятий по подготовке объекта к вводу системы в эксплуатацию
	Описание автоматизируемых функций	П3	ОР	—	—	—
	Описание постановки задач (комплекса задач)	П4	ОР	—	—	Допускается включать в документы П2 или П3
	Описание информационного обеспечения системы	П5	ИО	—	—	—
ТП	Описание организации информационной базы	П6	ИО	—	—	—
	Описание систем классификации и кодирования	П7	ИО	—	—	—
	Описание массива информации	П8	ИО	—	—	—
	Описание комплекса технических средств	П9	ТО	—	—	Для задачи допускается включать в документ П6 по ГОСТ 19.101
	Описание программного обеспечения	ПА	ПО	—	—	—
	Описание алгоритма (проектной процедуры)	ПБ	МО	—	—	Допускается включать в документы П2, П3 или П4
	Описание организационной структуры	ПВ	ОО	—	—	—
	План расположения	С8	ТО	Х	—	Допускается включать в документ П9
	Ведомость оборудования и материалов	—	ТО	Х	—	—
	Локальный сметный расчет	Б2	ОР	Х	—	—
ТП, РД	Проектная оценка надежности системы	Б1	ОР	—	—	—
	Шаблон документа	С9	ИО	—	Х	На стадии ТП допускается включать в документы П4 или П5
РД	Ведомость держателей подлинников	ДП*	ОР	—	—	—
	Ведомость эксплуатационных документов	ЭД*	ОР	—	Х	—
	Спецификация оборудования	В4	ТО	Х	—	—
	Ведомость потребности в материалах	В5	ТО	Х	—	—
	Описание информационного массива	В6	ИО	—	Х	—
	Описание базы данных	В7	ИО	—	Х	—
	Локальная смета	Б3	ОР	Х	—	—
	Методика (технология) автоматизированного проектирования	И1	ОО	—	Х	—
	Технологическая инструкция	И2	ОО	—	Х	—
	Руководство пользователя	И3	ОО	—	Х	—
РД	Инструкция по эксплуатации комплекса технических средств	ИЭ	ТО	—	Х	—
	Схема соединения внешних проводок	С4*	ТО	Х	—	Допускается выполнять в виде таблиц
	Схема подключения внешних проводок	С5*	ТО	Х	—	То же
	Таблица соединений и подключений	С6	ТО	Х	—	—
	Схема деления системы (структурная)	Е1*	ТО	—	—	—
	Чертеж общего вида	ВО*	ТО	Х	—	—
	Чертеж установки технических средств	СА	ТО	Х	—	—
	Схема принципиальная	СБ	ТО	Х	—	—
	Схема структурная комплекса технических средств	С1*	ТО	Х	—	—
	План расположения оборудования и проводок	С7	ТО	Х	—	—
	Описание технологического процесса обработки данных (включая телеобработку)	ПГ	ОО	—	Х	—
	Общее описание системы	ПД	ОР	—	Х	—
	Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем)	ПМ*	ОР	—	—	—
	Формуляр	ФО*	ОР	—	Х	—
	Паспорт	ПС*	ОР	—	Х	—
* Документы, код которых установлен в соответствии с требованиями стандартов Единой системы конструкторской документации (ЕСКД). Примечания 1 В таблице приняты следующие обозначения: ЭП — эскизный проект; ТП — технический проект; РД — рабочая документация; ОР — общесистемные решения; ОО — решения по организационному обеспечению; ТО — решения по техническому обеспечению; ИО — решения по информационному обеспечению; ПО — решения по программному обеспечению; МО — решения по математическому обеспечению. 2 Знак «Х» означает принадлежность к проектно-сметной или эксплуатационной документации. 3 Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений. 4 Код (обозначение) документов, отмеченных в графе «Принадлежность к проектно-сметной документации» знаком «Х», может быть установлен по требованиям стандартов Системы проектной документации для строительства (СПДС).

В зависимости от применяемых методов проектирования и специфики создаваемых АС допускается:

разрабатывать групповые и базовые документы в соответствии с разделами 1, 3, 4, 6 ГОСТ 2.113— 75;
выпускать документы отдельными самостоятельными частями, соответствующими разделам основного документа;
расширять номенклатуру документов, установленную настоящим стандартом.

При изготовлении несерийных компонентов комплексов средств автоматизации и на стадии «Ввод в действие» разрабатывают следующие организационно-распорядительные документы:

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

4 Комплектность документации

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

Примечание — Комплектность проектно-сметных документов определяют в соответствии с правилами, установленными системой проектной документации для строительства.

4.2 На каждый комплект должна быть составлена ведомость документов.

4.3 Комплектность документации, обеспечивающей разработку, изготовление, приемку и монтаж технических средств, — по ГОСТ 2.102. Комплектность эксплуатационной документации на эти средства — по ГОСТ 2.601.

4.4 Комплектность документации на программные средства вычислительной техники — по ГОСТ 19.101.

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

5 Обозначения документов

5.1 Каждому разработанному документу должно быть присвоено самостоятельное обозначение. Документ, выполненный на разных носителях данных, должен иметь одно обозначение. К обозначению документов, выполненных на машинных носителях, добавляют букву «М».

Заимствованным документам сохраняют ранее присвоенные обозначения.

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

5.3 Обозначение документа имеет следующую структуру, показанную на рисунке 1.

5.3.1 Правила обозначения системы (части системы) приведены в приложении А.

5.3.2 Код документа состоит из двух буквенно-цифровых знаков. Код для документов, определенных настоящим стандартом, проставляют в соответствии с графой 3 таблицы 2. Код дополнительных документов формируют следующим образом: первый знак — буква, означающая вид документа согласно таблице 1, второй знак — цифра или буква, указывающая порядковый номер документа данного вида.

Код документа отделяют от предыдущего обозначения точкой.

Рисунок 1. Структура обозначения документа.

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

5.3.4 Номер редакции документа присваивают, начиная со второй в порядке возрастания от 2 до 9, и отделяют от предыдущего значения точкой. Очередной номер редакции присваивают в случаях сохранения (не аннулирования) предыдущей редакции.

5.3.5 Номер части документа отделяют от предыдущего обозначения дефисом. Если документ состоит из одной части, то дефис не проставляют и номер части документа не присваивают.

5.3.6 Признак документа, выполненного на машинных носителях, вводят при необходимости. Букву «М» отделяют от предыдущего обозначения точкой.

Приложение А (рекомендуемое). Правила обозначения систем и их чертежей

А.1 Структура обозначения автоматизированной системы или ее части имеет вид, показанный на рисунке А.1.

Рисунок А.1. Структура обозначения АС

А.2 Код организации-разработчика представляет собой основной государственный регистрационный номер (ОГРН) из Единого государственного реестра юридических лиц (ЕГРЮЛ).

А.З Код классификационной характеристики системы или ее части (подсистемы, комплекса, компонента) присваивают в соответствии с правилами, установленными в отрасли.

А.4 Порядковый регистрационный номер системы (части системы) присваивает служба организации разработчика, ответственная за ведение картотеки и учет обозначений. Регистрационные номера присваивают с 001 до 999 по каждому коду регистрационной характеристики.

Скачать документ в формате .doc вы можете здесь.

Источник