Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное

учреждение высшего профессионального образования

«Сочинский государственный университет»

Институт информационных технологий и математики

Кафедра общей математики и информатики

УТВЕРЖДАЮ

Заведующий кафедрой

___________ А. Р. Симонян

« » ___________ 2012 г.

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

Выпускная квалификационная работа

по специальности 050201

Научный руководитель:

кандидат технических наук,

доцент кафедры общей математики и информатики

_________ С. Ж. Симаворян

« » __________ 2012 г.

Выполнил:

студент группы 07-МИ

_________ Л. Р. Зарандия

« » _________ 2012 г.

Содержание

• Введение
• ГЛАВА 1. БЕЗОПАСНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
• 1.1 Угрозы безопасности программного обеспечения и примеры их реализации
• 1.1.1 Классификация угроз.
• 1.1.2 Используемая терминология.
• 1.2. Жизненный цикл программного обеспечения
• 1.2.1 Стандарты жизненного цикла ПО
• 1.3 Принципы обеспечения безопасности программного обеспечения
• 1.3.1 Классификация средств атаки на средства защиты программного обеспечения
• 1.3.2 Основные принципы обеспечения безопасности ПО.
• 1.4 Оценка качества программного обеспечения
• 1.4.1 Показатели сопровождения программного обеспечения
• 1.4.2 Показатели надежности
• 1.4.3 Показатели удобства применения программного обеспечения
• 1.4.4 Показатели эффективности программного обеспечения
• 1.4.5 Показатели универсальности программного обеспечения
• 1.4.6 Показатели корректности программного обеспечения
• 1.5 Постановка задачи оценки защищенности ПО
• ГЛАВА 2. МЕТОДЫ ЗАЩИТЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ИХ ОЦЕНКА И АНАЛИЗ ЗАЩИЩЕННОСТИ.
• 2.1 Методы технологической защиты ПО и их оценка эффективности.
• 2.1.1Аппаратные средства защиты программного обеспечения
• 2.1.2 Программные средства защиты программного обеспечения
• 2.2 Методы обеспечения эксплуатационной безопасности ПО.
• 2.2.1 Методы и средства защиты программ от компьютерных вирусов
• 2.2.2 Методы защиты программного обеспечения от средств исследования программ
• 2.3 Правовая поддержка процессов разработки и применения ПО.
• 2.3.1 Стандарты в области информационной безопасности
• 2.4 Оценка защищенности ПО
• 2.4.1 Качества систем защиты программного обеспечения
• 2.4.2 Методы анализа и оценки безопасности ПО
• Заключение
• Литература

Введение

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

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

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

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

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

· несанкционированное использование либо распространение ПО (кража, копирование, пиратство);

· несанкционированная модификация ПО;

Рассмотрим подробнее эти методы атаки на программное обеспечение.

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

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

· неправомерное использование - выполнение программы (либо использование ее результатов) пользователем, которому автор или владелец не предоставил разрешения на выполнение;

· нарушение требований лицензии на ПО;

· перепродажа программного продукта от своего имени.

Незаконное копирование и перепродажа ПО, а также несанкционированное его использование лицами, которые не имеют на это права, ежегодно обходится производителям, по разным оценкам, потерями от 10 до 12 млрд. долларов. По данным Business Software Alliance, 36% всего используемого в мире ПО является пиратским. Можно утверждать, что пиратство - основная проблема для разработчиков и распространителей коммерческого ПО. Это подтверждается и обилием решений для противостояния пиратству. За всю историю коммерческого ПО были придуманы тысячи способов (как программных, так и аппаратных) защиты ПО от нелегального использования и распространения.

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

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

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

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

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

ГЛАВА 1. БЕЗОПАСНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1.1 Угрозы безопасности программного обеспечения и примеры их

реализации

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

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

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

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

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

• оценку ценности информации, хранящейся в системе;

• построение модели злоумышленника (другими словами, определение того, от кого нужно защищаться - от постороннего лица, пользователя системы, администратора и т.д.);

• оценку допустимых затрат времени, средств и ресурсов системы на организацию ее защиты.

1.1.1 Классификация угроз

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

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

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

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

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

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

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

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

• несанкционированный доступ к приложению;

• внедрение вредоносного программного обеспечения;

• злоупотребление системными ресурсами;

