Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
LEKTsII_obschie.doc
Скачиваний:
4
Добавлен:
01.07.2025
Размер:
1 Мб
Скачать
☆

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

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

Общей классификации угроз не существует. Имеет смысл различать неумышленные и умышленные угрозы.

Неумышленные угрозы связаны с:

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

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

  • Форс-мажорными обстоятельствами

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

    • Незаконное проникновение под видом легального пользователя

    • Нарушение функционирования системы с помощью программ-вирусов или программ-червей.

    • Нелегальные действия легального пользователя.

    • Типизация угроз не слишком строгая.

А.Таненбаум приводит свой список наиболее успешных атак на ОС:

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

      • Попытки выполнения нелегальных системных вызовов, или системных вызовов с нелегальными параметрами

      • Внедрение программы, которая выводит на экран слово login . Многие легальные пользователи, видя такое, начинают пытаться входить в систему, и их попытки могут протоколироваться (вариант Троянского коня).

      • Попытки торпедировать программу проверки входа в систему путем многократного нажатия клавиш del, break, rubout, cancel и.т.д. В некоторых системах проверочная программа погибает, и вход в систему становится возможным.

      • Подкуп персонала. Hапример, малооплачиваемого секретаря.

      • Использование закладных элементов (дыр), специально оставленных дизайнерами системы.

      • И т.д.

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

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

3.3.3 Формализация подхода к обеспечению информационной безопасности. Классы безопасности

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

  • оранжевая (по цвету обложки) книга МО США

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

  • руководящие документы Гостехкомиссии при Президенте РФ

  • рекомендации X.800 по защите распределенных систем

  • федеральный закон Об информации, информатизации и защите информации.

  • и др.

Основополагающие документы открыли путь к ранжированию информационных систем по степени надежности. Так, в Оранжевой книге определяется четыре уровня безопасности - D , С , В и А. По мере перехода от уровня D до А к надежности систем предъявляются все более жесткие требования. Уровни С и В подразделяются на классы (C1, С2, В1, В2, ВЗ). Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять оговоренным требованиям.

В качестве примера рассмотрим требования класса C2, которому удовлетворяют некоторые популярные ОС (Windows NT, отдельные реализации Unix и др.):

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

  • Операционная система должна защищать объекты от повторного использования.

  • Владелец ресурса (например, такого как файл) должен иметь возможность контролировать доступ к этому ресурсу.

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

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

15.4 Политика безопасности

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

  • Какую информацию защищать?

  • Какого рода атаки на безопасность системы могут быть предприняты?

  • Какие средства использовать для защиты каждого вида информации?

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

Формируя политику безопасности необходимо учитывать несколько базовых принципов. Так, Saltzer и Schroeder (1975) на основе своего опыта работы с MULTICS сформулировали следующие принципы разработки ОС:

  • Проектирование системы должно быть открытым. Hарушитель и так все знает. (криптографические алгоритмы открыты)

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

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

  • Давать каждому процессу минимум возможных привилегий. ...

  • Защитные механизмы должны быть просты, постоянны и встроены в нижний слой системы, это не аддитивные добавки. (Известно много неудачных попыток улучшения защиты слабо приспособленной для этого ОС MS-DOS).

  • Физиологическая приемлемость. Если пользователь видит, что защита требует слишком много усилий, он от нее откажется.

Можно добавить еще ряд, например:

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

    • Принцип единого контрольно-пропускного пункта

    • Принцип баланса возможного ущерба от реализации угрозы и затрат на ее предотвращение

    • И ряд других.

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