Способ проверки функционирования протоколов информационных систем

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

 

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

Известна "Система тестирования "Телетестинг" по свидетельству на полезную модель РФ №98123105/20, "Система тестирования "Телетестинг", класс G06F 15/00, от 22.12.1998. Указанная система содержит следующие блоки: блок подготовительных модулей, соединенный с имеющим вход от потребителя блоков модулей тестирования, который имеет программу тестового диалога, к которой подсоединен снабженный выходом к потребителю блок телекоммуникационных модулей, соединенный обратной и, через канал протоколов, прямой связями с блоком модулей анализа и обработки, содержащим базу данных с результатами телетестинга, блок модулей тестирования снабжен модулем регистрации, а программа тестового диалога снабжена подпрограммой технологического мониторинга, блок телекоммуникационных модулей снабжен модулем программы-робота обработки, выполненного в виде соединенной с выходом к потребителю программы автоматизированной обработки и выдачи первичных тестовых баллов, и соединен с блоком модулей анализа и обработки дополнительной прямой связью через канал данных технологического мониторинга, а обратная связь с блоком модулей анализа и обработки выполнена в виде канала итоговых результатов тестирования, блок модулей анализа и обработки содержит соединенный с каналами протоколов и данных технологического мониторинга модуль анализа достоверности результатов, модуль итоговой обработки результатов, соединенный с каналом итоговых результатов тестирования, и модуль анализа тестовых заданий, выход которого соединен с блоком подготовительных модулей.

Недостатком "Системы тестирования "Телетестинг" является узкая область применения, что обусловлено ее предназначением, в основном, для тестирования характеристик телекоммуникационного оборудования. Предлагаемая система не позволяет осуществлять проверку функционирования протокола в соответствии с нормативными документами, а также осуществлять поиск уязвимостей, внесенных в протоколы разработчиками, и выявление недокументированных возможностей протоколов. Кроме этого указанная система тестирования не позволяет осуществлять построение комплексов защиты коммуникационного оборудования от выявленных угроз безопасности информационных систем.

Известна заявка на изобретение "Раннее определение сетевой поддержки для мобильного межсетевого протокола" по заявке на изобретение РФ №2005121891/09, класс H04L 29/06, от 11.12.2003. В заявке осуществляется следующая последовательность действий: разъединение беспроводной сетью; тестируются на условие разъединение, при этом условие разъединения представляет собой раннюю индикацию сетевой поддержки мобильного МП, причем шаг тестирования содержит определение того, что беспроводной сетью требуется аутентификация; разъединяются от беспроводной сети, если удовлетворяется условие разъединения; и остаются соединенными с беспроводной сетью, если условие разъединения не удовлетворяется.

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

Наиболее близким по своей технической сущности к заявленному является "Способ и система тестирования DVD плеера" по заявке на изобретение РФ №2003115966/09, класс G06F 11/00, от 29.05.2003. Заявка содержит способ тестирования, включающий использование тестового DVD, содержащего набор функциональных тестов плеера, тестирование DVD плеера осуществляют с помощью тестов в управляющий компьютер, при этом связывают проверяемый DVD плеер и управляющий компьютер интерфейсом, протокол которого поддерживает передачу команд управления от компьютера к плееру и информации о состоянии плеера обратно, от плеера к компьютеру; копируют содержимое тестового DVD на накопитель управляющего компьютера, загружают тестовый DVD в тестируемый плеер и запускают управляющую программу; с помощью управляющей программы анализируют состав и структуру тестового DVD; выбирают режим тестирования: ручной, полу- или полностью автоматизированный; используя функции управляющей программы, составляют сценарии тестирования из набора тестов выбранного DVD и сохраняют сценарии в виде последовательностей инструкций для модулей системы; выбирают тест или сценарий тестирования, выполняют тестирование и регистрируют его результаты.

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

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

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

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

Сущность изобретения поясняется чертежами, приведенными на фигурах 1-5, на которых показаны:

фиг.1 - структурная схема программно-аппаратного комплекса проверки протоколов информационных систем;

алгоритм реализации процедуры тестирования составляют три основных этапа, представленные на фигурах 2-5:

