6. Поиск критических участков кода, путем его синтаксического анализа, выявление синтаксических характерных конструкций с точки зрения РПВ, например, вирусов.

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

8. Метод Мельсона - тестирование всех путей переходов программе.

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

Изолированная программная среда

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

ИПС характеризуется выполнением следующих условий:

1. на ЭВМ с проверенным BIOS-ом установлена проверенная ОС;

2. достоверно установлена неизменность ОС и BIOSа для текущего сеанса работы пользователя;

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

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

4. исключен запуск проверенных программ вне проверенной среды;

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

Идентификацию и аутентификацию пользователя желательно также выполнять на аппаратном блоке.

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

· их принадлежность к списку разрешенных для записи

· их целостность

Лекция № 11. Сертификация программного обеспечения по уровню контроля отсутствия НДВ

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

Под НДВ понимается функциональная возможность ПО, не описанная в документации, либо не соответствующая описанным в документации., которая может привести к нарушению конфиденциальности, целостности, доступности информации.

Проверка ПО на наличие НДВ осуществляется согласно РД ФСТЭК 1998 г. «Защита от НСД. Часть 1. ПО средств защиты. Классификация по уровню контроля отсутствия НДВ». Согласно этому РД выделяется 4 уровня контроля, 1-высокий, 4 - низкий.

1 - системы, обрабатывающее информацию «Особой Важности»

2 - системы, обрабатывающее информацию «Совершенно Секретно»

3- системы, обрабатывающее информацию «Секретно»

4 - системы, обрабатывающее конфиденциальную информацию

№	Наименование требования	Уровень контроля
		4	3	2	1
	Требования к документации
1	Контроль состава и содержания документации
1.1	Спецификация (ГОСТ 19.202-78)	+	=	=	=
1.2	Описание программы (ГОСТ 19.402-78)	+	=	=	=
1.3	Описание применения (ГОСТ 19.502-78)	+	=	=	=
1.4	Пояснительная записка (ГОСТ 19.404-79)	-	+	=	=
1.5	Тексты программ, входящих в состав ПО (ГОСТ 19.401-78)	+	=	=	=
	Требования к содержанию испытаний
2	Контроль исходного состояния ПО	+	=	=	=
3	Статический анализ исходных текстов программ
3.1	Контроль полноты и отсутствия избыточности исходных текстов	+	+	+	=
3.2	Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду	+	=	=	+
3.3	Контроль связей функциональных объектов по управлению	-	+	=	=
3.4	Контроль связей функциональных объектов по информации	-	+	=	=
3.5	Контроль информационных объектов	-	+	=	=
3.6	Контроль наличия заданных конструкций в исходных текстах	-	-	+	+
3.7	Формирование перечня маршрутов выполнения функциональных объектов	-	+	+	=
3.8	Анализ критических маршрутов выполнения функциональных объектов	-	-	+	=
3.9	Анализ алгоритма работы функциональных объектов на основе блок-схем, диаграмм и т.п., построенных по исходным текстам контролируемого ПО	-	-	+	=
4	Динамический анализ исходных текстов программ
4.1	Контроль выполнения функциональных объектов	-	+	+	=
4.2	Сопоставление фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа	-	+	+	=
5	Отчётность	+	+	+	+

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

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

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

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

Контроль исходного состояния программного обеспечения.

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

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

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

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

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

Лекция № 12. Статический анализ исходных текстов программ

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

· контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов;

· контроль соответствия исходных текстов ПО его объектному (загрузочному) коду.

1. Контроль полноты и отсутствия избыточности

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

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

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

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

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

Берутся предоставленные исходные тексты (*) и производится их контрольная сборка - т.е. они компилируется и полученные модули сравниваются по контрольным суммам с модулями зафиксированного ПО (см. пункт 2)

В случае отсутствия исходных текстов используются два подхода:

1. С восстановлением исходных текстов:

· дизассемблирование;

· статический анализ;

· динамический анализ;

· с использованием отладчиков;

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

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

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

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

Последовательность действий при выполнении трансляции исходных текстов, версия транслятора, а также исходные данные (директивы) для транслятора должны соответствовать приведённым в сопроводительной документации.

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

Отчётность

По окончании испытаний оформляется отчёт (протокол), содержащий результаты:

· контроля исходного состояния программного обеспечения;

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

· контроля соответствия исходных текстов программного обеспечения его объектному (загрузочному) коду.

Требования к третьему уровню контроля

Контроль состава и содержания документации

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

Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав программного обеспечения, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.

