Зегжда Д.П. Информационная безопасность

Подождите немного. Документ загружается.

Наиболее распространены случайные ошибки в исходных текстах программ. Чаще

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

интерфейсов модулей, либо просто из-за ошибок программистов.

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

Программист может внедрить в систему код, не предусмотренный ее спецификациями,

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

по завершению разработки этот код не будет удален из программы, он превратится в

реальный канал утечки информации и может быть использован злоумышленником.

Самый известный пример такого рода—программа Sendmail, позволившая широко

распространиться сетевому вирусу Морриса (смотри пример U10 в Приложении 1).

Генерация исполняемого кода.

Исполняемый код генерируется компиляторами из исходных текстов программ и

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

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

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

во второй. Однако если ошибки содержатся в самом компиляторе, они могут

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

нужных им фрагментов кода (смотри пример U1 в приложении 1).

Возникновение ПББ в процессе сопровождения и развития системы.

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

обусловлены неправильным представлением программистами всех аспектов

функционирования системы в целом. Любые изменения, вносимые ими в систему,

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

такой ситуации каждое вносимое изменение должно сопровождаться тщательной

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

Возникновение ПББ в процессе функционирования системы.

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

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

воздействия на нее специально написанных программ (РПС).

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

необходимости постоянного контроля и анализа состояния системы и исполняемых

файлов[18] Основной задачей такого анализа в процессе функционирования системы

является выявление несанкционированной модификации каких-либо фрагментов

исполняемого кода. Очевидно, что целью РПС является не просто модификация кода, а

нарушение функционирования системы и возможно доступ к конфиденциальным

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

3.3.3. классификация ПББ по размещению в системе.

ПББ можно классифицировать по их размещению в ВС, в зависимости от того, в каких

компонентах системы они находятся. Большинство ошибок, приводящих к возникновению ПББ и

нарушению требований защиты, присутствует в программном обеспечении; в тоже время они

встречаются и в аппаратуре. Хотя в данной работе основное внимание уделено исследованию

таксономии ПББ в программном обеспечении вообще и в операционных системах в частности,

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

платформы. Этот факт, а также то, что ПББ может использовать ошибки аппаратуры, определяет

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

программном обеспечении" и "ошибки аппаратных платформ" — смотри Таблицу 3.3.

Кол-во

примеров

Индексы в

приложении

Размещение

в ВС

Программное

обеспечение

Операционные

системы

Инициализация ОС

(загрузка)

2 U5, U13,

PC2, PC4,

MA1, MA2,

AT1, CA1

Управление выделением

памяти

8 MT3, MU5

Управление процессами 10 I6, I9, MT1,

MT2, MU2,

MU3, MU4,

MU6, U7,

UN1

Управление

устройствами

3 I2, I3, I4

Управление файловой

системой

6 I1, I5, MU8,

U2, U3, U9

Средства идентификации

и аутентификации

5 MU1, DT1,

U6, U11, D1

Другие (неизвестные) 1 MT4

Сервисные

программы и

утилиты

Привилегированные

утилиты

10 I7, B1, U4,

U7, U8,

U10, U12,

U14, PC1,

PC3

Непривилегированные

утилиты

1 U1

Прикладные программы 1 I8

Аппаратное обеспечение 3 MU9, D2,

IN1

Таблица 3.3. Таксономия ПББ по размещению в вычислительной системе.

Ошибки и каналы утечки в программном обеспечении.

Компоненты программного обеспечения, вне зависимости от их конкретного

предназначения, чрезвычайно сильно связаны и взаимозависимы. Поэтому предлагаемое

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

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

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

реализована архитектура всей вычислительной системы, в целом, и наличие в ней

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

серьезные последствия для всей ВС в целом.

Непосредственно с ОС связано сервисное программное обеспечение,

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

того, существует прикладное программное обеспечение, с которым непосредственно

работают пользователи.

Системное программное обеспечение.

Операционная система обычно включают в себя функции управления процессами,

устройствами, распределением памяти, файловой системой и т.д. Кроме того, она

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

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

системе, в данной работе из их состава выделен только механизм

идентификации/аутентификации — как один из важнейших и присущий всем системам

без исключения.

Таким образом, ПББ в операционной системе могут быть разделены по следующим

категориям:

- инициализация (загрузка) системы;

- управление распределением памяти;

- управление устройствами;

- управление процессами;

- управление файловой системой;

- идентификация и аутентификация.

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

дополнительную категорию "другие" (неизвестные).

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

времени и функциям, все же достаточно сложен и значительно различается от системы к

системе. Ошибки на этапе инициализации могут возникнуть в результате неправильного

