В данном разделе будут рассмотрены основы сертификации и тестирования МЭ: причины и необходимость сертификации, основные существующие подходы к тестированию, методы и инструменты тестирования. В конце данного раздела будут рассмотрены критерии сертификации МЭ.
МЭ в сети Интернет стали широко использоваться в последнее время, и как следствие, возросло число продуктов МЭ на рынке. Сейчас существует несколько десятков крупных производителей МЭ. Ответом покупателей на такое большое количество предложений стало, естественно, замешательство. Покупатели, которые хотят купить МЭ, не очень хорошо ориентируются во всех особенностях технологии защиты и очень обеспокоены, что они могут купить не совсем то, что им нужно.
МЭ - это очень сильно конкурирующая область рынка ИТ. Производители постоянно совершенствуют свои продукты, совершенствуют свои требования к защищенности, совершенствуют собственные тесты. В конце концов, получается, что похожие МЭ становятся очень разными, и одни типы технологий описываются как неуместные, а другие как самые важные. И не так просто определить потом, что действительно важно, а что нет.
Может ли какая-нибудь одна авторитетная организация определить, является ли какой-то конкретный МЭ действительно "хорошим" и что значит определение "хороший" для МЭ. Ответ на эти вопросы могут дать сертификация и тестирование. Главная проблема состоит в том, что признак "хороший" для МЭ зависит от нужд покупателя, его требований по безопасности и стоимости. Чтобы специфицировать критерий оценки МЭ, необходимо чтобы они имели примерно одинаковые свойства, и цель их использования была бы то же примерно одинаковой. Такие критерии оценки МЭ уже существуют.
В правительственной компьютерной безопасности США "Оранжевая Книга" (The Orange Book) является руководством по требуемым свойствам компьютерных систем. "Оранжевая Книга" содержит очень жесткие требования, определяя уровень защиты для каждого элемента системы. Тем не менее, существует мнение что, она просто содержит запись о том, что такое наилучшая безопасность, совершенно игнорируя то, как пользователь будет использовать систему. По этой причине данное руководство не очень успешно. Причина, по которой "Оранжевая Книга" используется, это то, что она имеет очень ограниченное число объектов защиты (полный и подробный список) и ограниченное число пользователей (пользователей правительственных организаций). Главный вопрос - где ее можно и удобно использовать остальным пользователям?
Какой должна быть "Оранжевая Книга" для МЭ? Не все МЭ одинаковы, многие содержат различные компоненты и созданы для разных целей защиты. Некоторые, основанные на маршрутизаторе, разработаны для защиты систем с низкой стоимостью, низкой пропускной способностью и малой гибкостью. Правильно установленные коммерческие МЭ для некоторых приложений обеспечивают просто замечательную безопасность. Но они могут быть недостаточными для других приложений, которые требуют сложного аудита, мониторинга трафика и жесткой политики доступа. В другом случае правильно установленный сервер может обеспечить все, что необходимо для достаточной защиты используемых сетевых сервисов. Проблема состоит в том, что если "Оранжевая Книга" для МЭ будет написана, она будет такой же общей и бесполезной или будет настолько специфичной, что производители МЭ будут постоянно откладывать ее утверждение, пытаясь ориентировать ее для своей выгоды. Сегодня существуют "Сетевая Интерпретация" (Trusted Network Interpretation) для "Оранжевой Книги", критерии NCSA безопасности и сертификации МЭ, рекомендации CERT, критерии защищенности РД ГТК РФ и т.п. Перспектива того, что производители будут оказывать давление на соответствующую авторитетную организацию, выдающую сертификаты, очень вероятна. Сегодня производители активно "давят" на процесс стандартизации МЭ, чтобы изменить текущие и будущие стандарты для собственного преимущества.
Возможно ли существование более одной авторитетной организации? Производители, не оказывающие давления на критерии сертификации МЭ, которыми пользуется конкретная авторитетная организация, могут объединиться и создать свою, подходящую для них, сертификационную организацию. Таким образом, возможна ситуация, когда у нас будет только одна авторитетная организация сертификации МЭ с очень общим, "туманным" и бесполезным критерием проверки, или возможна ситуация наличия нескольких соревнующихся организаций сертификации, ни одна из которых не будет полностью объективной, но только для составляющих ее производителей МЭ.
Что означает сертификация для МЭ? По определению, сертификация - это процесс установления соответствия средства вычислительной техники или автоматизированной системы набору определенных требований (например, требований по защите). Содержанием сертификации является тестирование. Тестирование - это метод проверки выполнения определенных требований. Но, перед тем как тестировать МЭ, необходимо построить соответствующий тест, прохождение которого для МЭ будет означать некоторый гарантированный уровень обеспечиваемой защиты. Тест строится по соответствующей методологии тестирования исходя критериев безопасности МЭ (например, "Оранжевая Книга", критерии NCSA и РД ГТК). Кроме того, сертификационное тестирование должно осуществляться на соответствующем стенде тестирования и с применением соответствующих программных тестовых пакетов (test suites). Задачи анализа критериев тестирования МЭ, построения тестовых примеров для МЭ по критериям, построение программного пакета для сертификационного тестирования МЭ - задачи данной дипломной работы.
Теперь рассмотрим основные существующие подходы к тестированию.
Как же тестировать МЭ? МЭ можно тестировать двумя методами, которые можно и совмещать:
Тестирование по спискам проверки похоже на запуск программ SATAN, AutoHack или ISS против МЭ в целях поиска "дыр" в системе защиты. Этот метод очень ограничен - если была пропущена какая-то ошибка, то ее могут использовать злоумышленники завтра, и нужно будет отменять результаты сертификации. Преимущества данного метода тестирования состоят в том, что он относительно дешевый, быстрый и легко позволяет производителям поставить печать "одобрено" на свои МЭ.
При тестировании по разработке необходимо идти к разработчикам МЭ и начать с вопроса: почему вы думаете, что этот МЭ эффективно защищает себя и сеть? В зависимости от ответов, которые вам дадут на этот и аналогичные вопросы, необходимо сформулировать набор тестов, подтверждающих те свойства, которые имеет данный МЭ. Основная проблема заключается в том, что это очень сложно. Совсем не много людей могут протестировать МЭ таким образом. Это медленно, дорого, трудно понимаемо и трудно объяснимо (экспертный подход).
Стоит отметить, что как таковых методов тестирования МЭ не существует в силу того, что МЭ - это довольно новая область ИТ.
Рассмотрим теперь, кто может осуществлять тестирование МЭ. Возможен следующий выбор:
Тестирование МЭ самим производителем не является объективным. Производители постоянно имеют дело с технологией МЭ и находятся в курсе всех проблем с безопасностью. Также производители могут быть менее изобретательны во время составления тестов, так как в правильной работе некоторых частей МЭ они просто могут быть уверены и не проверять их с помощью тестов.
Вторая возможность - это нанять хакеров для тестирования МЭ. Тем не менее, хотя у хакеров (hackers) есть достаточно знаний и опыта, чтобы тестировать МЭ, хакеры являются потенциальными злоумышленниками. Они могут просто умолчать о найденных "дырах" в безопасности МЭ и использовать эти "дыры" для совершения атак в будущем.
Можно также самостоятельно произвести тестирование МЭ. Однако при этом в организации должна быть группа достаточно квалифицированных экспертов и должны быть в наличии соответствующие ресурсы. Часто дешевле нанять третью сторону, чтобы провести тестирование. Такой третьей стороной обычно является организация, авторитетная в области сертификационного тестирования МЭ.
Одним из подходов к тестированию систем защиты является рассмотрение безопасности системы с точки зрения потенциального злоумышленника. При этом проверка безопасности осуществляется путем попыток взлома. Если проникновение в систему осуществить не удалось, то она считается потенциально надежной. Здесь нельзя говорить о надежности с большой уверенностью, не обладая полной информацией о методах и технике взлома злоумышленников, тем более что число путей взлома постоянно растет.
Автоматическое тестирование - одно из наиболее развивающихся направлений в тестировании МЭ. Это быстрый и дешевый способ тестирования. Он не требует большой квалификации от человека, проводящего тестирование. Инструменты автоматического тестирования очень удобны. Следует отметить, что эти инструменты также активно используются пользователями МЭ для проверки надежности установки МЭ и правильности исполнения политики безопасности.
Автоматическое тестирование разделяется на активное и пассивное тестирование. Активное тестирование является навязчивым по свое природе. В активном тестировании уязвимости обнаруживаются путем использования их для проникновения в систему. Пассивное тестирование нацелено на анализ системы и обнаруживает уязвимости, независящие от состояния системы.
Пассивное тестирование проверяет конфигурацию системы, анализирует пароли, проверяет права доступа для различных файлов. Активное тестирование проверяет права доступа в систему, возможность подмены адреса или изменения маршрутизации. Пассивное тестирование довольно безопасно в отличие от активного. Инструменты для активного тестирования могут довольно легко превратиться в инструменты для взлома.
Различают также локальное, сетевое и распределенное виды автоматического тестирования. Локальным тестированием является тестирование, при котором проверка ограничивается локальной машиной, на которой запущена тестирующая программа. В сетевом тестировании используются коммуникационные связи для анализа состояния удаленной системы или проверки доступности сервиса. В распределенном случае тестирующая программа запускается на разных машинах для анализа какого-либо компонента системы или для проверки синхронизации.
Необходимо также отметить момент генерации отчетов. Отчеты необходимо создавать в форме, понятной для людей, которые их используют. Некоторые системы генерируют отчеты для разных уровней: для экспертов по безопасности и инженеров.
Общими требованиями к системам автоматического тестирования являются следующие:
Из существующих инструментов автоматического тестирования наиболее распространены следующие: Internet Security Scanner (ISS) - многофункциональный коммерческий продукт, SATAN и Nessus - условно-бесплатные программы проверки защищенности (отсутствия известных уязвимых мест) компьютерных систем и сетей. Все эти инструменты тестируют работающие сконфигурированные системы, причем тестирование сконфигурированного МЭ обычно производится косвенно - путем тестирования извне всей локальной сети, защищенной данным МЭ. Тем не менее, эти инструменты могут использоваться для автоматизации сертификационного тестирования МЭ - МЭ тестируется с помощью данных инструментов многократно в различными конфигурациях, причем как извне, так и изнутри имитируемой локальной сети.
Ниже проводится анализ существующих методов тестирования, методов составления тестов, а также существующих типов ошибок реализации и функционирования МЭ.
В общем, существуют следующие способы тестирования МЭ:
Что касается методов составления тестов (тестовых примеров), то существует несколько подходов к этому. Первый подход заключается в том, что тесты должны быть составлены таким образом, чтобы проверялась каждая возможная цепочка команд. Этот подход удобен в случае, когда программа, реализующая функции МЭ, может быть описана конечным графом не очень большой сложности. Второй подход заключается в тестировании в зависимости от входных параметров по границам критических областей. Для каждого параметра составляются области, для которых программа выполняет одни и те же действия, и для каждой такой области берутся значения на границе и одно значение внутри области. Этот подход также ограничен по своим возможностям количеством параметров и областей. Вообще при тестировании больших программ возникают большие сложности. Поэтому было создано еще несколько подходов, позволяющих повысить эффективность тестирования больших программ. Один из таких подходов - это модульное тестирование. При этом программа разбивается на функциональные модули, у которых есть вход и выход, и каждый модуль тестируется по отдельности, а затем тестируются межмодульные связи. Другая разновидность этого подхода, заключается в том, что если модулей больше шести-семи, то программа разбивается на несколько компонент, которые в свою очередь разбиваются на тестируемые модули.
Рассмотрим теперь типы ошибок, которые могут быть допущены в реализации МЭ, и попробуем составить их классификацию. Классификация ошибок может быть составлена различными способами: по причине возникновения, по методу поиска и т.д. Классификации могут быть также неоднозначными или неудобными для использования или для обнаружения ошибок. Ниже приводятся несколько существующих классификаций.
Вот классификация ошибок, которую можно применить к любым программам:
Эта классификация несет общий смысл и содержит неоднозначности. Вот другая классификация, допускающая однозначное отнесение ошибок в ту или иную категорию. Ошибки бывают:
В нашем случае сертификационного тестирования МЭ мы исключаем возможность ошибки в конфигурации, потому что это не ошибка продукта, а ошибка пользователя. Ошибки среды остаются в рассмотрении, потому что производители должны обеспечить защищенность всех уязвимых мест среды либо выбрать другую более надежную среду. Ошибки в условиях и синхронизационные ошибки связаны с ошибками в алгоритме или его реализации.
Варианты ошибок в условиях:
Здесь проверка ошибок осуществляется на основе исходного текста программы или на основе алгоритма, то есть при тестировании по разработке. Здесь не учитываются ошибки более глобального характера, например неправильный алгоритм.
Ниже приводится другая классификация ошибок, разработанная с учетом особенностей систем МЭ и методов тестирования.
Ошибки среды (ошибки ОС и стандартных утилит). Тестирование этой группы ошибок должно проводиться специалистом по этой ОС. Здесь можно использовать автоматическое локальное пассивное тестирование (на основе списка проверки) и/или сетевое активное тестирование (создание модели атаки).
Ошибки работы с памятью. Эти ошибки можно искать несколькими способами: можно анализировать текст программы, можно автоматически либо полуавтоматически, можно вручную. Если анализировать текст программы, то это довольно медленно и очень сложно. Нет гарантии, что при такой проверке не будет пропущено ни одной ошибки, потому что проверка правильности работы с указателями и памятью - это одна из самых сложных задач. Возможно, также придется анализировать еще и текст используемых библиотек и даже ОС. Ручное и полуавтоматическое тестирование возможно, но оно потребует больших трудозатрат. Здесь довольно предпочтительно автоматическое тестирование - автоматическое создание большого количества соединений, пакетов разной длины, передача длинных параметров и т.д.
Ошибки системы управления. Проверка безопасности и надежности системы управления МЭ - очень важная задача, особенно если возможно удаленное управление. В этом случае необходимо рассматривать возможность перехвата и подмены пакетов, имитации авторизованного администратора управления. Для успешного тестирования здесь необходимо знать, по крайней мере, алгоритмы, по которым происходит кодирование и шифрование сообщений, аутентификация, т.е. лучше всего проводить анализ текста программы. Но им одним обойтись нельзя, потому что эти алгоритмы довольно сложны. Знание алгоритмов скорее поможет при полуавтоматическом тестировании обнаружить слабые места МЭ.
Ошибки в реализации криптографических протоколов. Здесь рассматриваются алгоритмы распределения и передачи ключей, шифрования данных и генерации электронной подписи. При тестировании используются те же методы, что и в предыдущей категории.
Ошибки посредников уровня соединения и прикладного уровня. Здесь все проверки необходимо проводить отдельно для каждого сервиса, то есть отдельно для каждого посредника. Здесь необходимо проверять правильность разбора команд и правильность их выполнения, то есть синтаксис и семантику протокола приложений. Необходимо также проверить правильность фильтрации команд и данных прикладного уровня. Каждый сервис помимо всего содержит свои уязвимые места и может быть не защищен от известных типов атак. Еще необходимо проверять надежность процедуры аутентификации (если таковая присутствует). Почти все эти проверки (за исключением проверки аутентификации, и, может быть, защиты от некоторых атак) лучше всего проводить с помощью автоматического тестирования - это быстро, качественно и эффективно. Проверка схемы аутентификации проводится при полуавтоматическом тестировании.
Ошибки фильтрации пакетов. Тестирование фильтров пакетов такое же, как и тестирование посредников, за исключением того, что здесь нет специальных протоколов и аутентификации. Лучше всего использовать автоматическое тестирование, где проверяется фильтрация на основе адресов, портов и других параметров.
Ошибки обнаружения активности злоумышленников. Здесь необходимо проверять своевременность, надежность, гибкость и информативность оповещения. При этом из-за большого числа различных алгоритмов и разной техники исполнения лучше всего проводить полуавтоматическое тестирование, при котором сигнал оповещения будет отслеживать человек, проводящий тестирование.
Ошибки журнализации. Здесь необходимо проверять полноту журнализации и надежность защиты журналов от несанкционированного удаления информации из них.
Другие ошибки. Методы тестирования дополнительных возможностей зависят от конкретных особенностей конкретного МЭ.
Эта классификация ошибок не является однозначной и не претендует на универсальность. Но организация процесса тестирования МЭ с учетом этих категорий ошибок поможет легко составить план тестирования, выделить необходимые для тестирования ресурсы и иметь полную картину (сценарий) тестирования. Эта классификация поможет также подобрать соответствующие методы и инструменты для проведения тестов.
Рассмотрим теперь критерии, которым должен удовлетворять МЭ для успешного прохождения им сертификации. Как отмечалось ранее, существуют различные документы, специфицирующие требования к МЭ и критерии сертификации МЭ - критерии NCSA сертификации систем Firewall, "Сетевая" Интерпретация "Оранжевой Книги", соответствующие Руководящие документы ГосТехКомиссии РФ и т.д. Все эти документы содержат общие требования к МЭ и процессу их сертификации, не содержат деталей и не учитывают характерных особенностей МЭ того или иного типа. Ниже приводятся основные критерии сертификации МЭ, как взятые из этих документов, так и полученные путем анализа сетевых угроз, основных уязвимых мест защищаемых ресурсов и принципов функционирования типовых МЭ.
Описание основных типов сетевых атак находится в приложении А. Более детальное описание всех вышеперечисленных критериев дается в приложениях Б и В.