• отказ от подтверждения авторства передаваемой информации;

• сбои системного и сетевого программного обеспечения;

• сбои прикладного программного обеспечения.

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

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

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

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

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

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

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

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

Нарушитель (нарушители) - субъект (субъекты), совершающие несанкционированный доступ к информационному ресурсу.

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

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

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

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

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

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

1.2 Жизненный цикл программного обеспечения

Жизненный цикл программного обеспечения - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. (Стандарт IEEE Std 610.12)

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

• системный анализ и обоснование требований к ПО;

• предварительное (эскизное) и детальное (техническое) проектирование ПО;

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

• испытания, опытная эксплуатация и тиражирование ПО;

• регулярная эксплуатация ПО, поддержка эксплуатации и анализ результатов;

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

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

1.2.1 Стандарты жизненного цикла ПО

• ГОСТ 34.601-90

• ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)

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

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

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

• риск превышения сроков и стоимости проекта;

• необходимость выполнения ещё одной итерации;

• степень полноты и точности понимания требований к системе;

• целесообразность прекращения проекта.

Стандартизация ЖЦ ПО проводится по трем направлениям. Первое направление организуется и стимулируется Международной организацией по стандартизации (ISO - International Standard Organization) и Международной комиссией по электротехнике (IEC - International Electro-technical Commission). На этом уровне осуществляется стандартизация наиболее общих технологических процессов, имеющих значение для международной кооперации. Второе направление активно развивается в США Институтом инженеров электротехники и радиоэлектроники (IEEE - Institute of Electrotechnical and Electronics Engineers) совместно с Американским национальным институтом стандартизации (American Na-tional Standards Institute-ANSI). Стандарты ISO/IEC и ANSI/IEEE в основном имеют рекомендательный характер. Третье направление стимулируется Министерством обороны США (Department of Defense-DOD). Стандарты DOD имеют обязательный характер для фирм, работающих по заказу Министерства обороны США.

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

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

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

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

1.3 Принципы обеспечения безопасности программного

обеспечения

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

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

• создания безопасных информационных технологий;

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

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

Модель угроз должна включать:

• полный реестр типов возможных программных закладок;

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

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

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

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

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



Схема угроз технологической безопасности ПО

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

ПРОЕКТИРОВАНИЕ Проектные решения Злоумышленный выбор нерациональных алгоритмов работы. Облегчение внесения закладок и затруднение их обнаружения. Используемые информационные технологии Внедрение информационных технологий или их элементов, содержащих программные закладки. Внедрение неоптимальных информационных технологий. Используемые аппаратно-технические средства Поставка вычислительных средств, содержащих программные, аппаратные или программно-аппаратные закладки. Поставка вычислительных средств с низкими эксплуатационными характеристиками.
КОДИРОВАНИЕ Архитектура программной системы, взаимодействие ее с внешней средой и взаимодействие подпрограмм программной системы Доступ к «чужим» подпрограммам и данным. Нерациональная организация вычислительного процесса. Неправильная организация динамически формируемых команд или параллельных вычислительных процессов. Неправильная организация переадресации команд, запись злоумышленной информации в используемые программной системой или другими программами ячейки памяти. Функции и назначение кодируемой части программной системы, взаимодействие этой части с другими подпрограммами Формирование программной закладки, воздействующей на другие части программной системы. Организация замаскированного спускового механизма программной закладки. Формирование программной закладки, изменяющей структуру программной системы. Технология записи программного обеспечения и исходных данных. Поставка программного обеспечения и технических средств со встроенными дефектами.
ОТЛАДКА И ИСПЫТАНИЯ Назначение, функционирование, архитектура программной системы Встраивание программной закладки как в отдельные подпрограммы, так и в управляющую программу программной системы. Формирование программной закладки с динамически формируемыми командами. Неправильная организация переадресации отдельных команд программной системы. Сведения о процессе испытаний (набор тестовых данных, используемые вычислительные средства, подразделения и лица, проводящие испытания, используемые модели) Формирование набора тестовых данных, не позволяющих выявить программную закладку. Поставка вычислительных средств, содержащих программные, аппаратные или программно-аппаратные закладки. Формирование программной закладки, не обнаруживаемой с помощью используемой модели объекта в силу ее неадекватности описываемому объекту.
КОНТРОЛЬ Используемые процедуры и методы контроля Формирование спускового механизма программной закладки, не включающего ее при контроле на безопасность. Маскировка программной закладки путем внесения в программную систему ложных «непреднамеренных» дефектов. Формирование программных закладок в ветвях программной системы, не проверяемых при контроле. Формирование программных закладок, не позволяющих выявить их внедрение в программную систему путем контрольного суммирования. Поставка программного обеспечения и вычислительной техники, содержащих программные, аппаратные и программно-аппаратные закладки. Сведения об обнаруженных при контроле программных закладках Разработка новых программных закладок при доработке программной системы. Сведения об обнаруженных незлоумышленных дефектах и программных закладках Сведения о доработках программной системы и подразделениях, их осуществляющих Сведения о среде функционирования программной системы и ее изменениях. Сведения о функционировании программной системы, доступе к ее загрузочному модулю и исходным данным, алгоритмах проверки сохранности программной системы и данных.

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

