Марков А.С., Цирлов В.Л. mail@npo-echelon.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22. III. ПРЕДЛАГАЕМЫЕ НАПРАВЛЕНИЯ СОВЕРШЕНСТВОВАНИЯМЕТОДИЧЕСКОЙ БАЗЫ ПРОВЕРКИ ПО Что выявляем: метрики, ошибки, НДВ, уязвимости, угрозы? 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. Разработка полноценной системы сопутствующей документации, регламентирующей практические аспекты реализации отдельных положений «Общих критериев»

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

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