IDENTIFICATION OF INFORMATION SYSTEMS VULNERABILITIES

Sergei Konovalenko

postgraduate of Krasnodar higher military school,

Russia, Krasnodar

Igor Korolev

doctor of Engineering, Professor, Professor of the department of protected information technologies, Krasnodar higher military school,

Russia, Krasnodar

АННОТАЦИЯ

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

ABSTRACT

An assessment of existing tools for analyzing information systems security was performed. On the basis of the achieved results the models of detection, identification and evaluation of information systems vulnerabilities images were built. The main characteristics (elements) inherent to the images of the existing information systems vulnerabilities were defined.

Ключевые слова: выявление; информационная система; идентификация; оценка; описание образа; уязвимость.

Keywords: detection; information system; identification; evaluation; description of the image; vulnerability.

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

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

Согласно ГОСТ Р 56545-2015, «уязвимость» – это недостаток (слабость) программного (программно-технического) средства или ИС в целом, который (которая) может быть использована для реализации угроз безопасности информации . «Информационная система» – это совокупность содержащейся в базах данных (далее по тексту – БД) информации и обеспечивающих ее обработку информационных технологий и технических средств .

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

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

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

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

Таблица 1.

Элементы различных типов образов уязвимостей ИС

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

• уровень прикладного программного обеспечения (далее по тексту – ПО), отвечающий за взаимодействие с пользователем;
• уровень системы управления базами данных (далее по тексту – СУБД), отвечающий за хранение и обработку данных ИС;
• уровень операционной системы (далее по тексту – ОС), отвечающий за обслуживание СУБД и прикладного ПО;
• сетевой уровень, отвечающий за взаимодействие узлов ИС.

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

Основными источниками возникновения уязвимостей ИС являются :

• ошибки при разработке (проектировании) ИС (например, ошибки в ПО);
• ошибки при реализации ИС (ошибки администратора ИС) (например, неправильная настройка или конфигурация ПО, не эффективная концепция политики безопасности и т. п.);
• ошибки при использовании ИС (пользовательские ошибки) (например, слабые пароли, нарушение в политике безопасности и т. п.).

Для выявления, идентификации и оценки уязвимостей ИС, а также формирования отчетов и устранения (нейтрализации) уязвимостей, используются средства анализа защищенности сети (далее по тексту – САЗ) (сканеры безопасности (далее по тексту – СБ)), которые можно разделить на два типа :

• сетевые САЗ (СБ) (осуществляют удаленный анализ состояний контролируемых хостов на сетевом уровне);
• САЗ (СБ) уровня ОС (осуществляют локальный анализ состояний контролируемых хостов, порой требуется установка специального агента на контролируемых хостах).

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

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

Рисунок 1. Обобщенная модель выявления образов уязвимостей ИС

Процесс выявления уязвимостей ИС строится посредствам выполнения пассивных проверок (сканирование – scan) и активных проверок (зондирование – probe) наличия уязвимостей контролируемой ИС.

В процессе сканирования САЗ, отправляя соответствующие запросы в адрес контролируемой ИС (на порты контролируемого хоста), анализирует обратно возвращаемые баннеры (заголовки пакетов данных) и делает соответствующие выводы о типе ИС и наличии потенциальных (возможных) ее уязвимостей. Результат сканирования не всегда на сто процентов говорит о наличии возможных (типовых) уязвимостей ИС, так как текстовое содержание баннера могло быть специально модифицировано, либо известные уязвимости, присущие данной ИС, были устранены специалистом в процессе ее реализации (использования). Еще одним способом выполнения сканирующих действий являются активные зондирующие проверки, которые предоставляют возможность проанализировать возвращаемый цифровой слепок (fingerprint) фрагмента ПО контролируемой ИС (т. е. выполнить процесс сравнения полученного результата с цифровым слепком известной уязвимости данного типа ИС). Данный способ обеспечивает более надежную и точную процедуру выявления возможных (типовых) уязвимостей контролируемой ИС.

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

Результаты сканирования и зондирования поступают в БД уязвимостей, в которой хранятся образы уязвимостей контролируемой ИС. На основании процедуры сравнения образа обнаруженной уязвимости с образами уязвимостей контролируемой ИС САЗ формирует отчет об отсутствии или наличии совпадений в образах уязвимостей (обнаружение уязвимостей), который сохраняется в БД уязвимостей.

Детализирует обобщенную модель выявления образов уязвимостей обобщенная модель идентификации и оценки образов уязвимостей ИС (рисунок 2).

Рисунок 2. Обобщенная модель идентификации и оценки образов уязвимостей ИС

Процесс идентификации образа обнаруженной уязвимости ИС, который имеет специфические характеристики (элементы), осуществляется посредствам процедуры его сравнения с образами известных уязвимостей и уязвимостей нулевого дня, хранящихся в БД уязвимостей. Формализованное описание известных уязвимостей и уязвимостей нулевого дня оформляется в виде паспортов, которые содержат информацию о специфических характеристиках (элементах) конкретной уязвимости. Для точной идентификации образа обнаруженной уязвимости он должен содержать информацию о наименовании и версии ПО ИС, в которой обнаружена уязвимость, о идентификаторе, наименовании и классе обнаруженной уязвимости. На основании вышеуказанной информации САЗ соотносит образ обнаруженной уязвимости к одному из типов образов уязвимостей. Для качественного проведения оценки идентифицированный образ уязвимости, в свою очередь, должен содержать информацию об идентификаторе и типе недостатка ИС, при котором обнаружена уязвимость, о месте обнаружения уязвимости в ИС, о способе выявления уязвимости. Процесс оценки образа уязвимости оканчивается выработкой рекомендаций по устранению уязвимости или по исключению возможности ее использования. В случаях, если был обнаружен образ впервые выявленной уязвимости, то САЗ помещает информацию о нем в БД уязвимостей с формированием нового паспорта уязвимости нулевого дня. При выпуске разработчиком ИС мер защиты информации, необходимых обновлений и при исправлении недостатков, уязвимость нулевого дня переходит в статус известной уязвимости.

Поводя итоги данной статьи, отмечаем, что специалист по обеспечению безопасности ИС обязан постоянно проводить работу по выявления уязвимостей в системе, четко представлять и понимать процессы, протекающие в САЗ, следить за обновлением (расширением) БД уязвимостей, своевременно устранять недостатки в системе, устанавливать соответствующие меры защиты и обновления на контролируемую ИС.

Список литературы:

1. Астахов А.С. Анализ защищенности корпоративных автоматизированных сетей // Информационный бюллетень Jet Info. – 2002. – № 7 (110). / – [Электронный ресурс]. – Режим доступа: URL: http://www.jetinfo.ru
2. Горбатов В.С., Мещеряков А.А. Сравнительный анализ средств контроля защищенности вычислительной сети // Безопасность информационных технологий. – 2013. – № 1. / – [Электронный ресурс]. – Режим доступа: URL: http://www.bit.mephi.ru
3. ГОСТ Р 56545-2015 «Защита информации. Уязвимости информационных систем. Правила описания уязвимостей». – М.: Стандартинформ, 2015.
4. ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем». – М.: Стандартинформ, 2015.
5. Лукацкий А.В. Как работает сканер безопасности? / – [Электронный ресурс]. – Режим доступа: http://www.citforum.ru/security/internet/scaner.shtml (Дата обращения: 14.09.2016).
6. Лукацкий А.В. Обнаружение атак. – СПб. : Издательство «БВХ», 2001. – 624 с.
7. Руководство пользователя программного комплекса «Средство анализа защищенности «Сканер-ВС». НПЭШ.00606-01. ЗАО «НПО «Эшелон», 2011.
8. Сканер безопасности XSPider. Руководство администратора / – [Электронный ресурс]. – Режим доступа: http://www.ptsecurity.ru (Дата обращения: 15.09.2016).
9. Сканер безопасности MaxPatrol. Система контроля защищенности / – [Электронный ресурс]. – Режим доступа: http://www.ptsecurity.ru (Дата обращения: 16.09.2016).
10. Стивен Норткат, Джуди Новак. Обнаружение нарушений безопасности в сетях. 3-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. – С. 265–280.

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

Применение метода

Как было отмечено во Введении, существующие средства обнаружения уязвимостей используют методы белого и чёрного ящика. В первом случае производится анализ исходных коды и / или файлов конфигурации веб-приложения. Выявляются участки кода, потенциально содержащие уязвимость или небезопасные параметры конфигурации . Во втором случае осуществляется поиск уязвимостей «извне» - веб-приложению отсылаются HTTP-запросы и анализируются ответы. При этом встают задачи выявления структуры веб-приложения, определения типа сервера и построения тестового набора HTTP-запросов и последующего анализа HTTP-ответов . Но данные средства не осуществляют контроль поведения веб-приложения в смысле, определённом в Разделе 3, в то время как необнаруженные уязвимости могут проявиться именно в обращении к объектам окружения. Предлагаемый метод обнаружения уязвимостей предполагает сравнение поступающего HTTP-трафика со внутренней работой веб-приложения. Метод предназначен для обнаружения уязвимостей, приводящих к недопустимым с точки зрения профиля нормального поведения операциям веб-приложения над объектами окружения и / или изменению значений допустимых операций.

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

Array ( => Y => Y => Y => Y => presscenter => 23 => Array () => Array ( => Otype => linked_products => linked_service => linked_solutions) => /press-center/article/#ELEMENT_ID#/ => - => - => - => => 1 => N => 1 => 1 => d.m.Y => A => 3600 => Y => => Array ( => 1) => => 1 => Страница => => => 1 => 1 => 10023 => => /press-center/article/ => N => => => => => => /press-center/article/ => ACTIVE_FROM => DESC => ID => DESC [~DISPLAY_DATE] => Y [~DISPLAY_NAME] => Y [~DISPLAY_PICTURE] => Y [~DISPLAY_PREVIEW_TEXT] => Y [~IBLOCK_TYPE] => presscenter [~IBLOCK_ID] => 23 [~FIELD_CODE] => Array ( => =>) [~PROPERTY_CODE] => Array ( => Otype => linked_products => linked_service => linked_solutions) [~DETAIL_URL] => /press-center/article/#ELEMENT_ID#/ [~META_KEYWORDS] => - [~META_DESCRIPTION] => - [~BROWSER_TITLE] => - [~DISPLAY_PANEL] => [~SET_TITLE] => Y [~SET_STATUS_404] => N [~INCLUDE_IBLOCK_INTO_CHAIN] => Y [~ADD_SECTIONS_CHAIN] => Y [~ACTIVE_DATE_FORMAT] => d.m.Y [~CACHE_TYPE] => A [~CACHE_TIME] => 3600 [~CACHE_GROUPS] => Y [~USE_PERMISSIONS] => N [~GROUP_PERMISSIONS] => [~DISPLAY_TOP_PAGER] => N [~DISPLAY_BOTTOM_PAGER] => Y [~PAGER_TITLE] => Страница [~PAGER_SHOW_ALWAYS] => N [~PAGER_TEMPLATE] => [~PAGER_SHOW_ALL] => Y [~CHECK_DATES] => Y [~ELEMENT_ID] => 10023 [~ELEMENT_CODE] => [~IBLOCK_URL] => /press-center/article/ [~USE_SHARE] => N [~SHARE_HIDE] => [~SHARE_TEMPLATE] => [~SHARE_HANDLERS] => [~SHARE_SHORTEN_URL_LOGIN] => [~SHARE_SHORTEN_URL_KEY] => [~SEF_FOLDER] => /press-center/article/ [~SORT_BY1] => ACTIVE_FROM [~SORT_ORDER1] => DESC [~SORT_BY2] => ID [~SORT_ORDER2] => DESC =>)

Практические аспекты выявления уязвимостей программного обеспечения

Виктор Сердюк,
кандидат технических наук, CISSP,
Генеральный директор ЗАО «ДиалогНаука»

Издание «Information Security» №3 за 2013 год
www.itsec.ru

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

Ни для кого не секрет, что с каждым годом увеличивается количество уязвимостей, которые обнаруживаются в прикладном программном обеспечении (ПО). При этом растет не только их количество, но и их разновидность. Так, например, по данным компании Hewlett Packard на сегодняшний день можно выделить более 500 классов различных уязвимостей в ПО. Примерами таких уязвимостей являются «переполнение буфера» (buffer overflow), SQL injection, Cross Site Scripting и многие другие.

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

Стоимость устранения уязвимостей на различных этапах разработки ПО

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

Средства статического анализа

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

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

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

Процесс использования средства статического анализа безопасности ПО

Примерами систем, которые реализуют данный метод анализа, являются HP Fortify и IBM AppScan. Данные решения позволяют полностью автоматизировать процесс анализа исходного кода, интегрируются во все наиболее распространенные среды разработки ПО, а также позволяют идентифицировать конкретные участки кода, содержащие уязвимость, и предложить рекомендации по её устранению. В качестве рекомендаций приводятся примеры фрагментов исходного кода, в котором показано, как исправить ту или иную уязвимость. Как правило, решения подобного класса поддерживают возможность анализа исходного кода, написанного на различных языках программирования. Так, например, решение HP Fortify поддерживает более 20-ти различных видов языков программирования, начиная от COBOL, заканчивая C#.

Средства динамического анализа

Динамический анализ предполагает проведение тестирования уже скомпилированного ПО и функционирующего в определенной среде. Для решения данной задачи, в частности, могут использоваться специализированные сканеры безопасности, которые моделируют возможные атаки злоумышленников, а также анализируют конфигурационные файлы ПО. Динамический анализ позволяет выявлять не только технологические, но и эксплуатационные уязвимости, связанные с неправильной настройкой ПО. К таким уязвимостям можно отнести: использование слабых и нестойких к угадыванию паролей доступа, наличие неиспользуемых учетных записей, неправильно настроенные функции безопасности ПО и др. В качестве примеров продуктов, реализующих функционал динамического анализа, можно привести решения Max Patrol (компании Positive Technologies) и Qualis (компании Qualys, Inc.).

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

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

Комплексный подход

Для обеспечения максимально эффективной оценки уровня безопасности ПО необходимо использование средств как статического, так и динамического анализа, поскольку они позволяют дополнить друг друга. Так, статический анализ позволяет обнаружить до 80% имеющихся уязвимостей, которые можно идентифицировать на основе исходного кода. В то же время динамический анализ позволяет дополнительно выявить оставшиеся 20% уязвимостей, которые связаны с настройкой ПО и тем окружением, в котором оно работает. Необходимо также отметить, что данные решения по анализу безопасности ПО могут использоваться как в виде специализированных продуктов, установленных в ЛВС компании, так и в виде облачных сервисов.

При этом анализ безопасности ПО, безусловно, должен стать частью комплексного подхода к обеспечению информационной безопасности компании в целом. Требования о необходимости проведения такого рода анализа уже прописаны в ряде стандартов по защите информации, в частности в PCI DSS и СТО БР ИББС. Это означает, что помимо использования инструментальных средств статического или динамического анализа необходимо также наличие документированных процедур, которые описывают процессы, связанные с разработкой безопасного ПО. За основу таких процедур можно взять рекомендации ведущих компаний-разработчиков ПО, таких как Microsoft или EMC, которые внедрили у себя и создали специальные рекомендации по организации процесса разработки безопасного ПО – SDL (Security Development Lifecycle). Эти рекомендации в том числе включают в себя процедуры повышения осведомленности разработчиков о проблемах, связанных с созданием небезопасного кода. Конечным результатом внедрения всех этих процедур должно являться повышение качества разрабатываемого кода, в том числе и с точки зрения информационной безопасности.

Заключение

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

12.12.2005 Алексей Марков, Сергей Миронов, Валентин Цирлов

Современная нормативная, методическая и инструментальная база выявления недекларированных возможностей программ не позволяет эффективно обеспечивать безопасность программных ресурсов. Данной проблемой занимаются испытательные лаборатории Минобороны, ФСБ и ФСТЭК России, однако большинство уязвимостей обнаруживаются не в соответствии с нормативными документами, а даже вопреки им. Мало того, имеется тенденция увеличения числа уязвимостей в программном коде.

Сегодняшняя нормативная, методическая и инструментальная база выявления недекларированных возможностей программ не позволяет эффективно обеспечивать безопасность программных ресурсов. Данной проблемой занимаются испытательные лаборатории Минобороны, ФСБ и ФСТЭК России, однако большинство уязвимостей обнаруживаются не в соответствии с нормативными документами, а порой даже вопреки им. Мало того, имеется тенденция увеличения числа уязвимостей в программном коде.

Проблемой защиты программ занимаются испытательные лаборатории Минобороны, ФСБ и ФСТЭК России, которые в своей работе опираются на Руководящий документ (РД) Гостехкомиссии России по контролю над недекларированными возможностями . Однако опыт выявления авторами более 20 закладок и тысяч некорректностей кода показал, что большинство из них обнаружены не только не в соответствии с указанным документом, но и порой вопреки ему. Существующая нормативная, методическая и инструментальная база выявления недекларированных возможностей в программном обеспечении не позволяет эффективно обеспечивать безопасность программ.

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

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

Сертификационные испытания

Ограничения Руководящего документа

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

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

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

Инструментальная база испытаний

Чтобы получить аттестат аккредитации ФСТЭК по выявлению недекларированных возможностей, испытательная лаборатория должна иметь сертифицированные инструментальные средства («АИСТ», EMU). Здесь возникают два вопроса.

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

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

Скажем, для анализа кода на языке Си рекомендуется программа «АИСТ-С» (непререкаемый «авторитет» в области анализа кода на наличие недекларированных возможностей). Однако, несмотря на ее очевидные достоинства, установлено, что она некорректно обрабатывает структуры объектно-ориентированных программ, например не анализирует конструктор и деструктор. Не анализируются и исходные тексты, подключаемые директивами #include - лишь проверяется исходный текст программы. Мало того, нормальная работа анализатора возможна, только если объем исходных текстов не превышает нескольких мегабайт: блок-схемы программ строятся некорректно уже для программ объемом более нескольких килобайт. Те же ограничения относятся к построению матрицы связей по информации, да и отчеты не в полной мере соответствуют требованиям РД по недекларированным возможностям. Но главное отставание от реалий дня состоит в том, что это средство вообще не имеет базы сигнатур и умеет анализировать лишь программы на языке Cи/C++.

Организационные проблемы сертификации

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

Способы выявления уязвимостей

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

Очевидно, что второй подход лишен недостатков избыточной структуризации всего программного обеспечения и «проклятья размерности» полномаршрутного тестирования. Поскольку число потенциально опасных операций, как правило, не превышает 5-10% объема программного обеспечения, в десять-двадцать раз снижается время «ручного» анализа исходного текста. В отношении статического и динамического анализа следует подчеркнуть, что результаты статического анализа по сложности интерпретации сопоставимы с исходными текстами, а динамический анализ дополнительно требует составления и реализации соответствующих тестов маршрутов. Таким образом, сигнатурно-эвристический анализ сокращает временные затраты на поиск недекларированных возможностей в десятки раз. Наш опыт показывает, что большинство выявленных на этапе сертификационных испытаний уязвимостей кода обнаружены благодаря использованию именно второго подхода.

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

Развитие нормативной базы возможно в рамках использования новых стандартов и руководящих документов по линии «Общих критериев».

Литература

1. Руководящий документ. Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей. М.: Гостехкомиссия России, 1998.
2. Калайда И.А. Недекларированные возможности в программном обеспечении средств защиты информации. Jet Info, 2000, № 8.
3. Марков А.С., Щербина С.А. Испытания и контроль программных ресурсов. InformationSecurity, 2003, № 6.
4. Дастин Э., Рэшке Д., Пол Д. Автоматизированное тестирование программного обеспечения: внедрение, управление, эксплуатация. М.: Лори, 2003.
5. ГОСТ Р ИСО/МЭК 15408-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Части 1, 2, 3. М.: ИПК «Изд-во стандартов», 2002.
6. Методическое руководство по оценке качества функционирования информационных систем. М.: Изд-во 3 ЦНИИ МО РФ, 2003.
7. ГОСТ РВ 51719-2001. Испытания программной продукции. М.: ИПК «Изд-во стандартов», 2001.
8. Руководящий документ. Безопасность информационных технологий. Критерии оценки безопасности информационных технологий. Части 1, 2, 3. - М.: Гостехкомиссия России, 2002.
9. Скрытые каналы, // Jet Info, 2002, № 11.
10. Хогланд Г., Мак-Гроу Г. Взлом программного обеспечения: анализ и использование кода. М.: Вильямс, 2005.

Алексей Марков ([email protected] , [email protected] ), Сергей Миронов, Валентин Цирлов - сотрудники Испытательного центра НПП «БИТ», (Москва).

Примеры выявленных программных закладок

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

Методы выявления и устранения уязвимостей

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

Выявление уязвимостей типа " buffer overflow ", " SQL Injection " и " format string " возможно либо путём анализа исходных текстов потенциально уязвимой программы, либо при помощи поведения анализа безопасности уже работающей программы. Первый способ предполагает экспертный анализ исходных текстов программы с целью поиска и исправления ошибок, которые были допущены на этапе её разработки. В большинстве случае для устранения выявленных уязвимостей необходимо добавление новых функций, обеспечивающих проверку корректности входных данных , поступающих в программу. Так, например, для исправления уязвимостей типа " buffer overflow " необходимо добавить процедуру проверки, которая должна следить за тем, чтобы объём входных данных не превышал максимальный размер переменной, для которой они предназначаются. Исправление уязвимости " SQL Injection " возможно путём защиты от вставки символа """, который в большинстве случаев и позволяет модифицировать исходный SQL - запрос . Для устранения уязвимостей типа " format string " необходимо использовать такой формат вызова функций, в котором форматирующая строка задаётся в явном виде разработчиком программы. Как правило, метод анализа исходных текстов отличается высокой трудоёмкостью и используется только в компаниях, которые занимаются разработкой ПО .

Второй метод выявления уязвимостей используется для анализа защищённости ПО , которое уже установлено и функционирует в ИС. Метод предполагает использование специализированных программных средств - так называемых сканеров безопасности или систем анализа защищённости. Эти средства позволяют обнаруживать уязвимости на основе активного и пассивного методов. При помощи пассивного метода осуществляется сбор информации о настройках ПО , присутствующего в ИС и на основе этих данных делается вывод о наличии или отсутствии в системе уязвимостей . Так, например, если будет выявлено наличие ОС без установленного модуля Service Pack , то это означает, что она подвержена ряду уязвимостей . Активные методы анализа защищённости приложений имитируют информационные атаки и затем на основе анализа результатов делается вывод о наличии уязвимостей в системе. Совместное использование пассивных и активных методов анализа защищённости приложений ИС позволяет выявить не только уязвимости " buffer overflow ", " SQL Injection " и " format string ", но и эксплуатационные уязвимости конфигурации ПО . Устранение уязвимост ей в этом случае возможно путём установки соответствующих модулей обновления ( service packs , hotfixes , patches и др.) или изменения настроек используемого ПО . Рассмотренные активные и пассивные методы наиболее часто используются для анализа защищённости ПО , на основе которых функционируют ИС организаций.

Что такое информационная атака?

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

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

Рис. 23.5.

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

• информация о структуре и топологии ИС. Для получения информации этого типа нарушитель может воспользоваться стандартными утилитами типа " traceroute ", входящими в состав практически любой операционной системы (ОС). Эти утилиты позволяют сформировать список IP-адресов маршрутизаторов , через которые проходят пакеты от компьютера нарушителя до хоста, который выступает в роли объекта нападения. Злоумышленник также может получить необходимую ему информацию о структуре ИС путём обращения к DNS -серверу, на котором могут храниться данные о хостах ИС;
• информация о типе ОС, установленной в ИС. Один из наиболее распространённых методов определения типа ОС основан на том факте, что разные системы по-разному реализуют требования стандартов RFC , в которых определены правила взаимодействия на основе различных сетевых протоколов . Таким образом, при формировании одних и тех же сетевых запросов разные ОС в ответ отправляют отличные друг от друга данные, на основе которых можно с большой долей вероятности определить характеристики используемой ОС. Данный метод также позволяет определить тип аппаратной платформы, на основе которой функционирует та или иная ОС;
• информация о типе прикладных сервисов, присутствующих в ИС. Нарушитель может определить какие