CC BY
53
18 января 2012 г, 2:28
ТЕХНОЛОГИИ ИНФОРМАЦИОННОГО ОБЩЕСТВА
К вопросу о тестировании коммутационного оборудования по требованиям безопасности информации
Марков А.С., Рауткин Ю.В., Цирлов ВЛ.
Введение
Разграничение доступа в компьютерных системах в защищенном исполнении основано на УЬАМ-технологиях и технологиях межсетевого экранирования. В настоящее время в специальных нормагивных документах ФСТЭК России и ФС'Ь России сформулированы общие требования средствам межсетевой и межсегментной шииты, однако отсутствуют формами юванные типовые методики их тестирования. В статье рассмотрены вопросы формализации способа и методик тестирования управляющих коммутаторов, реализующих функции фильтрации трафика.
Способ тестирования управляющих комму гаторов
Управляющий коммутатор (УК) Е представляет собой профаммно-анпаратнос средство (комплекс), реализующее функции разграничения (блокирования, фильтрации, регистрации) информационного трафика, поступающего в компьютерную сеть и/или выходящей из сети. Положим, что Я = {г,}- множество требований, предъявляемых к УК Г. а 7* = {*4} - множество тестов, проверяющих реализацию предъявляемых требований.
Пол способом р<пработки тестов будем понимать отображение: М: I X й -* Т.
Каждый тест Г, € Т характеризуется целью выполнения. последовательностью выполняемых действий, результатом выполнения теста и критерием принятия положительного решения.
Цель испытания содержит изложение намерения о выполнения оценки соответствия УК предъявляемым требованиям. Последовательность выполняемых действий определяет набор тагов, осуществляемых экспертом для приведения УК в исходное состояние и выполнения теста. Результаты выполнения тестов фиксируются с использованием различных профаммных средств (ПС) проведения испытаний, таких как: средства генерации и перехвата сетевого трафика, поиска остаточной информации, проверки системы раираннчения доступа. Критерий принятия положительного решения должен содержать эталонные результаты выполнения тестов. Введем операторы выполнения требования ^ и корректности выполнения теста 5^.
Оператор выполнения требования Г, для УК
£ X Я -» {0.1}:
{1, если требование г, выполнено;
0, в противном случае.
Оператор корректности выполнении теста г. для УК £ Ге:£ХГ-»{0Д}:
!1, если тест г. выполнен успешно:
0, в противном случае.
Оператор Рс показывает, что для УК Е выполнение теста завершилось успешно: фактические результаты, зарегистрированные при выполнении теста, соответствуют эталонным значениям, указанным в описании теста.
Методикой испьпаний назовем набор из пяти объектов где Я - множество требований, предъявляемых к УК Е. М - метод разработки тестов. и Гс операторы выполнения требования и коррскшости выполнения теста соответственно, а также для \/г, € й справедливо => ^(Е,М(Г,г,)).
В общем виде испытания включают три стадии: планирование. тестирование, анализ результатов.
При планировании выполняется анализ документации и особенностей работы УК. Эксперты должны установить, что в технической документации разработчик декларирует соответствие УК требованиям Я. то есть Гл(Е,г,) = 1 для Уг, € Я. На основании анализа документации, тестовых запусков УК и предъявляемых требований, формируется множество тестов Т = {г,}, где С, = Л#(Е,гД
Тестирование выполняется с использованием набора тестов Т = {г,}, в результате чего для каждою теста определяются результаты выполнение теста, подлежащие регистрации.
На стадии анализа фактических и эталонных значений получают множество упорядоченных пар вида (г^ГсС&О). Дтя УК Е декларируется соответствие требованиям И = {гД если:
£(/Ь(Е.г()Ге(1,М(Е.г1)))-п.
то есть в ходе проведения испытаний установлено соответствие реальных возможностей УК декларируемым в документации или нормативном документе 11).
Таблица I
Основные требования по межсетевому экранированию
ОГмнначеннс Требование
п УК должен обеспечивать фильтрацию на сетевом уровне. Решение по фильтрации может приниматься для каждого сетевого пакета нетавненмо на основе, но крайней мерс, сетевых адресов отправителя и получателя или на основе других эквивалентных атрибутов.
Гг УК должен обеспечивать идентификацию и аутентификацию администратора УК при его таиросах на доступ. УК должен предоставлять возможность для идентификации и аутентификации но идентификатор) (коду ) и паролю > словно-постоянного действия. Дополнительно УК должен препятствовать доступу не-нлентифнцированною субъекта или субъекта, подлинность идентификации которого при аутентификации не подтвердилась.
V» УК должен содержать средства контроля 1а целостностью своей программной и информационной части.
Т-Сотт, #11-2011
71
Методика испытаний управляемых коммутаторов на соответствие требованиям беюиасносш информации
Основные требования к УК с точки зрения межсетевого экранирования можно рассмотреть на базе руководящего документа Гостехкомиссии России. Рассмотрим порядок проверки дтя наиболее ресурсоемких требований R = {гі/г2»гз) (см. табл 1).
Типовая схема испытательного стенда представляет собой два сетевых сегмента с ЭВМ. разделенных УК.
Проверка фнльгранни данных и трансляции
адресов
Цель выполнения проверки состоит в определение степени соотвстствия функциональных возможностей УК по фильтрации сетевых пакетов с учетом следующих параметров: сетевого адреса отправителя, сетевого адреса получателя. Исходными данными дтя формирования теста являются множество сетевых адресов, используемых в тестовых сегментах:
IP = IP' и IP, = {ІР},ІРІ,...,1РІ,ІРІ\ Предполагается, что при проведении тестирования выполняется отправление пакетов из внешнего сегмента сети (сетевые адреса вида I Р±) во внутренний сегмент (сетевые адреса вида I Р£).
І Іровсрка включает следующие шаги:
1. Настройка правил фильтрации УК в соответствии с проверяемым требованием, в результате чего формируется множество запрешакмцнх RULE0 — [rule*, rule*,...] и разрешающих RULE1 = {ru/ej.ru/ej, •••) правил межсетевою экранирования, причем, каждое правило представляет собой упорядоченное множество вила rule° 1 = (/Р^,/Ря;). где IPg - сетевой адрес отправителя, /Pr - сетевой адрес получателя.
2. Запуск ПС перехвата и анализа сетевых пакетов во внутреннем и внешнем сегментах сети.
3. Г енерация сетевых пакетов из внешней сегмента селі во внутренний сегмент дтя всех возможных нар (отправитель. получатель): packetk = (lP±,lP*,payloadk\
4. Завершение перехвата сетевых пакетов. В результа-
те получаем следующие множества перехваченных наксюв PACKETW = [packet!? .packet™.••• } *
РАСКЕТоит = [packet f1/7 .packet?07.где packet™ = (IP;, IP* .payload*) - сетевые пакеты, перехваченные во внешнем сегменте.
packet^ = (1Р'5,1Р£, pay load*) - сетевые пакеты, перехваченные во внутреннем сег менте.
5. Экспорт журнала регистрации разрешенных и запрещенных пакетов УК. В результате выполнения формируется множества записей о запрещении прохождения JOUR0 = (journal^, journal...} и разрешении прохождения /OUR1 = {/' our nail.journal ],...} сетевого пакета. Каждая запись имеет вид: journal° 1 = (/Р^,/Ря;).
Результатами выполнения теста являются:
1. Конфш урация УК - множества {rtiie®} и {rule}).
2. Результаты перехвата сетевых пакетов на внешнем и внутреннем интерфейсах УК - множества (packet™} и [packet?"7}.
3. Фрагмент журнала регистрации событий УК, демонстрирующий результаты фильтрации сетевых пакетов: множества {journal?} и [journal]}.
В качестве критерия принятия положительного решения примем фнксанию_соотвстствия фактических (пакеты на входном шпсрфсйсс УК, пакеты на выходном интерфейсе УК и фрагмент журната регистрации событий УК) и ожидаемых результатов (правила фильтрации УК):
1РАСКЕТоит = RULE';
PACKET'" /РАСКЕТоит = RULE0;
PACKETom = JOUR1;
PACKET'»/РАСКЕТоит = 10UR°.
При проведении тестирования могут быть использованы. например, следующие ПС: ппшр, Packe! Generator (генерация сетевых пакетов), wireshark. tc/xiitmpiперехват н анализ сетевых пакетов), программный комплекс «Сканер-ВС» (генерация, перехват и анализ сетевых пакетов) |2-4|.
К УК предъявляю гея также аналогичные гребования к мехашимам фильтрации на других уровнях модели 1SO/OSI. Для канального уровня требование выглядит следующих! обраюм: «УК должен обеспечивать фильтрацию с учетом входною и выходною сетевою интерфейса как средство проверки подтинности сетевых адресов». Методика проверки аналогична методике, представленной выше, но в качестве критериев фильтрации используются адреса канальною уровня (МАС-адрес). На сетевом уровне проверяется требование но фнлырации с учетом любых значимых нолей сетевых пакетов. При проведении испытаний, как правило, внимание следует уделять тестированию механизма фюырацни с учетом следующих нолей пакета сетевою уровня: адрес отправителя, адрес получателя. тип протокола верхнею (транспортного) уровня, время жизни пакета (TTL).
Проверка механитмов и лет нфикаиии
и аутентификации администраторов
Целью проверки является определение степени соответствия функциональных возможностей УК по идентификации и аутентификации администратора УК.
Будем считать, что А - алфавит паролей и идентификаторов администраторов УК. Обозначим идентификатор администратора id € ID С А\ пароль -
pwd € PWD С А\ Учетная запись администратора adml € ADM характеризуется следующим кортежем admt = (idj.pwdk).
Введем оператор корректности учетных данных Faut:ADM-{0.1}:
[1. доступ на администрирование получен;
0. в противном случае.
Предполагается, что идентифнкация/аутентификация выполняется с использованием сетевых протоколов с 'ЭВМ внутреннею сегмента сети. Тогда проверка будет включать следующую последовательность действий:
1. Включение механизма идентификации и аутентификации УК и создание множества учетных записей администраторов УК ADM = [adml,adm2,...).
2. Запуск ПС перехвата и анализа сетевых пакетов во внутреннем сегменте сети.
3. Выполнение запросов на идентификацию и про-
ведение аутентификации с использованием различных сочетаний учетных данных: зарегистрирован-
ный/незарегистрированный идентификатор. верный/неверный пароль - tryt = (id.. pwdk ).
4. Генерация сетевых пакетов из внутренней сети во внешнюю (или наоборот), прохождение которых разреша-
72
T-Comm, #11-2011
сгся (запрещается) в соответствии с правилами фи. 1Ыранни УК.
5. Завершение перехвата сетевых пакетов, экспорт журнала регистрации событий УК.
6. Анализ на предмет наличия учетных данных, передаваемых в открытом виде.
При выполнении проверки реализации локальной идентификации/аутентификации шаги 2, 5 последовательности действий не выполняются.
Результатами выполнения теста являются:
1. Конфигурация УК - множество ADM учетных записей администраторов УК.
2. Полученные результаты тестовых запросов ка
идентификацию и аутентификации: множество
{Faut (fry*))-
3. Результаты перехвата сетевых пакетов на внешнем н внутреннем интерфейсах УК.
4. Фрагмент журнала регистрации событий УК. демонстрирующий результаты идентификации и аутентификации
Определим критерии принятия положительного решения:
1. После ввода зарегистрированного идентификато-
ра и пароля пользователю предоставляется досту п к средствам администрирования УК:
=1° fry, 6 ADM.
2. После ввода незарегистрированного идентификатора и/или неверного пароля пользователю отказывается в доступе к средствам администрирования УК: ?лит (fry,) = 0«=> try, 6 ADM.
3. Журнал pei истратит событий содержит записи о всех тестовых попытках получения доступа.
4. Попытки поиска идентификационных данных (имя пользователя, пароль) в перехваченных пакетах не дан» результатов.
При провелении тестирования механизмов илситифи-каним/аутентификации для перехвата и анализа сетевых пакетов могут быть использованы, например, программы wireshark. lepdump, программный комплекс «Сканер-ВС»
РА
Проверка механизмов контроля целостности
11ровсрка состоит в определении степени соответствия функциональных возможностей УК по контролю целостности программной и информационной части УК.
ПуСА FILE = [file у file*.........f^en) ■ множество
файлов УК (конфигурационные файлы. про1раммные модули). Введем операторы нарушения целостности FM0D и контроля целостности файлов УК Ъ.ЧТ-
Оператор нарушения целостности
FM0B:FILE^{ 0.1}:
»(/«.) ■
1. целостность флАла нарушена при проведении испытаний.
(О. ш противном случае
Оператор контроля целостности файлов УК Г/дт:ГШГ->{0Д}:
{1, целостность файла нарушена;
0, в противном случае.
Обозначим ГНЕЛ = [file}.file2......./і/е*} - мно-
жество файлов УК, модифицированных в ходе проведения испытания. При этом выполняется модификация файла filei в файл file*■ При проверке корректности реализации механизма контроля целостности УК может быть ис-
пользована следующая последовательность выполняемых действий:
1. Включение механизма контроля целостности программной и информационной части УК и идентификация множества файлов УК FILE = [filevfile2,...,filen).
2. Внесение изменений в файлы УК (изменение
конфшурации. подмена (модификация) исполняемых файлов и т. п.) - получение множества измененных фай-юв FILE* = [filet fikf.......file*}.
3. Инициализация проверки целостности файлов УК (создание условий, при которых УК осуществляет контроль целостности).
4. Анализ реакции УК на нарушение целостности своей профаммной или информационной части.
Результатами выполнение теста следует считать:
1. Множество файлов УК
FILE = [filevflle2.....filen).
2. Множество модифицированных файлов УК
FILE* = [file*, file*.....fUe*\
3. Реакции УК на нарушение целостности: Fmr (ftt*i)»Ънт (ЛЦ г )• •••» Fmr (/***•)•
В качестве критерия принятия положительного решения примем факт, что обнаружены все факты нарушения целостности:
Fmrtffaf) ~
Рекомендации по оптимизации процедуры
проведения испытаний
Залача оптимизации процедуры проведения испытаний УК может быть сформулирована следующим образом. Пусть Т: Т X Z -* N0 - время, затрачиваемое экспертами на выполнение оценки соответствия с использованием теста t, € Т для УК Е. Обозначим через отображение C:/?x£-*N0 - затраты на проведение тестирования реализации требований R для УК Г. Тогда залача оптимизации процедуры проведения испытаний УК формулируется следующим образом (минимизация времени тестирования УК при ограничениях на затраты):
-♦ min,
£с(г„ї)<св.
где Са - ограничения, наклалывасмыс на затраты.
Наиболее трудоемкой частью испытаний является лестированис подсистемы управления доступом (фильтрации сетевых пакетов) УК. Опыт тестирования УК позволяет сформулировал ь ряд рекомендаций, позволяющих сократить эти затраты:
1. ОС тестовых ЭВМ должны загружаться со сменного носителя (СІ), I ЧВ-накопитсль и т. д.) и не требовать для своего функционирования услановки на жёсткий диск. Это позволит сократить временные затраты на установку и конфигурирование ОС* тестовых ЭВМ.
2. ПС. необходимые для проведения испытаний (например. ПС перехвата и анатиза сетевого трафика или Ьпр-сервер), должны входить в состав ОС. загружаемой на тестовых ЭВМ.
3. Должна быть предусмотрена программа централизованною управления процессом генерации и анализа сетевых пакетов (программа должна входить в состав ОС. загружаемой на тестовых ЭВМ). Данная проірамма должна получать на вход правило фильтрации, проверяемое в ходе конкретной проверки, и необходимую информацию
T-Comm, #11-2011
73
о конфшурации испытательного стенда. Программа должна управлять запуском н прекращением работы тестовых ПС' (генерации и перехвата сетевых пакетов), собирать необходимую информацию с тестовых ЭВМ (например. список перехваченных пакетов) и выполнять анатиза полученных результатов (сравнение фактических результатов е установленными правилами фильтраиии). Централизованное управление и сбор информации должен происходить по компьютерным сетям, не входящим в состав внутреннего или внешнего сегментов. В целях минимизации экономических затрат управление и сбор информации может происходить с использованием беспроводных технологий передачи данных.
4. Должны быть предусмотрены средства экспорта результатов испытаний.
Указанные рекомендации позволят сократить время испытаний в части выполнения следующих процедур:
- установка ОС' и необходимых ПС на ЭВМ стенда;
- запуск ПС перехвата и анатиза сетевых пакетов во внутреннем сегменте сети;
• запуск ПС перехвата н анатиза сетевых пакетов во внешнем сегменте сети;
• генерация сетевых пакетов из внешней сегмента во внутренний сегмент сети;
- завершение работы ПС перехвата и анатиза сетевых пакетов во внутреннем сегменте сети;
- завершение работы ПС перехвата и анатиза сетевых пакетов во внешнем сегменте сети;
- формирование списков пропущенных н запрещенных сетевых пакетов:
• сравнительный анатиз списков пропущенных (запрещенных) сетевых пакетов и настроенных правит фильтрации УК.
Выводы
Предложенные в работе способ и методики тестирования межсетевых средств зашиты позволяют форматизо-
ваи. процесс оценки и верификации степени безопасности управляющих коммутаторов и компьютерных сетей.
Форматизация типовых методик тестирования УК позволяет автоматизировать и оптимизировать процесса испытаний и снизить временные, экономических татраты при заданной полноте проверок.
11рслложснный подход может быть рекомендован XIя проведения сертификационных испытаний средств защиты информации но требованиям безопасности информации [6].
Литература
1. Марков А.С., Никулин М.К)., Цирлов BJI. С ертификация средств зашиты персональных данных: революция или эволюция? // Зашита информации. Иисайл. 2008. №5. С.2-7.
2. Марков А.С., Крчолаев С. Инструментальные средства аттестации иротрамчных ресурсов объектов информатизации: Часть I. И Information Security /Информационная безопасность. 2004. №4. С.58-59.
3. Марков А.С., Крчолаев С. Инструментальные средства аттестации программных ресурсов объектов информатизации: Часть 2. И Information Sccurity/Ннфорчаннонная безопасность. 2004. №5. С.58-61.
4. Марков А.С., Цнр.юв В.1., Миронов С.В. Аттестация без проблем: об использовании сетевых сканеров безопасности при аттестации AC II Information Security Информационная безопасность. 2005. №3. С.44-45.
5. Ьарабанов А.А. Инструментальные средства проведения испытаний систем по требованиям безопасности информации // Защита информации. Инсайд. 2011. №1. С.2-4.
6. Адамова .I.E.. Амарян М.Р., Варламов ().().. .1мса-ковскнй В.А. Об одном подходе к созданию ревизоров обеспечения безопасности информации на отдельных компьютерах Известия Гатанротскою государственною ратиотехнического университета. 2003. Т.ЗЗ. №4. С. 175-176.
7. Марков А.С., Цирк»» ВЛ., Маслов В.Г., Олексснко И. А. Тестирование и испытания upoi рам мною обеспечения по требованиям безопасности информации // Известия Института инженерной физики. 2009. Т.2. №12. - С.2-6.
74
T-Comm, #11-2011