фиг.2 - алгоритм реализации предсессионного этапа;

фиг.3 - алгоритм реализации стадии генерации сессионного этапа;

фиг.4 - алгоритм реализации стадии анализа сессионного этапа;

фиг.5 - алгоритм реализации постсессионного этапа.

Алгоритм реализации процедуры тестирования составляют три основных этапа, представленные на фигурах 2-5:

- предсессионный этап (фиг.2), в ходе которого задаются исходные данные: интенсивность следования, размер тестовых блоков и их структура, а также режим отправки; проверяется корректность ввода исходных данных; исходные данные преобразуются к машинным кодам и заносятся в рабочую память системы; инициализируются служебные временные переменные, отвечающих как за выработку тестовых блоков с заданной интенсивностью следования, размером и структурой, так и за генерацию и отправку диагностических пакетов, а также разбор принятых ответных диагностических пакетов;

- сессионный этап (фиг.3-4), включающий две стадии функционирования:

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

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

- постсессионный этап (фиг.5), в процессе которого стираются значения параметров интенсивности следования, размера тестовых блоков, их структуры и режима отправки, а также служебных временных переменных в системе; осуществляется чтение собранных данных из хранилища и загрузка их в рабочую память системы; загруженные в рабочую память системы критические последовательности индексируются, преобразуются к стандартному виду, то есть к визуальной форме представления информации, и выводятся в пользовательский интерфейс.

Структурная схема программно-аппаратного комплекса тестирования протоколов информационных систем изображена на фиг.1. На структурной схеме программно-аппаратного комплекса тестирования протоколов информационных систем представлены следующие элементы:

Тестирующий узел - рабочая станция, непосредственно на которой установлена система тестирования, представляющая собой прикладной программный продукт, реализующий алгоритм процедуры тестирования.

Исследуемый узел - рабочая станция (либо сервер), являющаяся объектом исследования в ходе проведения процедуры тестирования.

Исследуемый / Транзитный коммутатор - коммуникационное устройство, которое в ходе проведения процедуры тестирования может выступать как в качестве непосредственно объекта исследования, так и посредником, осуществляющим доставку тестовых блоков от тестирующего узла к исследуемому.

Исследуемый / Транзитный маршрутизатор - коммуникационное устройство, которое в ходе проведения процедуры тестирования также как и коммутатор может выступать как в качестве непосредственно объекта исследования, так и посредником, осуществляющим доставку тестовых блоков от тестирующего узла к исследуемому.

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

Алгоритм реализации процедуры тестирования:

1. Алгоритм реализации предсессионного этапа (фиг.2):

Блок №1. Осуществляется ввод исходных данных в пользовательский интерфейс, задается интенсивность следования, размер тестовых блоков и их структура, а также режим отправки.

Блок №2. Проверяется корректность ввода исходных данных. Если веденные данные оказываются некорректными, алгоритм возвращается к блоку №1, иначе - переходит к блоку №3.

Блок №3. Инициализация начальных установок системы. Происходит преобразование исходных данных (интенсивности следования, размера тестовых блоков и их структуры, а также режима отправки) к машинному формату, что подразумевает под собой переход от визуальной формы представления информации к машинным кодам, которые затем заносятся в рабочую память системы.

Блок №4. Подготовка системы к выработке тестовых блоков. В соответствии с начальными установками системы (интенсивности следования, размера тестовых блоков, их структуры и режима отправки, хранящихся в рабочей памяти системы в форме машинных кодов) активизируются генератор и анализатор тестовых последовательностей, что заключается в инициализации служебных временных переменных, отвечающих как за выработку тестовых блоков с заданной интенсивностью следования, размером и структурой, так и за генерацию и отправку диагностических пакетов, а также разбор принятых ответных диагностических пакетов.

2. Алгоритм реализации стадии генерации сессионного этапа (фиг.3):

Блок №5.1. Осуществляется запуск циклического процесса тестирования. Указанный процесс является циклическим исходя из того, что происходит генерация и анализ реакции исследуемого узла не для одного, а для множества тестовых блоков.

