«Организация комплексной системы мониторинга безопасности компьютерных сетей ...»

Vulnerability Name (Название уязвимости) Risk (Уровень риска) Description (Описание уязвимости) Solution (Способы ликвидации уязвимости) Additional Information (Дополнительная информация) Links (Ссылки на источники информации о данной уязвимости) # of Network Resources (Кол-во сетевых ресурсов, подверженных данной уязвимости) Network Resource (Список сетевых ресурсов) Рис.2.11. Описание уязвимости в отчете, сгенерированном сканером NetRecon NetRecon самостоятельно определяет конфигурацию сети и позволяет выбрать сетевые ресурсы для сканирования. Может осуществляться параллельное сканирование всех сетевых ресурсов, сканирование по диапазону сетевых адресов, сканирование отдельных систем или подсетей. Сеанс сканирования может включать в себя все виды проверок, либо отдельные проверки по выбору пользователя. Глубина сканирования определяется продолжительностью сеанса сканирования, которая задается пользователем.

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

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

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

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

Обновление этой базы данных производится через Web-узел компании Symantec автоматически, при помощи механизма LiveUpdate.

Сетевой сканер NESSUS. Сетевой сканер Nessus может рассматриваться в качестве достойной альтернативы коммерческим сканерам. Nessus является свободно распространяемым и постоянно обновляемым программным продуктом. Удобный графический интерфейс позволяет определять параметры сеанса сканирования, наблюдать за ходом сканирования, создавать и просматривать отчеты. По своим функциональным возможностям сканер защищенности Nessus находится в одном ряду, а по некоторым параметрам и превосходит такие широко известные коммерческие сканеры, как NetRecon компании Symantec, Internet Scanner компании ISS и CyberCop Scanner компании NAI.

Версии 0.99 серверной части сканера Nessus была сертифицирована в Гостехкомиссии России (Сертификат N 361 от 18 сентября 2000 г.).

Сценарии атак реализованы в NESSUS в качестве подключаемых модулей (plugins). Количество подключаемых модулей постоянно увеличивается, в настоящее время насчитывается более 700. Новые внешние модули, эмулирующие атаки, можно инсталлировать, скопировав файлы, содержащие их исходные тексты, с web-сервера разработчиков www.nessus.org.

Nessus предоставляет очень широкие возможности по поиску уязвимостей корпоративных сетей и исследованию структуры сетевых сервисов. Помимо использования стандартных способов сканирования ТСР и UDP портов, Nessus позволяет осуществлять поиск уязвимостей в реализациях протоколов управления сетью ICMP и SNMP. Кроме того, поддерживаются различные стелс-режимы сканирования, реализуемые популярным некоммерческим стелссканером nmap, который можно рассматривать в качестве одного из компонентов сканера Nessus. Другой популярный некоммерческий сканер queso используется в составе Nessus для определения типа и номера версии сканируемой ОС.

Высокая скорость сканирования достигается за счет использования при реализации сканера Nessus многопотоковой архитектуры программирования, позволяющей осуществлять одновременное параллельное сканирование сетевых хостов. Для сканирования каждого хоста сервером nessusd создается отдельный поток выполнения. Подробное описание используемых методов сканирования TCP/UDP портов можно найти в онлайновой документации на сканер nmap. Они включают в себя следующее:

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

Клиентская часть Nessus работает и в среде UNIX и в среде Windows и реализует графический интерфейс пользователя для управления сервером nessusd. Пользователь сканера, перед запуском сеанса сканирования, определяет параметры сканирования, указывая диапазон сканируемых IPадресов и TCP/UDP портов, максимальное количество потоков сканирования (число одновременно сканируемых хостов), методы и сценарии сканирования (plugins), которые будут использоваться.

Все сценарии сканирования разделены на группы по типам реализуемых ими сетевых атак (Рисунок 8), обнаруживаемых уязвимостей, а также по видам тестируемых сетевых сервисов. Так, имеется специальная группа сценариев Backdoors для обнаружения троянских программ, Gain Shell Remotely - для реализации атак на получение пользовательских полномочий на удаленной UNIX системе, Firewalls – для тестирования МЭ, FTP – для тестирования FTPсерверов, Windows – для поиска уязвимостей Windows-систем и т.п.

Особую группу сценариев сканирования Denail of Service составляют атаки на отказ в обслуживании (DoS). Единственный способ убедиться в том, что сканируемая система подвержена той или иной DoS – это выполнить эту атаку и посмотреть на реакцию системы. Эта группа сценариев, однако, является потенциально опасной, т.к. их запуск может привести к непредсказуемым последствиям для сканируемой сети, включая сбои в работе серверов и рабочих станций, потерю данных и «полный паралич» корпоративной сети. Поэтому большинство DoS в данной группе по умолчанию отключено.

Для написания сценариев атак служит специализированный Сподобный язык программирования высокого уровня NASL (Nessus Attack Scripting Language). Существует также интерфейс прикладного программирования (API) для разработки подключаемых модулей со сценариями атак на языке C, однако предпочтительным является все же использование NASL.

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

Результаты работы сканера Nessus представлены на Рисунок 9. Данные об обнаруженных уязвимостях отсортированы по IP-адресам просканированных хостов. Найденные уязвимости проранжированы. Наиболее критичные (security holes) выделены красным цветом, менее критичные (security warning) – желтым.

По каждой уязвимости приводится ее описание, оценка ассоциированного с ней риска (Risk Factor) и рекомендации по ее ликвидации (Solution).

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

