НАПРАВЛЕНИЯ СОВЕРШЕНСТВОВАНИЯ МЕТОДОВ СЕРТИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯНА ОТСУТСТВИЕ УЯЗВИМОСТЕЙ презентация

Содержание

П Р О Б Л Е М А Пример из жизни: новости от 10 октября 2006 г.: в программе «XXX 4.хх» обнаружена серьезная уязвимость Злоумышленник может выполнить произвольный код в

Слайд 1НАПРАВЛЕНИЯ СОВЕРШЕНСТВОВАНИЯ МЕТОДОВ СЕРТИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА ОТСУТСТВИЕ УЯЗВИМОСТЕЙ
Совещание «Взаимодействие участников рынка

продуктов и услуг в области безопасности», 10 – 17 марта 2007 г.

Марков А.С., Цирлов В.Л.

mail@npo-echelon.ru



Слайд 2П Р О Б Л Е М А
Пример из жизни: новости

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

Слайд 3Фрагмент кода
Уязвимый фрагмент кода
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;
}


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

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

Трудоемкость
часы – месяцы - столетия


Слайд 7СИТУАЦИЯ
Продукт в 2006 году прошел сертификацию ..

Вероятно, уязвимость была обнаружена без

исходных кодов

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

испытаний
Возможные подходы к выявлению уязвимостей
Возможности перехода к «Общим критериям»
Возможности применения организационных стандартов

Слайд 9I. ПРОБЛЕМНАЯ СИТУАЦИЯ
3 Системы обязательной сертификации: МО РФ, ФСБ России, ФСТЭК

России
Система добровольной сертификации АйТиСертифика
Руководящий документ Гостехкомиссии России «Защита от НСД к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей»

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

информационных технологий, версий и реализаций программных ресурсов
Относительная легкость модификации программного кода
Сложность идентификации программной закладки (ПЗ) как преднамеренно внесенной

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

НДВ и ПЗ
Недостаточность регламентированной инструментальной базы испытаний
Отсутствие прикладных реализаций математического аппарата испытаний ПО

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

отсутствия НДВ
Возможности инструментальной базы испытаний
Организационные особенности сертификационных испытаний

Слайд 13
ПО СЗИ. Классификация по уровню контроля отсутствия

недекларированных возможностей (НДВ). Документация, контроль

Слайд 14
ПО СЗИ. Классификация по уровню контроля отсутствия

НДВ. Статический анализ

Слайд 15
ПО СЗИ. Классификация по уровню контроля отсутствия

НДВ. Динамический анализ

Слайд 16ПОЛОЖИТЕЛЬНЫЕ МОМЕНТЫ РД

Требование по предоставлению исходного кода и документации
Контроль избыточности (что

позволяет исключить некоторые закладные элементы)
Определение полномаршрутного тестирования ПО

Слайд 17СЛОЖНОСТИ РЕАЛИЗАЦИИ ИСПЫТАНИЙ
1) Высокая вычислительную сложность статического анализа и чрезвычайно

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


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

Например:
- отсутствие сигнатурного анализа в требованиях к испытаниям ПО ниже 2 уровня контроля;
- отсутствие требований и содержания базы потенциально опасных конструкций;
- отсутствие механизмов выявления недекларированных возможностей, связанных с переполнением буфера, гонками, вызовом функций не из своего адресного пространства, отсутствием очистки памяти и др.

Слайд 19НЕГАТИВНЫЕ МОМЕНТЫ ИСПЫТАНИЙ
3) Неопределенность в действиях экспертов и достоверности получаемых результатов:


- отсутствие задекларированных способов построения перечня маршрутов выполнения функциональных объектов (ветвей);
- отсутствие механизмов подсчета полноты покрытия и его достаточности при динамическом анализе;
- отсутствие рекомендаций, как именно выявляются НДВ при анализе, например, матрицы связей по информации


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

отражающие несовершенную нормативную базу и не позволяющие эффективно выявлять уязвимости кода?
Следует ли сертифицировать средства тестирования в обязательном порядке?

Слайд 21ОРГАНИЗАЦИОННЫЕ ПРОБЛЕМЫ
Как влияет НДВ на угрозу ОИ? (Оценка риска и наличия

угрозы)
Как организовать сертификацию программных продуктов с постоянно изменяющимся кодом? Если в продукте обнаружены уязвимости, то действие сертификата должно быть приостановлено?
Уровень выявления НДВ. Оценка скрытых каналов.
Что делать, если нет исходных кодов - некоторые проверки можно (и даже желательно) провести и без исходного кода?
Что делать, когда сертификацию нельзя провести по правовым моментам? Не пора ли ввести систему спецпроверки ПО по аналогии с аппаратными средствами?


Слайд 22III. ПРЕДЛАГАЕМЫЕ НАПРАВЛЕНИЯ СОВЕРШЕНСТВОВАНИЯ МЕТОДИЧЕСКОЙ БАЗЫ ПРОВЕРКИ ПО
1. Определение полного множества

классов уязвимостей ПО;
2. Исследование способов выявления классов уязвимостей;
3. Развитие методической базы выявления уязвимостей в рамках сертификационных испытаний;
4. Развитие методической базы определения требований (с учетом угроз) к безопасности ПО в рамках аттестационных испытаний

