§ Модели угроз безопасности программного обеспечения

Вид материала

Лекции

Содержание 1.5.2 Подходы к созданию модели угроз технологической без­опасности ПО Используемые информационные технологии. Используемые аппаратно-технические средства. Задачи коллективов разработчиков и их персональный со­став. Функции и назначение кодируемой части программной си­стемы, взаимодействие этой части с другими подпрограмма­ми. Отладка и испытания Сведения о процессе испытаний (набор тестовых данных, используемые вычислительные средства, подразделения и лица, проводящие исп Сведения о персональном составе контролирующего подраз­деления и испытываемых программных системах. Сведения об обнаруженных при контроле программных за­кладках. Сведения о доработках программной системы и подразде­лениях, их осуществляющих. 1.5.3. Элементы модели угроз эксплуатационной безопасности ПО 1.5.4. Модель разрушающего программного средства Модели взаимодействия прикладной программы и РПС. Методы внедрения РПС.

Подобный материал:

• Учебно-методический комплекс дисциплины разработка и стандартизация программных средств, 362.73kb.
• Особенности обеспечения экономической безопасности в монопрофильных городах, 222.37kb.
• И. Ф. Бабалова московский инженерно-физический институт (государственный университет), 39.62kb.
• Администрация города ишима, 487.91kb.
• Метрология и качество программного обеспечения, 39.54kb.
• Классификация программного обеспечения, 77.32kb.
• Положение об организации обучения и проверки знаний рабочих организаций-членов нп «Объединение, 94.34kb.
• Структура программного обеспечения, 39.47kb.
• Рабочая программа учебной дисциплины (модуля) case-средства проектирования программного, 143.56kb.
• Удк 004. 056. 5 Моделирование и прогнозирование информационных угроз как составная, 94.29kb.

Лекции №2 и №3 (16.02.11)


§ 1.5. Модели угроз безопасности программного

обеспечения

1.5.1 Вводные замечания


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

Напомним, что мы рассматриваем в качестве основных угроз — внед­рение РПС в разрабатываемое ПО КС, а также деструктивное изменение различных процессов в КС.¹

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

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


1.5.2 Подходы к созданию модели угроз технологической без­опасности ПО


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

-полный реестр типов возможных РПС;

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

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

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

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

В основе модели может лежать схема угроз, типовой вид которой при­менительно к ПО КС представлен на рис. 1.1.



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


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


ПРОЕКТИРОВАНИЕ

Проектные решения.

Злоумышленный выбор нерациональных алгоритмов работы.

Облегчение внесения РПС и затруднение их обнаружения.

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

Используемые информационные технологии.

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

Внедрение информационных технологий или их элементов, со­держащих РПС.

Внедрение неоптимальных информационных технологий.

Используемые аппаратно-технические средства.

Поставка вычислительных средств, содержащих программные, аппаратные или программно-аппаратные закладки.

Поставка вычислительных средств с низкими эксплуатационными ха­рактеристиками.

Задачи коллективов разработчиков и их персональный со­став.

Внедрение злоумышленников в коллективы разработчиков про­граммных и аппаратных средств.

Вербовка сотрудников путем подкупа, шантажа и т.п.


КОДИРОВАНИЕ

Архитектура программной системы, взаимодействие ее с внешней средой и взаимодействие подпрограмм программной системы.

Доступ к «чужим» подпрограммам и данным.

Нерациональная организация вычислительного процесса.

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

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

Функции и назначение кодируемой части программной си­стемы, взаимодействие этой части с другими подпрограмма­ми.

Формирование РПС, воздействующей на другие части программ­ной системы.

Организация замаскированного спускового механизма РПС.

Формирование РПС, изменяющей структуру программной си­стемы.

Технология записи программного обеспечения и исходных данных.

Поставка программного обеспечения и технических средств со встроенными РПС.


ОТЛАДКА И ИСПЫТАНИЯ

Назначение, функционирование, архитектура программной системы.

Встраивание РПС как в отдельные подпрограммы, так и в управ­ляющую программу компьютерной системы.

Формирование РПС с динамически формируемыми командами.

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

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

Формирование набора тестовых данных, не позволяющих вы­явить РПС.

Поставка вычислительных средств, содержащих программные, аппаратные или программно-аппаратные закладки.

Формирование РПС, не обнаруживаемой с помощью используемой модели объекта в силу ее неадекватности описываемому объекту.

Вербовка сотрудников коллектива, проводящих, испытания.


КОНТРОЛЬ

Используемые процедуры и методы контроля.

Формирование спускового механизма РПС, не включающего ее при контроле на безопасности.

Маскировка РПС путем внесения в программную систему лож­ных «непреднамеренных» дефектов.

Формирование РПС в ветвях программной системы, не проверя­емых при контроле.

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

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

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

Внедрение злоумышленников в контролирующее подразделение.

Вербовка сотрудников контролирующего подразделения.

Сбор информации об испытываемой программной системе.

Сведения об обнаруженных при контроле программных за­кладках.

Разработка новых РПС при доработке программной системы Сведения об обнаруженных непреднамеренных дефектах а РПС.

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

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

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


1.5.3. Элементы модели угроз эксплуатационной безопасности ПО


Анализ угроз эксплуатационной безопасности ПО КС [7, 41, 45, 48,
63, 69, 118, 142, 147, 165] позволяет разделить их на два типа: случайные и преднамеренные, причем последние подразделяются на активные и пассивные. Активные угрозы связаны с изменением технологически обусловленных алгоритмов, программ функциональных преобразований или информации, над которой эти преобразования осуществляются. Пассивные угрозы ориентированы на нарушение безопасности информационных технологий без реализации таких модификаций.
Вариант структуры потенциальных угроз безопасности информации
и ПО на этапе эксплуатации КС приведен в таблице 1.1.

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

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

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

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

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

1.5.4. Модель разрушающего программного средства


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

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

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

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

• разрушение или модификация кода программ в оперативной памяти КС;

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

• искажение произвольным образом, блокировки и/или подмены вы­водимых во внешнюю память или в канал связи данных, образовав­шихся в результате работы прикладных программ.

Можно выделить следующие основные типы РПС.

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

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

Существуют три основные архитектуры построения перехватчиков па­ролей.

1. Перехватчики паролей первого рода осуществляют сценарий ими­тации ошибки ввода идентификатора и/или пароля. Злоумышленник за­пускает программу, содержащую РПС — перехватчик паролей. Он ими­тирует приглашение пользователю для входа в систему и ждет от него ввода соответствующих данных. Когда пользователь вводит идентифи­катор и пароль, РПС сохраняет их в доступном для злоумышленника месте, после чего завершает работу и осуществляет выход из системы пользователя-злоумышленника. По окончании работы РПС на экране появляется настоящее приглашение для входа пользователя в систему. Пользователь, ставший «жертвой» РПС, видит, что он не вошел в систему и ему снова предлагается ввести идентификатор и пароль. Пользователь предполагает, что при вводе пароля произошла ошибка, и вводит иденти­фикатор и пароль повторно. После этого он входит в систему, и дальнейшая его работа протекает нормально.

2. Перехватчики паролей второго рода перехватывают данные, вво­димые пользователем с клавиатуры. Простейшие РПС данного типа просто сбрасывают все эти данные на какой-либо носитель, доступный для злоумышленника. Более совершенные РПС анализируют перехвачен­ные данные и отсеивают информацию, заведомо не имеющую отношения к идентификаторам и паролям. Эти РПС представляют собой резидентные программы, перехватывающие одно или несколько прерывании , исполь­зуемых при работе с клавиатурой. Информация о введенном символе, возвращаемая этими прерываниями, используется закладками дли своих целей.

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

Перехватчики потоков данных. Такие РПС перехватывают те или иные потоки данных, протекающие в атакованной системе. В частности, к ним относятся перехватчики паролей второго рода.

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

• собственно перехватывать потоки данных;

• сохранять перехваченную информацию в доступном для злоумыш­ленника месте;

• модифицировать потоки данных;

• полностью или частично блокировать потоки данных;

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

Разрушающие программные средства, осуществляющие превы­шение полномочий пользователя. Такие РПС применяются для преодо­ления тех систем защиты, в которых реализовано разграничение доступа пользователей к объектам доступа. РПС данного типа позволяют зло­умышленнику осуществлять доступ к тем объектам, доступ к которым дол­жен быть ему запрещен согласно текущей политике безопасности. Если, например, РПС наделяет пользователя-злоумышленника полномочиями администратора, то злоумышленник имеет практически неограниченный доступ к ресурсам КС. Чаще всего РПС данного класса используют ошиб­ки в программном обеспечении.

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

Иногда выделяют особый класс логических бомб — временные или событийные бомбы, для которых условием срабатывания является до-' стижение определенного момента времени или наступление какого-либо события. Характерным свойством логических бомб является то, что реа-' лизуемые ими негативные воздействия на атакованную КС носят исклю­чительно разрушающий характер.

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

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

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

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

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

1) РПС резидентного типа — находятся в памяти постоянно с некото­рого момента времени до окончания сеанса работы компьютера (вы­ключения питания или перезагрузки); РПС может быть загружено" в память при начальной загрузке компьютера, загрузке операцион­ной среды или запуске некоторой программы (которая по традиции называется вирус оное ител ем или просто носителем), а также запу­щено отдельно;

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

