Содержание к диссертации
Введение
ГЛАВА 1 Анализ проблемы обеспечения безопасности программного обеспечения в автоматизированных системах ОАО «РЖД» 11
1.1 Общая характеристика предметной области 11
1.2 Анализ проблемы обеспечения безопасности
1.2.1 Уязвимости программного обеспечения 16
1.2.2 Классификация и учет уязвимостей ПО 19
1.2.3 Последствия эксплуатации уязвимого ПО 23
1.2.4 Анализ недекларированных возможностей как уязвимостей ПО 25
1.3 Обзор существующих методов выявления уязвимостей 29
1.3.1 Стандарты разработки программного обеспечения 33
1.3.2 Методы тестирования безопасности 35
1.3.3 Особенности сертификации безопасности программного обеспечения 38
1.3.4 Методы статического анализа 44
1.4 Постановка научной и частных задач исследования 56
Выводы по главе 1 58
Глава 2 Модель системы оценки соответствия програм много обеспечения требованиям безопасности 60
2.1 Анализ существующей системы выявления уязвимостей 60
2.1.1 Формализация показателей, оцениваемых экспертом 64
2.1.2 Обобщение и систематизация данных статического анализа 71
2.1.3 Модель системы
2.2 Выбор и обоснование используемых математических методов 75
2.3 Особенности применения аппарата искусственных нейронных сетей
2.3.1 Модель нейрона 84
2.3.2 Классификация нейронных сетей 87
2.3.3 Исследование процесса обучения нейронных сетей 89
2.3.4 Применение нейронных сетей для решения задач классификации 93
2.4 Разработка модели системы поддержки принятия решения о
соответствии программного обеспечения требованиям безопасности 97
Вывод по главе 2 99
ГЛАВА 3 Разработка метода принятия решения о соотвест вии программного обеспечения требованиям безопасности 102
3.1 Метод верификации безопасности ПО 102
3.1.1 Основные этапы метода 103
3.1.2 Формирование вектора характеристик безопасности ПО 105
3.1.3 Оценивание характеристик безопасности 105
3.1.4 Принятие решения о соответствии ПО требованиям безопасности 107
3.2 Разработка архитектуры нейронной сети для решения задачи верификации безопасности ПО 110
3.2.1 Определение условий решаемой задачи ПО
3.2.2 Определение топологии ИНС 111
3.2.3 Расчет мощности ИНС 112
3.2.4 Разработка метода обучения искусственной нейронной сети используемой в качестве решателя в модуле принятия решений 114
3.2.5 Анализ полученных результатов обучения 128
3.3 Разработка метода использования ИНС для решения задачи поиска заданных конструкций 132
3.3.1 Разработка модели подсистемы поиска заданных конструкций 133
3.3.2 Анализ полученных результатов 137
3.4 Методика автоматизированной верификации безопасности ПО 141
Выводы по главе 3 142
ГЛАВА 4 Описание прототипа системы выявления уязвимостеи и предложений по его практической реализации 143
4.1 Разработка прототипа системы 143
4.1.1 Разработка функциональных требований 146
4.1.2 Методика обучения и тестирования системы 147
4.1.3 Проверка корректности исходных данных 150
4.1.4 Расчет характеристик безопасности ПО 152
4.1.5 Определение классификатора соответствия 152
4.1.6 Принятие решения о соответствии ПО требованиям безопасности 154
4.2 Апробация прототипа 156
4.2.1 Структура системы верификации безопасности ПО АС ОАО «РЖД». 158
4.2.2 Интерфейс системы верификации ПО 160
4.2.3 Анализ соответствия проекта требованиям безопасности 1 4.3 Методика проведения испытаний 168
4.4 Анализ полученных результатов и разработка предложений по
практическому применению СВУ 174
Выводы по главе 4 179
Заключение 182
Список использованных источников 185
- Анализ недекларированных возможностей как уязвимостей ПО
- Выбор и обоснование используемых математических методов
- Оценивание характеристик безопасности
- Принятие решения о соответствии ПО требованиям безопасности
Введение к работе
Актуальность темы исследования
Актуальность работы обусловлена существующей проблемой обеспечения безопасности информационных систем (ИС). В настоящее время сложно представить современную высокотехнологичную организацию без различных ИС, количество которых ежегодно увеличивается. Однако, с ростом количества новых ИС, также растет и количество уязвимостей программного обеспечения (ПО), входящего в их состав. Наличие уязвимостей является риском информационной безопасности для любой современной организации. Следствием этого является нарушение основополагающих свойств безопасности информации - конфиденциальности, целостности и доступности, что может привести к существенному ущербу.
Исследованию в области безопасности ПО и защиты ИС посвящены труды таких российских и зарубежных ученых как: Амир Пнуели, Эдмунд М. Кларк, Аллен Эмерсон и Иосиф Сифакис в области верификации безопасности программ, Брайан Чесс, Джейкоб Вест, Ломако А.Г., Корт С.С., Новиков В. А. в области различных методов анализа ПО, а также работы в области безопасности программ: Тампе Л., Корниенко А.А., Зегжда П.Д., Липаев В.В., Казарин О.В., Марков А., Цирлов В, Иванов- Сотиров A. В основном эти труды посвящены проблеме представления программ в виде, пригодном для его верификации. Отдельные работы посвящены автоматизации выявления некоторых типов уязвимостей.
Также вопросами обеспечения безопасности ПО занимаются такие компании как IBM, Microsoft, Oracle, институт SAMATE, организации OWASP, WASC и MITRE (курирует проект - Common Vulnerabilities and Exposures (CVE)). Анализ проведенных исследований показывает, что количество новых уязвимостей существенно увеличивается с каждым годом. Нельзя не отметить, что в направлении мобильного ПО рост выявляемых уязвимостей составил более 200%.
Наибольшее распространение, при решении задач подтверждения соответствия и выявления уязвимостей в программах, получили методы статического анализа. Системы, построенные на этих методах, используются как базовые, в существующей системе сертификации соответствия ПО требованиям безопасности. В то же время, применение существующих средств выявления уязвимостей для решения задачи сертификации имеет существенные недостатки, из которых, в первую очередь, следует выделить временные и финансовые затраты на проведение сертификационных испытаний. Это делает сертификацию безопасности ПО недоступной для широкого круга разработчиков, так как с учетом сжатых сроков выхода продукции на рынок нет возможности выделить несколько месяцев на получение сертификата безопасности.
Таким образом, исследование и развитие методов верификации безопасности программ и поддержки принятия решения об их безопасности является весьма актуальной задачей.
Объектом диссертационного исследования является автоматизированная система выявления недекларированных возможностей в ПО, применяемая в рамках существующей процедуры сертификации. Предметом исследования являются методы и алгоритмы верификации соответствия ПО требованиям безопасности.
Целью исследования является сокращение временных затрат на проведение сертификационных испытаний ПО.
Научная задача состоит в обосновании и разработке новых методов автоматизированной верификации программ, позволяющих существенно снизить нагрузку на эксперта, и, тем самым, сократить временные затраты на проведение сертификационных испытаний.
Достижение поставленной цели и решение научной задачи требует решения следующих частных задач:
Исследование существующих подходов выявления уязвимостей и подтверждения соответствия программ требованиям безопасности.
Анализ процесса принятия решения экспертом при проведении сертификационных испытаний.
Разработка модели системы верификации соответствия ПО требованиям безопасности.
Разработка метода принятия решения о безопасности ПО.
Разработка методики верификации соответствия ПО требованиям безопасности.
Разработка прототипа системы выявления уязвимостей.
Методы исследования. Для решения поставленных задач
использовались методы абстрактной алгебры и искусственного интеллекта, теория вероятностей, системный анализ, методы верификации ПО, а также информационной безопасности и защиты информации.
Теоретическая основа и методологическая база исследования представляет собой фундаментальные труды в области искусственного интеллекта и теории безопасности ПО, труды отечественных и зарубежных ученых и исследователей в области верификации безопасности ПО, стандарты в области информационных технологий и информационной безопасности.
На защиту выносятся следующие научные результаты:
Метод принятия решения о соответствии ПО требованиям безопасности с применением аппарата искусственных нейронных сетей.
Алгоритм обучения нейронной сети, решающей задачу оценки соответствия ПО требованиям безопасности.
Прототип системы верификации соответствия ПО требованиям безопасности, построенной в соответствии с предложенным методом.
Научной новизной обладают следующие результаты:
Метод принятия решения о соответствии ПО требованиям безопасности с применением аппарата искусственных нейронных сетей, позволяющий снизить нагрузку на эксперта за счет автоматизации решаемых им задач.
Алгоритм обучения нейронной сети, решающей задачу оценки соответствия ПО требованиям безопасности. Применение предложенного алгоритма позволяет повысить скорость сходимости, а также оказывает положительное влияние на качественные показатели принимаемых решений.
Достоверность полученных результатов обеспечивается корректным применением использованного математического аппарата, близостью и согласованностью полученных расчетных оценок с теоретическими выводами, а также апробацией результатов диссертационного исследования на научно-технических конференциях и практическими внедрениями.
Практическая значимость диссертационной работы заключается в том, что применение предложенного метода позволяет автоматизировать решение таких задач как оценивание данных анализа и принятие решения, позволяя, тем самым, практически полностью, снять нагрузку с эксперта при проведении сертификационных испытаний.
Эффективность применения подтверждена численным анализом.
Основные результаты работы использованы в ОАО «Научно- исследовательский и проектно-конструкторский институт информатизации, автоматизации и связи на железнодорожном транспорте», в учебном процессе ПГУПС в дисциплинах «Комплексное обеспечение информационной безопасности автоматизированных систем» и «Безопасность операционных систем», а также работе Испытательной лаборатории средств защиты информации ПГУПС.
Апробация работы. Основные положения и результаты диссертации докладывались и обсуждались на заседаниях кафедры «Информатика и информационная безопасность», международной научно-практической конференции (МНПК) «ИнтеллектТранс 2011», МНПК «ИнтеллектТранс 2012», юбилейной научно-технической конференции «Инновации на железнодорожном транспорте - 2009», Юбилейной 20-й научно- технической конференции «Методы и технические средства обеспечения безопасности информации».
Публикации. По теме диссертации опубликовано одиннадцать печатных работ (статьи и доклады на научно-технических и научно- практических конференциях), из них четыре в изданиях, рекомендованных ВАК Минобрнауки России.
Структура и объем диссертации. Диссертационная работа состоит из введения, четырех разделов основного содержания с выводами по каждому разделу, заключения, списка используемых источников, включающего 151 наименование. Материалы диссертации изложены на 197 страницах машинописного текста, включающих 88 иллюстраций и 22 таблицы, а также приложения объемом 19 страниц, включая 1 таблицу и 2 рисунка.
Анализ недекларированных возможностей как уязвимостей ПО
Ежедневно обнаруживаемые уязвимости необходимо не только систематизировать, но и вести их учет. Эту задачу решают специализированные системы учета выявленных уязвимостей. В настоящее время, общепринятых систем по классификации программных уязвимостей на территории РФ не существует. Наибольших успехов в классификации и систематизации уязвимостей добились США, которые ведут несколько классификаций и активно используют их как в образовательном процессе, так и при разработке высокотехнологичной продукции. Одной из основных систем учета уязвимостей является CVE (Common Vulnerabilities and Exposures), которая курируется компанией NCSD (National Cyber Security Division) при одном из Министерств США.
CVE - список известных уязвимостей, имеющий строгую классификацию по описательным критериям, что отличает его, скажем, от Bugtrack-ленты. Полностью CVE можно отыскать в Национальной Базе Уязвимостей США (NVD - nvd.nist.gov) или на официальном сайте (cve.mitre.org/data/downloads). Причем, распространяется база в нескольких форматах: xml, html, csf, xsd schema. База уязвимостей CVE в силу доступности, открытости и удобства, наиболее часто используется разработчиками ПО (в первую очередь, нацеленного на рынок информационной безопасности и критичных систем).
В общем виде, запись CVE содержит следующую информацию: В CVE ID записывается код и порядковый номер, например "CVE-1999-03". В поле Reference записываются различного рода ссылки на патчи, рекомендательного рода документы или комментарии разработчика. Поле Description - отвечает за описание самой уязвимости. CVE- система широкого профиля и никоим образом не сосредотачивается только на клиентских уязвимостях или, скажем, исключительно на WEB-протоколе. Изначально она задумывалась как единый стандарт идентификации уязвимостей, который должен охватывать несколько звеньев информационной системы: систему поиска и обнаружения брешей (например, сканер безопасности), антивирусное ПО, а также исследуемое ПО.
Компания MITRE Corporation (mitre.org) предложила решение, независимое от различных производителей средств поиска уязвимостей, и взяла на себя ответственность за создание подобной системы. В настоящее время, многие производители ПО, а также антивирусных средств обращаются к системе CVE и добавляют соответствующие сигнатуры в свои продукты.
Система учета уязвимостей BID присутствует исключительно на портале Securityfocus (используется в ленте securityfocus.com/vulnerabilities). Одна из отличительных особенностей BID - совместимость с CVE. У системы есть ряд дополнительных описательных свойств - например, класс, возможность локального или удаленного исполнения и т.п. К преимуществам BID можно отнести то, что она дает разработчику более наглядную информацию о выявленной уязвимости.
Open Source Vulnerability Database (OSVDB) является независимой и открытой базой уязвимостей, созданной сообществом разработчиков ПО с открытым кодом. К главным преимуществам OSVDB можно отнести то, что она предоставляет точную и детализированную техническую информацию о каждой выявленной уязвимости. Проект способствует большему открытому сотрудничеству между компаниями и индивидуальными разработчиками, устраняет избыточные работы и уменьшает расходы, связанные с разработкой и обслуживанием внутренних баз данных уязвимостей.
Датская компания Secunia, специализирующаяся на компьютерной и сетевой безопасности, наиболее известна своими тестами на наличие уязвимостей. Secunia также отслеживает активность компьютерных вирусов. Компания получила широкую известность и репутацию после обнаружения глобальных уязвимостей, связанных с Zero day attack в Internet Explorer и других широко используемых программах. У компании есть сравнительно большая база уязвимостей, доступ к которой осуществляется на платной основе. Для каждой уязвимости в базе данных описаны:
Источник уязвимости (Attack vector) - определяет источник (локальная система, локальная сеть, удаленный компьютер), из которого возможно использование уязвимости.
Критичность - внутренняя оценка (от 1 до 5) Secunia, характеризующая последствия использования уязвимости. - Воздействие - характеризует модель (тип) атаки на уязвимость. ISS X-Force затрагивает все перечисленные выше критерии, но вдобавок описывает бизнес-импакт, а именно - материальный ущерб, который может повлечь за собой эксплуатацию уязвимости. Например, уязвимость "Microsoft Excel Remote Code Execution", нацеленная на компьютер сотрудника банка или предприятия, способна привести к краже важных документов [15]. Также в системе присутствует качественно новая черта - переход к метрикам безопасности для описания свойств уязвимости. Для этого используется общая система подсчета рисков уязвимостей CVSS v.2. Она представляет собой шкалы, на основе которых выставляются баллы. Система метрик была придумана для разделения приоритетов над исправлением уязвимостей. Каждая шкала относится к определенному смысловому разделу, который называется метрикой. В CVSS v.2 их три: базовая, временная и контекстная.
Выбор и обоснование используемых математических методов
Если ФО не передает управление далее, то это может свидетельствовать, либо о наличии ошибки, которая может привести к зависанию ПО, либо о том, что данный ФО является точкой завершения программы, т.е. принадлежит к множеству исключений. Выявить подобные ФО можно анализируя МФО. Если все элементы матрицы, лежащие над главной диагональю для данного ФО; равны 0 и при этом выполняется условие ФО, і ФОИскд, тогда данный ФО является уязвимостью (2.13).
Контроль связей функциональных объектов по информации заключается в построении графа взаимодействия функциональных объектов по информации (граф передачи переменных между функциями и использованию глобальных переменных внутри функций) (Рисунок 2.9). В ходе проверки эксперт выявляет ИО, которые:
Участвуют во взаимодействии, которое является недекларирован-ным или несоответствует определенным правилам (V6). - Объявлены в коде, но в дальнейшем не используются. Показывает наличие отладочной информации, сохраненных паролей и д.р. (V7).
Для выявления недекларированной передачи информационных объектов необходимо задать множество, определяющее границы декларированной передачи. В большинстве случаев, все множество ФО разделяют на более крупные подмножества (сеть, печать, реестр, и д.р.). Передача ИО описывается множеством Информационных взаимодействий (ИВ).
ИВ = {ив19... ивт }, ив = (ФО/гот, ИО, Ф01о) (2.14)
где п - количество осуществляемых передач ИО, ФО/ют - функциональный объект или группа ФО, объединенных по какому-либо признаку, передающий ИО, Ф01о - принимающий ФО или группа ФО.
Для определения недекларированной передачи ИО необходимо определить множество допустимых ИВ.
О,иначе Ситуации, когда глобальные ИО переопределяются в локальных ФО, выявляются сравнением множества глобальных переменных с множеством переменных, определяемых в рамках локальных ФО. Если результатом перемножения этих множеств будет не пустое множество, тогда можно сделать вывод, что в анализируемом ПО есть переопределяемые глобальные ИО (2.17). где И01 - множество локальных переменных, а И02 - множество глобальных.
Контроль информационных объектов. Данная проверка заключается в построении перечня информационных объектов (все переменные, кроме локальных, не передаваемых в другие функциональные объекты). В ходе проверки определяется отсутствие недекларированных в документации обращений к переменным, а также выполняется формирование перечня информационных объектов, подлежащих контролю, и анализ всех участков кода, в которых осуществляется обращение к указанным в перечне ИО.
Контроль ИО различных типов (локальных, глобальных, внешних) направлен на выявление пересечений ИО на различных уровнях. Если подобное переопределение отсутствует, то такое ПО соответствует данному требованию безопасности (2.18). V9=Fm(MT)=[0,l] (2А8) где FHO - функция поиска пересечений ИО различного уровня.
При формировании перечня ИО, подлежащих контролю, определяется подмножество ИО\ в соответствии с определенными правилами. Если полученное множество ИО — 0, тогда данное ПО соответствует требованиям безопасности. В противном случае, необходимо провести дополнительный анализ тех участков кода, где происходит обращение к подозрительным ИО: Кіо = і, (яо)=ш =0 (219) В ходе контроля наличия заданных конструкций в исходных текстах осуществляется синтаксический и семантический поиск опасных конструкций в соответствии с базой заданных конструкций: V„ = e где N3K - количество выявленных уязвимостей, а С - осредненное значение критичности выявленных уязвимостей.
Значение характеристики VJ2, отражающей результаты семантического поиска заданных конструкций, рассчитывается аналогично Vu, с той лишь разницей, что для поиска уязвимостей используется метод семантического анализа.
Характеристика V13 показывает возможность формирования перечня маршрутов выполнения ФО по ИТ. Если удалось построить такой перечень, то требование безопасности считается выполненным и возможно проведение дальнейшего анализа:
Формализация работы эксперта позволит автоматизировать расчет характеристик безопасности ПО, а представление всех характеристик в численном виде позволит создать СППР, помогающую эксперту в принятии решения о соответствии данного ПО требованиям безопасности.
Важнейшим этапом при построении системы поддержки принятия решения, вне зависимости от используемых методов, является систематизация характеристик оцениваемого объекта. В виду того, что данные, анализируемые экспертом, являются неоднородными, необходимо их привести к общему виду, что является неотъемлемым требованием при создании СППР [25, 34]. В ходе формализации характеристик безопасности, оцениваемых экспертом, были определены новые уровни представления оцениваемой информации (Рисунок 2.10):
Оценивание характеристик безопасности
После того, как сформирован вектор характеристик безопасности исследуемого ПО, необходимо на основании этого вектора оценить его соответствие заявленным требованиям, т.е. определить к какому классу безопасности он относится. Теоретически, для задачи классификации на М классов, в которой объединение М классов формирует все пространство 105 входных сигналов, для представления всех возможных результатов классификации требуется М выходов. Вектор Xj является j-м прототипом (т.е. отдельной реализацией) m-мерного случайного вектора х, который должен быть классифицирован многослойным персептроном. k-й из М возможных классов, которому принадлежит данный входной сигнал, обозначается Ск- Пусть ykj - к-й выход сети, генерируемый в ответ на прототип Ху ykj=Fk(Xj),k = l,2,...,M (3.5) где функция Fk() определяет отображение, которому обучается сеть при передаче входного примера на k-й вход. Для удобства представления обозначим: У j =\Уи У2,} - УМ,ІЇ =[FI{XJ1F2(XJ\--- FN(XJ)]T =FMHC{XJ) (3.6) где FHHCO - вектор-функция. Следовательно, оптимальное решающее правило 9Ї, применяемое для классификации входов сети, после ее обучения должно основываться на значении вектор-функции: F: Rmx- ye RM (3.7) В общем случае, о вектор-функции FHHc() определенно известно лишь то, что это непрерывная функция, минимизирующая функционал эмпирического риска: где d, - желаемый (целевой) выход для прототипа х,; - Евклидова норма вектора; N - общее число примеров, представленных сети для обучения. Сущность критерия та же, что и у функции стоимости. Вектор-функция FHHCO строго зависит от выбора примеров (х,, dj), использованных для обучения сети. Это значит, что разные значения пар (xJ5 dj) приведут к построению различных вектор-функций FHHCO Результатом оценивания характеристик безопасности является классификатор Y, включающий в себя два элемента (3.9): - уі показывает степень соответствия заявленным требованиям; - у2 показывает степень несоответствия заявленным требованиям.
В виду того, что оценивание осуществляется обученной ИНС, то встает задача копирования этой обученной ИНС для предоставления ее функционала широкому кругу экспертов. Для решения этой задачи необходимо сохранить информацию о структуре ИНС и значениях ее весовых коэффициентов.
Информация о структуре ИНС включает в себя: тип ИНС, модель используемых нейронов и функций активации, количество слоев и нейронов на каждом слое. Значения весовых коэффициентов удобнее представить матричным отображением нейросети. Данным способом представления можно отобразить как структуру, конфигурацию, топологию графа, так и численные значения характеристик его синапсических связей. Составим матрицу следования S, число строк (и столбцов) которой равно числу нейронов сети, включая нейроны входного и выходного слоя. Каждая строка (и столбец с тем же номером) соответствует одному нейрону.
Принятие решения о соответствии ПО требованиям безопасности Целью этапа принятия решения является формирование окончательного решения R на основании полученного на предыдущем этапе классификатора Y. Исходя из основной задачи, решаемой разрабатываемой СППР, возможны следующие варианты: - ПО соответствует требованиям безопасности. - ПО не соответствует требованиям безопасности. Также необходимо предусмотреть возможность ситуации, когда система не сможет принять достоверного решения и потребует вмешательства эксперта. Следовательно, окончательное решение R может принимать одно из трех значений (3.11). 107 / - соовтетствует требованиям безопасности R = 0— не соответствует (3.11) — 1 — требуется вмешательство эксперта Для вычисления окончательного решения R необходимо определить положение текущего решения в пространстве возможных решений, относительно эталонного положительного и отрицательного решения. Кие = 24{і-уІ)2Ло-у2)2 (3.12) Кие = 2р-у1)2 + (1-у2У где уі и у2 - значения элементов рассчитанного ранее классификатора соответствия для анализируемого ПО. Таким образом, на пространстве возможных решений определим три зоны: соответствия, несоответствия и неопределенности (Рисунок 3.2).
Пространство возможных решений R Для того, чтобы расширить зону неопределенности и, тем самым, повысить вероятность правильного решения, необходимо задать допуск Rvaiid-Значения этого допуска будет рассчитано в ходе эксперимента, но не должно превысить 50%.
Принятие окончательного решения осуществляется путем сравнения положения текущего решения в пространстве возможных решений со значением допуска относительно эталонных Соответствует (1) Все характеристики ПО,заданные уровнембезопасности соответствуюттребованиям безопасности 2 Несоответствует (0) Хотя бы одна изхарактеристик, заданныхуровнем безопасности, несоответствует требуемому,безопасному значению Используется для описанияситуаций, в которыхнейронная сеть не можетпринять окончательноерешение и требуетсядополнительно евмешательство эксперта
Как показано ранее, для решения задачи верификации соответствия ПО требованиям безопасности наиболее подходит многослойный персептрон. Основной задачей разрабатываемой ИНС является обработка вектора характеристик безопасности Х-{х1,...хг+п \х1 є {0:l}}, который состоит из
четырех элементов, показывающих класс (уровень) контроля и 16 характеристик безопасности. Следовательно, входной слой нейронной сети должен содержать в себе 20 элементов. Результатом работы нейронной сети является классификатор соответствия требованиям безопасности Y = [y,, 2}, У, є {0:1}, содержащий 2 элемента. Следовательно, в результирующем слое ИНС должно находится 2 нейрона (Рисунок 3.3).
Принятие решения о соответствии ПО требованиям безопасности
Для проверки правильности всех вводимых данных было разработано множество шаблонов и правил, которые определяют формат представления данных, воспринимаемый СВУ. Если все необходимые данные были введены и при этом формат их представления соответствует разработанным шаблонам, тогда данный этап проверки считается пройденным.
После того, как все исходные данные прошли проверку на корректность, СВУ приступает к определению характеристик безопасности. Для определения характеристик безопасности использовался предложенный выше подход. Полученные значения выводились в окне системы (Рисунок 4.6).
Исходные данные) Характеристики безопасное і и .[ Классификатор соответствия Принятое решение Определение классификационных признаков Промежуточным решением задачи верификации является отнесение верифицируемого ПО к одному из определенных классов (3.11), т.е. его классификация. Классификация осуществляется в соответствии с классификационными признаками по правилу, предложенному ранее (3.14.). Классификационные признаки рассчитываются в соответствии с предложенным методом в модуле принятия решения (Рисунок 4.7).
На вход МПР подаются рассчитанные ранее характеристики безопасности ПО - X. Далее они проходят интеллектуальную обработку в разработанной и обученной ИНС, которая формирует вектор классификационных признаков Y.
Основным элементом МПР является обученная нейронная сеть. Расчет основных параметров и описание алгоритма обучения приведены в третьей главе диссертации. Для создания ИНС использовалась среда математического моделирования MATLAB: HHC=newff([0 logsig logsig logsig }, traincgb ); 4 4 После создания объекта ИНС и прохождения процедуры обучения и тестирования, готовая ИНС компилируется с помощью внутреннего компилятора MATLAB, который позволяет транслировать « .т» файлы в « .с» файлы. Эти « .С» файлы могут далее использоваться для создания любого из конечных типов продуктов: mcc-dmpr.m (4.49) Результатом компиляции является динамически подключаемая библиотека, содержащая основной функционал МПР. Эта библиотека подключается к прототипу СВУ и обеспечивает расчет классификационных признаков (Рисунок 4.8).
Этап расчета классификационных признаков является промежуточным этапом в процессе принятия решения. Это необходимо для обеспечения контроля за качеством принимаемых решений и внесением меры уверенности системы в полученном решении. Мера уверенности определяется расстоянием от полученного решения R до эталонного, в пространстве возможных решений. Чем меньше это расстояние, тем увереннее СВУ в полученном решении.
За принятие окончательного решения отвечает модуль интерпретации решения (МИР), который вычисляет координаты решения в пространстве возможных решений, в соответствии с полученным вектором Y. Результатом работы МИР является одно из возможных решений R: соответствует требованиям безопасности, не соответствует требованиям безопасности и нет правильного решения (рисунок 4.9). Выбор окончательного решения осуществляется в соответствии с предложенным ранее методом.
Для настройки точности работы МИР используется переменная Rvalid, которая задает максимально допустимое отклонение полученного решения от эталонного. Экспериментально установлено, что значение Rvaiid равное 10 % является оптимальным.
Результатом работы МИР является окончательное решение предоставляемое эксперту (Рисунок 4.10), которому остается зафиксировать его или, в случае, когда СВУ не смогла принять решение, определить причины возникновения ошибки в работе СВУ.
Прототип СВУ прошел апробацию в рамках работ по теме «Разработка методики автоматизированного оценивания уровня информационной безопасности программного обеспечения автоматизированных систем дорожного уровня» (шифр 19.5.017.Р), на которую был получен грант ОАО «РЖД». В рамках темы была создана Автоматизированная система аудита программного обеспечения (АСАПО), основным элементом которой является разработанный прототип СВУ (Рисунок 4.11).
Автоматизированная система аудита программного обеспечения СУБД СВУ к Web-сервер Разработчик Эксперт Пользователь Рисунок 4.11 - Структура АСАПО Основными задачами, решаемыми АСАПО, являлись: - систематизация информации о ПО, используемом в структурных подразделениях ОАО «РЖД». - оценка безопасности используемого ПО. В основе АСАПО лежит архитектура "клиент-сервер". Серверная часть реализована в виде Web-сервера, реализующего весь функционал анализа ПО, а в качестве клиента может использоваться любое устройство, поддерживающее протокол HTML.
Серверная часть устанавливается на персональный компьютер, находящийся под управлением операционной системы семейства Windows.
Прежде всего, устанавливается Web-сервер и сервер баз данных. Рекомендуется использовать ХАМРР - кроссплатформенную сборку Web-сервера, включающую Apache, MySQL и интерпретатор РНР. Затем в папку «htdocs», находящуюся в главном каталоге ХАМРР (по умолчанию «C:\xampplite»), копируются файлы АСАПО. После перезагрузки компьютера автоматически запуститься системная служба «httpd.exe» (Apache HTTP Server), это означает, что серверная часть установлена успешно.
Для проверки корректности инсталляции необходимо запустить Web-браузер и в строке адреса написать: «http://localhost/» (Рисунок 4.12). Если в окне браузера появился интерфейс АСАПО, значит, инсталляция прошла корректно.
Запуск серверной части программного комплекса осуществляется на базе операционной системы семейства Windows (версии ХР или более новой). Серверная часть реализована в виде сайта, для запуска которого необходим установленный Web-сервер, поддерживающий язык программирования РНР и обеспечивающий взаимодействие с базой данных. Рекомендуется использовать Web-сервер Apache, версии не ниже 2.0.50. Вся информация, обрабатываемая программным комплексом, хранится в базе данных. Следовательно, необходимым условием нормального функционирования программного комплекса является наличие SQL-совместимой базы данных.
Похожие диссертации на Метод поддержки принятия решения о безопасности программного обеспечения