Блок №5.2. Происходит чтение текущих установок системы (параметров интенсивности следования, размера тестовых блоков, их структуры и режима отправки, а также служебных временных переменных). На первом цикле они соответствуют начальным установкам (соответственно блоку №3).

Блок №5.3. В генераторе тестовых последовательностей вырабатывается тестовый блок заданного размера и структуры.

Блок №5.4. Осуществляется подготовка и последующая отправка тестового блока с заданным размером и структурой к исследуемому узлу. При этом обе указанные процедуры осуществляются на основе известного компонентного драйвера WinPcap 4.1.1 и полностью прозрачны для пользователя.

Блок №5.5. Ожидается подтверждение успешной отправки. Если таковое приходит, алгоритм переходит к стадии анализа сессионного этапа (блок №5.6), в противном случае - переходит к блоку №5.2.

3. Алгоритм реализации стадии анализа сессионного этапа (фиг.4):

Блок №5.6. Запускается режим прослушивания в анализаторе последовательностей. Режим прослушивания осуществляется на основе известного компонентного драйвера WinPcap 4.1.1, котоый прозрачно для пользователя прослушивает канал и ожидает поступление ответного диагностического пакета (имеющего формат пакета протокола ICMP).

Блок №5.7. Осуществляется прием ответного диагностического пакета (имеющего формат пакета протокола ICMP).

Блок №5.8. Ожидается подтверждение приема пакета. Если таковое приходит, алгоритм переходит к блоку №5.10, в противном случае - к блоку №5.9.

Блок №5.9. Ожидается подтверждение остановки таймера ожидания диагностического пакета. Если таковое приходит, алгоритм переходит к блоку №5.10 (передает ему управляющий сигнал), в противном случае - возвращается к блоку №5.7.

Блок №5.10. Происходит преобразование и разбор ответного диагностического пакета (имеющего формат пакета протокола ICMP), после чего на основании управляющих сигналов из блоков №5.8 и №5.9 осуществляется принятие решения в системе о степени критичности отправленного тестового блока, а результат в форме управляющего сигнала направляется в блок №5.11.

Блок №5.11. Уточняется решение системы о степени критичности отправленного тестового блока. Если тестовый блок признается критичным, алгоритм переходит к блоку №5.12, иначе - к блоку №5.13.

Блок №5.12. Осуществляется запись критического (текущего) блока в хранилище в форме последовательности параметров полей заголовка пакета тестируемого протокола.

Блок №5.13. Происходит обновление установок системы (изменение значений параметров интенсивности следования, размера тестовых блоков, их структуры и режима отправки, а также служебных временных переменных) и подготовка ее к следующему циклу работы.

Блок №5.14. По завершении установленного пользователем цикла работы, циклический процесс останавливается.

4. Алгоритм реализации постсессионного этапа (фиг.5):

Блок №6. Сброс текущих установок системы. При остановке циклического процесса происходит остановка анализатора и генератора тестовых последовательностей (стираются значения параметров интенсивности следования, размера тестовых блоков, их структуры и режима отправки, а также служебных временных переменных в системе).

Блок №7. Осуществляется чтение собранных данных из хранилища. При этом все записанные (на сессионном этапе) в хранилище данные загружаются в рабочую память системы.

Блок №8. Полученный результат интерпретируется. Осуществляется индексирование загруженных в рабочую память системы критических последовательностей и преобразование полученного результата к стандартному виду, то есть к визуальной форме представления информации.

Блок №9. Осуществляется вывод результата в пользовательский интерфейс.

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

Для проверки протокола необходимо осуществить построение физического сегмента тестируемой сети согласно структурной схеме программно-аппаратного комплекса тестирования протоколов информационных систем (фиг.1) и ввести корректные исходные данные в пользовательский интерфейс прикладного программного продукта. Установление фильтрующих правил предлагается осуществлять путем извлечения из хранилища критических последовательностей соответствующих сигнатур и внедрения их в такие программные средства обеспечения информационной безопасности как, например, межсетевые экраны, списки контроля доступа.

Заявленный способ реализуют следующим образом.