Угрозы нарушения безопасности ПО
Случайные	Преднамеренные
	Пассивные	Активные
Не выявленные ошибки программного обеспечения; отказы и сбои технических средств; ошибки операторов; старение носителей информации; разрушение информации под воздействием физических факторов (аварии, неправильная эксплуатация и т.п.).	Маскировка несанкционированных запросов под запросы ОС; обход программ разграничения доступа; чтение конфиденциальных данных из источников информации; подключение к каналам связи с целью получения информации («подслушивание» и/или «ретрансляция»); анализ трафика; использование терминалов и ЭВМ других операторов; намеренный вызов случайных факторов.	Незаконное применение ключей разграничения доступа; обход программ разграничения доступа; вывод из строя подсистемы регистрации и учета; уничтожение ключей шифрования и паролей; подключение к каналам связи с целью модификации, уничтожения, задержки и переупорядочивания данных; несанкционированное копирование, распространение и использование программных средств; намеренный вызов случайных факторов.

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

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

1.3.1 Классификация средств атаки на средства защиты программного обеспечения

1.3.2 Основные принципы обеспечения безопасности ПО.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

безопасности.

1.4 Оценка качества программного обеспечения

Согласно ГОСТ 28195-89 качеством программного обеспечения называ-ется совокупность потребительских свойств ПО, характеризующих способность программного обеспечения удовлетворять потребность пользователей в обработке данных в соответствии с назначением. [15]

Оценка качества ПО чаще всего проводится экспертными методами на основе технического задания и спецификации на разработку оцениваемого ПО и интуитивных представлений о том, каким должно быть данное ПО для успешного исполнения требуемых функций. К экспертизе привлекались специалисты в области применения оцениваемого ПО или будущие пользователи данного ПО. Недостатками такогометода являются, во-первых, необходимость индивидуального подхода к оценке качества каждого конкретного ПО и, во-вторых, неоднозначность и субъективность оценки. В настоящее время, оценка качества конкретного ПО производится путем раздельной оценки некоторой совокупности показателей качества оцениваемого ПО и последующим суммированием полученных оценок, в результате которого получается общая оценка качества. Формализации показателей качества посвящена группа нормативных документов. Существует международный стандарт ISO 9126:1991 , в котором выделены характеристики (показатели качества), позволяющие оценивать ПО с точки зрения пользователя, разработчика и управляющего проектом. Всего в международном стандарте рекомендуется шесть основных показателей качества ПО, каждый из которых детализирован несколькими характеристиками. Аналогом международного стандарта IS09126:1991 является российский стандарт ГОСТ 28195-89. Он близок к международному стандарту по структуре и идеологии, хотя номенклатура показателей несколько отличается от номенклатуры показателей качества, предложенной в международном стандарте.

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

• метод экспертных оценок;

• оценки с применением различных математических методов (так называемые метрики программ);

• эвристические методы, выработанные практикой.

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

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

1) Показатели сопровождения - структурная и информационная сложность ПО, структурность ПО, наглядность, повторяемость.

2) Показатели надежности.

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

4) Показатели эффективности - уровень автоматизации, временная эффективность, ресурсоемкость.

5) Показатели универсальности - гибкость, мобильность, модифицируемость.

6) Показатели корректности - логическая корректность, полнота реализации, согласованность, проверенность.

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

1.4.1 Показатели сопровождения программного обеспечения

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