Просмотр исходного текста страницы СПО в процессах безопасной разработки на примере OC PB Embox (Антон Бондарев, OSSDEVCONF-2023)

;{{SpeakerInfo}}: {{Speaker|Антон Бондарев}}
<blockquote>
Основная критика использования Open source в объектах критической информационной инфраструктуры заключается в том, что поддержка и сопровождение подобных решений имеет ряд трудностей, в результате итоговые системы небезопасны. 

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

В докладе также будут рассмотрены процессы, по которым на базе открытой ОС PB Embox могут быть построены надёжные и безопасные системы.
</blockquote>

{{VideoSection}}
{{vimeoembed|892800033|800|450}}
{{youtubelink|}}

{{SlidesSection}}
[[File:СПО в процессах безопасной разработки на примере OC PB Embox (Антон Бондарев, OSSDEVCONF-2023).pdf|left|page=-|300px]]

{{----}}

== Thesis ==

=== СПО в процессах безопасной разработки на примере ОС РВ Embox ===
По данным Gartner, более 95% ИТ-компаний в мире сейчас используют Open source-решения. Среди остальных компаний не
менее 40% предпочитают в работе свободное ПО. И если в системах общего назначения, где цена ошибки не очень велика,
правильность применения СПО не вызывает сомнений, то, поскольку при создании критически важных вычислительных систем на
первый план выходит не скорость и стоимость разработки, а качество и надёжность полученной системы, применение Open
source{}-решений порой резко критикуется.

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

Для классификации систем по уровню безопасности и надёжности существует принятый в России международный стандарт «Общие
критерии оценки защищённости информационных технологий, Общие критерии», (англ. Common Criteria for Information
Technology Security Evaluation, Common Criteria, CC). По данному стандарту существует 7 уровней Evaluation Assurance
Level (EAL) (Вычислимых уровней надёжности):
*  EAL1: Functionally Tested (функционально протестированная система);
*  EAL2: Structurally Tested (структурно протестированная система);
*  EAL3: Methodically Tested and Checked (протестировано по описанной методике);
*  EAL4: Methodically Designed, Tested, and Reviewed (существует методика для разных этапов жизненного цикла
продукта);
*  EAL5: Semiformally Designed and Tested (существуют инструменты, с помощью которых формально описывается и ведётся
процесс разработки);
*  EAL6: Semiformally Verified Design and Tested (существуют инструменты для формального определения соответствия
функциональности заявленным требованиям);
*  EAL7: Formally Verified Design and Tested (существуют наборы инструментов, позволяющих осуществить проверку на
полное соответствие полученной функциональности системы заявленным требованиям).


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

Такой процесс описан в серии стандартов КТ-178 (перевод международного DO-178B). DO-178B требует внедрения в процесс
наработки критически важного ПО так называемой V-образной модели.

[[Файл:СПО_в_процессах_безопасной_разработки_на_примере_OC_PB_Embox_(Антон_Бондарев,_OSSDEVCONF-2023).pdf|page=12|center|640px]]

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

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

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

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

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

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

=== Выводы ===
Уровень безопасность информационной системы зависит в первую очередь от процессов, которые применялись при её создании.
Существует стандарт DO-178B, который описывает модель разработки для увеличения надёжности. В частности, в её основе
лежит так называемая V-образная модель или циклическая модель, которая в отличие от водопадной модели подразумевает
возврат к более ранним стадиям проектирования в случае обнаружения каких то несоответствий заявленным характеристикам.

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

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

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

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



{{----}}
[[File:{{#setmainimage:СПО в процессах безопасной разработки на примере OC PB Embox (Антон Бондарев, OSSDEVCONF-2023)!.jpg}}|center|640px]]
{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->

<references/>

[[Категория:OSSDEVCONF-2023]]
[[Категория:Open-source projects]]
[[Категория:Draft]]