96161

Жизненный цикл защищенного ПО

Реферат

Информатика, кибернетика и программирование

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

Русский

2015-10-03

137.08 KB

2 чел.

2

Министерство образования и науки Украины

Харьковский национальный университет радиоэлектроники

Кафедра ТКС

Реферат

на тему Жизненный цикл защищенного ПО

Выполнил:           Проверил:

Ст. гр. АМСЗИс-14-1         Дуравкин Е.В.

Пузырей О.С.                                                                  

                                                            

Харьков 2014

СОДЕРЖАНИЕ

1.ОПРЕДЕЛЕНИЕ ЗАЩИЩЕННОГО ПО       3

2. ПРОЦЕСС РАЗРАБОТКИ ПО        8

2.1Рассмотрение вопросов надежности

на каждом из этапов разработки       8

2.2 Планирование         9

2.3 Создание качественных требований      10

2.4 Определение критериев перехода между процессами   11

2.5 Процесс обеспечения качества       11

3. МЕТОДЫ ЗАЩИТЫ ПО ОТ ИЗУЧЕНИЯ      13

3.1. Виртуальный процессор в защите ПО     14

3.2. Реализация метода         15

4. ЗАЩИЩЕННАЯ РАЗРАБОТКА

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ       18

ВЫВОДЫ            20

СПИСОК ИСПОЛЬОЗОВАНОЙ ЛИТЕРАТУРЫ     21


1. ОПРЕДЕЛЕНИЕ ЗАЩИЩЕННОГО ПО

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

Рисунок 1.1 — Качественное ПО

Защищенный - значит качественный. Качество определяется способностью программного продукта при определенных условиях удовлетворять установленным или предполагаемым потребностям пользователя [1].

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

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

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

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

Таблица 1.1 Набор атрибутов при моделировании качественного ПО

Название атрибута

Описание атрибута

Функциональные возможности

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

Пригодность для применения по назначению

Наличие и соответствие набора функций конкретным задачам

Правильность/корректность реализации требований

Способность программного обеспечения обеспечивать правильность (или соответствие) результатов

Способность к взаимодействию с компонентами и средой

Способность ПО взаимодействовать с конкретными системами

Согласованность

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

Защищенность/безопасность функционирования

Способность ПО предотвращать несанкционированный доступ (случайный или преднамеренный) к программам и данным

Надежность

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

Стабильность/уровень завершенности

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

Устойчивость к ошибке

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

Восстанавливаемость после проявления дефектов

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

Практичность

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

Понятность функций и документации

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

Изучаемость процессов функционирования и применения

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

Простота использования

Характеризует усилия пользователя по эксплуатации и оперативному управлению ПО

Эффективность

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

Временная эффективность реализации комплекса программ

Характеризуется временем отклика и скоростью выполнения функций

Используемость вычислительных ресурсов

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

Сопровождаемость

Характеризует объем работ, требуемых для проведения конкретных изменений (модификаций)

Анализируемость

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

Изменяемость компонентов и комплекса программ

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

Устойчивость

Характеризует риск от непредвиденных эффектов модификации

Тестируемость изменений при сопровождении

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

Мобильность

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

Адаптируемость к изменениям среды

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

Простота установки / внедрения / инсталляции после переноса

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

Соответствие

Способность программного обеспечения подчиняться стандартам или соглашениям, относящимся к мобильности

Взаимозаменяемость компонентов при корректировке комплекса программ

Характеризует простоту и трудоемкость применения данного ПО вместо другого конкретного программного средства в среде этого средства


2. ПРОЦЕСС РАЗРАБОТКИ ПО

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

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

2.1 Рассмотрение вопросов надежности на каждом из этапов разработки

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

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

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

2.2 Планирование

Невозможно создать надежного ПО, если нет детального плана действий. Планирование – это ключевой этап жизненного цикла разработки безопасного и надежно ПО.

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

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

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

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

2.3 Создание качественных требований

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

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

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

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

2.4 Определение критериев перехода между процессами

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

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

