Software & Systems

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

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

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

Мерами по безопасной разработке ПО будем считать организационно-технические меры, на­правленные на создание программ с минимально возможным количеством уязвимостей и формиро- вание среды обеспечения оперативного устранения уязвимостей, выявленных пользователями. Опыт крупных разработчиков ПО показал, что внедрение подобных мер в жизненный цикл его разработки позволяет сократить число уязвимостей ПО в среднем на 80 % [1].

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

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

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

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

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

–      разработка концептуальной модели анализа и синтеза комплекса мер разработки безопасного ПО.

В качестве ограничения области исследования следует определить необходимость гармонизации получаемых решений с современной нормативной базой оценки соответствия в области ИБ (линейка ISO 15408/18045, Common Criteria) [2] и жизненного цикла программ (ISO 12207) [3].

Анализ стандартов по безопасной разработке

В настоящее время известен ряд корпоративных, отраслевых и международных стандартов, содержащих описание мер и механизмов, направленных на разработку безопасного ПО, например, ISO 15408 [4–6], ISO 27034-1, ISO TR 24772 [7], Microsoft Security Development Life Cycle [1], Cisco Security Development Life Cycle, OpenSAMM [8], OWASP CLASP [9].

Результаты сравнительного анализа указанных стандартов представлены в таблице 1.

На основании проведенного анализа сделаны следующие выводы.

1. Существуют достаточно детально проработанные стандарты на разработку безопасного ПО, направленные, как правило, на следующие цели:

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

–      реализация ПО элементов политики обеспечения безопасности среды (места) применения ПО (политики ИБ организации или страны, где применяется ПО).

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

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

Базовый набор требований

Как известно, современное развитие отечественной системы сертификации средств защиты информации по требованиям безопасности информации связано с апробацией методологии Common Criteria (ISO 15408) [12]. По этой причине в данном исследовании было принято решение об использовании аппарата ISO 15408 при разработке концептуальной модели анализа и синтеза мер разработки безопасного ПО.

На рисунке 1 представлена последовательность формирования множеств функций безопасности ПО (объекта оценки) и мер обеспечения доверия к нему в соответствии с методологией ISO 15408.

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

–      предположений безопасности, содержащих аспекты безопасности среды, в которой будет ис- пользоваться ПО или предполагается к использованию;

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

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

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

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

1. С целью обеспечения практического применения и эффективного выполнения требований разрабатываемый набор должен согласовываться с международным стандартом ISO 12207, который описывает процессы жизненного цикла ПО [3, 13].

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

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

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

–      название требования;

–      уникальный идентификатор требования;

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

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

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

–      элементы содержания и представления документированных свидетельств выполнения требования;

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

–      примечание с пояснительным текстом.

В ходе выполнения исследования на основе существующих стандартов и методологий разработки безопасного ПО синтезировано множество B = {b1, b2, …, b24} требований по разработке безопасного ПО (см. табл. 2).

Так как статический анализ безопасности про- грамм является наиболее результативным (к сожа- лению, весьма трудоемким [16–18]), целесообразно следовать следующим разработанным требованиям КК-4 (b7).

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

Идентификатор требования: КК-4.

Процесс жизненного цикла ПО: процессы конструирования и комплексирования ПО.

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

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

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

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

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

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

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

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

Концептуальная модель

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

При описании среды разработки ПО следует определить:

– множество угроз ИБ, которые являются актуальными для среды разработки ПО: U = {u1, u2, …, ua};

– множество идентифицированных положений политик ИБ, которым должна соответствовать среда разработки ПО: P = {p1, p2, …, pb}.

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

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

Для достижения идентифицированных политик безопасности и нейтрализации идентифицированных угроз ИБ следует сформировать множество целей разработки безопасного ПО: O = {o1, o2, …, oc}.

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

R = {r1, r2, …, rd}, R Í B, d £ 24.

Для выполнения идентифицированных требований разработчик ПО может сформировать и реализовать в среде разработки ПО комплекс мер разработки безопасного ПО, а именно множество C = {c1, c2, …, ce}.

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