Пусть исследуемым протоколом будет протокол сетевого уровня IPν4, и пусть имеется физический сегмент тестируемой сети, представленный на структурной схеме программно-аппаратного комплекса тестирования протоколов информационных систем (фиг.1), где на тестирующем узле реализована система тестирования, выполняется алгоритм процедуры тестирования, а тестовые блоки отправляют на исследуемый узел.

Согласно алгоритму реализации процедуры тестирования осуществляются следующие основные этапы (фигуры 2-5):

1. Предсессионный этап(фиг.2).

Пользователем задаются исходные данные: интенсивность следования пакетов - 0,01 пакета/мс, размер тестовых блоков и их структура - 3 тестовых IP-пакета в тестовом блоке, режим отправки - повторение тестовой последовательности.

Системой тестирования проверяется корректность ввода указанных исходных данных, которые затем преобразуются к машинным кодам и заносятся в рабочую память системы.

Далее в системе тестирования инициализируются служебные временные переменные, отвечающие за выработку тестовых блоков с заданной интенсивностью следования, размером и структурой, при этом из выбранной пользователем тестовой последовательности в системе тестирования составляются тестовые ЕР-пакеты с установленным флагом фрагментации (общий вид тестовой последовательности со структурой IP-пакета указан в таблице 1):

Таблица 1
Общий вид тестовой последовательности со структурой IP-пакета
4 бита Ver Версия протокола, соответствующая текущему стандарту
4 бита HL Длина заголовка в 32-битовых словах
8 битов TOS Тип обслуживания
16 битов FL Длина пакета в байтах
16 битов PaID Идентификационный номер пакета
3 бита Flag Флаги фрагментации пакета
13 битов FO Смещение фрагмента
8 битов TTL Время жизни пакета в секундах
8 битов PrID Идентификатор инкапсулированного протокола
16 битов НС Контрольная сумма заголовка
32 бита SIP IP-адрес отправителя
32 бита DIP IP-адрес получателя
Data Инкапсулированные данные

Также в системе тестирования инициализируются служебные временные переменные, отвечающие за генерацию и отправку диагностических ICMP-пакетов, а также разбор принятых ответных диагностических ICMP-пакетов (общая структура диагностических ICMP-пакетов отражена в таблице 2):

Таблица 2
Общая структура диагностических ICMP-пакетов
8 битов Type Тип сообщения
8 битов Code Код дополнительной диагностической информации
16 битов Checksum Контрольная сумма данного сообщения
32 бита Unused Заполнитель
Data Инкапсулированные (необязательные) данные

2. Сессионный этап (фиг.3-4), включающий две стадии функционирования:

- Стадия генерации (фиг.3).

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

Вырабатывают тестовый блок заданного размера и структуры, подготавливают его и отправляют по сети к исследуемому узлу фрагментами, соответствующими тестовым IP-пакетам, с интервалами задержки между отправкой смежных тестовых IP-пакетов, равными 100 мс. В каждом тестовом блоке упаковано три тестовых IP-пакета, структура и содержание задаваемых полей которых отражены в таблице 3:

Таблица 3
Структура и содержание задаваемых полей тестовых IP-пакетов
Ver 0100 (4)
HL 0101 (5)
TOS 00000000 (0)
FL 1000000000000000 (32768)
PaID 0000000000000001 (1)
Flag 001 (1)
TTL 10000000 (128)
PrID 00000000 (0)
Data 00000000…00000000 (0)

Кроме того, в тестовый блок входит один диагностический ICMP-пакет (реализующий стандартную утилиту PING по протоколу ICMP), структура и содержание задаваемых полей которого отражены в таблице 4:

Таблица 4
Структура и содержание задаваемых полей диагностических ICMP-пакетов
Type 00001000 (8)
Code 00000000 (0)

Отправив к исследуемому узлу тестовый блок, система тестирования ожидает получения подтверждения успешной его отправки.

- Стадия анализа (фиг.4).

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