2.5 Процесс обеспечения качества

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

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

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

  1.  окружение обеспечения качества, а именно: инструменты, процедуры, стандарты, в чем заключается обеспечение качества, как организован процесс обеспечения качества, и кто за что в нем отвечает и перед кем.
  2.  действия по обеспечению качества: аудиты, рапорты, инспекции, мониторинг, контроль процессов жизненного цикла, отслеживание запросов на изменение и проблемных рапортов, и их мониторинг.
  3.  критерии перехода для процесса обеспечения качества, контрольные списки того, что должно быть проверено.
  4.  частота и последовательность действий процесса обеспечения качества.
  5.  список всех данных, создаваемых за время работы процесса, например протоколы митингов, записи проверок, записи установленных отклонений от процессов [3].


3. МЕТОДЫ ЗАЩИТЫ ПО ОТ ИЗУЧЕНИЯ

Рассмотрим, какие методы существуют для защиты ПО от изучения:

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

Существуют и другие методы, а так же их комбинации и разновидности, однако, нетрудно заметить, что все они основаны на одной простой идее: избыточности. В самом деле, что такое запутывание, как не избыточное кодирование программы? Лишние переходы, лишние параметры, лишние инструкции - ключевое слово метода "лишние". То же касается любого из перечисленных методов, и, вероятно, было бы естественным объединить все эти методы в одну группу "Методов избыточного кодирования". Чем же так хороша избыточность, ведь интуитивно понятно, что она увеличивает размер программы и снижает скорость ее работы? Дело в том, что во всех этих разновидностях защиты используется понимание "человеческого фактора" - человеку тем сложнее понять логику какого-либо процесса, чем больше ресурсов этот процесс использует.  Например, функциональность одной простой инструкции загрузки константы на регистр может быть "размазана" на десятки, а то и сотни инструкций, и проследить связь всех используемых ресурсов (регистров, памяти и др.) в этой последовательности человеку довольно сложно. Метод шифрования с этой точки зрения не является чем-то особенным - так же, как и в других методах, для выполнения простой инструкции (или группы) требуется избыточная последовательность команд - в данном случае это операции расшифровки, плюс операции расшифрованного кода.

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

 

3.1 Виртуальный процессор в защите ПО

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

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

3.2 Реализация метода

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

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

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

Рис. 3.1. — Схема работы защищенного программного продукта

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

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

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

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

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

Рис. 3.2. — Схема вызова защищенной функции

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

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

Недостатки же метода - следствие его достоинств:

  1.  скорость работы перенесенного в виртуальную среду кода в разы (ориентировочно в 10-50, в зависимости от архитектуры виртуального процессора и симулятора) ниже, чем кода оригинального;
  2.  объем защищенной программы, как правило, будет несколько выше, чем незащищенной. 

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


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

Защищенная разработка – это комплекс мер, добавляющихся к обычному процессу создания программного обеспечения, направленных на обеспечения высокого уровня безопасности информации, обрабатываемой разрабатываемым программным обеспечением. Существует множество методик защищенной разработки, самые известные из них созданы крупнейшими разработчиками программного обеспечения и различными общественными и государственными организациями. Методики защищенной разработки описывают необходимые действия на всех шагах жизненного цикла программного обеспечения. Рассмотрим Microsoft Security Development Lifecycle (SDL) – формализованное описание процесса защищенной разработки программного обеспечения и набор программных инструментов для реализации отдельных элементов процесса. Процесс защищенной разработки делится по этапам разработки и состоит из элементов, приведенных в таблице 4.1 [2].

Таблица 4.1 Этапы разработки ПО

Этап разработки

Действия

Обучение

Обучение основам безопасности

Требование

Задание требований безопасности

Создание контрольных условий качества и панелей ошибок

Оценка рисков безопасности и конфиденциальности

Проектирование

Задание требований проектирования

Анализ возможных направлений для злоумышленных атак

Моделирование рисков

Реализация

Применение утвержденных инструментов

Отказ от небезопасных функций

Статический анализ

Проверка

Динамический анализ

Нечеткое тестирование (фаззинг)

Проверка возможных направлений для злоумышленных атак

Выпуск

Планирование реагирования на инциденты

Окончательная проверка безопасности

Сертификация и архивация выпуска

Реагирование

Выполнение плана реагирования на инциденты


ВЫВОДЫ

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

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

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

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


СПИСОК ИСПОЛЬЗОВАНОЙ ЛИТЕРАТУРЫ

1. Майкл Ховард, Дэвид Леблан - Защищенный код.