Последний вопрос является, пожалуй, одним из наиболее сложных. Реализация программно-технических мер защиты требует произведения настроек большого количества параметров ОС, МЭ, СУБД, сетевых сервисов, прикладных программ и активного сетевого оборудования. Когда речь идет о защите отдельного сервера или рабочей станции, то задача хоть и является сложной, но ее решение вполне по силам опытному системному администратору. В этом безопасностью, используются специальные списки проверки. Когда же речь заходит о настройке десятков и сотен сетевых устройств, функционирующих на различных программно-аппаратных платформах, в соответствии с единой политикой безопасности, контроле параметров защиты и мониторинге безопасности в реальном масштабе времени, то без специальных средств автоматизации уже не обойтись. Производители ОС предоставляют специальный инструментарий для контроля целостности и анализа защищенности ОС (утилита C2 Configuration в Windows NT Resource Kit, утилита ASET в ОС Solaris и т.п.). Имеется немало свободно распространяемых и широко используемых продуктов, предназначенных для решения подобных задач, таких как программа COPS для ОС UNIX. Однако эти средства, функционирующие на системном уровне, позволяют обеспечить только некоторый базовый уровень защищенности самой ОС. Для контроля приложений, сетевых сервисов, активного сетевого оборудования в распределенных системах, функционирующих в динамичной агрессивной среде необходимо использовать специализированный инструментарий, поддерживающий распределенные архитектуры, централизованное управление, различные программно-аппаратные платформы, различные виды приложений, использующий изощренные алгоритмы поиска и устранения уязвимостей, интегрированный с другими средствами защиты и удовлетворяющий многим другим требованиями, предъявляемым к современным продуктам этого класса.

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

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

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

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

Описание объекта защиты. В [1] подчеркивалось, что основными защищаемыми активами компании являются бизнес-процессы, совокупность которых ассоциируются с корпоративной информационной системой (КИС).

При организации защиты активов КИС может быть две ситуации:

1. информационная система – в стадии разработки и одновременно с ней происходит проектирование защиты как межкатегорийного сервиса [2] ИС.

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

2. информационная система – в стадии эксплуатации и стоит задача спроектировать для ее бизнес-процессов систему безопасности. Именно эта ситуация и рассматривается в данной работе.

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

среду функционирования, которую можно представить моделью OSE\RM Operating System Interface for Unix ), представляющую собой трехмерную логическую (справочную, эталонную, референсную) структуризацию функциональности информационной системы и описанную в [2,3] (на рис.2.13. представлен пример некоторых реализаций «клеток» модели).

Уровни описания в данной модели следующие:

- компоненты служб и сервисов промежуточного слоя (MW);

- компоненты операционных систем или операционного слоя (OW);

- аппаратный слой (HW).

Функциональные группы компонентов в данной модели составляют:

- компоненты, обеспечивающие интерфейс с пользователем (User - "U");

- компоненты, обеспечивающие всех необходимых процессов в системе (System - "S");

- компоненты, обеспечивающие организацию, представление, доступ и хранение данных (Information - "I");

взаимосвязь информационных систем (Communication - "C"), данный уровень представляет собой модель взаимосвязи открытых систем (OSI/RM– Open System Interconnection/Reference Model).

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

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

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

Анализ осуществляется с целью определения необходимости организации дополнительной защиты тому или иному бизнес-процессу.

Проводить его будем по следующим направлениям:

1. Идентификация и оценка ценности информационных ресурсов КИС.

2. Загрузка вычислительных ресурсов бизнес-процесса.

3. Опасность среды бизнес-процесса с точки зрения проникновения нарушителя, ее уязвимость.

4. Защищенность, которая обеспечивается встроенными в среду средствами защиты.

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

К информационным ресурсам, в первую очередь, относится так называемый интеллектуальный капитал (ИК) организации, включая нематериальные активы. В [11] определен следующий состав ИК:

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

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

Перечисленные интеллектуальные активы в виде различных по семантике БД, хранилищ, отдельных файлов привязаны как внешние сущности к бизнес-процессам; при моделировании последних подсистема мониторинга ведет учет этих сущностей. Таким образом осуществляется структуризация ИК, в результате чего все информационные ресурсы КИС ставятся в соответствие «клеткам» платформенной компоненты, а именно, столбцу Information того или иного бизнес-процесса.

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

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

Оценочные критерии при определении значений приоритета Pr активов ИК могут быть следующие:

К1. Нормативные акты, которые регламентируют актив: «закон РФ-4», «ГОСТ-3», «РД-2», «внутренние документы-1»; (этот критерий имеет свою лингвистическую шкалу, но она волне согласуется с общей).

К2. Конкурентные преимущества.

К3. Объем недополученного дохода.

К4. Степень личной ответственности ЛПР.

К5. Степень юридической ответственности.

К6. Стоимость восстановления кодов.

К7. Стоимость восстановления аппаратных средств.

К8. Потери от компрометации брэнда.

К9. Стоимость восстановления данных и т.д.

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

Далее по каждому активу «клетки» подсистема мониторинга предлагает предварительные списки каждому эксперту, которые они могут утвердить или модифицировать. После этого СППР проводит процедуру согласования списков экспертов. Алгоритмы согласования хорошо известны, в систему могут быть заложены несколько с тем, чтобы ЛПР мог выбрать процедуру согласования. На рис. 2.14. приведена блок-схема процедуры согласования, проводимой СППР, которая включает блоки автоматического и ручного согласования [4].

предварительного списка каждым экспертом по каждой Комментарии к блокам, требующим пояснения Блок 2 проводит сравнение экспертных списков и создает два списка параметров: список А, в который вошли критерии, выбранные всеми экспертами, и список В, содержащий все остальные критерии. Список В подлежит дальнейшему согласованию.

Блок 4 проверяет номер итерации. Если итерация первая – переход к блоку 5, если нет – к блоку 7. Вообще итераций может быть сколь угодно много, но опыт показывает, что на последующих итерациях скорость сходимости падает или сближение оценок вообще прекращается. Поэтому после первой (или первых) итераций лучше перейти к какому-либо методу их автоматического согласования использованием процедур голосования, тогда в списке остаются те критерии, которые прошли ту или иную процедуру голосования. В настоящее время в литературе описано достаточно много процедур голосования, с которыми можно ознакомиться, например, в [5].

Важно отметить, что от выбора процедуры может зависеть ее результат, поэтому выбор процедуры может вызвать дискуссию, но процедура может быть определена и руководителем.

Пусть после первой итерации ЛПР решил провести голосование по правилу абсолютного большинства, т.е. считать согласованными те критерии, за которые проголосовали больше половины экспертов. СППР сравнивает перечень параметров в списке В и определяет число экспертов, давших одинаковые оценки. Оказалось, что у большинства экспертов оценки совпадают. Система записывает эти оценки в список А, ликвидируя список Процедура согласования списка критериев по «клеткам» закончена.

