Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Теоретические основы защиты информации. Учебное пособие
.pdf
новной заинтересованной стороной. Поддержка руководства компании является необходимым условием для проведения аудита.
Аудит представляет собой комплекс мероприятий, в которых
помимо самого аудитора, оказываются задействованными представители большинства структурных подразделений компании. Действия всех участников этого процесса должны быть скоординированы. Поэтому на этапе инициирования процедуры аудита должны
быть решены следующие организационные вопросы:
– права и обязанности аудитора должны быть четко определены и документально закреплены в его должностных инструкциях,
а также в положении о внутреннем (внешнем) аудите;
– аудитором должен быть подготовлен и согласован с руководством план проведения аудита;
– в положении о внутреннем аудите должно быть закреплено,
в частности, что сотрудники компании обязаны оказывать содействие аудитору и предоставлять всю необходимую для проведения
аудита информацию.
На этапе инициирования процедуры аудита должны быть
определены границы проведения обследования. Одни информационные подсистемы компании не являются достаточно критичными
и их можно исключить из границ проведения обследования. Другие подсистемы могут оказаться недоступными для аудита из-за
соображений конфиденциальности.
Границы проведения обследования определяются в следующих терминах:
– список обследуемых физических, программных и информационных ресурсов;
– площадки (помещения), попадающие в границы обследования;
– основные виды угроз безопасности, рассматриваемые при
проведении аудита;
– организационные (законодательные, административные и
процедурные), физические, программно-технические и прочие аспекты обеспечения безопасности, которые необходимо учесть
в ходе проведения обследования, и их приоритеты (в каком объеме
они должны быть учтены).
181
Контрольные вопросы
1. Дайте определение аудита информационной безопасности.
2. Для чего предназначен механизм аудита?
3. Поясните роли пользователей механизма аудита.
4. Аудит каких операций необходимо производить?
5. Опишите основные методы выбора событий аудита.
6. Что обычно включают в себя записи аудита?
7. Какие дополнительные требования могут быть предъявле-
ны к подсистеме аудита?
8. Какие журналы аудита имеет операционная система Win-
dows?
9. Опишите функционирование механизма аудита.
10.
11. Определите события, которые должна фиксировать подси-
стема аудита в системе, построенной на основании модели Белла и
Лападула.
12. Определите события, которые должна фиксировать подси-
стема аудита в системе, построенной на основании модели Кларка–
Вилсона.
13. С какой целью проводят аудит информационной безопас-
ности предприятия
14. Назовите цели проведения аудита безопасности.
15. Какие этапы включают в себя работы по аудиту безопас-
ности информационных систем?
182
13. УЯЗВИМОСТИ
13.1. Основные определения
Под уязвимостью [7] понимается некая слабость, которую
можно использовать для нарушения безопасности системы или
содержащейся в ней информации. Уязвимости могут возникать
вследствие следующих причин.
1. Логическая ошибка – ошибка реализации механизма без-
опасности, использование которой приводит к успешной атаке на
систему. Логическая ошибка может содержаться в операционной
системе или пользовательском приложении.
2. Слабость – механизм безопасности, реализованный так, что
его использование может при определенных условиях привести к
нарушению безопасности. Слабость может возникнуть из-за обеспечения безопасности посредством сокрытия (безопасности, базирующейся на том, что никто не знает деталей реализации механизмов безопасности), устаревшего программного и аппаратного
обеспечения, небезопасных конфигураций.
3. Некорректное использование системы – пользователи си-
стемы могут сами нарушать политику безопасности системы, создавая условия для успеха атаки.
Уязвимость может быть описана с помощью следующих характеристик.
1. Ошибка – тип ошибки, приведшей к образованию уязвимо-
сти; систематизация уязвимостей по типу ошибки приведена в работах Лендвера, Аслама и Спаффорда.
2. Последствия – степень компрометации безопасности си-
стемы; примером систематизации последствий могут служить следующие типы последствий:
– получение нарушителем прав администратора;
– получение нарушителем доступа к системе с правами авторизованного пользователя;
– получение нарушителем несанкционированного доступа
к защищенным файлам;
– отказ системы или ее функциональной части в обслуживании.
3. Авторизация – права, необходимые нарушителю для осу-
ществления атаки, определяющие его уровень возможности.
183
По уровню возможностей нарушитель может быть классифицирован так, как показано в документах Гостехкомиссии.
4. Местонахождение – описывает необходимость физического
доступа нарушителя для проведения атаки на систему; может быть
систематизирована следующим образом:
– доступ к системному серверу;
– доступ к клиенту системы;
– доступ к сети.
Три последние характеристики уязвимости характеризуют
требования к нарушителю, который может выполнить атаку с использованием уязвимости.
Говоря об описании уязвимостей, следует упомянуть список
уязвимостей CVE (Common Vulnerabilities Exposures), разработан-
ный организацией MITRE. Список уязвимостей CVE является словарем, используемым для определения общих имен известных уязвимостей. Данный список можно найти по интернет-адресу
http://cve.mitre.org.
Список уязвимостей CVE можно рассматривать как стандартизованный список, содержащий все известные уязвимости, присваивающий каждой уязвимости уникальное, стандартное имя, существующий независимо от различных существующих взглядов на
уязвимости, открытый и распространяемый без каких-либо ограничений.
До разработки списка CVE каждая организация давала свое
наименование известным уязвимостям, что приводило к неопределенности понятий и несовместимости программных продуктов,
работающих с уязвимостями (таких, как сканеры безопасности или
системы обнаружения атак). При этом необходимо отметить, что
очень многие программные продукты, созданные для поддержания
информационной безопасности, обладают той или иной базой данных уязвимостей различных систем.
Процесс занесения уязвимости в список CVE состоит из следующих этапов:
– обнаружение уязвимости;
– оповещение пользователей об уязвимости (с помощью списков
рассылки, групп новостей и т. д.) – информация об уязвимости доводится до лиц, отвечающих за поддержание списка уязвимостей;
184
– присвоение уязвимости – кандидату в список CVE идентификатора в том случае, если она еще не входит в список; уязвимость в дальнейшем именуется на основании присвоенного идентификатора;
– предложение – соответствующий комитет рассматривает
предложенную для включения в список уязвимость и проводит
голосование, на основании которого описание уязвимости включается в список CVE, отвергается или модифицируется; результаты
голосования публикуются на WEB-сайте CVE;
– модификация – при необходимости описание уязвимости
переделывается в соответствии с пожеланиями комитета; если требуются незначительные изменения описания, то повторное голосование не требуется и уязвимость включается в список;
– публикация – после того как уязвимости присвоено имя и
она включена в список, новая версия списка CVE публикуется на
WEB-сайте CVE;
– переоценка – при необходимости изменить описание элемента списка CVE должна быть осуществлена процедура, аналогичная процедуре включения нового элемента.
В настоящее время список уязвимостей CVE стал стандартом
де-факто идентификации уязвимостей и поддерживается многими
программными продуктами. Для того чтобы программный продукт
удовлетворял требованиям совместимости со списком уязвимостей
CVE, необходимо выполнение следующих условий.
1. Поиск CVE – пользователь должен иметь возможность
найти информацию об уязвимости на основании ее идентификатора CVE.
2. Представление CVE – при выводе информации об уязвимо-
сти необходимо выводить ее CVE-идентификатор.
3. Отображение CVE – в программе должно поддерживаться
отображение между используемыми уязвимостями и некоторой
версии списка CVE.
Для лучшего понимания природы уязвимостей рассмотрим
более подробно типы ошибок, приводящих к уязвимостям.
185
13.2. Ошибки, приводящие к уязвимостям
Ошибки реализации
К ошибкам реализации относятся следующие ошибки.
1.Ошибки синхронизации – временные проблемы (существо-
вание временного окна между операциями) или проблемы последовательности операций в программном обеспечении системы.
Примером существования временного окна может служить
ошибка, связанная с тем, что программа привилегированного пользователя создает файл, который может быть в течение короткого
промежутка времени модифицирован любой программой в системе. Другим примером данной ошибки является ошибка создания
временных файлов программным обеспечением привилегированного пользователя в каталогах, доступных по чтению и записи
всем пользователям системы. Модификация данных файлов может
привести к нарушению безопасности системы.
2.Ошибки проверки условий. Различаются три основные
ошибки: предикат в условном выражении пропущен (выбирается
некорректный путь выполнения), условие пропущено (операция
будет выполнена, невзирая на условия), условие некорректно
определено (выбирается некорректный путь выполнения, или операция будет выполнена, невзирая на условия). Примером ошибки
данного рода является неспособность программы обработать исключение.
3.Ошибка проверки входных данных. Программа может быть
вызвана с любыми параметрами, передаваемыми в командной
строке. Такая программа может быть вызвана с любыми переменными окружения, устанавливаемыми родительским процессом.
Как следствие этого программа, опирающаяся в своей работе на
значения внешних переменных и не проверяющая их, может быть
уязвимой.
Программа, делающая предположения об открытых и закрытых файлах, также является уязвимой. В связи с тем, что нарушитель может открыть или закрыть любой файл перед запуском программы, предположения об открытых файлах могут быть ложными. В том числе могут быть закрыты файлы stdin, stdout и stderr.
Ввод данных в приложения WEB (в частности, выполняющиеся на доверенных серверах, осуществляется различными пользова-
186
телями и должен тщательно проверяться. Многие сценарии CGI
принимают в качестве входных данных URL, который записывается с использованием символов %НН (НН – шестнадцатеричный
код символа). Таким образом, сценарии CGI должны преобразовывать это значение и после этого проверять допустимость ресурса.
Кроме этого, приложения WEB могут использовать при работе
cookies (небольшой фрагмент данных о предыстории обращений
пользователя к некоторому WEB-серверу, автоматически создаваемый сервером на машине пользователя). Cookies могут быть модифицированы пользователями и должны проверяться программами. Пользователи могут запретить использование cookies (как
нарушающие безопасность данных), так что приложения WEB
должны проектироваться с учетом данной ситуации.
Использование HTML форм в приложениях WEB может быть
также небезопасно. Некоторые HTML формы используют проверку параметров на стороне клиента (осуществляется с помощью
Javascript/Java). Эта проверка полезна для пользователя (корректность ввода может быть оценена сразу, без пересылки данных по
сети), но бесполезна в смысле безопасности (данные можно передать напрямую, минуя всякие проверки). Таким образом, сервер
должен проводить собственную проверку данных в формах.
Дополнительным источником уязвимостей могут служить локализация и интернационализация программного обеспечения (локализация – процесс адаптации программы к национальному языку; интернационализация – процесс адаптации программы к нескольким языкам). В процессе данной адаптации возможны ошибки, приводящие к некорректной обработке данных, введенных на
языке, не предусмотренном программой. Информация о поддерживаемой в системе кодировке устанавливается переменными окружения. Эти переменные должны проверяться программой на корректность перед приемом пользовательских данных. Приложения
WEB должны выделять эту информацию из заголовков запросов.
Однако некоторые приложения WEB выделяют данную информацию из форм HTML, что может служить причиной уязвимости.
Таким образом, программа должна фильтровать кодировки (или
самостоятельно устанавливать желательные переменные окружения), с которыми она предполагает работать. В некоторых случаях
187
вводимые пользователем символы могут ограничиваться регулярным выражением [A-Za-z][A-Za-z0-9_,+@\-\.]*.
Некоторые приложения могут принимать данные от нарушителя и передавать их другому приложению. Данная ситуация (часто встречающаяся в приложениях WEB) может вызвать проблемы
безопасности второго приложения. Например, приложение WEB
может разрешить использование HTML-тегов во вводе пользователя. Данный ввод позже передается другому пользователю (например, гостевая книга). При этом нарушитель может использовать
HTML-теги для атаки других пользователей с использованием
вставки сценариев, Java апплетов, DHTML-тегов, признаков раннего окончания документов (</HTML>), запросов некорректного
размера шрифта и т. д. Как следствие описанной проблемы все выходные данные приложения WEB (URL, данные форм, cookies, запросы к БД, запросы к CORBA ORB, а также данные пользователя,
сохраненные в файлах) должны фильтроваться (некорректные
символы должны удаляться), декодироваться (все символы должны быть декодированы) или проверяться (относительно корректных регулярных выражений).
4. Ошибка переполнения буфера. Данная ошибка состоит
в том, что некоторый буфер в программе имеет фиксированную
длину, программа не проверяет количество байт, которые в него
копируются. При этом правильно подобранные записываемые
в буфер данные могут дать нарушителю дополнительные полномочия. Рассмотрим данный тип ошибок более подробно.
Буфер – это непрерывный блок памяти, используемый для
хранения набора элементов, относящихся к одному типу данных.
При программировании на языке Си под буфером обычно понимается массив данных (чаще всего массив символов). Переполнение
буфера – это просто помещение в область памяти, отведенную под
буфер, данных большей длины, чем этот буфер может содержать,
при отсутствии проверки выхода за границы буфера. Большинство
компиляторов языка Си такую проверку не осуществляет, поэтому
все нижесказанное следует воспринимать в контексте именно этого
языка.
Для того чтобы понять суть уязвимости переполнения буфера,
рассмотрим фрагмент программы:
188
void func (char *str)
{
char buffer[256];
strcpy(buffer, str);
return;
}
void main(int argc, char * argv[])
{
…
char *BigString;
…
func(BigString);
return;
}
Подобные фрагменты программ, в которых функция принимает строку как один из нескольких аргументов, имеет локальный
буфер ограниченного размера и использует вызовы типа strcpy()
или sprintf(), можно встретить в большом количестве программ.
Параметры функции func передаются через стек – туда заносятся указатели на параметры или сами параметры, а вызванная
функция извлекает их оттуда. После того как параметры занесены
в стек, а процессор встречает инструкцию вызова функции, он заносит в стек некоторую информацию о текущем состоянии – как
правило, это смещение следующей после команды вызова. Таким
образом, функция, завершив свою работу, будет знать адрес возврата управления. Функции надо запомнить указатель на текущую
верхушку стека (ВР), который будет использоваться в ссылке на
параметры. Поэтому независимо от архитектуры выполняются
следующие две инструкции: push bp; mov bp,sp.
Теперь в верхушке стека лежит предыдущее значение регистра ВР, а сам он указывает на верхушку стека и может быть использован в качестве базового регистра при ссылке на параметры.
В программе был объявлен размер буфера в 256 байт. Поскольку
не использовались функции malloc() или new для выделения требуемого объема памяти и не указывался модификатор static, этот буфер будет зарезервирован в стеке. Таким образом, строка длиной
более 256 байт, передаваемая в функцию func, затрет адрес возвра-
189
та из функции и изменит нормальное выполнение программы. При
отсутствии проверки выхода за границы буфера искажается содержимое других переменных состояния и параметров программы,
которые входят в область переполнения буфера. Типы искажаемых
объектов-переменных определяют способ передачи управления
коду атакующего. Можно выделить три основные группы объектов, являющихся целью атаки на переполнение буфера.
1. Адрес возврата из функции. Изменяется таким образом,
чтобы при возврате из функции управление было передано на код
нарушителя.
2. Указатель на функцию. Изменяется таким образом, чтобы при
вызове функции управление было передано на код нарушителя.
3. Указатель на данные. Результатом изменения значения ука-
зателя может быть как подстановка данных нарушителя вместо
оригинальных данных в ходе нормального исполнения атакуемой
программы, так и передача управления на код нарушителя (с помощью модификации некоторых управляющих структур).
Необходимо отметить, что уязвимость переполнения буфера
может содержаться в библиотечных функциях, таких как strcpy(3),
strcat(3), sprintf(3), vsprintf(3) и gets(3).
Таким образом, для недопущения уязвимости переполнения
буфера следует предпринять следующие меры.
1.При использовании статически размещенных буферов рас-
сматривать размер аргументов приемника и источника, а также
использовать проверку вводимых и результирующих данных.
2.По возможности использовать динамические буферы в связи
с тем, что при данном подходе возможна обработка ситуаций, связанных с вводом данных различной длины (до тех пор, пока они не
исчерпают свободную память). При этом необходимо учитывать,
что память может исчерпаться в любой точке программы (не обязательно в месте предотвращения переполнения буфера), что приведет к отказу в обслуживании. Даже наличие виртуальной памяти
может привести к ситуации, при которой система будет производить обмен данными между диском и памятью, не выполняя никакой полезной работы. Некоторые ограничения на размер вводимых
данных могут предотвратить описанную проблему.
190
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]