Что выявляем: метрики, ошибки, НДВ, уязвимости, угрозы?


Слайд 23БЕЗОПАСНОСТЬ ПРОГРАММНОГО КОДА
Безопасность ПО - свойство ПО АС быть защищенным от

угроз целостности, доступности и конфиденциальности информационно-программных ресурсов системы
Уязвимость программного кода - реализационный дефект ПО, который может потенциально снизить степень ИБ системы
Угроза ПО АС – возможность реализации уязвимости
Риск – комбинация вероятности реализации угрозы и ее последствий

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

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

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

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

Слайд 26НАИБОЛЕЕ РАСПРОСТРАНЕННЫЕ КЛАССЫ УЯЗВИМОСТЕЙ
- программные закладки типа логические бомбы;
- некорректности кодирования

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

Слайд 27СПОСОБЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ НА ЭТАПЕ СЕРТИФИКАЦИОННЫХ ИСПЫТАНИЙ
1) Структурный статический и динамический

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


Слайд 28Примеры реальных закладок
#ifndef US
#define US "test"
#endif

#ifndef PA
#define PA “qwerty"
#endif

db->setUsNa (US); db->setPa

(PA);


Недекларированные имя пользователя и пароль по умолчанию


Слайд 29Примеры реальных закладок
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 ); }

Содержимое текстового поля искажается – выводится недекларированное сообщение


Слайд 30Примеры эвристического анализа
Возможность некорректности кода, допускающей переполнение буфера:

1. Поиск соответствующих функций

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



Слайд 31Расчет
Пример ПО (5Мб, Си):

Ручной просмотр листингов всего кода
- 2000

чел/час
Сигнатурно-эвристический анализ
- 200 чел/час
Статический и динамический анализ
- от 4000 чел/час


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


Слайд 33
СПОСОБЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ КОДА


Слайд 34ВОЗМОЖНЫЕ ЭТАПЫ ИСПЫТАНИЯ НА ОТСУТСТВИЕ УЯЗВИМОСТЕЙ КОДА - ПРИОРИТЕТЫ
1) Формирование ПБ

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


Слайд 35ПЕРЕЧЕНЬ СРЕДСТВ ТЕСТИРОВАНИЯ
Структурное тестирование (по методу «белого ящика»):
Отечественные средства проведения

сертификационных испытаний относят: «АИСТ», «КСАИТ», «АК-ВС» и др.
Зарубежные средства тестирования: 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 и др.



Слайд 36
СРЕДСТВА СТРУКТУРНОГО ТЕСТИРОВАНИЯ


Средства испытаний


Слайд 37
СПЕЦИАЛИЗИРОВАННЫЕ СРЕДСТВА ТЕСТИРОВАНИЯ

Средства тестирования ПО


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


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


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


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


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


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


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

испытаний




Слайд 45Неопределённый статус сертификата



Проблемы реализации сертификации по «ОК»


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


Проблемы реализации

сертификации по «ОК»

Слайд 47Неоднозначность толкования определенных положений «Общих критериев»

- Полнота отчётной документации
- Язык описания

предположений, угроз, политик и целей безопасности
- Выбор оценочного уровня доверия
- Функциональные требования безопасности и требования доверия, формулируемые в явном виде
- Детализация краткой спецификации объекта оценки
- Ссылки на профили защиты
- Глубина логического обоснования разделов профилей защиты и заданий по безопасности



Проблемы реализации сертификации по «ОК»


Слайд 48НАПРАВЛЕНИЯ РЕШЕНИЯ ПРОБЛЕМЫ
1. Формирование рынка независимых консалтинговых услуг по подготовке продукции

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



Слайд 49V. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К ОБЪЕКТУ ИНФОРМАТИЗАЦИИ
Комбинированный подход к анализу рисков, рекомендуемый

современными стандартами в области управления информационной безопасностью –
ГОСТ 17799-05,
ГОСТ 27001-05,
ГОСТ 13335-05,
BS 7799:3-06,
серия ISO 27000


Слайд 50Возможная схема проведения сертификационных и аттестационных испытаний
1. На этапе высокоуровневого анализа

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

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

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

Слайд 52Возможность использования подхода «Общих критериев» при аттестации
1. ГОСТ 15408 («Общие критерии»),

недостающие требования могут быть сформулированы в явном виде
2. Проект - Технический доклад ISO/IEC PDTR 19791)



Слайд 53ВЫВОДЫ
Назрела необходимость в разработке и внедрении новых методов и средств выявления

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

Слайд 54ВЫВОДЫ
IV. При выборе необходимой глубины анализа программных продуктов руководствоваться

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


Слайд 55Спасибо за внимание!

Источник:
Выявление уязвимостей в программном коде / А. С. Марков,

С.В.Миронов, В.Л.Цирлов // Открытые системы, 2005. - №12. С.64-69.


Алексей Сергеевич Марков
Валентин Леонидович Цирлов
mail@npo-echelon.ru
www.npo-echelon.ru
www.cnpo.ru


Обратная связь

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

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

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


Для правообладателей

Яндекс.Метрика