F0: U È P ® 0 – процедура формирования целей разработки безопасного ПО;

FR: B È 0 ® R – процедура выбора требований по разработке безопасного ПО;

FC: R ® C – процедура синтеза мер разработки безопасного ПО.

Разработанная концептуальная модель характеризуется кортежем áB, U, P, O, R, F0, FR, FCñ.

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

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

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

Шаг 1. Формирование множества U = {u1, u2, …, ua} угроз ИБ, которые являются актуальными для среды разработки ПО.

Шаг 2. Формирование множества P = {p1, p2, …, pb} положений политик ИБ, которым должна соответствовать среда разработки ПО. В качестве источников для формирования множества политик безопасности могут использоваться требования законов, нормативных правовых актов, отраслевых стандартов, перечень требований пользователя, сценарии использования ПО.

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

Шаг 3. Формирование множества целей разработки безопасного ПО: .

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

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

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

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

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

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

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

Этап 3. Выбор и обоснование требований по разработке безопасного ПО, включающие следующие шаги.

Шаг 5. Формирование множества требований по разработке безопасного ПО на основе базового набора требований с учетом необходимости достижения идентифицированных целей: rm=FR(bn, oi); .

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

Этап 4. Синтез и обоснование мер разработки безопасного ПО.

Шаг 7. На основе множества идентифицированных требований по разработке безопасного ПО и информации о конкретной среде разработки ПО, технологиях и инструментальных средствах, применяемых при разработке, необходимо сформулировать множество мер разработки безопасного ПО, которые планируется применять в среде разработки ПО: cq = FC (rm); .

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

Переход к математическим моделям

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

,

где ki – коэффициент i-й меры; K £ 24 – число мер.

Следует отметить, что в работе не ставилась цель получить значения указанных математических показателей, однако эффективность предложенного концептуального подхода была подтверждена результатами сравнения уровня уязвимости программных продуктов, разработанных в организациях, имеющих авторитетные зарубежные сертификаты на системы менеджмента ИБ, и продуктов, разработанных иными разработчиками ПО. Анализ статистики за 2008–2015 гг. показал, что обобщенный показатель числа уязвимостей в продуктах первой категории ниже в 5 раз, чем аналогичный показатель у продуктов второй категории [20].

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

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

–      интеграцию с существующими стандартами, определяющими процессы жизненного цикла программ, например, определенными ISO 12207;

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

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

На основе анализа, систематизации и обобщения стандартов в области разработки безопасного ПО разработан базовый набор из 24 требований по разработке безопасного ПО. Отличительные особенности разработанного базового набора требований:

–      наличие перекрестных ссылок на процессы жизненного цикла ПО, определенные ISO 12207, что обеспечивает более простую интеграцию в уже существующие в организации-разработчике ПО процессы разработки ПО;

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

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

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

Литература

1.     Howard M., Lipner S. The security development lifecycle: a process for developing demonstrably more secure software. Microsoft Press, 2006, 352 p.

2.     Markov A., Luchin D., Rautkin Y., Tsirlov V. Evolution of a radio telecommunication hardware-software certification paradigm in accordance with information security requirements. Proc. 11th Intern. Siberian Conf. on Control and Communications (Omsk, Russia, May 21–23, 2015). SIBCON-2015. IEEE, 2015, pp. 1–4; URL: http://dx.doi.org/10.1109/SIBCON.2015.7147139 (дата обрпщения: 20.09.2015).

3.     Липаев В.В. Развитие базовых стандартов программной инженерии // Программная инженерия. 2012. № 6. С. 2–7.

4.     Biró M., Molnár B. Synergies between the common criteria and process improvement. LNCS, 2007, no. 4764, pp. 31–45; URL: http://dx.doi.org/10.1007/978-3-540-75381-0_4 (дата обращения: 20.09.2015).

5.     Kara M. Review on Common Criteria as a secure soft- ware development model. IJCSIT, 2012, vol. 4, no. 2 (Apr. 2012), pp. 83–94. DOI = http://dx.doi.org/10.5121/ijcsit.2012.4207.

