'

НАПРАВЛЕНИЯ СОВЕРШЕНСТВОВАНИЯ МЕТОДОВ СЕРТИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА ОТСУТСТВИЕ УЯЗВИМОСТЕЙ

Понравилась презентация – покажи это...





Слайд 0

НАПРАВЛЕНИЯ СОВЕРШЕНСТВОВАНИЯ МЕТОДОВ СЕРТИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА ОТСУТСТВИЕ УЯЗВИМОСТЕЙ Совещание «Взаимодействие участников рынка продуктов и услуг в области безопасности», 10 – 17 марта 2007 г. Марков А.С., Цирлов В.Л. mail@npo-echelon.ru


Слайд 1

П Р О Б Л Е М А Пример из жизни: новости от 10 октября 2006 г.: в программе «XXX 4.хх» обнаружена серьезная уязвимость Злоумышленник может выполнить произвольный код в системе из-за некорректной обработки входных данных параметров Причина состоит в ошибке обработки LHA-архивов, содержащих длинные имена директорий в расширенном заголовке директорий. Удаленный пользователь может вызвать переполнение динамической памяти и выполнить произвольный код на целевой системе. Ошибка вызвана некорректностью кодирования, а именно использования функции копирования строк без проверки длины Рабочий эксплоит можно скопировать с сайта …


Слайд 2

Фрагмент кода Уязвимый фрагмент кода if(dir_length) { strcat(pDirname, hdr->name); strcpy(hdr->name, pDirname); name_length += dir_length; } Исправленная версия if(dir_length) { strcat(pDirname, hdr->name); DWORD temp = (DWORD)&hdr->crc - (DWORD)hdr->name; if (dir_length > temp) { dir_length = temp; memcpy(hdr->name, pDirname, temp); } else { strcpy(hdr->name, pDirname); } name_length += dir_length; }


Слайд 3

Как можно обнаружить? Способы выявления: сигнатурно-эвристический анализ исходных кодов на предмет выявления ошибок работы с памятью по исходным кодам просмотр исходных кодов на предмет выявления ошибок работы с памятью функциональное тестирование граничных значений или нагрузочное тестирование полное структурное и функциональное тестирование продукта Трудоемкость часы – месяцы - столетия


Слайд 4


Слайд 5


Слайд 6

СИТУАЦИЯ Продукт в 2006 году прошел сертификацию .. Вероятно, уязвимость была обнаружена без исходных кодов


Слайд 7

НАПРАВЛЕНИЯ СОВЕРШЕНСТВОВАНМЯ МЕТОДОВ СЕРТИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА ОТСУТСТВИЕ УЯЗВИМОСТЕЙ Проблемная ситуация Возможности сертификационных испытаний Возможные подходы к выявлению уязвимостей Возможности перехода к «Общим критериям» Возможности применения организационных стандартов


Слайд 8

I. ПРОБЛЕМНАЯ СИТУАЦИЯ 3 Системы обязательной сертификации: МО РФ, ФСБ России, ФСТЭК России Система добровольной сертификации АйТиСертифика Руководящий документ Гостехкомиссии России «Защита от НСД к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей»


Слайд 9

ОБЪЕКТИВНЫЕ ПРИЧИНЫ УЯЗВИМОСТИ ПРОГРАММНЫХ РЕСУРСОВ Чрезвычайно высокая структурная сложность программных систем Динамичность развития информационных технологий, версий и реализаций программных ресурсов Относительная легкость модификации программного кода Сложность идентификации программной закладки (ПЗ) как преднамеренно внесенной


Слайд 10

СУБЪЕКТИВНЫЕ ПРИЧИНЫ УЯЗВИМОСТИ ПРОГРАММНЫХ РЕСУРСОВ Несовершенство нормативно-методической базы сертификационных испытаний на отсутствие НДВ и ПЗ Недостаточность регламентированной инструментальной базы испытаний Отсутствие прикладных реализаций математического аппарата испытаний ПО


Слайд 11

II. ВОЗМОЖНОСТИ СЕРТИФИКАЦИОННЫХ ИСПЫТАНИЙ Возможности использования руководящего документа Гостехкомиссии России по контролю отсутствия НДВ Возможности инструментальной базы испытаний Организационные особенности сертификационных испытаний


Слайд 12

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


Слайд 13

ПО СЗИ. Классификация по уровню контроля отсутствия НДВ. Статический анализ


Слайд 14