взаимодействия с аппаратурой (например, если произошли изменения в составе

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

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

доступа процессов и пользователей к ресурсам системы.

Управление процессами и управление распределением памяти — основные задачи

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

злоумышленником контроля над всей системой и свободному доступу к любой

информации.

Управление устройствами подразумевает наличие комплекса программ

ввода/вывода, обеспечивающих функционирование этих устройств параллельно и

независимо от центрального процессора. Ошибки в таких программах, например,

ошибки приема/передачи управляющих параметров и команд устройствам (возможно

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

значений) приводят либо к отказам и сбоям в работе устройств, либо позволяют

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

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

— управление процессами, устройствами, распределением памяти и т.д. Соответственно,

ошибки в этих компонентах автоматически распространяются и на файловую систему.

Кроме того, файловой системе присущи и собственные ошибки, касающиеся хранения

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

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

механизмы обеспечения безопасности, принадлежащие операционной системе,

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

системой. Наличие ошибок в механизмах управления файловой системой способно

привести к нарушению функционирования и безопасности всей ВС в целом.

Идентификация и аутентификация являются отправными точками в

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

содержит специальные файлы, в которых хранятся имена и пароли, на основании

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

только адекватную реализацию процедур идентификации и аутентификации, но и

всестороннюю защиту этих файлов от несанкционированного доступа и изменения,

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

соответствующие полномочия.

Сервисное программное обеспечение.

Термин "сервисное программное обеспечение" включает в себя компиляторы,

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

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

специальные привилегии, превышающие привилегии работающего с ними пользователя.

Поэтому о сервисном программном обеспечении можно говорить как о множестве

привилегированных утилит.

Привилегированные утилиты, как правило, являются сложными программами, и

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

Кроме того, они разрабатываются отдельно от последней и могут не поддерживать

принятые в ней требования и ограничения безопасности, даже при наличии собственной

системы защиты. Это означает, что привилегированные утилиты являются потенциально

опасными с точки зрения защиты ВС в целом.

Наличие ошибок в реализации систем защиты привилегированных утилит или

каналов утечки информации в них

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

возможности, соответствующие специальным привилегиям утилиты, с которой он

работает, что с точки зрения безопасности будет серьезным нарушением. Наиболее

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

программ ОС Unix (смотри пример U5 в Приложении 1).

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

Нарушения в функционировании вычислительных систем, вызванные

неумышленными ошибками в прикладном программном обеспечении, обычно

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

функционирует либо саморазрушается. Однако это не означает, что все ошибки в

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

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

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

могут стать любые компоненты вычислительной системы, и в результате такого

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

системы из строя. В этом случае успех атаки зависит от того, насколько защищена

конкретная ОС от разрушительных действий прикладных программ.

Многопользовательские многозадачные ОС (такие как Unix) сравнительно легко

справляются с подобной проблемой, а широко распространенные DOS и Windows в этой

ситуации оказываются практически бессильными.

3.3.4. результаты исследования таксономии ПББ и возможность их

практического применения.

Рассмотренная таксономия ПББ, основанная на результатах исследования [1] дает

достаточно полное представление о классификации ПББ с точки зрения источника их

появления, этапа возникновения и размещения в ВС. Эти результаты, несомненно,

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

теоретическую ценность для пассивного исследования и классификации ПББ. С точки

зрения поиска путей и способов противостояния угрозам безопасности, этого

недостаточно, т. к. отсутствует классификация причин нарушений безопасности.

Поэтомупредставляется целесообразным провести анализ случаев нарушения

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

представление о первоисточниках данного явления Такая таксономия будет служить

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

устраняющих причины существования ПББ, и, следовательно, обеспечивающих

максимальную безопасность

3.4 Исследование причин

возникновения ПББ.

3.4.1. Таксономия причин возникновения ПББ.

По мнению авторов сложившаяся практика исследования случаев нарушения

безопасности, уделяющая основное внимание методам и средствам преодоления защиты,

обладает существенным недостатком — отталкиваясь от действий злоумышленника она,

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

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

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

классифицируемые по способам преодоления защиты, и неумышленные, обусловленные

ошибками программирования Авторы придерживаются прагматической точки зрения на

этот вопрос — важен сам факт нарушения безопасности и те меры, которые необходимо

предпринять для предотвращения подобных нарушений, а преднамеренность не имеет

значения.

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

предпосылки случайных нарушений предопределены свойствами самой ВС — ее

архитектурой, реализацией и администрированием Анализ случаев нарушения

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

нарушителем, сколько на выявлении свойств системы, позволивших ему осуществить

свои действия Поэтому авторы попытались построить таксономию причин нарушений

безопасности ВС, или причин возникновения ПББ, связывающую случаи нарушения

безопасности с принципами организации защиты ВС, обусловившими их существование

Таксономия причин возникновения ПББ должна дать ответ на имеющий ключевое

значение с практической точки зрения вопрос: что явилось причиной успешного

осуществления нарушения безопасности в том или ином случае? Для ответа на него

необходимо выявить те свойства и особенности архитектуры ВС, которые привели к

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

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

безопасность, а также понять недостатки в существующих средствах обеспечения

безопасности, которые привели к соответствующим нарушениям, и построить

защищенную систему, лишенную этих недостатков.

Рассмотрим с этой точки зрения известные случаи нарушения безопасности ВС,

используя в качестве примеров статистику из Приложения 1. Анализ показывает, что все

случаи произошли по одной из следующих причин (см. рис. 3.1):

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

ВС. Модель безопасности(см гл.2) должна соответствовать как требованиям,

предъявляемым к безопасности ВС, так и принятой в ней парадигме обработке

информации. В настоящий момент наблюдается определенное несоответствие между

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

безопасности существуют только в виде теории, а разработчики ОС вынуждены

подвергать их интерпретации, чтобы приспособить к той или иной конкретной ОС. При

этом приходится идти на определенные компромиссы, и может оказаться, что модель

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

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

противном случае, несмотря на все достоинства модели, гарантированного ею уровня

безопасности достичь не удастся.

2. Неправильное внедрение модели безопасности. В этом случае модель

безопасности была выбрана верно, но ее применение к конкретной реализации ОС в силу

свойств модели или самой ОС было проведено неудачно. Это означает, что при

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

доказательстве безопасности модели. Это наиболее распространенная причина

нарушения безопасности ВС Обычно, неправильное внедрение модели безопасности в

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

безопасности ОС и системным службам и объектам, а также введении различных

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

привилегированных процессов, утилит и т. д. В качестве примеров можно привести

случаи, обозначенные в Приложении 1 индексами 11, 14, 16, 17, MU3, В1, UN1, U4, U5,

U14.

3. Отсутствие идентификации и/или аутентификации субъектов и объектов. Во

многих современных ОС (различные версии Unix, Novell Netware, Wndows)

идентификация и аутентификация субъектов и объектов взаимодействия находятся на

весьма примитивном уровне — субъект взаимодействия может сравнительно легко

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

информации. Кроме того, можно внедрить в систему "ложный" объект, который будет

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

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

уровни взаимодействия — так, например, в ОС Novell Netware предусмотрена

аутентификация пользователя, но отсутствует аутентификация рабочей станции и

сервера (см главу 4). В стандартной версии ОС Unix аутентификация пользователей

находится на очень примитивном уровне — программы подбора пароля легко

справляются со своей задачей при наличии у злоумышленника идентификатора

пользователя и зашифрованного пароля. Ряд служб ОС Unix(B первую очередь сетевые

службы) в силу сложившихся традиций (необходимости соблюсти требования по

совместимости в глобальном масштабе) вообще не предусматривает аутентификации.

Пример в Приложении 1 — MU1

Рис.3.1. причины нарушения безопасности ВС.

Причины нарушения безопасности ВС

Предопределенные

на стадии

разработки

требований

Обусловленные

принципами

организации системы

обеспечения

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

Обусловленные

реализацией

Ошибки

администрирован

ия

Ошибки, допущенные в

ходе программной

реализации систем

обеспечения безопасности

Наличие средств

отладки и тестирования

в конечных продуктах

Отсутствие

контроля

целостности

средств

обеспечения

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

Неправильное

внедрение модели

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

Отсутствие

идентификации

и/или

аутентификации

субъектов и объектов

Выбор модели

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

несоответствую

щей

назначению или

архитектуре ВС

4. Отсутствие контроля целостности средств обеспечения безопасности. Во многих

ОС слабое внимание уделено контролю целостности самих механизмов, реализующих

функции защиты. Как уже говорилось, в условиях распространения РПС контроль

целостности приобретает решающее значение. Во многих системах возможна прозрачная

для служб безопасности подмена компонентов. В ОС Unix традиционно система

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

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

уровень(с помощью механизма замены прав пользователя на права владельца

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

т.к. нуждаются в проверке на безопасность при установке в систему и постоянном

контроле целостности. С точки зрения безопасности такая ситуация нежелательна — не

соблюдается принцип минимальной достаточности при распределении полномочий

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

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

ограничен. Этого можно достигнуть путем последовательного применения принципа

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

Пример — U1.

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

безопасности. Эта группа причин нарушения безопасности будет существовать до тех

пор, пока не появятся технологии программирования, гарантирующие производство

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

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

продуктов (особенно реализующих функции защиты) позволит сократить вероятность

появления подобных ошибок до минимума. Примеры: МТ1, MU2, DT1, D1, U2, U3, U7,

U11, U12.

6. Наличие средств отладки и тестирования в конечных продуктах. Многие

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

возможности и т.д. Наиболее известные примеры — отладочная опция в программе

sendmail и встроенный отладчик ОС Novell NetWare Причины, по которым это

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

и отладить их в лабораторных условиях становится просто невозможно. Следовательно,

для определения причин сбоев и ошибок уже в процессе эксплуатации, разработчикам

приходится оставлять в своих продуктах возможности для отладки и диагностики.

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

применение подобной практики недопустимо. Пример U10.

7. Ошибки администрирования. Наличие самых современных и совершенных

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

остается человеческий фактор — администратор, управляющий средствами обеспечения

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

нет. Неграмотное администрирование является достаточно распространенной причиной

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

защиты

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

отличие от существующих подходов (в частности от описанных выше) позволяет

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

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

влияющих на реальную степень безопасности системы.

3.4.2. взаимосвязь таксономии причин нарушения безопасности и таксономии

ПББ.

Рассмотрим взаимосвязь между рассмотренной таксономией причин

возникновения ПББ и предложенной в работе[1] классификацией источников

возникновения и этапов внедрения ПББ.

При сопоставлении таксономии причин нарушения безопасности и классификации

источников возникновения ПББ[1] возникает следующая картина.

Как видно из рисунка 3.2, источником возникновения наибольшего количества

категорий ПББ является неправильное внедрение модели безопасности и ошибки в ходе

программной реализации. Это означает, что эти причины являются более значимыми, и

должны быть устранены в первую очередь.

На рис 3.3. показано соответствие между причинами нарушений безопасности и

классификацией ПББ по этапу внесения[1].

Из рис.3.3. следует, что появление основных причин нарушения безопасности

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

Это вполне ожидаемый вывод т.к. именно этап составления спецификаций является

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

всех дальнейших этапах разработки и распространяются на все взаимосвязанные

компоненты системы.

Перекрестный анализ таксономии причин нарушений безопасности и

классификаций ПББ по источнику возникновения и этапу появления показывает, что

наиболее значимые причины (неправильное внедрение модели безопасности и ошибки

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

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

защищенных систем.

Сопоставление причин нарушения безопасности с размещением ПББ в системе

нецелесообразно, т.к. большинство причин приводит к возникновению ПББ практически

в любом компоненте ВС.

Из приведенного сопоставления следует, что указанные причины нарушения

безопасности полностью охватывают как все аспекты происхождения, так и этапы

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

обладают более высокой степенью общности.

Таким образом, предлагаемая таксономия причин нарушения безопасности

полностью подтверждается существующими исследованиями таксономии ПББ.

Ошибки проверки границ

объектов

Ошибки в логике

функционирования

Ошибки, допущенные в ходе

программной реализации систем

обеспечения безопасности

Неправильное внедрение модели

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

Рис.3.2. Сопоставление таксономии причин нарушения безопасности и классификации

источников возникновения ПББ.

3.5 Заключение.

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

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

разработки ВС на котором она может быть ликвидирована. Как следует из данных

исследований наибольшее значение имеют принципы организации защиты и средства

разграничения доступа, т.е. те основы безопасности ВС, которые закладывается на

ранних стадиях разработки — выработки требований, разработки концепции создания

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

защищенной ВС.

Ошибки контроля допустимых

значений параметров

Скрытые каналы утечки

информации

Черные ходы, люки, скрытые

возможности проникновения в

систему

Ошибки определения областей

(доменов)

Ошибки последовательности

действий и использования

нескольких имен для одного

объекта

Выбор модели безопасности,

несоответствующей назначению или

архитектуре ВС

Отсутствие контроля целостности

средств обеспечения безопасности

Отсутствие идентификации и/или

аутентификации субъектов и объектов

Наличие средств отладки и

тестирования в конечных продуктах

Ошибки администрирования

РПС

Ошибки

идентификации/аутентификации

Внесение

ПББ в ходе

разработки

Ошибки в

требованиях

Ошибки в

спецификациях

Ошибки в исходных

текстах программ

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

назначению или архитектуре ВС

Неправильное внедрение модели безопасности

Отсутствие идентификации и/или аутентификации

субъектов и объектов