Далее ожидают получение подтверждения приема ответного диагностического пакета до момента остановки таймера ожидания диагностического пакета (в рассматриваемом примере - 10 с). Если на момент остановки таймера ответный диагностический пакет не прибывает, система тестирования делает вывод о критичности отправленного тестового блока (произошел либо логический разрыв соединения, либо критический сбой в работе исследуемого узла, что обусловлено наличием уязвимости протокола IP, полученной в отправленном тестовом блоке) и передает сигнал в блок принятия решения (фиг.4).

Далее принимают ответный диагностический пакет, выполняют его преобразование и разбор. Пусть на данном этапе произошел прием следующего ответного диагностического ICMP-пакета:

Таблица 5
Содержание значимых полей ответного диагностического ICMP-пакета
Type 00000011 (3)
Code XXXXXXXX

В поле Type ответного диагностического ICMP-пакета указан общий код значения ошибки (3), соответствующий недостижимости узла назначения (Destination Unreachable). В поле Code ответного диагностического ICMP-пакета код значения ошибки уточняется (ХХХХХХХХ), где ХХХХХХХХ одно из значений, указанных в таблице 6:

Таблица 6
Значения кода недостижимости узла назначения
00000000 (0) Сеть недостижима
00000001 (1) Компьютер недостижим
00000010 (2) Протокол недостижим
00000011 (3) Порт назначения недостижим
00000100 (4) Необходима фрагментация передаваемого пакета
00000101 (5) Ошибка при маршрутизации источника
00000110 (6) Сеть назначения неизвестна
00000111 (7) Компьютер назначения неизвестен
00001000 (8) Компьютер-источник изолирован
00001001 (9) Взаимодействие с сетью административно запрещено
00001010 (10) То же самое с компьютером назначения
00001011 (11) Сеть недостижима из-за класса обслуживания
00001100 (12) Компьютер недостижим из-за класса обслуживания

Поскольку все сгенерированные тестовые пакеты имели установленный флаг фрагментации в протоколе IP (поле Flag в таблице 3), на исследуемом узле осуществляется их сборка согласно процедурной характеристике протокола IP. Размер каждого тестового пакета - 32 кб (поле FL в таблице 3), а в каждом тестовом блоке 3 тестовых пакета, поэтому в процессе сборке произойдет ошибка (вследствие превышения максимального порогового размера - 64 кб (65535 байт)), в результате которой произойдет логический разрыв связи между рабочими станциями.

Логический разрыв связи между рабочими станциями может выражаться как отсутствием ответного диагностического ICMP-пакета в течение 10 с, так и приемом ответного диагностического ICMP-пакета, имеющего значения полей заголовка, указанные в таблицах 5 и 6.

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

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

3. Постсессионный этап (фиг.5).

В процессе постсессионного этапа стираются значения параметров интенсивности следования пакетов, размера тестовых блоков, их структуры и режима отправки, а также служебных временных переменных в системе, осуществляется чтение собранных данных из хранилища и загрузка их в рабочую память системы. После чего загруженные в рабочую память системы критические последовательности индексируются, преобразуются к стандартному виду, то есть к визуальной форме представления информации, и выводятся в пользовательский интерфейс. Таким образом, формируются сигнатуры уязвимостей, которые в любой момент могут быть применены пользователем на средствах обеспечения безопасности (межсетевых экранах, списках доступа).

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

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

Таким образом, предлагаемый способ проверки функционирования протоколов информационных систем является универсальным способом обнаружения уязвимостей протоколов, которые внесены разработчиками этих протоколов и выявляются посредством физического соединения сетевого оборудования как в локальных, так и в глобальных компьютерных сетях, в которых связь между абонентами осуществляется путем передачи пакетов данных в соответствии с принципами организации стека протоколов TCP/IP. При этом для каждой из множества последовательностей параметров полей заголовка пакета тестируемого протокола осуществляется: составление тестовых пакетов, генерация тестовых блоков, состоящих из набора тестовых и диагностического пакетов, отправка тестовых блоков с заданной интенсивностью, размерами блоков и структурой, где завершает каждый блок тестовых пакетов диагностический пакет, анализ реакции системы на блоки тестовых пакетов по заданным правилам и формирование хранилища критических последовательностей. После чего на основе хранилища критических последовательностей устанавливаются фильтрующие правила путем изъятия из хранилища критических последовательностей соответствующих сигнатур и внедрения их в такие средства защиты, как, в частности, межсетевые экраны.

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

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

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



 