В табл. 2.1 приведен пример согласованных оценок приоритета ресурсов «клеток» Si-го бизнес-процесса по списку критериев K1, K2, K3.

Идентификатор процесса Si Таблица 2.1. Пример согласованных оценок приоритета ресурсов.

критериям К1, К2 и К3 соответственно, кот орые считаются как средние по столбцу.

Последний столбец таблицы содержит приоритеты «клеток», которые представляют собой линейные функции где арs – вес критерия, xрs – значения критерия, а также совокупную потребуется в дальнейшем при ранжировании целей безопасности.

Далее следует определить значимость критериев, их вес aps. Для этого эксперту таблицу рангов (значимости). Ранг критерия определяет, какова по мнению экспертов, его важность (табл.2).

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

бизнес-процесса Таблицы типа 2.1, 2.2 определяющие балльные или лингвистические оценки критериев и их веса, составляются экспертами заранее и согласовываются в подсистеме предпроектного проектирования СППР.

После того, как каждый эксперт проставил ранги в таблицах 2 для каждой «клетки» СППР определяет сумму рангов, набранным каждым критерием:

rps= r js ns, где rjs– ранг s-го критерия, определенный j-м экспертом для р-ой «клетки», ns – число экспертов, давших данную оценку критерию, а также вес критерия, т.е нормированную сумму рангов aps= ps В итоге получим табл. 2.3, последний столбец которой содержит значения весов арs из Оценка загрузки вычислительных ресурсов бизнес-процесса.

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

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

1. Степень загрузки того или иного оборудования (производится по аппаратному слою референсной модели – рис.1).

2. Степень разбалансировки загрузки сетевого оборудования (столбец Communication) и оборудования столбцов User, System, Information.

3. Отклонение от штатных значений и т.д.

«отсутствует-0», «низкая-1», «средняя-2», «высокая-3», «критическая-4».

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

Оценка параметров уязвимости среды бизнес-процесса. Среда, которая представляется «клетками» платформенной компоненты OSE\RM, подвержена влиянию ряда объективных факторов, декларируемых стандартом ИСО\МЭК 15408 [6]:

угрозы информационной безопасности со стороны среды бизнеспроцесса Y(Si), где i=1I, I – количество автоматизированных бизнеспроцессов предприятия, характеризующиеся вероятностью возникновения и вероятностью реализации;

контрмер X ( ~ 1, ~ 2,…. ~ n), влияющие на вероятность реализации угрозы;

нарушитель, определяющий вероятность возникновения угрозы;

риск – фактор, отражающий возможный ущерб в результате реализации угрозы.

Р(А( ~ i))–вероятность реализации той или иной угрозы, здесь А( ~ i)-событие, интерпретируемое как использование нарушителем уязвимости ~ i ;

U(Si)–величина функционирования бизнес-процесса Si.

Тогда количественный уровень риска определяется как функция R(Si) = f (Р(А( ~ i)),U(Si))).

При этом вероятностные оценки будем рассматривать в рамках субъективного подхода, который рассматривает вероятность как субъективную меру убежденности наблюдателя, соответствующую его знаниям и опыту, в истинности или ложности предложенного ему утверждения [7]. Тогда оценку меры риска Risk(Si), присущего бизнеспроцессу, можно определить как произведение оценки угрозы Y(Si) на оценку ценности ущерба Pr(Si) Итак, среда бизнес-процесса несет угрозы его безопасности, т.к. является носителем уязвимостей X, т.е. тех огрехов в ПО или защите, которые могут быть использованы нарушителем. Рассматриваются два типа уязвимостей:

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

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

1. С помощью определенного ПО (сканеры уязвимостей) для конкретной проектирования СППР выявляются перечни уязвимостей X ( ~ 1, ~ 2,…. ~ n)и ставятся в соответствие «клеткам».

2. Любую уязвимость ~ i можно характеризовать двумя действиями:

сначала идентифицировать уязвимость, а затем ее использовать. ~ i с точки зрения этих действий характеризуется следующими параметрами:

a. временем, которое необходимо для совершения этих действий, b. необходимой квалификации, c. уровнем знаний о среде, d. характером и продолжительностью доступа к среде, e. необходимыми аппаратно-программными ресурсами.

Для каждого критерия в СППР имеются согласованные экспертами оценочные балльные шкалы, разработанные на основе [8] (в табл. 2. приведен пример шкалы по критерию а), оценочные шкалы остальных критериев можно посмотреть там же).

Далее для ~ i СППР получает общую оценку (рейтинг уязвимости) по алгоритму, описанному в [8], который использует используют аддитивную функцию, т.е. выбранные значения по обоим действиям по всем таблицам суммируются. Если уязвимость можно идентифицировать\использовать несколькими способами, для каждого из них вычисляется рейтинг и из полученных значений выбирается минимальное, т.е. уязвимость характеризуется самым простым методом успешного нападения. По этому же правилу по всем. ~ i «клетки» вычисляется общий рейтинг Rклетки,т.е. Rклетки= min(R x 1, R x 2,…., R x i), где R x i -рейтинг уязвимостей, принадлежащих данной «клетке». Оценочная шкала рейтинга уязвимостей приведена в табл.

2.5.

3. По тому же принципу вычисляется потенциал нарушителя NР. В [8] этот потенциал с учетом правила максимума NP =max(NP1,NP2,…, NPn)(из нескольких сценариев нападения выбирается худший вариант, с наибольшим потенциалом) определяется оценками табл.2.6.

Оценка защищенности встроенными средствами. Защита среды бизнес-процессов от несанкционированного вмешательства в процессы их функционирования обеспечивается специальными механизмами. В литературе [6,8] описываются следующие защитные механизмы (Мх):

1. Идентификация и аутентификация пользователя;

2. Разграничение доступа пользователей к ресурсам бизнес-процесса;

3. Мониторинг и аудит событий, происходящих в системе;

передаваемых данных;

5. Контроль целостности и аутентичности (подлинности и авторства) хранимых и передаваемых данных;

6. Экранирование компьютерной сети, т.е. защита ее периметра;

7. Анализ защищенности, т.е. выявление и анализ уязвимостей среды бизнес-процесса;

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

