Диссертация (Разработка программного комплекса оценки качества и надежности программных продуктов без исходных текстов), страница 3

Информацию о наличии вируса официально подтвердил президент ИранаМахмуд Ахмадинежад в интервью агентству Reuters3 в 2010 году [26].Оценка надежности программно-аппаратных систем связана с возможностьювнедрения в текст программных средств на этапе разработки и/или модификациипрограммных закладок (недокументированных возможностей – НДВ), используякоторые злоумышленник реализует созданные уязвимости. В связи с этимнеобходимость проверки (сертификации) ПП на соответствие требованиямдействующих нормативных документов на всем протяжении его жизненного циклане вызывает сомнений.На территории Российской Федерации действует система сертификации ППна соответствие требованиям безопасности.

Уполномоченным органом являетсяФедеральная служба по техническому и экспортному контролю (ФСТЭК России),которая на основании ведомственных нормативных документов осуществляетвыдачу сертификатов. Однако действующие нормативные документы моральноустарели, процедура сертификации является сложной и ресурсоемкой, требующейбольших временны́х затрат, при этом в нашей стране отсутствует системаклассификации, систематизации и учета выявленных уязвимостей. По всему мируразработчики используют базу данных распространенных уязвимостей и ошибокCVE (Common Vulnerabilities and Exposures) [31],которая имеет четкуюклассификацию и регулярно обновляется.ПомимоCVEиспользуютсясистемыучетаBID,OpenSourceVulnerabilityDatabase (OSVDB) [26] является независимой и открытойбазой уязвимостей, созданной сообществом разработчиков ПП с открытым кодом.Датская компания Secunia, специализирующаяся на компьютерной и сетевойбезопасности, наиболее известна своими тестами на наличие уязвимостей.ISSX-Force [26] затрагивает все перечисленные выше критерии, но вдобавокописывает бизнес-импакт.Агентство «Рейтер» (англ.

Reuters) — одно из крупнейших в мире международных агентствновостей и финансовой информации, существует с середины XIX века3131.2. Классификация методов анализа и оценки качества программныхпродуктовЗадачи анализа и контроля программного продукта с исходными текстамиможнорешитьдвумяспособами:ручным(экспертным)анализомиавтоматизированным (шаблонным) анализом.Ручной анализ выполняют специалисты высокой квалификации, которыеполагаются исключительно на свои знания и опыт. На ряду с этимуказанныйспособ имеет большие затраты по времени и является крайне дорогостоящим. Приэтом массовость использования ручного способа анализа не наблюдается в силуследующих причин: усложнения аппаратных архитектур вычислительных машин,увеличения исходныхпрограммныхтекстов программ допрослоек(гипервизоров)сотен мегабайт, появлениямеждуоперационнойсистемой,программным и аппаратным обеспечением. В случае отсутствия исходных текстовпрограммаподлежитдизассемблированиюиполученныйматериал(восстановленные исходные тексты) подвергается дальнейшему анализу.Прииспользованиишаблонногоспособа,деятельностьэкспертовоблегчается в силу применения средств, которые осуществляют статичный анализструктурыисследуемойпрограммынаналичиепотенциальноопасныхконструкций языка программирования (уязвимостей), используемого в ПП.

Частопри данном способе используется совмещение автоматизированного и ручногопоиска уязвимостей.Вопросами выявления уязвимостей и сертификационных испытанийпрограммных продуктов занимаются: органыпосертификации–органы,проводящиесертификацию–лаборатории,проводящиеопределенной продукции; испытательныелабораториисертификационные испытания (отдельные виды этих испытаний) определеннойпродукции, аккредитованные органом исполнительной власти (ФСБ и/или ФСТЭК14России), которые в своей работе опираются на нормативно-методическиедокументы.Основным руководящим документом является Руководящий документ (РД)Гостехкомиссии России [38].На ряду с этим, в нормативной базе выделяется ряд определений отдельныхклассов уязвимостей, а именно: программной закладки (ГОСТ Р 50.1.053-2005),скрытого канала (ГОСТ Р 53113.2-2009), бреши/уязвимости (ГОСТ Р 50922-2006).Объективные причины появления уязвимостей в программных продуктахзаключаются в чрезвычайно высокой структурной сложности программного кода,динамичности развития версий, выпускаемых разработчиком, и легкостисамомодификации программ при удаленном обновлении.

К этому можно добавитьпроблему достоверной идентификации преднамеренно созданных программныхзакладок,несовершенствонормативно-методическойбазыиотставаниеинструментальной базы сертификационных испытаний.Методы, определяемые в РД [38], берут начало в теории надежностифункционирования программ, поэтому вопросы защиты кода в них не отражены. Влитературе информацию об оценке качества и надежности программного продуктапо требованиям безопасности найти очень сложно, все сводится к поискупотенциальных уязвимостей в исходных текстах, не говоря уже о программах,исходный текст которых отсутствует. Стоит отметить, что наибольшую опасностьпредставляютуязвимости,заложенныевпрограммномпродуктеиз-заневнимательности разработчиков на ранних этапах его жизненного цикла.Учитывая, что цикл разработки ПП принято разделять на три этапа(проектирование, разработка, тестирование), при этом широко известна западнаяоценка, по которой трудоемкость между этапами распределяется в процентномсоотношении 40%-20%-40%.Иными словами, цикл разработки программного продукта принято разделятьна три этапа, причем по оценке специалистов, наименьшую трудоемкость занимаетвторой этап – этап разработки программного обеспечения.15Автоматизированный анализ призван уменьшить трудоемкость последнегоэтапа и результат, к которому может стремиться современная индустрияразработки ПП, распределяется как 60%-20%-20%.Уязвимые сигнатуры в исходных текстах ищутся разработчиками лишь наэтапах внутреннего тестирования, основной целью которого является выявлениесобственных ошибок в разработанном продукте.

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

Утилиты динамическогоанализа могут требовать загрузки специальных библиотек, перекомпиляциюпрограммного кода. Некоторые утилиты могут инструментировать исполняемыйкод в процессе исполнения или перед ним. Для большей эффективностидинамического анализа требуется подача тестируемой программе достаточногоколичества входных данных, чтобы получить более полное покрытие кода.В соответствии с РД статический и динамический анализы позволяютвыполнить следующие виды контроля:16Контроль полноты и отсутствия избыточности исходных текстовосуществляется экспертом с помощью программных средств, которые выявляютвозможно избыточные функциональные объекты (неиспользуемые функции,конструкторы, деструкторы и т.д.).

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

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

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

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