Контроль исходного состояния программного обеспечения

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

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

Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявляются следующие требования:

· контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур);

· контроль связей функциональных объектов (модулей, процедур, функций) по управлению;

· контроль связей функциональных объектов (модулей, процедур, функций) по информации;

· контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);

· формирование перечня маршрутов выполнения функциональных объектов (процедур, функций).

Лекция № 13. Перечень типовых дефектов программного обеспечения

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

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

2. Скрытое использование приоритетных данных.

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

4. Неправильное преобразование в последовательную форму.

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

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

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

8. Незавершённые разработка и описание.

9. Недокументированные передачи управления.

10. Обход контроля или неправильные точки контроля.

11. Неправильное присвоение имен, использование псевдонимов.

12. Неполная инкапсуляция или неполное скрытие описания реализации объекта.

13. Подменяемые контрольные журналы.

14. Передача управления в середине процесса.

15. Скрытые и недокументированные вызовы из прикладных программ, команд ОС и аппаратных команд.

16. Не устранение остаточных данных или отсутствие их адекватной защиты.

17. Неправильное освобождение ресурсов.

18. Игнорирование отключения внешних приборов.

19. Неполное прерывание выполнения программ.

20. Использование параметров ОС в прикладном пространстве памяти.

21. Не удаление средств отладки до начала эксплуатации.

Формы проявления программных дефектов

(Вариант 1)

1. Выполнение арифметических операций и стандартных функций:

· деление на 0;

· переполнение разрядной сетки;

· отличие результатов арифметических операций от ожидаемых;

· обращение к стандартным функциям с недопустимыми значениями параметров.

2. Ошибки, связанные с затиранием команд и переменных.

3. Ошибки управления:

· зацикливание - бесконечное повторение одной и той же части программы;

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

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

· 4. Ошибки ввода-вывода:

· «странный» вывод (на печать, на монитор и т.д.);

· сообщения об ошибках от системных программ ввода-вывода.

(Вариант 2)

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

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

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

· значительное искажение или потеря накопленной информации о текущем состоянии управляемого процесса;

· прекращение или значительное снижение темпа решения некоторых задач вследствие перегрузки ЭВМ по пропускной способности;

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

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

· пропуск подпрограмм или их существенных частей;

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

· обработка ложных или сильно искаженных сообщений.

3. Ошибки, мало и кратковременно влияющие на результаты, выдаваемые управляющим алгоритмом.

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

Лекция № 14

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

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

Классификация угроз безопасности ОС

Классификация угроз по цели:

· Несанкционированное чтение информации.

· Несанкционированное изменение информации.

· Несанкционированное уничтожение.

· Полное или частичное разрушение операционной системы, полное или частичное ее завешивание, завешивание программных модулей, физическое стирание с диска системных файлов (вирусы, DoS).

Классификация по принципу воздействия на ОС:

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

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

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

По характеру воздействия на ОС:

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

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

По типу слабости защиты:

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

· Ошибки и недокументированные возможности программного обеспечения ОС: люки - случайные или преднамеренные служебные входы.

· Ранее внедренная программная закладка.

По способу воздействия на объект атаки:

· Непосредственное воздействие.

· Превышение пользователем своих полномочий.

· Работа от имени другого пользователя.

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

По способу действий злоумышленника:

· В интерактивном режиме.

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

По объекту атаки:

· ОС в целом.

· Объекты ОС (файлы, устройства, и т.д.).

· Субъекты ОС (пользователи, системные процессы, и т.д.).

· Каналы передачи данных.

По используемым средствам атаки:

· Штатные средства ОС, без использования дополнительного ПО.

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

· Специально разработанное ПО.

По состоянию атакуемого объекта на момент атаки: хранение, передача, обработка.

Типичные атаки на ОС

1. Сканирование файловой системы

2. Кража ключевой информации.

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

3. Подбор пароля.

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

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

5. Превышение полномочий. Злоумышленник использует дырки в ПО или ОС и получает полномочия, превышающие те, которые были ему выданы в соответствии с политикой безопасности. Обычно это достигается путем запуска программы от имени другого пользователя или подмены динамически подгружаемой библиотеки (скрипт МЭЛТ запускался от имени администратора и копировал содержимое файлов в HTML, выдавая их другому пользователю).

6. Программные закладки.

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

Лекция № 15. Понятие защищенной операционной системы

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

Данная система должна обязательно содержать следующие компоненты:

1. Средства разграничения доступа пользователей к ресурсам.