9. Обеспечение обслуживаемости, т.е. способности к быстрому и безопасному восстановлению;

10. Туннелирование, т.е. «упаковка» передаваемого пакета данных в новый «конверт»;

11. Уничтожение остаточных на носителях данных;

12. Выявление и нейтрализация вирусов;

13. Обнаружение компьютерных атак;

14. Управление, обеспечивающее согласованное функционирование средств защиты.

Каждый механизм реализуется методами, алгоритмы которых и обеспечивают тот или иной уровень защиты. Традиционно уровень защиты принято определять стойкостью механизмов. Под стойкостью понимается характеристика, отражающая минимальные усилия нарушителя, необходимые для нарушения безопасности, обеспечивающейся данным механизмом [9]. Параметр оценивается шкалой «Стойкость»: «базовая-1», «средняя-2», «высокая-3».

В свою очередь, совокупности механизмов реализуются в виде тех или иных средств защиты, которые делятся на два класса:

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

2.Наложенные, т.е. реализованные как самостоятельные программные или программно-аппаратные комплексы и устанавливаемые дополнительно.

На стадии предпроектного проектирования подсистема мониторинга в интерактивном режиме опрашивает экспертов и сопоставляет каждой «клетке» реализованные в ней штатные механизмы. СППР заполняет таблицу стойкости типа табл.2.7.

Идентификатор «клетки» Стойкость механизмов S(Mxk) Здесь S(Mxk) – стойкость k-го защитного механизма.

S (Mxk) - средняя стойкость k-го механизма по бизнес-процессу, оценки механизмов по столбцу 2 k.

S(Mxp)–совокупная синергетического защитного эффекта от влияния механизмов друг на друга.

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

Оценка S(Mxp) производится экспертами следующим образом:

1. каждый эксперт на основании столбцов 2 k выставляет совокупную оценку. Для этого вводится шкала «Совокупная стойкость»: «низкая-1», «умеренная-2», «высокая-3», «очень высокая-4», т.к. шкала «Стойкость», предлагаемая стандартами [6,9], не обеспечивают однородность оценочных шкал.

2. согласование совокупных оценок по вышеприведенному алгоритму. В табл.7 приведен пример согласованных оценок.

S (Mx)– средняя совокупная стойкость механизмов бизнес-процесса, вычисляется по недостатку как среднее по столбцу S (Mxk)= x p, хрp p совокупные оценки механизмов по столбцу k+1.

Анализ параметров мониторинга. Анализ взаимосвязей этих параметров позволяет решить вопрос о достаточности \не достаточности штатных механизмов.

Итак, в результате мониторинга получим распределение параметров по референсной модели, представленное на рисунке 2.15, где каждая «клетка»

оценивается рейтингом уязвимостей Rклетки, потенциалом нарушителя NP, который может воспользоваться уязвимостями клетки X клетки, стойкостью S(Mxp) защитных средств и приоритетом ресурсов Pr(Kp), сопоставленных данной «клетке».

NP NP NP

NP NP NP NP

NP NP NP NP

Рис.2.15. Матрица параметров мониторинга в соответствии с моделью OSE\RM Соотношение параметров определяется по следующим правилам:

СППР рассматривает пару рейтинг «клетки» Rклетки – потенциал нарушителя NP. Первое решающее правило гласит: нарушитель может совершить успешное нападение на ресурсы «клетки», если его потенциал не меньше рейтинга уязвимости, т.е., если рейтинг уязвимости имеет, например, оценку «умеренный», то для успешного нападения потенциал нарушителя должен быть «высокий» (см. рис. ).

Таким образом, условие успешного нападения заключается в том, что существует NP= max (NPj) такое, что Rклетки < NP, где j – типы нарушителя.

2.С другой стороны, нападение нейтрализует защитный механизм, обладающий определенной стойкостью, т.е. необходимо сравнить пару:

потенциал нарушителя NP – стойкость механизмов S(Mxp). Сравнение будем проводить следующим образом: если S(Mxp)NP, то нападение нарушителя будет отражено защитным механизмом и уязвимости «клетки» не «сыграют».

Рис. 2.16 демонстрирует схему сравнения параметров Rклетки, NP и S(Mxp) в нечетких шкалах по правилам 1 и 2.

Рис. 2.16. Схема сравнения параметров по правилам 1, 3. В результате проверки правил 1 и 2 для параметров NP, S(Mxp), Rклеткиподсистема мониторинга делает вывод о степени реализации угрозы Yр для той или иной «клетки». При этом возможны следующие девять ситуаций:

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

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

В). Ситуация, когда угроза, скорее всего, осуществима, т.к. в силу приближенности оценок правило 2 может не сработать.

Г). Очень возможно, что угроза реализуется, т.к. потенциал выше рейтинга уязвимостей, хотя стойкость выше потенциала.

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

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

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

З). Угрозы почти нет, т.к. рейтинг выше потенциала, а стойкость ему соответствует.

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

Рис.2.16 демонстрирует графическое представление различные соотношения анализируемых параметров в соответствии с исходами правил 1, 2.

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

4. Вообще говоря, на основании выводов, представленных подсистемой мониторинга в соответствии с проведенным анализом, СППР может принять решение о необходимости привлечения наложенных средств защиты. Но, в дополнение к полученным оценкам, она может осуществить и анализ того, какие риски ожидают компанию, если угроза реализуется с уверенностью Yp. Риск – это категория, зависящая не только от степени реализации угрозы, но и от объема ущерба.

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

где Pr(Kp) – оценка ущерба, Yp – оценка угрозы, p=1,…,P.

Вычисленное значение Riskp отображается на шкалу «Риск клетки», которая формируется из следующих соображений. Формула (2) может дать 20 возможных произведений: 0, 1, 2, 3, 4, 6, 8, 9, 10, 12, 14, 15, 16, 18, 20, 21, 24, 28, которые СППР автоматически может разнести по, например, 5-и балльной шкале, отнеся 0, 1, 2, 3 к уровню риска «очень низкий»; 4, 5, 6, 7 – к уровню «низкий»; 8, 9, 10, 12 – к «средний»; 14, 15, 16, 18 – к «выше среднего»; 20, 21, 24, 28 – к «высокий». Если такое разнесение экспертов не устроит, возможна процедура ручного формирования шкалы риска и разнесения по ней возможных значений Riskp.

