Geum.ru

Уткин В. Б. У 84 Информационные системы в экономике: Учебник для студ высш учеб, заведений / В. Б. Уткин, К. В. Балдин

Вид материалаУчебник

Содержание


3.2. Исследование причин нарушений безопасности
Уязвимость защиты
Подобный материал:
1   2   3   4   5   6   7   8   9   ...   21
^

3.2. Исследование причин нарушений безопасности



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

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

В 70-х гг. XX в. были предприняты попытки формального описания и систематизации информации об УЗ. Исследования проводились по проектам RISOS (Исследование безопасности защищенных операционных систем) и РА (Анализ защиты).

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

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

1. Каким образом ошибки, приводящие к появлению УЗ, вносятся в систему защиты?

2. Когда, на каком этапе они вносятся?

3. Где, в каких компонентах системы защиты (или ВС в целом) они возникают и проявляются?

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

I. Преднамеренные.

1. С наличием деструктивных функций (активные):

а) разрушающие программные средства (РПС) (несамовоспроизводящиеся РПС («троянские кони»), самовоспроизводящиеся РПС (вирусы));

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

2. Без деструктивных функций (пассивные),

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

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

II. Непреднамеренные.

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

2. Ошибки определения областей (доменов).

3. Ошибки последовательностей действий и использования нескольких имен для одного объекта.

4. Ошибки идентификации/аутентификации.

5. Ошибки проверки границ объектов.

6. Другие ошибки в логике функционирования.

Этап внедрения ошибки и возникновения УЗ может происходить:
  • на стадии разработки (ошибки при проектировании; ошибки при написании программ);
  • стадии настройки систем;
  • стадии сопровождения;
  • стадии эксплуатации.

Классификация УЗ по размещению в системе:

1. Программное обеспечение:

а) операционная система:
  • инициализация (загрузка);
  • управление выделением памяти;
  • управление процессами;
  • управление устройствами;
  • управление файловой системой;
  • средства идентификации и аутентификации;
  • другие;

б) сервисные программы и утилиты:
  • привилегированные утилиты;
  • непривилегированные утилиты;

в) прикладные программы.

2. Аппаратное размещение.

Таксономия причин возникновения УЗ должна дать ответ на имеющий ключевое значение с практической точки зрения вопрос: что явилось причиной успешного осуществления нарушения безопасности в том или ином случае?

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

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

2) причины, обусловленные принципами организации системы обеспечения безопасности:
  • неправильное внедрение модели безопасности;
  • отсутствие идентификации и/или аутентификации субъектов и объектов;
  • отсутствие контроля целостности средств обеспечения безопасности;

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

4) ошибки администрирования.

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

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

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

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

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