2. Средства проверки подлинности пользователя.

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

Подходы к построению защищенных ОС.

2 подхода - фрагментарный и комплексный.

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

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

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

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

Административные меры защиты

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

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

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

3. Инструктирование пользователей ОС о необходимости соблюдения мер безопасности при работе с ОС и контроль за соблюдением этих мер.

4. Регулярное создание и обновление резервных копий программ и данных ОС.

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

Адекватная политика безопасности

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

Существует некоторое противоречие - чем лучше защищена ОС, тем труднее с ней работать пользователям и администраторам. Это обусловлено следующими факторами.

1. Неинтеллектуальная СЗИ не всегда способна определить, является ли некоторое действие пользователя злонамеренным. Поэтому зачастую она не пресекает некоторые виды НСД, либо запрещает легальные действия. Чем выше защищенность, тем шире класс легальных действий, которые система запрещает. Например, если некоторому пользователю запрещено создавать файлы на ЖД, то этот пользователь не сможет запустить ни одну программу, для которой необходимо создавать временные файлы. С точки зрения рассматриваемой политики без-ти, создание временного файла является НСД, и в том, что оно пресекается ошибки нет. Просто в данной ПБ класс НСД настолько широк, что это препятствует нормальной работе пользователя с ОС.

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

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

4. Поддержание слишком жесткой политики безопасности может негативно сказаться на надежности функционирования ОС. (WIN NT - отказ от выполнения определенных программ). В некоторых случаях ошибки в организации политики трудно выявить. Пример - если запретить псевдопользователю SYSTEM, от имени которого выполняются системные процессы, доступ к исполняемым файлам системных процессов, ОС не сможет загрузиться. Таким образом, чрезмерная ПБ привела к краху ОС. В других случаях, подобная ПБ может приводить к трудно выявляемым ошибкам и сбоям в процессе функционирования.

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

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

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

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

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

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

4. Претворение в жизнь политики безопасности.

5. Поддержание и коррекция политики безопасности. Например, изменение политики при установление нового продукта.

Лекция № 16. Аппаратное обеспечение средств защиты

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

· Управление оперативной и виртуальной памятью компьютера.

· Распределение процессорного времени между задачами в многозадачной ОС.

· Синхронизация выполнения параллельных задач в многозадачной ОС.

· Обеспечение корректности совместного доступа задач к ресурсам ОС.

· Исключение тупиковых ситуаций в процессе совместного доступа задач к ресурсам ОС.

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

Управление оперативной памятью

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

Существуют 2 способа защиты ОЗУ процесса от несанкционированного доступа со стороны других процессов.

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

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

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

Управление планированием задач. Возможности атаки и защита.

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

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

1. Вытесняющее.

2. Не вытесняющее.

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

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

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

1. Поддерживается вытеснение задач.

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

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

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

Обеспечение корректности совместного доступа к объектам

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

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

Предотвращение тупиковых ситуаций

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

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

Уровни привелигированности

Для реализации защитных механизмов на Intel могут использоваться уровни привилегированности. Уровень привилегированности - это числовой идентификатор, принимающий значения от 0 до 3, который определяет возможности задачи выполнять команды процессора, модифицировать регистры и области ОЗУ и т.д. Чем меньше идентификатор уровня, тем более полный доступ имеет задача к аппаратным возможностям процессора. Множество задач, обладающих некоторым конкретным уровнем привилегированности- кольцо защиты. Например, если программа имеет уровень 3, то третье кольцо. Обычно код программы - в третьем кольце, а код ОС - в нулевом. Первое и второе - редко (OS/2). RISC - 2 кольца.

Лекция № 17. Защищенные механизмы в NT

Ядро и драйверы устройств в NT - в нулевом кольце, весь остальной код ОС и программы - в третьем. 1 и 2 - не используются.

Планирование задач

Каждый поток может находиться в одном из трех состояний -

1. Выполняющемся.

2. Ожидающем - ожидает сигнала от внешнего устройства.

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

Многозадачность - вытесняющая. Для вытеснения - аппаратное прерывание от таймера.

Каждый поток имеет приоритет - от 1 до 31. Чем выше приоритет, тем больше шансы у процесса получить квант времени. Для присвоения потокам приоритетов в NT применяется двухступенчатая система - абсолютный приоритет потока вычисляется на основе

1. Класса приоритета процесса.

2. Относительного приоритета потока.

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

· Фоновый (idle): 4

· Нормальный (normal): 9 если процесс обслуживает активное окно и 7 в противном случае.

· Высокий (high): 13.

· Реального времени (real-time): 24.

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

Относительные приоритеты могут быть следующими:

· Фоновый (idle): 16 если процесс имеет класс приоритета реального времени и 1 в противном случае.

· Низший (lowest): на 2 ниже базового приоритета процеса.

· Пониженный (below normal): на 1 ниже базового приоритета процесса.

· Нормальный (normal): совпадает с базовым приоритетом процесса.

· Повышенный: на 1 выше базового приоритета процесса.

· Высший: на 2 выше базового приоритета процесса.

· Критичный: 31, если базовый - приоритет реального времени или 16 в ином случае.

В NT поддерживается временное повышение приоритета, для потоков, которые долгое время ожидают сигнала от медленнодействующих устройств (FD, Modem).

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

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

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

Для обеспечения корректности совместного доступа к данным, не являющимся объектами ОС, в NT применяются мьютексы, критические секции и семафоры.

Мьютексы

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

Аудит

Аудит - регистрация в специальном журнале безопасности потенциально опасных событий для ОС. Необходимость ведения данного журнала обусловлена следующими причинами:

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

2. Необходимо хранить предисторию.

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

Требования к аудиту

1. Только ОС может добавлять записи в журнал безопасности ОС.

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

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

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

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

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

1. Попытки входа-выхода пользователей из системы.

2. Попытки изменения списка пользователей.

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

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

В ОС UNIX поддерживается регистракция следующих событий:

1. Загрузка-выгрузка системы.

2. Успешный вход и выход из системы.

3. Создание-уничтожение процесса.

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

5. Отобразить объект в субъект (выполнение программы).

6. Модификация объекта (запись в файл).

7. Сделать объект недоступным (закрыть файл, размонтировать файловую систему и т.д.).

8. Создание объекта (файла,...).

9. Удаление объекта.

10. Изменение разграничения доступа.

11. Отказ доступа.

12.Действия системных администраторов и операторов.

13. Процессы, которые пытаются превысить свои полномочия.

14. Отказы в рессурсах (отсутствие файла, переполнение памяти, и т.д.).

15. Посылка сигналов и сообщений процессам.

16. Модификация процесса.

17. События системы контроля.

18. События базы данных (изменение базы данных безопасности и ее целостности).

19. События подсистемы (использование защищенных подсистем).

20. Использование привилегий (контроль действий с использованием различных привилегий).

Разграничение доступа в NT

Операционная система NT поддерживает 22 метода доступа субъектов к объектам. Шесть из них представляют собой стандартные методы доступа и поддерживаются для объектов всех типов.

· Удаление объекта.

· Получение и изменение атрибутов защиты объекта

· Изменение владельца объекта.

· Получение и изменение параметров аудита в отношении объекта.

· Синхранизация - ожидание сообщения от объекта.

Для каждого типа объекта поддерживается до 16 специфичных методов доступа.

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

· Создание нового сервиса.

· Блокирование списка сервисов.

· Запуск сервиса.

· Останов сервиса.

· Приостановка/возобновление сервиса.

· Назначение процессу маркера доступа.

· Получение или изменение параметров аудита в отношении объекта.

Привилегии субъектов в NT.

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

Существуют следующие привилегии:

· Привилегия завершать работу ОС и перезагружать компьютер.

· Привилегия устанавливать системное время.

· Привилегия анализировать производительность одного процесса.

· Привилегия анализировать производительность всей ОС.

· Привилегия создавать постоянные объекты в ОЗУ.

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

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

· Привилегия назначать процессам и потокам высокие приоритеты.

· Привилегия изменять системные переменные среды.

· Привилегия отлаживать программы.

· Привилегия загружать и выгружать системные драйверы и сервисы.

· Привилегия аудита.

· Привилегия объявлять себя владельцем любого объекта.

· Привилегия добавлять записи в журнал аудита.

· Привилегия создавать маркеры доступа.

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

· Привилегия выступать как часть ОС.

· Привилегия получать оповещения от файловых систем.

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

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

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

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

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

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

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

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

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

Вопросы для контроля

Лекция 1

1. Почему аппаратная реализация защитных механизмов считается более стойкой по сравнению с программной?

2. Приведите примеры нарушения целостности программных механизмов защиты.

3. Что понимают под идентификацией и аутентификацией? В чем заключается различие данных этапов и как они связаны между собой?

4. Чем определяется стойкость к взлому подсистемы идентификации и аутентификации?

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

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

7. Перечислите требования к выбору и использованию паролей?

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

9. Как изменится стойкость к взлому подсистемы парольной аутентификации при увеличении характеристик A,L,V,T? При их уменьшении?

Лекция 2

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

2. Как реализуется защита от угрозы непосредственного доступа злоумышленника к БД аутентификации?

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

4. Сформулируйте и докажите утверждение о подмене эталона.

5. Как реализуется защита от угрозы несанкционированного изучения БД аутентификации.

6. Почему непосредственное шифрование БД аутентификации не является стойким ко взлому?

7. Опишите алгоритм хэширования LANMAN. Укажите на уязвимые места данного алгоритма.

8. Опишите алгоритм хэширования NTLM.

Лекция 3

1. Что понимают под атаками методом повторов при удаленной аутентификации?

2. В чем заключается механизм запрос-ответ при безопасной удаленной аутентификации?

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

4. Опишите схему протокола безопасной удаленной аутентификации CHAP.

5. Почему злоумышленник не может восстановить ответ клиента в протоколе CHAP?

6. Опишите протокол одноразовых ключей S/KEY.

7. Почему злоумышленник не может восстановить следующий пароль в последовательности в протоколе S/KEY?

8. Какой из паролей передается раньше в протоколе S/KEY - Y1 или Y2?

Лекция 4

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

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

3. В чем заключается различие между пассивными и активными пластиковыми картами?

4. Приведите примеры пассивных и активных карт.

5. Перечислите основные компоненты интеллектуальных карт.

6. Какова область применения интеллектуальных карт?

7. Каков размер идентификатора в iButton?

8. В каком компоненте смарт-карты хранится операционная система?

9. В какой компонент смарт-карты загружаются ключи при выполнении криптографических операций?

Лекция 5

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

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

3. Что из себя представляет вектор биометрических признаков?

4. Что понимают под коэффициентом ошибочных отказов и коэффициентом ошибочных подтверждений биометрической системы?

5. Дайте геометрическую интерпретацию коэффициентов ошибочных отказов и ошибочных подтверждений.

6. Как в биометрических системах принимается решение о прохождении либо не прохождении пользователем аутентификации?

7. Какие функции выполняют СКД?

8. Какой компонент СКД принимает решения о допуске \ недопуске пользователя на охраняемый объект?

Лекция 6

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

2. В чуть заключается суть организационно-экономических мер защиты программных продуктов?

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

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

5. В чем достоинства и недостатки встроенных и пристыковочных систем защиты ПО?

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

7. Перечислите требования к блоку сравнения характеристик среды.

8. В чем особенности атак злоумышленника на блок установки характеристик среды и блок ответной реакции?

Лекция 7

1. Что собой представляют электронные ключи HASP?

2. Перечислите типы электронных ключей HASP. Кратко охарактеризуйте их.

3. Перечислите основные элементы электронных ключей HASP.

4. Перечислите основные функции HASP4 Standard, MemoHASP, TimeHASP, NetHASP.

5. Попарно сравните возможности ключей HASP4 Standard, MemoHASP, TimeHASP, NetHASP.

6. Словесно опишите несколько приемов защиты ПО, которыми Вы будете пользоваться при использовании HASP4 Standard, MemoHASP, TimeHASP, NetHASP.

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

8. Может ли электронный ключ HASP использоваться для решения задач идентификации пользователей. Если может, то какие типы?

9. Что представляет собой модель защиты структурным кодом PCS?

Лекция 8

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

2. Перечислите средства статического исследования ПО. Кратко охарактеризуйте их.

3. Перечислите средства динамического исследования ПО. Кратко охарактеризуйте их.

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

5. Перечислите и охарактеризуйте несколько триков для отладчиков реального и защищенного режимов. В чем их недостатки?

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

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

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

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

Лекция 9

1. Охарактеризуйте средства анализа системы защиты ПО по данным. Как защититься от данных средств?

2. Охарактеризуйте средства анализа системы защиты ПО по алгоритмам. Как защититься от данных средств?

3. Охарактеризуйте средства преодоления систем защиты ПО. Как защититься от данных средств?

4. Охарактеризуйте средства обхода систем защиты ПО. Как защититься от данных средств?

5. Что понимают под опосредованным НСД?

6. Дайте определение программы с потенциально опасными последствиями. Какие функции свойственны данным программам?

7. Перечислите основные классы программ с потенциально опасными последствиями. Дайте их сравнительную характеристику.

8. Что понимают под активизирующим событием? Перечислите основные виды активизирующих событий для РПВ.