Модели взаимодействия прикладной программы и РПС. Обоб­щенную модель РПС можно представить в виде совокупности моделей, каждая из которых соответствует приведенной выше типизации РПС и ха­рактеризует действия злоумышленника исходя из его возможностей [124]. Кроме того, очень важно представлять сценарии взаимодействия РПС и атакуемого им объекта защиты (прикладной программы, операцион­ной системы, системного сервиса, постоянного запоминающего устройства и т.д.). Моделирование такого взаимодействия для разных типов РПС можно представить в виде «работы» совокупности «сопряженных» мо­делей, описываемых ниже.

1. Модель «перехват». Разрушающее программное средство встра­ивается (внедряется) в объект защиты и сохраняет все или избранные фрагменты вводимой, выводимой или обрабатываемой информации в скры­той области локальной или удаленной внешней памяти прямого доступа. Объектом сохранения могут быть данные клавиатурного ввода, докумен­ты, выводимые на принтер/монитор, или уничтожаемые файлы/документы. Необходимо также, чтобы сохраняемая информация была каким-либо об­разом замаскирована от просмотра легальными пользователями.

2. Модель «троянский конь». Разрушающее программное средство встраивается в постоянно используемое программное обеспечение и по некоторому активизирующему событию имитирует сбойную ситуацию на средствах хранения информации или в оборудовании КС. Тем самым могут быть достигнуты две цели: во-первых, может быть парализована нор­мальная работа КС и, во-вторых, злоумышленник (например, под видом обслуживания или ремонта) может ознакомиться с имеющейся в системе или накопленной посредством использования модели «перехват» инфор­мацией. Событием, активизирующим РПС, может быть некоторый момент времени, либо сигнал из канала связи (явный или замаскированный), либо состояние некоторых счетчиков (например, число запусков программ).