Совокупный по бизнес-процессу риск Risk подсистема мониторинга может определять двумя способами (хотя могут быть заложены и другие алгоритмы):

1.Как среднее значение по «клеткам» Risk= 2.Как мультипликативная функция с учетом важности риска для «клетки» Risk= a p Risk p. При этом СППР производит процедуру назначения и согласования весов «клеток» ар с точки зрения риска по алгоритмам, описанным ранее.

Стратегии, связанные с управлением рисками, из которых ЛПР производит выбор могут быть различные, но существуют четыре стандартные:

Стратегия 1. Пусть Risk* - некоторый порог риска, приемлемого для компании с точки зрения ЛПР. Тогда, если Risk < Risk*, то по данной клетке компания готова нести потери в случае атаки злоумышленника, но систему безопасности из дополнительных средств проектировать не нужно.

Стратегия 2. Ликвидация риска, т.е сведение его до нулевого уровня.

Стратегия 3. Уменьшение риска до приемлемого уровня.

Стратегия 4. Переадресация риска – означает, что компания решает застраховать риски, связанные с информационными атаками и дополнительные средства защиты.

Стратегии 2 и 3 работают при условии Risk Risk*. Это означает, что при неприемлемом риске в дополнение к защитным штатным средствам необходимы наложенные, т.е. нужно проектировать комплексную систему защиты (КСЗ) из наложенных и штатных средств, а стало быть, необходимо реализовывать процедуру определения целевых векторов безопасности KShцель(K(T*),C(Т*)D(T*) где K(T*),C(Т*),D(T*)–уровни конфиденциальности, целостности, доступности соответственно, которые должна обеспечивать КСЗ для ресурсов, обрабатываемых бизнес-процессом. Состав вектора безопасности продиктован тем, что информационная безопасность обеспечивается именно перечисленными основными свойствами данных в информационных системах.

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

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

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

ГЛАВА 3. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ

МОНИТОРИНГА БЕЗОПАСНОСТИ КОМПЬЮТЕРНЫХ СЕТЕЙ

мониторинга безопасности на примере использующих Internet –ресурсов.

В качестве разграничения доступа к глобальной компьютерной сети Internet используют proxy-сервер.

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

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

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

HTTP HTTP

FTP FTP

TCP TCP

Internet Рис. 3.1. Предоставление proxy – сервером индивидуальных шлюзов для Наиболее популярными на сегодняшний день являются такие прикладные программы как WinProxy и Wingate..

Proxy под управлением Wingate. Wingate был создан для облегчения доступа в Internet. Он может использоваться в любом сетевом окружении, использующем протокол TCP/IP. Wingate управляет доступом к сервисам Internet, таким как электронная почта и World Wide Web. Wingate может использоваться в Интрасети или корпоративной сети, не имеющих доступа в Internet.

Wingate состоит из двух серверных компонентов и клиентского приложения.

Wingate engine - это сервис, запускаемый на машине соединенной с Internet. Он обеспечивает работоспособность соединения, но невидим для пользователя.

Gatekeeper - это интерфейс для управления и настройки Wingate engine. Wingate Internet Client (WGIC) запускается на клиентской машине и обеспечивает доступ к средствам перенаправления Winsock (Winsock redirection).

Так как, GateKeeper использует протокол TCP/IP для соединения с Wingate engine, то он может быть запущен на любой машине. Это означает, что имеется возможность администрировать Wingate с той машины, на которой Wingate установлен.

Wingate управляется и настраивается с помощью инструмента удаленного администрирования Gatekeeper.

Gatekeeper DHCP автоматизирует конфигурацию клиентов в сети. С авто DHCP Сервер режимом или ручным режимом, Wingate DHCP конфигурирует DNS - сервер обеспечивает достаточные функциональные DNS Сервер возможности, чтобы использовать сервер SOCKS для запросов SOCKS4. DNS-сервер Wingate объединен с DHCP-сервером, что позволяет разрешить DNS. Если требуется большее количество функциональных возможностей, может использоваться Mapping Планировщик Планировщик позволяет администратору управлять Wingate и системным операциями. Многие операции могут быть автоматизированы, включая очистку Log-журнала, выключение Аутентификаци WWW-Proxy Wingate включает инструмент идентификации я клиента Java. Это позволяет администраторам требовать идентификации аутентифицированный пользователь пытается обращаться к странице сети, отображается ‘Sorry’ страница и апплет входа в Wingate может использовать различные подключения к Internet, Поддержка чтобы дать более широкую пропускную способность и быстрый конфигурируемых на уровне "сервиса", дают полное управление SOCKS V5 Wingate SOCKS сервер совместим с SOCKS 4 и SOCKS 5 (RFC 1928). Поддерживается RFC1929 идентификация, используя базу Сервер данных пользователей Wingate. Wingate SOCKS-сервер понимает HTTP. Он может распознать и обрабатывать HTTP-запросы с Мощный Wingate WWW-Proxy - CERN-совместимый HTTP proxy сервер.

WWW Proxy Особенности включают способность обработать нормальные (не-proxy) запросы, которые делают его хорошим внешним интерфейсом для существующего WWW-сервера, или даже инструментом автоматического mirroring. Он также позволяет располагать proxy-серверы каскадом через другой proxy или Кэширование HTTP Caching - процесс сохранения графики, HTML документов HTTP Wingate WWW-Proxy настраивается так, чтобы понимать и proxy Типы запросов и не-proxy запросы, позволяя запросам быть обработанными "как обычно" или переназначить их на сервер Internet или Превосходный инструмент управления LAN, который позволяет Учет осуществлять контроль в реальном масштабе времени.

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

Политика Безопасность Wingate обеспечивается назначением прав безопасности и пользователей и групп. Имеется множество типов прав, которые права можно предоставлять FTP proxy обеспечивает доступ к FTP- серверам. Используется FTP Proxy username@hostname метод прохождения firewall. FTP proxy поддерживают non-proxy запросы. Это позволяет proxy действовать как front-end на FTP сервере или каскадом через XDMA Proxy Wingate поддерживает Xing Streamworks audio и video клиентов.

Wingate Telnet proxy предоставляет доступ к telnet серверам.

Telnet Proxy Telnet proxy в Wingate поддерживает множество telnet-клиентов, в том числе и под Unix. Telnet также понимает каскадирование Сложная система firewall позволяет контролировать загрузку Правила сервера Wingate, включая права на доступ к сервису, системные права доступа, и взаимодействие с группами и пользователями.

Запуск как Wingate работает как сервис под Windows NT Это означает, что Wingate начинает работать когда Windows загружается, вне Сервиса зависимости от того, какой пользователь вошел в систему.

Пользователи локаль ной сети Рис. 3.2. Схема работы proxy-сервера Wingate.

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

отслеживание объема и содержимого данных получаемых из Internet сотрудниками;

ведение групповых учетных записей;

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

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

удаленное администрирование через Панель Управления.

Решение вышеперечисленных задач позволит отделу информатизации принимать правильные решения, а Аппарату Правительства - снизить издержки на Internet.

3.2. Алгоритм функционирования программы.

В результате работы proxy-сервера Wingate вся информация о работе пользователя, фиксируется в log-файлах. Это является основным базисом для генерации отчетов и статистики. Извлекаемые данные могут быть представлены в качестве структурированных таблиц, либо в форме отчетов подтверждением того, что пользователь работал в сети на случай претензий последнего.

Как показала практика последних лет, для достижения этих задач оптимально подходит разработанная фирмой Borland программная среда Delphi.

«Delphi» – это современный программный продукт, позволяющий создавать широкий спектр приложений для среды Microsoft Windows» [11].

Он объединяет в себе высокопроизводительный компилятор с языка ObjectPascal, (визуального) создания программ и масштабируемую технологию управления БД. Основное назначение Delphi – служить средством для приложения, отвечающие технологии распределенной обработки данных, называемой технологией клиент-сервер.

Для разработки Windows-приложений Delphi имеет следующие средства:

высокопроизводительный компилятор необходимости можно воспользоваться и пакетным компилятором DCC.EXE.

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

При этом язык остался совместимым с языком Pascal, поддерживаемым компилятором BorlandPascal 7. -быстрая среда разработки (RAD) Среда Delphi содержит полный набор визуальных средств для быстрой разработки приложений, поддерживающих как создание пользовательских интерфейсов, так и обработку корпоративных данных (с использованием соответствующих средств). Использование библиотеки визуальных компонентов (VCL) и визуальных объектов для работы с данными позволяет создавать приложения с минимальными затратами на непосредственное кодирование. При этом компоненты, включенные в состав Delphi, максимально инкапсулируют вызовы функций Windows API, тем самым облегчая процесс создания программ.

-расширяемость «Delphi является системой с открытой архитектурой, что позволяет дополнять ее новыми средствами и переносить на различные платформы»

[11].

-средства для построения БД Delphi поддерживает практически все форматы существующих реляционных таблиц. Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland DataBase Engine.В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходят с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер InterBase, для того, чтобы можно было разрабатывать расширяемые на любые внешние SQL-серверы приложения в информационную систему для локальной машины может использовать для хранения информации файлы формата.dbf (как в dBase и Clipper) или.db (Paradox). Если же он будет использовать локальный InterBase for Windows 4.2 (и выше), то его приложения безо всяких изменений будут работать и в составе большой системы с архитектурой «клиент-сервер».

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

Библиотека классов, входящих в Delphi, содержит около 140 классов, инкапсулирующих различные группы функций Windows API. Delphi является системой с открытой архитектурой, что позволяет дополнять ее новыми средствами, и переносить на различные платформы. Модернизированное ПО ОПВ включает в себя базу данных, для управления которой вполне подходит InterBase Server, разработанный той же фирмой. Производительность и возможности сервера превышают требования данного проекта. При этом InterBase Server условно бесплатен и доступен.

Выходные данные.

Выходная информация представляет собой файлы следующих типов:

HTML, EXL, DOC.

Система генерирует следующие виды отчетов:

сводный отчет;

отчеты по месяцам, неделям и дням;

сводные отчеты дням и часам;

отчеты по пользователям;

отчеты по IP адресу;

отчеты о сервисах.

Информационная система мониторинга реализована в виде двух модулей: «генерации отчетов» и «модуля контроля».

1. Генерация отчетов основана с применением компонент Fast Report, и Export Strings которые позволяют быстро создавать отчеты, обрабатывать большое количество информации. А также экспортировать отчеты в Microsoft Excel, Microsoft Word и HTML.

2. Модуль контроля разбит на две части:

управление Wingate осуществляется через системный реестр Windows;

подпрограмма которая отслеживает время, пройденное с момента входа пользователя в сеть Internet, до его выхода. А также реализованы API функции Application Programming Interface (что можно приблизительно перевести как "Интерфейс программирования для приложений"), с помощью которых осуществляется связь с приложением Wingate и системой Windows.

Microsoft Word, Microsoft Excel Рис. 3.3. Структурная схема работы программы мониторинга.

Алгоритм функционирования программы можно представить в виде следующей блок схемы. ( рис. 3.4).

НАЧАЛО ПРОГРАММЫ

Обработка входных данных с помощью объектноориентированного языка программирования – Delphi v. 8.

ВЫХОДНЫЕ ДАННЫЕ.

КОНЕЦ ПРОГРАММЫ

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

настроить ее.

Для этого нужно выбрать в главном меню «Настройки».

Форма «Настройки» содержит несколько закладок:

Денежные единицы.

В закладке «Log файлы» указывается путь где находятся журналы регистрации генерируемые proxy-сервером Wingate. А также путь куда будут поступать отчеты генерируемые самой программой.

В закладке «Лимиты» задается количество трафика выделяемого на пользователя Internet-ресурсов.

Форма «Отчеты» содержит графы:

Имя пользователя.

Входящий трафик.

Исходящий.

Позволяет создавать необходимый отчет в необходимом формате (HTML, Word, Excel. Text).

Также позволяет выбрать интервал по датам.

Генерируемые отчеты:

Отчет по IP адресам;

Отчеты по группам и по пользователям;

Рис. 3.11. Отчеты «Отчеты по группам и по пользователям».

Отчет по временным интервалам;

Рис. 3.12. Отчет «Отчет по временным интервалам».

Выводы по третей главы 1. Показана целесообразность применения Proxy-серверов для организации системы мониторинга безопасности.

2. С использованием Proxy-серверов в данной работе разработаны алгоритм и программный модуль мониторинга безопасности на примере использующих Internet-ресурсов, позволяющий получить статистические данные о сетевом трафике.

ЗАКЛЮЧЕНИЕ

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

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

Основными результатами работы являются:

1. Рассмотрены методы защиты ИКС, сбор и анализ трафика для выявления вредоносных и нежелательных объектов и разработки комплексной системы мониторинга безопасности ИКС.

2. Рассмотрены методы мониторинга безопасности, решающие проблемы непрерывного контроля компьютерных сетей, обнаруживая при этом внутренние и внешние воздействия на ресурсы компьютерных сетей.

3. Выполнен анализ существующих аппаратно-программных средств мониторинга безопасности для определения основных компонентов позволяют обнаруживать уязвимости до их применения.

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

позволяющий получить статистические данные о сетевом трафике.

Выступление Президента Республики Узбекистан Ислама Каримова на открытии международной конференции «Подготовка образованного и интеллектуально развитого поколения – как важнейшее условие устойчивого развития и модернизации страны»

Каримов И. А. «Узбекистан по пути углубления экономических реформ» Т.: Узбекистон, 1995 г.

Управление доступом и информационными потоками: Учеб. пособие для вузов.- М.: Горячая линия - Телеком, 2011.- 320 с.

Липаев В.В. Тестирование компонентов и комплексов программ.— М.:

Синтег, 2010.— 400 с.

Черников Б.В. Управление качеством программного обеспечения:

Учебник для вузов.— М.: ИНФРА-М, Варлатая С.К., Шаханова М.В. Программно-аппаратная защита информации: учеб. пособие – Владивосток: Изд-во ДВГТУ, 2007. – информации.

М.: Агентство «Яхтсмен», 1996.

Зегжда Д.П., Ивашко A.M. Основы безопасности информационных систем. М.: Горячая линия - Телеком, 2000.

Корн Г., Корн Т. Справочник по математике (для научных работников 10.

и инженеров). М.: Наука, 1973. 832 с.

Репин Д.С. Анализ и моделирование трафика в корпоративных 11.

компьютерных сетях: дис. канд. техн. наук

: спец. 05.13.01 «Системный анализ, управление и обработка информации (промышленность)» / Д.С.

Репин. – М., 2008. – 143 с.

Крон Г. Тензорный анализ сетей, пер. с англ., род ред. Л.Т.Кузина, 12.

П.Г.Кузнецова. – М.: Сов. радио, 1978. – 720 с.

13. Vincent Berk, Annarita Giani, George Cybenko Detection of Covert Channel Encoding in Network Packet Delays. 2005.

14. Myong H. Kang, Ira S. Moskowitz A Pump for Rapid, Reliable, Secure Communication // 1st ACM Conference on Computer & Communications Security. 1993. PP. 119–129.

Тарасюк М. В. Адаптивная маскировка скрытых каналов в открытых 15.

системах с многоуровневым доступом.

16.

КомпьютерПресс. – 2005. - №2. – С. 80-86.

17. F. Baker and P. Savola, "Ingress Filtering for Multihomed Networks," RFC Интернет ресурсы:

1. www.gov.uz 2. www.tuit.uz 3. www.intuit.uz 4. http://www.loniis.ru/about/ 5. http://inf-bez.ru/?p= 6. http://www.sseu.ru/about/inform/norm/insmonit/ 7. http://www.computel.ru/decision/ssb/Monitoring%20IS/ 8. http://www.infosec.ru/services/support/outsourcing/monitoring/

ПРИЛОЖЕНИЕ

unit Unit1;

interface uses Windows, Messages, SysUtils,shellapi, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, lmdctrl, lmdstdcA, ExtCtrls, EC_Main, EC_TStrings, Mask, ToolEdit, lmdcctrl, lmdgroup, RxLogin,Hyperstr;

type TForm1 = class(TForm) GroupBox1: TGroupBox;

List1: TLMDListBox;

Panel1: TPanel;

Button1: TButton;

Exp1: TExportStrings;

Panel2: TPanel;

Label1: TLabel;

DateEdit1: TDateEdit;

DateEdit2: TDateEdit;

Panel3: TPanel;

Label2: TLabel;

Edit1: TEdit;

Edit2: TEdit;

Button2: TButton;

Button3: TButton;

Button4: TButton;

Button5: TButton;

LMDCheckBox1: TLMDCheckBox;

LMDCheckBox2: TLMDCheckBox;

Box1: TComboBox;

Login1: TRxLoginDialog;

M1: TMemo;

LBox1: TListBox;

Button6: TButton;

procedure Button1Click(Sender: TObject);

procedure Button5Click(Sender: TObject);

procedure FormShow(Sender: TObject);

procedure Button6Click(Sender: TObject);

private { Private declarations } public { Public declarations } end;

var Form1: TForm1;

implementation uses Unit2;

{$R *.DFM} procedure TForm1.Button1Click(Sender: TObject);

var i,traff,a,b,a1:longint;

w,st,ss,traf,filen,data,ip,user,gr,traf1,lim,time,file_buf:string;

begin file_buf:= form2.patchwg1.Text+'\'+form2.file1.Items[0] ;

m1.Lines.LoadFromFile(file_buf);

case box1.ItemIndex of begin exp1.ExportType:=xHTML;

filen:='report.html';

end;

begin exp1.ExportType:=xMicrosoft_Word;

filen:='report.rtf';

begin exp1.ExportType:=xMicrosoft_Excel;

filen:='report.xls';

end;

begin exp1.ExportType:=xText_Tab_Delimited;

filen:='report.txt';

end;

end;

//exp1.ExportFile:='strings';

exp1.ExportFile:=form2.DirectoryEdit1.Text+'\'+filen;

//list1.Items.LoadFromFile('c:\program files\Wingate\logs\logs_all1.txt');

for a:=1 to m1.Lines.Count-1 do begin st:=m1.Lines[a];

for b:=1 to length(st) do begin if b0 then LBox1.Items.Add(W) else break;

until True=False;

data:=LBox1.Items[0]+'-'+LBox1.Items[1];

user:=LBox1.Items[3];

ip:=LBox1.Items[2];

if LBox1.Items.Count>5 then traf:=LBox1.Items[6] else traf:='0';

if LBox1.Items.Count>9 then begin traf1:=LBox1.Items[7];

time:=LBox1.Items[10];

end;

if length(form2.Edit1.text)0 then if IsNum(ss)= true then traff:=strtoint(ss)+traff;

//showmessage(ss);

end;

exp1.Strings:=list1.Items;

exp1.Footer.Add('Общий трафик: '+inttostr(traff)+' байт');

exp1.Footer.Add(inttostr(round(traff/1024))+' Kбайт');

exp1.Footer.Add(inttostr(round(traff/1024/1000))+' Мбайт');

exp1.Execute;

end;

procedure TForm1.Button5Click(Sender: TObject);

begin form2.ShowModal;

end;

procedure TForm1.FormShow(Sender: TObject);

begin box1.ItemIndex:=0;

dateedit1.Date:=date;

dateedit2.Date:=date;

form2.file1.Directory:=form2.patchwg1.text;

end;

procedure TForm1.Button6Click(Sender: TObject);

begin ShellExecute(0, 'open', pchar(exp1.ExportFile), '',pchar(exp1.ExportFile), SW_SHOWNORMAL);

end;

end.

unit Unit2;

interface uses Windows, Messages,shellapi,SysUtils, Classes, Graphics, Controls, Forms, Dialogs, Menus, StdCtrls, ExtCtrls, RXClock, ToolEdit, CurrEdit, RXCtrls, Mask, ComCtrls, aprstore, lmdcctrl, lmdctrl, lmdeditb, lmdeditc, lmdbredt, lmdstdcA, Lmddbctr, FileCtrl;

type TForm2 = class(TForm) MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

LogWingate1: TMenuItem;

OpenDialog1: TOpenDialog;

N4: TMenuItem;

N5: TMenuItem;

Page1: TPageControl;

TabSheet1: TTabSheet;

TabSheet2: TTabSheet;

TabSheet3: TTabSheet;

TabSheet4: TTabSheet;

FilenameEdit2: TFilenameEdit;

RxLabel1: TRxLabel;

RxLabel2: TRxLabel;

DirectoryEdit1: TDirectoryEdit;

RxLabel3: TRxLabel;

CurrencyEdit1: TCurrencyEdit;

CurrencyEdit2: TCurrencyEdit;

RxLabel4: TRxLabel;

ComboEdit1: TComboEdit;

ComboEdit2: TComboEdit;

RxLabel5: TRxLabel;

RxLabel6: TRxLabel;

RxLabel7: TRxLabel;

FilenameEdit3: TFilenameEdit;

RxLabel8: TRxLabel;

DateEdit1: TDateEdit;

RxClock1: TRxClock;

RxLabel9: TRxLabel;

RxLabel10: TRxLabel;

Edit1: TEdit;

Edit2: TEdit;

Edit3: TEdit;

AutoPropertiesStore1: TAutoPropertiesStore;

patchwg1: TDirectoryEdit;

RxLabel11: TRxLabel;

RxLabel12: TRxLabel;

RxLabel13: TRxLabel;

SpinEdit1: TLMDSpinEdit;

SpinEdit2: TLMDSpinEdit;

Label1: TLabel;

Label2: TLabel;

CheckBox1: TCheckBox;

File1: TFileListBox;

procedure LogWingate1Click(Sender: TObject);

procedure N3Click(Sender: TObject);

procedure RxClock1GetTime(Sender: TObject; var ATime: TDateTime);

procedure FormCreate(Sender: TObject);

procedure patchwg1AfterDialog(Sender: TObject; var Name: String;

var Action: Boolean);

procedure patchwg1Change(Sender: TObject);

private { Private declarations } public { Public declarations } end;

var Form2: TForm2;

implementation uses Unit1;

{$R *.DFM} procedure TForm2.LogWingate1Click(Sender: TObject);

begin if OpenDialog1.Execute then //OpenDialog1.FileName:= form1.M1.Lines.LoadFromFile(OpenDialog1.FileName);

end;

procedure TForm2.N3Click(Sender: TObject);

begin page1.ActivePage:= TabSheet2;

end;

procedure TForm2.RxClock1GetTime(Sender: TObject; var ATime: TDateTime);

var dTime: TDateTime;

begin try //Rxclock1.AlarmMinute:=44;

if spinedit1.Value=0 then spinedit1.Text:='00';

if spinedit2.Value=0 then spinedit2.Text:='00';

dtime:=StrToDateTime('30.12.1899 '+spinedit1.Text+':'+spinedit2.Text+':02');

Label1.Caption := DateTimeToStr(dtime);

Label2.Caption := DateTimeToStr(Atime);

if not checkbox1.Checked then begin if dateedit1.Date=date then if Label1.Caption=Label2.Caption then ShellExecute(0, 'open', pchar(FilenameEdit3.FileName), '',pchar(FilenameEdit3.FileName), SW_SHOWNORMAL);

end else begin if Label1.Caption=Label2.Caption then ShellExecute(0, 'open', pchar(FilenameEdit3.FileName), '',pchar(FilenameEdit3.FileName), SW_SHOWNORMAL);

end;

except Application.MessageBox('=хяЁртшы№эvщ ЇюЁьрЄ фрЄv шыш тЁхьхэш!', '¦юьяр', MB_OK+MB_ICONHAND+MB_DEFBUTTON1+MB_APPLMODAL);

end;

end;

procedure TForm2.FormCreate(Sender: TObject);

begin dateedit1.date:=date;

//dateedit1.text:='01.01.01';

end;

procedure TForm2.patchwg1AfterDialog(Sender: TObject; var Name: String;

var Action: Boolean);

begin if Action = true then form2.file1.Directory:=form2.patchwg1.text;

end;

procedure TForm2.patchwg1Change(Sender: TObject);

begin form2.file1.Directory:=form2.patchwg1.text;

end;

end.