6.     Lee M.-G., Sohn H.-J., Kim B.-M., Kim J. B. A Study on secure SDLC Specialized in Common Criteria. ASTL, 2015, no. 93, pp. 11–23.

7.     Barabanov A., Markov A., Fadin A., Tsirlov V., Shakha- lov I. Synthesis of Secure Software Development controls. Proc. 8th Intern. Conf. SIN '15 (Sochi, Russian Federation, September 08-10, 2015). ACM, NY, USA, 2015, pp. 93–97; URL: http://dx.doi.org/ 10.1145/2799979.2799998 (дата обращения: 20.09.2015).

8.     Барабанов А.В. Стандартизация процесса разработки безопасных программных средств // Вопросы кибербезопасности. 2013. № 1 (1). С. 37–41.

9.     De Win B., Scandariato R., Buyens K., Grégoire J., Joosen W. On the Secure Software Development Process: CLASP, SDL and touchpoints compared. information and software technology, 2009, vol. 51, no. 7 (Jul. 2009), pp. 1152-1171; URL: http://dx.doi.org/ 10.1016/j.infsof.2008.01.010 (дата обращения: 20.09.2015).

10.  Essafi M., Ghezala H.B. Meta-modeling based secure software development processes. IJSSE, 2014, no. 5 (3) (Jul.–Sep. 2014), pp. 56–74; URL: http://dx.doi.org/10.4018/ijsse.2014070104 (дата обращения: 20.09.2015).

11.  Fal' A.M. Standardization in information security management. Cybernetics and Systems Analysis, 2010, vol. 46, no. 3 (May 2010), pp. 512–515; URL: http://dx.doi.org/10.1007/ s10559-010-9227-9 (дата обращения: 20.09.2015).

12.  Barabanov A., Markov A. Modern trends in the regulatory framework of the information security compliance assessment in russia based on Common Criteria. Proc. 8th Intern. Conf. SIN '15 (Sochi, Russian Federation, September 08-10, 2015). ACM, NY, USA, 2015, pp. 30–33; URL:  http://dx.doi.org/10.1145/2799979. 2799980 (дата обращения: 20.09.2015).

13.  Невлюдов И.Ш., Андрусевич А.А., Евсеев В.В. Анализ жизненного цикла разработки программного обеспечения для корпоративных информационных систем // Восточ.-Европ. журн. передовых технологий. 2010. Т. 6. № 8 (48). С. 25–27.

14.  Рибер Г., Малмквист К., Щербаков А. Многоуровневый подход к оценке безопасности программных средств // Вопросы кибербезопасности. 2014. № 1 (2). С. 36–39.

15.  Viega J., McGraw G. Building Secure Software: how to avoid security problems the Right Way. Addison-Wesley Professio­nal, 2001, 528 p.

16.  Аветисян А.И., Белеванцев А.А., Чукляев И.И. Технологии статического и динамического анализа уязвимостей программного обеспечения // Вопросы кибербезопасности. 2014. № 3 (4). С. 20–28.

17.  Демин А.А., Карпунин А.А., Ганев Ю.М. Методы верификации и валидации сложных программных систем // Программные продукты и системы. 2014. № 108. С. 229–233.

18.  Ardi S., Shahmehri N. Introducing vulnerability awareness to Common Criteria's security targets. Proc. 4th Intern. Conf. on Software Engineering Advances (20–25 Sept. 2009, Porto). ICSEA '09. IEEE Xplore Digital Library, 2009, pp. 419–424; URL: http://dx.doi.org/10.1109/ICSEA.2009.67 (дата обращения: 20.09.2015).

19.  Марков А.С., Ларионцева Е.А., Стельмашук Н.Н. Многофакторные модели планирования сертификационных испытаний программных средств защиты информации // Вопросы радиоэлектроники. 2013. Т. 3. № 2. С. 76–83.

20.  Марков А.С., Цирлов В.Л. Опыт выявления уязвимостей в зарубежных программных продуктах // Вопросы кибербезопасности. 2013. № 1 (1). С. 42–48.