Похожие патенты:

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

Изобретение относится к области настройки и/или конфигурирования программного обеспечения в устройствах. .

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

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

Изобретение относится к области антивирусной защиты. .

Изобретение относится к области тестирования программного обеспечения. .

Изобретение относится к области тестирования приложений, Техническим результатом является облегчение тестирования приложений. .

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

Изобретение относится к области обеспечения безопасности функционирования бортовой электронной системы

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

Изобретение относится к безопасному способу представления или отображения информации путем определения критических для безопасности ошибок в процессе обработки информации. Техническим результатом является безопасное представление информации на дисплее. Способ безопасного представления информации, имеющей отношение к безопасности, включающий: ввод, по меньшей мере, одного вводимого параметра в процессор, компьютерную обработку вводимого параметра преобразованием его в последовательность видеоданных, которые представляют собой вводимый параметр, передачу последовательности видеоданных на дисплей и представление последовательности видеоданных на дисплее, при этом последовательность видеоданных передают в испытательное устройство, выполняют испытание безопасности компьютерной генерацией тестового кода для этой последовательности видеоданных, тестовый код проверяют в сравнении с несколькими контрольными кодами, далее идентифицированному контрольному коду назначают соответствующее возможное значение вводимого параметра и проверяют в сравнении со значением вводимого параметра с помощью испытательного устройства, генерирующего либо положительный, либо отрицательный результат испытания для вызова отклика, направленного на безопасность. Устройство предназначено для реализации данного способа. 2 н. и 20 з.п. ф-лы, 4 ил.

Изобретение относится к вычислительной технике. Технический результат заключается в обеспечении гарантированной записи серийного номера с этикетки через кабель и проводной интерфейс во внутреннюю память контроллера управления радиоэлектронных устройств (РЭУ) в процессе тестирования. Способ автоматизированной сериализации для массового производства РЭУ, в котором осуществляют: тестирование работы РЭУ по беспроводному интерфейсу выполняют на выделенном частотном канале с использованием технологического серийного номера; в процессе тестирования через беспроводной интерфейс в РЭУ записывают программу, с помощью которой проверяют установку запрета на чтение памяти программатором, причем при снятом запрете восстанавливают технологическую программу и прекращают процесс тестирования, а при установленном запрете заменяют технологическую программу на рабочую программу РЭУ по проводному или беспроводному интерфейсу; в случае успешного тестирования уменьшают предустановленное значение, записанное в памяти счетчика, маркируют корпус РЭУ штрихкодом и уникальным серийным номером со сквозной нумерацией, сканируют упомянутый штрихкод и записывают уникальный номер, связанный со штрихкодом, во внутреннюю память контроллера управления РЭУ по проводному интерфейсу, и переводят РЭУ на рабочий частотный канал. 2 н. и 1 з.п. ф-лы, 2 ил.

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

Изобретение относится к вычислительной технике. Технический результат заключается в повышении производительности работы многопроцессорной системы. Способ обеспечения диагностической информации после сброса транзакции включает обнаружение сброса транзакции, которая включает одну или более команд и эффективно задерживает фиксацию транзакционных сохранений в главной памяти, пока не завершится выбранная транзакция; определение на основе сброса, должна ли диагностическая информация быть сохранена в блок диагностики транзакций (TDB); и сохранение в TDB диагностической информации, включающей адрес команды, соответствующей сброшенной транзакции, который зависит от причины сброса, представляемой кодом сброса, причем если код сброса имеет первое значение из одного или нескольких первых значений, диагностическая информация включает адрес команды, выполнявшейся при обнаружении сброса, если код сброса имеет второе значение из одного или нескольких вторых значений, диагностическая информация включает адрес команды, находящейся после команды, выполнявшейся при обнаружении сброса, и если код сброса имеет третье значение из одного или нескольких третьих значений, диагностическая информация включает адрес команды, более ранней или более поздней, чем команда, выполнявшаяся при обнаружении сброса. 3 н. и 17 з.п. ф-лы, 28 ил.

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