2. Электронный ресурс: http://daily.sec.ru/2013/09/18/Zashishennaya-razrabotka-programmnogo-obespecheniya.html.

3. Электронный ресурс:  http://rsdn.ru/article/20princ/20principles.xml#EDG.

4. Электронный ресурс: http://citforum.ru/security/software/virt_proc/.

5. Электронный ресурс: http://www.softreactor.ru/articles/zashchishchennoe-programmnoe-obespechenie.


 

А также другие работы, которые могут Вас заинтересовать

46887. Особенности философии Возрождения. Человек как центральная проблема философии эпохи Возрождения 35 KB
  Гуманизм представляет собой в эту эпоху образ мышления где идея блага человека объявляется главной целью социального и культурного развития. Обращение к человеку – не просто анализ его земного бытия а показатель сущности человека в мире. Путь творческой деятельности и творчества Особое значение приобретает не только духовная красота человека но и его телесная красота. Индивидуализм как принципиальная установка при рассмотрении человека становится средством обоснования его самоценности необходимости освобождения от...
46888. Метод проектов 35 KB
  Для комплексного решения задач технологического обучения используются различные методы в том числе выполнение творческих проектов целью которых является включение учащихся в процесс преобразовательной деятельности от разработки идеи до ее осуществления. Выполняя проекты школьники осваивают методы инновационной творческой деятельности учатся самостоятельно находить и анализировать информацию получать и применять знания по различным отраслям приобретать умения и навыки практической работы опыт...
46889. Планування площадки з «нульовим» балансом земляних мас 35 KB
  Розроблення ґрунтів здійснюють з метою підготовки основи під будинки та споруди для зміни природного рельєфу місцевості. Процес розроблення ґрунту складається з трьох основних операцій: розроблення ґрунту його переміщення транспортування та укладання з ущільненням. Розроблення може виконуватись з метою створення виїмки та насипу. Під час виконання земляних робіт велике значення має транспортування ґрунту до місця його призначення тому важливим завданням технолога є вибір і розроблення найефективніших методів розроблення та...
46890. ДОПОЛНИТЕЛЬНЫЕ ОПОРНЫЕ ПОВЕРХНОСТИ 35.14 KB
  В подобных случаях технолог вынужден использовать дополнительные опорные поверхности несущие на себе дополнительные опорные точки сверх шести теоретически необходимых. Дополнительные опорные поверхности могут быть естественными т. Примером использования дополнительной опорной поверхности может служить токарная обработка длинного вала.
46891. Государственная отраслевая политика 36.67 KB
  Базовыми видами оценок основных средств являются: первоначальная восстановительная и остаточная стоимость. Полная первоначальная стоимость основных средств предприятия представляет собой сумму фактических затрат в действующих ценах на: приобретение или создание средств труда: возведение зданий и сооружений покупку транспортировку установку и монтаж машин и оборудования и др. По полной первоначальной стоимости основные средства принимаются на баланс предприятия и она остается неизменной в течение всего срока службы средств труда и...
46892. Англійська мова. Додатки до білетів 35.34 KB
  Account holders have discovered that the good old days were not always the best ways of transacting business, especially when managing corporate and personal finances. Before the advent of the Internet, consumers had to visit a local branch bank to make deposits, withdraw funds, or order checks
46893. Особенности художественного развития и художественного образования в России XVIII века 35.5 KB
  По сравнению с худосочным академическим университетом окончательно ликвидированном в 60х годах. Так в области живописи Антропов 17161795 сын оружейника долгое время работавший в живописной команде занимавшийся росписью стен и потолков вырос в 50х годах в крупнейшего русского портретиста. Наибольшим успехом у высокопоставленных заказчиков в 40 – 50х годах пользовался зодчий в Растрелли сын итальянского скульптора приглашенного в Россию при Петре. В 50х 60х годах происходит поворот от пышного грузного барокко к более простым...
46895. Полные и неполные предложения. Двусоставные и односоставные предложения 35.5 KB
  В основу деления простых предложений на двусоставные и односоставные положено различие в способе выражения основного грамматического значения предложения предикативности: наличие отношений между носителем признака и признаком и их отсутствие когда утверждается независимый признак или бытие предмета. Предложения Донецкая дорога. При синтаксической характеристике односоставных и двусоставных предложений немаловажную роль играет интонация которая определяется коммуникативным заданием предложения.