ПО СЗИ. Классификация по уровню контроля отсутствия НДВ. Динамический анализ


Слайд 15

ПОЛОЖИТЕЛЬНЫЕ МОМЕНТЫ РД Требование по предоставлению исходного кода и документации Контроль избыточности (что позволяет исключить некоторые закладные элементы) Определение полномаршрутного тестирования ПО


Слайд 16

СЛОЖНОСТИ РЕАЛИЗАЦИИ ИСПЫТАНИЙ 1) Высокая вычислительную сложность статического анализа и чрезвычайно высокая сложность динамического анализа. Фактически, с ростом сложности изделия динамический анализ становится неразрешимой задачей и формальной процедурой (отнимающей много времени и ресурсов у экспертов лаборатории)


Слайд 17

НЕДОСТАТОЧНОСТЬ ИСПЫТАНИЙ 2). Отсутствие или недостаточность проверок, непосредственно связанных с безопасностью изделия. Например: - отсутствие сигнатурного анализа в требованиях к испытаниям ПО ниже 2 уровня контроля; - отсутствие требований и содержания базы потенциально опасных конструкций; - отсутствие механизмов выявления недекларированных возможностей, связанных с переполнением буфера, гонками, вызовом функций не из своего адресного пространства, отсутствием очистки памяти и др.


Слайд 18

НЕГАТИВНЫЕ МОМЕНТЫ ИСПЫТАНИЙ 3) Неопределенность в действиях экспертов и достоверности получаемых результатов: - отсутствие задекларированных способов построения перечня маршрутов выполнения функциональных объектов (ветвей); - отсутствие механизмов подсчета полноты покрытия и его достаточности при динамическом анализе; - отсутствие рекомендаций, как именно выявляются НДВ при анализе, например, матрицы связей по информации


Слайд 19

СОСТОЯНИЕ ИНСТРУМЕНТАЛЬНОЙ БАЗЫ ИСПЫТАНИЙ Целесообразно ли делать обязательными к применению инструментальные средства, отражающие несовершенную нормативную базу и не позволяющие эффективно выявлять уязвимости кода? Следует ли сертифицировать средства тестирования в обязательном порядке?


Слайд 20

ОРГАНИЗАЦИОННЫЕ ПРОБЛЕМЫ Как влияет НДВ на угрозу ОИ? (Оценка риска и наличия угрозы) Как организовать сертификацию программных продуктов с постоянно изменяющимся кодом? Если в продукте обнаружены уязвимости, то действие сертификата должно быть приостановлено? Уровень выявления НДВ. Оценка скрытых каналов. Что делать, если нет исходных кодов - некоторые проверки можно (и даже желательно) провести и без исходного кода? Что делать, когда сертификацию нельзя провести по правовым моментам? Не пора ли ввести систему спецпроверки ПО по аналогии с аппаратными средствами?


Слайд 21

III. ПРЕДЛАГАЕМЫЕ НАПРАВЛЕНИЯ СОВЕРШЕНСТВОВАНИЯ МЕТОДИЧЕСКОЙ БАЗЫ ПРОВЕРКИ ПО 1. Определение полного множества классов уязвимостей ПО; 2. Исследование способов выявления классов уязвимостей; 3. Развитие методической базы выявления уязвимостей в рамках сертификационных испытаний; 4. Развитие методической базы определения требований (с учетом угроз) к безопасности ПО в рамках аттестационных испытаний Что выявляем: метрики, ошибки, НДВ, уязвимости, угрозы?


Слайд 22

БЕЗОПАСНОСТЬ ПРОГРАММНОГО КОДА Безопасность ПО - свойство ПО АС быть защищенным от угроз целостности, доступности и конфиденциальности информационно-программных ресурсов системы Уязвимость программного кода - реализационный дефект ПО, который может потенциально снизить степень ИБ системы Угроза ПО АС – возможность реализации уязвимости Риск – комбинация вероятности реализации угрозы и ее последствий


Слайд 23

БЕЗОПАСНОСТЬ ПРОГРАММНОГО КОДА Недекларированная возможность - функциональная возможность ПО, не описанная или не соответствующая описанию в документации, при использовании которой возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации


Слайд 24

КЛАССИФИКАЦИОННЫЕ ПРИЗНАКИ УЯЗВИМОСТЕЙ КОДА Классификационные признаки: - уровень реализации (проектный или кодирования); - степень преднамеренности (идентифицируется как преднамеренная или нет); - уровень выполнения (прикладной, системный); - компрометируемая подсистема (парольная, криптографическая, целостности и др.); - результирующее действие (отказ в обслуживании, НСД, нарушение целостности) и др.


