Аникин_Катасёв_Кривилёв_ПАЗИ_Конспекты_лекций_2008. Конспект лекций по дисциплине Программноаппаратная защита информации специальность 090104 Комплексная защита объектов информатизации

• Название: Конспект лекций по дисциплине Программноаппаратная защита информации специальность 090104 Комплексная защита объектов информатизации
• Дата: 18.08.2020
• Размер: 1.34 Mb.
• Имя файла: Аникин_Катасёв_Кривилёв_ПАЗИ_Конспекты_лекций_2008.doc
• Тип: Конспект; #135734
• страница: 11 из 14

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

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

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

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борки ПО, предоставляемые разработчиком и полностью готовые к сборке ПО), либо непосредственно у разработчика.

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

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

3.2.4. Отчётность

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

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

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

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

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

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

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

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

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

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

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

Лекция № 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

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

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