3. Модель «наблюдатель». Разрушающее программное средство встраивается в сетевое или телекоммуникационное программное обес­печение, которое, как правило, всегда активно. В таком случае РПС осуществляет контроль за процессами обработки информации в данной КС, а также съем накопленной информации. Такая РПС может иници­ировать события для ранее внедренных РПС, действующих по модели «троянский конь».

4. Модель «компрометация». Разрушающее программное средство либо передает заданную злоумышленником информацию (например, дан­ные клавиатурного ввода) в канал связи, либо сохраняет ее на соответству­ющих носителях данных. Более редкий, но имеющий место в современной компьютерной практике случай — РПС инициирует постоянное обращение к информации, приводящее к росту отношения сигнал/шум для перехвата злоумышленником побочных излучений".

5. Модель «искажение данных или инициирование ошибок». Раз­рушающее программное средство искажает входные и/или выходные по­токи данных, возникающие при работе прикладных программ, либо ини­циирует (или подавляет) возникающие при работе прикладных программ ошибки.

6. Модель «сборка мусора». Разрушающее программное средство в данном случае не оказывает прямого влияния на прикладные про­граммы,— изучается лишь остаточная информация. В случае применения такого РПС навязывается такой порядок работы, чтобы максимизировать количество остающихся фрагментов ценной информации. Злоумышленник получает либо данные фрагменты, используя РПС моделей 2 и 3, либо непосредственный доступ к компьютеру под видом ремонта или профи­лактики.

Методы внедрения РПС. Можно выделить следующие основные методы внедрения РПС [124].

1. Маскировка РПС в «безобидном» программном обеспечении. Данный метод заключается в том, что РПС внедряется в КС в составе новой программы, на первый взгляд вполне безобидной. Такое РПС может быть внедрено в офисные программы, системные сервисы, компьютерные игры и т. п. После внедрения РПС его присутствие в системе не нужно мас­кировать— даже если администратор заметит факт появления в системе новой программы, он не придаст этому значения, поскольку эта программа внешне совершенно безобидна.

Многие программные среды допускают свое расширение дополни­тельными программными модулями. Например, для операционных систем семейства М!сгозоГ1 \УЫо\У5 модулями расширения могут выступать ди­намически подгружаемые библиотеки (ОЬЦ и драйверы устройств. В таких модулях расширения может также содержаться РПС, которое потенциаль­но может быть внедрено в систему.

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

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

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

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

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

Это, в свою очередь, позволит снизить ущерб от действия и последей­ствия РПС, а в ряде случаев и вообще избежать его.