Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Теоретические основы защиты информации. Учебное пособие
.pdf
Ошибки администрирования
Можно выделить следующие типы ошибок администрирования.
1. Ошибки конфигурирования. Включают ошибки установки и
выбора режимов функционирования программного обеспечения
вычислительной системы. При существовании ошибок конфигурирования уязвимости не содержатся непосредственно в программном обеспечении, а вносятся в систему администратором. Можно
привести следующие примеры ошибок данного типа:
– программное обеспечение установлено в неверном месте
(например, в разделяемый всеми пользователями каталог);
– программное обеспечение установлено с неверными пара-
метрами установки (при этом возможно последующее функционирование программ в небезопасном режиме);
– установлены некорректные права доступа к установленным
программам, файлам данных аудита и рабочим каталогам;
2. Ошибки окружения. При существовании ошибок окружения
уязвимости не содержатся непосредственно в программном обеспечении, а вносятся в систему администратором. К ошибкам данного типа относятся ошибки, связанные с некорректной обработкой переменных окружения, ошибки командного интерпретатора.
13.3. Поиск уязвимостей в процессе разработки
и анализа систем
Поиск уязвимостей в процессе разработки и анализа системы
может осуществляться с использованием следующих техник:
1. Анализ исходных текстов программ.
2. Динамический анализ безопасности программ.
Анализ безопасности программного обеспечения на основе
исходных текстов
Достоинством анализа безопасности программного обеспече-
ния на основе исходных текстов (так называемый статический анализ) является возможность выявления проблем безопасности,
а также анализ всех «скрытых» особенностей программного обеспечения до его запуска. В общем случае при статическом анализе
решаются следующие задачи:
– исследование структуры программы;
191
– выделение набора стандартных системных функций, исполь-
зуемых программой;
– выявление способов и целей взаимодействия программы
с внешними устройствами и системными ресурсами;
– поиск типовых уязвимостей;
– поиск разрушающих программных средств в коде программы.
Эффективность и, следовательно, целесообразность данного
анализа определяются его трудоемкостью. Таким образом, при
статическом анализе безопасности программного обеспечения
с точки зрения трудоемкости анализа возможны две ситуации:
– наличие исходных текстов программ на языке высокого
уровня;
– наличие объектного кода программы с необходимостью его
дизассемблирования.
Принципиальных отличий между этими двумя вариантами не
существует (методы, применяемые при анализе безопасности, схожи).
Требования к анализу исходных текстов программного обес-
печения на языке высокого уровня рассмотрены в нормативном
документе [6].
При этом необходимо отметить, что данный анализ менее тру-
доемок, чем дизассемблирование, хотя и не всегда возможен.
Исследование безопасности объектного кода программного
обеспечения основано на применении принципа дизассемблирования кода программы с последующим анализом мнемокода. Для
решения частных задач модуль включает в себя базы знаний
о стандартных функциях операционной системы. Данный метод
является единственно возможным методом статического анализа
программ в случае отсутствия исходных текстов (а это типичная
ситуация). Кроме того, необходимо отметить, что данный подход
позволяет решить проблему «доказательства безопасности компилятора», формально существующую для анализа безопасности
программ на основе исследования исходных текстов на языках
программирования высокого уровня. Однако применение данного
метода, в силу низкого уровня языка программирования, характеризуется высокими трудозатратами.
192
Современные средства статического анализа безопасности
программного обеспечения в основном исследуют уязвимости
в исходных текстах программ.
В настоящее время существуют следующие свободно распространяемые средства поиска уязвимостей: its4, rats, flawfinder,
lclint. Все эти средства обладают сходной функциональностью,
обнаруживая уязвимости в программном обеспечении, написанном
на языках С и C++, на основе базы данных известных ошибок программирования, приводящих к уязвимостям.
Динамический анализ безопасности программного
обеспечения
Статический анализ способен полностью решить поставленную задачу исследования входной информации только в том случае, если в программе не применены специальные средства маскировки своего присутствия и действий (например, шифрования, кодирования и т. п.). В противном случае статический анализ не
сможет выявить, а значит, исследовать несанкционированные действия, что приведет к нанесению ущерба компьютерной системе.
Для решения данной проблемы следует использовать методы динамического анализа программного обеспечения.
Идея динамического анализа заключена в исследовании поведения программы под воздействием разнообразной входной информации с обеспечением полного контроля использования внешних устройств и системных ресурсов. К средствам динамического
анализа можно отнести автоматизированные отладчики и средства
мониторинга.
Непосредственное тестирование программного
обеспечения
Отсутствие исходных текстов исключает применение большинства методов тестирования программного обеспечения. При
использовании метода непосредственного тестирования выводы
о свойствах исследуемого объекта делают на основе анализа реакции системы на внешние воздействия.
Схема, иллюстрирующая данный метод, показана на рис. 13.1.
193
Генератор
тестов
Анализ
откликов
Тестируемая
система
Интерфейсы
Тестирующее
воздействие
Тестирующее
воздействие
Рис. 13.1. Использование матрицы тестирования
При непосредственном тестировании программного обеспечения может пригодиться методика, известная как матрица тестирования, позволяющая выполнить декомпозицию множества тестов.
Данная методика описывает тесты с использованием матриц тестирования верхнего и нижнего уровней.
Матрица тестирования верхнего уровня определяет логически
объединенные группы объектов тестирования и функции, которые
необходимо протестировать для каждой группы. Составление матрицы тестирования верхнего уровня является отправной точкой
при анализе безопасности программного обеспечения. Строки матрицы верхнего уровня определяются логически объединенными
группами объектов тестирования. Столбцы данной матрицы определяются соответствующими функциями программы. Функции
программы могут быть определены, например, в соответствии
с требованиями к функциям защиты, предъявляемым к программе.
Элементы матрицы тестирования верхнего уровня являются указателями на матрицы тестирования низкого уровня, в которых более
детально описываются соответствующие тесты.
Матрицы тестирования нижнего уровня расширяют матрицу
верхнего уровня. Строки данной матрицы соответствуют программным интерфейсам, поддерживающим соответствующие подсистемы. Столбцы описывают соответствующие требования. Каждый элемент матрицы нижнего уровня описывает единственный
программный интерфейс и единственное требование. Элементы
матрицы указывают на множество тестов, которые необходимо
провести для анализа безопасности программных интерфейсов.
Если подсистема содержит большое количество программных
интерфейсов, можно создавать матрицы промежуточного уровня,
содержащие группы интерфейсов. Элементы такой матрицы ука-
194
зывают на матрицы более низкого уровня, описывающие все интерфейсы в группе.
Таким образом, при использовании методики матрицы тестирования необходимо:
1. Составить список логических подсистем тестируемой про-
граммы.
2. Составить список программных интерфейсов логических
подсистем.
3. Определить множество тестов, составляющих план тести-
рования.
Информация для создания матрицы тестирования верхнего
уровня может быть получена из документации на программный
продукт.
Для того чтобы начать конструирование матрицы тестирования нижнего уровня, необходимо создать по одной матрице для
каждой ячейки матрицы тестирования верхнего уровня. Для заполнения матрицы тестирования нижнего уровня для каждого элемента матрицы определяется:
– необходимо ли тестировать данное требование для данной
подсистемы; если тестирования не требуется, элемент матрицы
должен указывать на множество заключений, объясняющих, почему соответствие этому требованию не должно тестироваться для
данного программного интерфейса;
– множество тестов для тестирования требований.
В матрице нижнего уровня не должно остаться незаполненных
клеток. Если незаполненные клетки остались, то говорить о полном тестировании программы не представляется возможным.
По результатам заполнения матрицы нижнего уровня составляется план тестирования, содержащий описание тестов. Описание
теста тестирования должно содержать:
– описание и анализ теста;
– список указателей на процедуры тестирования;
– системное окружение, используемое при тестировании;
– автоматические инструменты, используемые при тестировании.
Описание теста создается на основе анализа документации на
разработанное программное обеспечение и идентификации условий, которые могут привести к нарушению безопасности.
195
До начала тестирования необходимо обеспечить соответствующее системное окружение. Некоторые параметры системного
окружения могут быть одинаковыми для многих тестов и должны
быть описаны в плане тестирования.
К понятию окружения относятся версии программного и аппаратного обеспечения, используемого при тестировании. Также
должны быть описаны особые условия, которые могут быть использованы при тестировании.
Процедуры тестирования должны описывать детальную документацию для одного или нескольких тестов.
Описание теста потенциально может привести к большому количеству тестирующих воздействий. Таким образом, желательно определение разумного количества выполняемых проверок. Например,
описание теста для интерфейса с большим количеством параметров
ведет к очень большому количеству тестов (тестирование с различной
комбинацией параметров). Предварительный анализ реализации должен уменьшить количество необходимых тестов.
Каждое логическое действие, выполняемое тестом, должно
быть четко документировано как в случае применения автоматических средств, так и без них. Обычно документацию к тестам представляют в виде псевдокода. Также документация должна включать специфические особенности описываемого теста, в том числе
данные о системном окружении, интерпретации результатов тестирования, верификации результатов тестирования и т. д. Рассмотрим подробнее требования к документации по тестированию.
Целесообразность выполнения теста, а также интерпретация
его результатов может зависеть от результатов выполнения предыдущих тестов. Данные зависимости должны быть четко оговорены.
Примером таких зависимостей может являться файл, созданный
одним тестом в качестве выходных данных и используемый другим тестом в качестве входных. Должно быть отмечено, является
ли тест независимым от других тестов.
Входные данные для теста должны являться соответствующими (по типу) для анализируемого программного интерфейса. Данные могут быть получены, например, в результате функционирования генератора случайных чисел.
196
13.4. Поиск уязвимостей в процессе
функционирования систем
Сканеры уязвимостей
Сканер уязвимостей – программа, которая обнаруживает уязвимости удаленной и/или локальной системы. Различают две основные стратегии, используемые сканерами уязвимостей: пассивное и активное сканирование.
Для поиска уязвимостей при пассивном сканировании необходимо рассматривать программы и настройки, реализующие политику
безопасности системы. Активное сканирование состоит в выполнении
типовых сценариев атак и анализе реакции системы на них.
Сканирование уязвимостей предоставляет администратору системы оценку безопасности системы на момент проведения сканирования. Таким образом, хотя сканер уязвимостей не в состоянии
зафиксировать атаку на безопасность системы, он способен определить условия, при которых возможен успех той или иной атаки
(а иногда и тот факт, что атака на систему уже была успешно осуществлена).
Тестирование путем проникновения в систему
Тестирование путем проникновения в систему впервые было
описано в методе гипотез об уязвимостях. Метод гипотез об уязвимостях (Flaw Hypothesis Methodology) был разработан System
Development Corporation для анализа возможности нарушения безопасности компьютерных систем с помощью проникновения в систему (penetration testing). Авторами метода было отмечено следующее: «В отсутствие формальных техник доказательства корректности метод проникновения является самым дешевым методом
поиска уязвимостей. Исчерпывающее тестирование операционной
системы отличается от метода проникновения. При тестировании
можно обнаружить ошибки реализации, а при проникновении анализ реализации системы используется в целях обнаружения ошибок проектирования». Метод гипотез об уязвимостях является
стратегией обнаружения уязвимостей разработки операционной
системы на основе ошибок, найденных при реализации системы.
Метод состоит из четырех этапов, перечисленных ниже.
197
1. Сбор знаний об управляющих структурах системы. Для
успешного проникновения нарушитель должен иметь информацию
о принципах взаимодействия пользователей с операционной системой, о сервисах, присутствующих в системе, и об ограничениях,
накладываемых на использование сервисов. В том числе требуется
информация о реализации:
– межмодульных связей;
– внутренних структур модулей системы;
– механизма контроля доступа;
– иерархии объектов управления;
– модулей.
2. Выдвижение гипотез об уязвимостях. На этом этапе нару-
шитель предлагает гипотезы о существовании уязвимостей в системе на основании изучения исходных текстов и документации на
систему.
3. Проверка гипотез. На данном этапе нарушитель подтвер-
ждает или отвергает гипотезы об уязвимостях на основании атак на
систему с использованием предполагаемых уязвимостей.
4. Обобщение уязвимостей. На данном этапе уязвимости ана-
лизируемой системы обобщаются на основе данных об ошибках
системы, полученных на этапе 3.
В изучаемых с использованием данного метода системах следующие функциональные модули, реализующие:
– контроль ввода / вывода;
– разделение программ и данных;
– контроль доступа;
– управление инсталляцией.
Метод гипотез об уязвимостях был успешно применен в нескольких исследованиях. К недостаткам данной методологии можно отнести требование глубоких априорных знаний о реализации
системы и отсутствие формализации алгоритмов тестирования механизмов безопасности.
Контрольные вопросы
1. Что обычно понимается под уязвимостью?
2. Вследствие каких причин могут возникать уязвимости?
198
3. С помощью каких характеристик может быть описана уяз-
вимость?
4. Поясните процесс занесения уязвимости в список CVE.
5. Какие ошибки, приводящие к уязвимостям, относятся к
ошибкам реализации?
6. В чем состоит ошибка переполнения буфера?
7. Назовите основные группы объектов, являющихся целью
атаки на переполнение буфера.
8. Какие меры следует предпринять для недопущения уязви-
мости переполнения буфера ?
9. Какие типы ошибок относятся к ошибкам администрирова-
ния?
10. Каким образом осуществляется поиск уязвимостей в про-
цессе разработки и анализа системы?
11. В чем состоит идея динамического анализа безопасности
программного обеспечения?
12. Как осуществляется поиск уязвимостей в процессе функци-
онирования систем?
199
14. АТАКИ И ВТОРЖЕНИЯ
Нарушитель Атакуемый хост
Нарушитель Атакуемый хост
Атакуемый хост
Атакуемый хост
14.1. Характеристики атак
Атака на компьютерную систему – это действие, предпринимаемое злоумышленником, которое заключается в поиске и использовании той или иной уязвимости. Атаку на вычислительную
систему можно рассматривать с точки зрения нарушителя и жертвы. Атака с точки зрения нарушителя может быть описана с использованием следующих компонентов:
– цель;
– сценарий;
– уязвимость в атакуемой системе;
– риск обнаружения нарушителя;
– ущерб, причиненный жертве / выгода нарушителя.
С точки зрения жертвы атака может быть описана с помощью
ответов на следующие вопросы:
– что случилось?
– кому и в каком размере нанесен ущерб?
– как был нанесен ущерб?
– кто нарушитель?
– когда, как и почему состоялось нарушение?
По соотношению нарушитель — атакуемый объект атаки могут быть описаны следующим образом.
1. «Один к одному» (см. рис. 14.1).
Рис. 14.1. Отношение нарушитель – атакуемый объект «один к одному»
2. «Один ко многим» (см. рис. 14.2).
Рис. 14.2. Отношение нарушитель – атакуемый объект «один ко многим»
200
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]