Слайд 25

НАИБОЛЕЕ РАСПРОСТРАНЕННЫЕ КЛАССЫ УЯЗВИМОСТЕЙ - программные закладки типа логические бомбы; - некорректности кодирования (переполнение буфера, гонки, некорректная обработка дат и счетчиков) – уязвимости ПО в узком смысле; - наличие отладочных функций; - недекларированные входные параметры и горячие клавиши; - уязвимости, компрометирующие подсистемы и механизмы защиты (парольные, криптографические и др.); - уязвимости, приводящие к отказу в обслуживании; - уязвимости, связанные с редко используемыми входными данными; - скрытые каналы и др.


Слайд 26

СПОСОБЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ НА ЭТАПЕ СЕРТИФИКАЦИОННЫХ ИСПЫТАНИЙ 1) Структурный статический и динамический анализ исходного кода (регламентируемый стандартами по тестированию и руководящим документом) 2) Сигнатурно-эвристический анализ потенциально опасных операций


Слайд 27

Примеры реальных закладок #ifndef US #define US "test" #endif … #ifndef PA #define PA “qwerty" #endif … db->setUsNa (US); db->setPa (PA); … Недекларированные имя пользователя и пароль по умолчанию


Слайд 28

Примеры реальных закладок void MTextEdit::keyPressEvent( QKeyEvent * e ) { QKeyEvent * ke; if ( e->text() == "," ) ke = new QKeyEvent( QEvent::KeyPress, e->key(), e->ascii(), e->state(), e->text().upper()+tr(“шокирующее ругательство") ); else ke = new QKeyEvent( QEvent::KeyPress, e->key(), e->ascii(), e->state(), e->text().upper() ); QTextEdit::keyPressEvent( ke ); } Содержимое текстового поля искажается – выводится недекларированное сообщение


Слайд 29

Примеры эвристического анализа Возможность некорректности кода, допускающей переполнение буфера: 1. Поиск соответствующих функций кода; 1.1. Например, функции копирования строк с контролем длины strncpy() wcsncpy() _tcsncpy() lstrcpyn() _mbsnbcpy() …. Проверка: 2.1. Необходимо обеспечить завершение нулём строки буфера-приёмника. 2.2. Необходимо реализовать обработку некорректных указателей.


Слайд 30

Расчет Пример ПО (5Мб, Си): Ручной просмотр листингов всего кода - 2000 чел/час Сигнатурно-эвристический анализ - 200 чел/час Статический и динамический анализ - от 4000 чел/час


Слайд 31

СПОСОБЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ КОДА Классификация уязвимостей


Слайд 32

СПОСОБЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ КОДА


Слайд 33

ВОЗМОЖНЫЕ ЭТАПЫ ИСПЫТАНИЯ НА ОТСУТСТВИЕ УЯЗВИМОСТЕЙ КОДА - ПРИОРИТЕТЫ 1) Формирование ПБ ПО, которая может соотноситься с ТУ на объект информатизации (ОИ) 2) Проведение сигнатурного анализа исходного кода по фрагментам потенциально опасным операциям и некоректностям кодирования 3) Проведение анализа подсистем безопасности (динамический анализ парольной защиты) 4) Проведение функционального, стрессового и нагрузочного тестирования, тестирования по производительности 5) Структурный анализ избыточности дистрибутива и контроль целостности 6) Анализ наличия скрытых каналов ("put-in") 7) Формирование ограничений на использование продукта в соответствии с ПБ 8) Формирование условий обновления и модификации ПР


Слайд 34

ПЕРЕЧЕНЬ СРЕДСТВ ТЕСТИРОВАНИЯ Структурное тестирование (по методу «белого ящика»): Отечественные средства проведения сертификационных испытаний относят: «АИСТ», «КСАИТ», «АК-ВС» и др. Зарубежные средства тестирования: Pascal Analyzer, RATS, MEMWATCH, PSCAN. IBM Rational Quantify, IBM Rational PureCoverage, Parasoft С++Test, Parasoft JTest и др. Функциональное/поведенческое тестирование (по методу черного «ящика»): Средства тестирования: IBM Rational Purify, IBM Rational Robot, IBM Rational Performance Tester, IBM Rational Functional Tester, IBM Rational Manual Tester и др.


Слайд 35

СРЕДСТВА СТРУКТУРНОГО ТЕСТИРОВАНИЯ Средства испытаний


Слайд 36

СПЕЦИАЛИЗИРОВАННЫЕ СРЕДСТВА ТЕСТИРОВАНИЯ Средства тестирования ПО


Слайд 37

IV. Соответствие между РД НДВ и «Общими Критериями»


Слайд 38

Соответствие между РД НДВ и «Общими Критериями»


Слайд 39

Соответствие между РД НДВ и «Общими Критериями»


Слайд 40

Соответствие между РД НДВ и «Общими Критериями»


Слайд 41

Соответствие между РД НДВ и «Общими Критериями»


Слайд 42

Требования доверия, позволяющие реализовать контроль на отсутствие НДВ


Слайд 43

Проблемы реализации сертификации по «ОК» Некомпетентность заявителей и возрастание трудоёмкости сертификационных испытаний


Слайд 44

Неопределённый статус сертификата Проблемы реализации сертификации по «ОК»


Слайд 45

Трудности при проведении экспертной оценки материалов сертификационных («ужасные» 30 месяцев) Проблемы реализации сертификации по «ОК»


Слайд 46

Неоднозначность толкования определенных положений «Общих критериев» - Полнота отчётной документации - Язык описания предположений, угроз, политик и целей безопасности - Выбор оценочного уровня доверия - Функциональные требования безопасности и требования доверия, формулируемые в явном виде - Детализация краткой спецификации объекта оценки - Ссылки на профили защиты - Глубина логического обоснования разделов профилей защиты и заданий по безопасности Проблемы реализации сертификации по «ОК»


Слайд 47

НАПРАВЛЕНИЯ РЕШЕНИЯ ПРОБЛЕМЫ 1. Формирование рынка независимых консалтинговых услуг по подготовке продукции к сертификации по требованиям «Общих критериев» 2. Расширение сложившейся практики организации экспертизы материалов сертификационных испытаний 3. Разработка полноценной системы сопутствующей документации, регламентирующей практические аспекты реализации отдельных положений «Общих критериев»


Слайд 48

V. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К ОБЪЕКТУ ИНФОРМАТИЗАЦИИ Комбинированный подход к анализу рисков, рекомендуемый современными стандартами в области управления информационной безопасностью – ГОСТ 17799-05, ГОСТ 27001-05, ГОСТ 13335-05, BS 7799:3-06, серия ISO 27000


Слайд 49

Возможная схема проведения сертификационных и аттестационных испытаний 1. На этапе высокоуровневого анализа рисков выявляются подсистемы, требующие детального анализа уязвимостей/оценки отсутствия недекларированных возможностей, и подсистемы, для которых проведение подобного анализа не является обязательным и может быть скомпенсировано другими сервисами безопасности. 2. В зависимости от выбранного уровня детализации, проводится сертификация программного продукта на отсутствие недекларированных возможностей или программных закладок. 3. Для тех подсистем, которые не отнесены к категории критических, защита, в соответствии с приведёнными рекомендациями, должна быть реализована путём применения положений некоторых руководств и стандартов.


Слайд 50

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


Слайд 51

Возможность использования подхода «Общих критериев» при аттестации 1. ГОСТ 15408 («Общие критерии»), недостающие требования могут быть сформулированы в явном виде 2. Проект - Технический доклад ISO/IEC PDTR 19791)


Слайд 52

ВЫВОДЫ Назрела необходимость в разработке и внедрении новых методов и средств выявления уязвимостей программного кода и оценке угроз Накопленный опыт проведения сертификационных испытаний на отсутствие НДВ и ПЗ позволяет наметить пути совершенствования нормативной базы, основанной на использовании сигнатурных методов анализа кода Развитие нормативной базы возможно в рамках использования новых стандартов и руководящих документов по линии «Общих критериев»


Слайд 53

ВЫВОДЫ IV. При выборе необходимой глубины анализа программных продуктов руководствоваться результатами анализа рисков, проводимого в соответствии с рекомендациями современных стандартов в области управления информационной безопасностью (серия 27000).


Слайд 54

Спасибо за внимание! Источник: Выявление уязвимостей в программном коде / А. С. Марков, С.В.Миронов, В.Л.Цирлов // Открытые системы, 2005. - №12. С.64-69. Алексей Сергеевич Марков Валентин Леонидович Цирлов mail@npo-echelon.ru www.npo-echelon.ru www.cnpo.ru


×

HTML:





Ссылка: