Направления совершенствования методов сертификации

Совещание «Взаимодействие участников рынка продуктов и услуг в
области безопасности», 10 – 17 марта 2007 г.
НАПРАВЛЕНИЯ
СОВЕРШЕНСТВОВАНИЯ
МЕТОДОВ СЕРТИФИКАЦИИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
НА ОТСУТСТВИЕ УЯЗВИМОСТЕЙ
Марков А.С., Цирлов В.Л.
mail@npo-echelon.ru
ПРОБЛЕМА
Пример из жизни: новости от 10 октября 2006 г.:
в
программе
«XXX
4.хх»
обнаружена
серьезная
уязвимость
Злоумышленник может выполнить произвольный код в системе
из-за некорректной обработки входных данных параметров
Причина состоит в ошибке обработки LHA-архивов, содержащих
длинные имена директорий в расширенном заголовке
директорий. Удаленный пользователь может вызвать
переполнение динамической памяти и выполнить
произвольный код на целевой системе. Ошибка вызвана
некорректностью кодирования, а именно использования
функции копирования строк без проверки длины
Рабочий эксплоит можно скопировать с сайта …
Фрагмент кода
Уязвимый фрагмент кода
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;
}
Как можно обнаружить?
Способы выявления:
часы
-
просмотр исходных кодов на предмет
выявления ошибок работы с памятью
месяцы
-
функциональное тестирование граничных
значений или нагрузочное тестирование
-
-
полное структурное и функциональное
тестирование продукта
Трудоемкость
сигнатурно-эвристический анализ
исходных кодов на предмет выявления
ошибок работы с памятью по исходным
кодам
–
-
столетия
СИТУАЦИЯ
Продукт в 2006 году прошел сертификацию ..
Вероятно,
уязвимость
исходных кодов
была
обнаружена
без
НАПРАВЛЕНИЯ СОВЕРШЕНСТВОВАНМЯ
МЕТОДОВ СЕРТИФИКАЦИИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
НА ОТСУТСТВИЕ УЯЗВИМОСТЕЙ
I.
Проблемная ситуация
II. Возможности сертификационных испытаний
III. Возможные подходы к выявлению уязвимостей
IV. Возможности перехода к «Общим критериям»
V. Возможности применения организационных
стандартов
I. ПРОБЛЕМНАЯ СИТУАЦИЯ
•
3 Системы обязательной сертификации:
МО РФ, ФСБ России, ФСТЭК России
•
Система добровольной сертификации
АйТиСертифика
•
Руководящий документ Гостехкомиссии России
«Защита от НСД к информации. Часть 1.
Программное обеспечение средств защиты
информации. Классификация по уровню контроля
отсутствия недекларированных возможностей»
ОБЪЕКТИВНЫЕ ПРИЧИНЫ УЯЗВИМОСТИ
ПРОГРАММНЫХ РЕСУРСОВ
•
Чрезвычайно высокая структурная сложность
программных систем
•
Динамичность развития информационных технологий,
версий и реализаций программных ресурсов
•
Относительная легкость модификации программного
кода
•
Сложность идентификации программной закладки (ПЗ)
как преднамеренно внесенной
СУБЪЕКТИВНЫЕ ПРИЧИНЫ УЯЗВИМОСТИ
ПРОГРАММНЫХ РЕСУРСОВ
•
Несовершенство нормативно-методической базы
сертификационных испытаний на отсутствие НДВ и ПЗ
•
Недостаточность регламентированной инструментальной
базы испытаний
•
Отсутствие прикладных реализаций математического
аппарата испытаний ПО
II. ВОЗМОЖНОСТИ
СЕРТИФИКАЦИОННЫХ ИСПЫТАНИЙ
•
Возможности использования руководящего
документа Гостехкомиссии России по контролю
отсутствия НДВ
•
Возможности инструментальной базы испытаний
•
Организационные особенности
сертификационных испытаний
ПО СЗИ. Классификация по уровню контроля
отсутствия недекларированных
возможностей (НДВ). Документация, контроль
ПО СЗИ. Классификация по уровню контроля
отсутствия НДВ. Статический анализ
ПО СЗИ. Классификация по уровню контроля
отсутствия НДВ. Динамический анализ
ПОЛОЖИТЕЛЬНЫЕ МОМЕНТЫ РД
•
Требование по предоставлению исходного кода и
документации
•
Контроль избыточности (что позволяет исключить
некоторые закладные элементы)
•
Определение полномаршрутного тестирования ПО
СЛОЖНОСТИ РЕАЛИЗАЦИИ ИСПЫТАНИЙ
1) Высокая вычислительную сложность статического
анализа и чрезвычайно высокая сложность
динамического анализа.
Фактически, с ростом сложности изделия
динамический анализ становится неразрешимой
задачей и формальной процедурой (отнимающей
много времени и ресурсов у экспертов лаборатории)
НЕДОСТАТОЧНОСТЬ ИСПЫТАНИЙ
2). Отсутствие или недостаточность проверок,
непосредственно связанных с безопасностью изделия.
Например:
- отсутствие сигнатурного анализа в требованиях к
испытаниям ПО ниже 2 уровня контроля;
- отсутствие требований и содержания базы
потенциально опасных конструкций;
- отсутствие механизмов выявления недекларированных
возможностей, связанных с переполнением буфера,
гонками, вызовом функций не из своего адресного
пространства, отсутствием очистки памяти и др.
НЕГАТИВНЫЕ МОМЕНТЫ ИСПЫТАНИЙ
3) Неопределенность в действиях экспертов и
достоверности получаемых результатов:
- отсутствие задекларированных способов построения
перечня маршрутов выполнения функциональных
объектов (ветвей);
- отсутствие механизмов подсчета полноты покрытия и
его достаточности при динамическом анализе;
- отсутствие рекомендаций, как именно выявляются НДВ
при анализе, например, матрицы связей по информации
СОСТОЯНИЕ ИНСТРУМЕНТАЛЬНОЙ
БАЗЫ ИСПЫТАНИЙ
1)
Целесообразно ли делать обязательными к
применению инструментальные средства,
отражающие несовершенную нормативную базу и не
позволяющие эффективно выявлять уязвимости
кода?
2)
Следует ли сертифицировать средства тестирования
в обязательном порядке?
ОРГАНИЗАЦИОННЫЕ ПРОБЛЕМЫ
1.
Как влияет НДВ на угрозу ОИ? (Оценка риска и наличия
угрозы)
2.
Как организовать сертификацию программных продуктов с
постоянно изменяющимся кодом? Если в продукте
обнаружены уязвимости, то действие сертификата должно
быть приостановлено?
3.
Уровень выявления НДВ. Оценка скрытых каналов.
4.
Что делать, если нет исходных кодов - некоторые проверки
можно (и даже желательно) провести и без исходного кода?
5.
Что делать, когда сертификацию нельзя провести по
правовым моментам? Не пора ли ввести систему
спецпроверки ПО по аналогии с аппаратными средствами?
III. ПРЕДЛАГАЕМЫЕ НАПРАВЛЕНИЯ
СОВЕРШЕНСТВОВАНИЯ
МЕТОДИЧЕСКОЙ БАЗЫ ПРОВЕРКИ ПО
Что выявляем: метрики, ошибки, НДВ, уязвимости,
угрозы?
1. Определение полного множества классов
уязвимостей ПО;
2. Исследование способов выявления классов
уязвимостей;
3. Развитие методической базы выявления
уязвимостей в рамках сертификационных
испытаний;
4. Развитие методической базы определения
требований (с учетом угроз) к безопасности ПО в
рамках аттестационных испытаний
БЕЗОПАСНОСТЬ ПРОГРАММНОГО КОДА
•
Безопасность ПО - свойство ПО АС быть защищенным от
угроз целостности, доступности и конфиденциальности
информационно-программных ресурсов системы
•
Уязвимость программного кода - реализационный дефект
ПО, который может потенциально снизить степень ИБ
системы
•
Угроза ПО АС – возможность реализации уязвимости
•
Риск – комбинация вероятности реализации угрозы и ее
последствий
БЕЗОПАСНОСТЬ ПРОГРАММНОГО КОДА
Недекларированная возможность - функциональная
возможность ПО, не описанная или не соответствующая
описанию в документации, при использовании которой
возможно нарушение конфиденциальности, доступности
или целостности обрабатываемой информации
КЛАССИФИКАЦИОННЫЕ ПРИЗНАКИ
УЯЗВИМОСТЕЙ КОДА
Классификационные признаки:
- уровень реализации (проектный или кодирования);
- степень преднамеренности (идентифицируется как
преднамеренная или нет);
- уровень выполнения (прикладной, системный);
- компрометируемая подсистема (парольная,
криптографическая, целостности и др.);
- результирующее действие (отказ в обслуживании, НСД,
нарушение целостности) и др.
НАИБОЛЕЕ РАСПРОСТРАНЕННЫЕ
КЛАССЫ УЯЗВИМОСТЕЙ
- программные закладки типа логические бомбы;
- некорректности кодирования (переполнение буфера, гонки,
некорректная обработка дат и счетчиков) – уязвимости ПО
в узком смысле;
- наличие отладочных функций;
- недекларированные входные параметры и горячие клавиши;
- уязвимости, компрометирующие подсистемы и механизмы
защиты (парольные, криптографические и др.);
- уязвимости, приводящие к отказу в обслуживании;
- уязвимости, связанные с редко используемыми входными
данными;
- скрытые каналы и др.
СПОСОБЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ НА
ЭТАПЕ СЕРТИФИКАЦИОННЫХ ИСПЫТАНИЙ
1) Структурный статический и динамический
анализ исходного кода (регламентируемый
стандартами по тестированию и
руководящим документом)
2) Сигнатурно-эвристический анализ
потенциально опасных операций
Примеры реальных закладок
#ifndef US
#define US "test"
#endif
…
#ifndef PA
#define PA “qwerty"
#endif
…
db->setUsNa (US);
db->setPa (PA);
…
Недекларированные имя пользователя и пароль по умолчанию
Примеры реальных закладок
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 );
}
Содержимое текстового поля искажается – выводится недекларированное
сообщение
Примеры эвристического анализа
Возможность некорректности кода, допускающей переполнение буфера:
1. Поиск соответствующих функций кода;
1.1. Например, функции копирования строк с контролем длины
strncpy()
wcsncpy()
_tcsncpy()
lstrcpyn()
_mbsnbcpy()
….
Проверка:
2.1. Необходимо обеспечить завершение нулём строки буфера-приёмника.
2.2. Необходимо реализовать обработку некорректных указателей.
Расчет
Пример ПО (5Мб, Си):
Ручной просмотр листингов всего кода
- 2000 чел/час
Сигнатурно-эвристический анализ
- 200 чел/час
Статический и динамический анализ
- от 4000 чел/час
СПОСОБЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ КОДА
Класс уязвимости
Метод структурного
тестирования
Метод тестирования при
отсутствие исх.кодов
Ошибки, возникающие
при редко используемых
входных данных
Тестирование граничных
значений
Тестирование граничных
значений и
рандомизированное
тестирование
Недекларированные
входные параметры и
горячие клавиши
Сигнатурноэвристический анализ
Профилирование
производительности,
функциональное
тестирование
Ошибки, связанные с
отказом в
обслуживании
Сигнатурноэвристический анализ
Нагрузочное и стрессовое
тестирование,
рандомизированное
тестирование
Уязвимости
подсистемы
парольной защиты и
других подсистем
Сигнатурноэвристический анализ
Функциональное
тестирование по
безопасности
Классификация уязвимостей
СПОСОБЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ КОДА
Класс уязвимости
Метод структурного
тестирования
Метод тестирования при
отсутствие исх.кодов
Программные закладки
(логические бомбы)
Сигнатурноэвристический анализ
Анализ изменения памяти
(счетчиков), изменение
интервалов времени,
наработка запусков
Некорректности
кодирования
(переполнение буфера и
др.)
Сигнатурноэвристический анализ
Тестирование корректности
ввода данных, стрессовое и
нагрузочное тестирование
Преднамеренные
нарушения, логические
бомбы, хулиганство,
«пасхальные яйца»
Сигнатурноэвристический анализ
Анализ сообщений и
комментарий кода, аналоги,
функциональное
тестирование
Скрытые каналы
Сигнатурноэвристический анализ
Изолированная среда,
разбор и анализ трафика и
памяти
ВОЗМОЖНЫЕ ЭТАПЫ ИСПЫТАНИЯ НА
ОТСУТСТВИЕ УЯЗВИМОСТЕЙ КОДА ПРИОРИТЕТЫ
1) Формирование ПБ ПО, которая может соотноситься с ТУ на объект
информатизации (ОИ)
2) Проведение сигнатурного анализа исходного кода по фрагментам
потенциально опасным операциям и некоректностям кодирования
3) Проведение анализа подсистем безопасности (динамический анализ
парольной защиты)
4) Проведение функционального, стрессового и нагрузочного тестирования,
тестирования по производительности
5) Структурный анализ избыточности дистрибутива и контроль целостности
6) Анализ наличия скрытых каналов ("put-in")
7) Формирование ограничений на использование продукта в соответствии с
ПБ
8) Формирование условий обновления и модификации ПР
ПЕРЕЧЕНЬ СРЕДСТВ ТЕСТИРОВАНИЯ
Структурное тестирование (по методу «белого
ящика»):
Отечественные средства проведения сертификационных
испытаний относят: «АИСТ», «КСАИТ», «АК-ВС» и др.
Зарубежные средства тестирования: 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 и др.
СРЕДСТВА СТРУКТУРНОГО ТЕСТИРОВАНИЯ
Средства испытаний
СПЕЦИАЛИЗИРОВАННЫЕ СРЕДСТВА ТЕСТИРОВАНИЯ
Средства тестирования ПО
IV. Соответствие между РД НДВ и «Общими
Критериями»
Требования РД
Классы «Требований доверия» общих
критериев
1. Контроль состава и содержания APE – оценка профиля защиты.
документации
ASE – оценка задания по безопасности
1.1. Спецификация (ГОСТ 19.20278)
1.2. Описание программы (ГОСТ
19.402-78)
ADV_FSP – функциональная спецификация
1.3. Описание применения (ГОСТ ADO – поставка и эксплуатация
19.502-78)
AGD_ADM – руководство администратора
AGD_USR – руководство пользователя
1.4. Пояснительная записка
(ГОСТ 19.404-79)
ADV_HLD – проект верхнего уровня
ADV_LLD – проект нижнего уровня
ADV_RCR – соответствие представлений
1.5. Тексты программ, входящих в ADV_IMP – представление реализации
состав ПО (ГОСТ 19.401-78)
Соответствие между РД НДВ и «Общими
Критериями»
Требования РД
2. Контроль исходного состояния
ПО
Классы «Требований доверия» общих
критериев
ACM_AUT – управление конфигурацией
ACM_CAP – возможности управления
конфигурацией.
ACM_SCP – область управления
конфигурацией
ALC_TAT – инструментальные средства и
методы
3. Статический анализ исходных
текстов программ
3.1. Контроль полноты и
отсутствия избыточности
исходных текстов
AVA_CCA – анализ скрытых каналов
AVA_VLA – анализ уязвимостей
3.2. Контроль соответствия
исходных текстов ПО его
объектному (загрузочному) коду
AVA_CCA – анализ скрытых каналов
AVA_VLA – анализ уязвимостей
Соответствие между РД НДВ и «Общими
Критериями»
Требования РД
Классы «Требований доверия» общих
критериев
3.3. Контроль связей функциональных
объектов по управлению
AVA_CCA – анализ скрытых каналов
AVA_VLA – анализ уязвимостей
3.4. Контроль связей функциональных
объектов по информации
AVA_CCA – анализ скрытых каналов
AVA_VLA – анализ уязвимостей
3.5. Контроль информационных
объектов
3.6. Контроль наличия заданных
конструкций в исходных текстах
AVA_CCA – анализ скрытых каналов
AVA_VLA – анализ уязвимостей
3.7. Формирование перечня маршрутов
выполнения функциональных объектов
(ветвей)
AVA_CCA – анализ скрытых каналов
AVA_VLA – анализ уязвимостей
Соответствие между РД НДВ и «Общими
Критериями»
Требования РД
Классы «Требований доверия» общих
критериев
3.8. Анализ критических маршрутов AVA_CCA – анализ скрытых каналов
выполнения функциональных
AVA_SOF – стойкость функций безопасности
объектов
ОО
AVA_VLA – анализ уязвимостей
3.9. Анализ алгоритма работы
функциональных объектов на
основе блок-схем, диаграмм и т.п.,
построенных по исходным текстам
контролируемого ПО
ADV_RCR – соответствие представлений
AVA_CCA – анализ скрытых каналов
AVA_VLA – анализ уязвимостей
Соответствие между РД НДВ и «Общими
Критериями»
Требования РД
Классы «Требований доверия» общих
критериев
4. Динамический анализ исходных
текстов программ
ATE_IND – независимое тестирование
AVA_MSU – неправильное применение
4.1. Контроль выполнения
функциональных объектов (ветвей)
ATE_COV – покрытие
ATE_DPT – глубина
AVA_CCA – анализ скрытых каналов
AVA_VLA – анализ уязвимостей
4.2. Сопоставление фактических
маршрутов выполнения
функциональных объектов и
маршрутов, построенных в
процессе проведения статического
анализа
AVA_CCA – анализ скрытых каналов
AVA_VLA – анализ уязвимостей
5. Отчетность
Требования доверия, позволяющие реализовать
контроль на отсутствие НДВ
Классы «Требований
доверия» ОК
Комментарии
AVA_VLA – анализ
уязвимостей
Вся совокупность механизмов анализа уязвимостей
программного обеспечения, включая программные
закладки и недекларированные возможности.
AVA_CCA – анализ скрытых
каналов
Важнейший класс уязвимостей программных и
программно-аппаратных
продуктов,
характеризующийся специфическими методами
анализа и требующий поэтому отдельного
рассмотрения.
ATE_IND – независимое
тестирование
Класс требований, позволяющий интегрировать
современные методы тестирования программного
обеспечения
в
процесс
сертификационных
испытаний.
Проблемы реализации сертификации по «ОК»
•
Некомпетентность заявителей и возрастание трудоёмкости
сертификационных испытаний
Заявитель
Разработка «Задания по
безопасности»
Разработка традиционной
консрукторской и проектной
документации
Разработка документации,
специфичной для «Общих
критериев»
Проведение всестороннего
тестирования объекта оценки
Проведение оценки уязвимостей
Оперативное взаимодействие с
оценщиком в ходе проведения
испытаний
Оценщик
Оценка «Задания по
безопасности»
Оценка представленной
документации
Выборочные проверки,
подтверждающие корректность
проведённых разработчиком
исследований
Разработка отчётной
документации
Проблемы реализации сертификации по «ОК»
•
Неопределённый статус сертификата
Сертификация по традиционным
РД Гостехкомиссии
Сертификация по общим
критериям
Статус
=
<
<
>
Стоимость
Длительность
Маркетинговая првлекательность
Проблемы реализации сертификации по «ОК»
•
Трудности при проведении экспертной оценки материалов
сертификационных
(«ужасные» 30 месяцев)
Проблемы реализации сертификации по «ОК»
•
Неоднозначность толкования определенных положений
«Общих критериев»
- Полнота отчётной документации
- Язык описания предположений, угроз, политик и целей безопасности
- Выбор оценочного уровня доверия
- Функциональные требования безопасности и требования доверия,
формулируемые в явном виде
- Детализация краткой спецификации объекта оценки
- Ссылки на профили защиты
- Глубина логического обоснования разделов профилей защиты и заданий по
безопасности
НАПРАВЛЕНИЯ РЕШЕНИЯ ПРОБЛЕМЫ
1. Формирование рынка независимых консалтинговых
услуг по подготовке продукции к сертификации по
требованиям «Общих критериев»
2. Расширение сложившейся практики организации
экспертизы материалов сертификационных испытаний
3. Разработка полноценной системы сопутствующей
документации, регламентирующей практические
аспекты реализации отдельных положений «Общих
критериев»
V. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К
ОБЪЕКТУ ИНФОРМАТИЗАЦИИ
 Комбинированный подход к анализу рисков,
рекомендуемый современными стандартами в
области управления информационной
безопасностью –
 ГОСТ 17799-05,
 ГОСТ 27001-05,
 ГОСТ 13335-05,
 BS 7799:3-06,
 серия ISO 27000
Возможная схема проведения
сертификационных и аттестационных
испытаний
1. На этапе высокоуровневого анализа рисков выявляются
подсистемы, требующие детального анализа
уязвимостей/оценки отсутствия недекларированных
возможностей, и подсистемы, для которых проведение
подобного анализа не является обязательным и может быть
скомпенсировано другими сервисами безопасности.
2. В зависимости от выбранного уровня детализации,
проводится сертификация программного продукта на
отсутствие недекларированных возможностей или
программных закладок.
3. Для тех подсистем, которые не отнесены к категории
критических, защита, в соответствии с приведёнными
рекомендациями, должна быть реализована путём
применения положений некоторых руководств и стандартов.
Преимущества предложенного подхода
1. Позволяет гибко учитывать специфику объектов
оценки при проведении сертификационных
испытаний, повышая общую экономическую
целесообразность данной деятельности.
2. Позволяет интегрировать лучшие технологии
тестирования программного обеспечения, в том
числе автоматизированного, в процесс
сертификационных испытаний.
Возможность использования подхода
«Общих критериев» при аттестации
1. ГОСТ 15408 («Общие критерии»),
недостающие требования могут быть
сформулированы в явном виде
2. Проект - Технический доклад ISO/IEC PDTR
19791)
ВЫВОДЫ
I.
Назрела необходимость в разработке и внедрении
новых методов и средств выявления уязвимостей
программного кода и оценке угроз
II.
Накопленный опыт проведения сертификационных
испытаний на отсутствие НДВ и ПЗ позволяет
наметить пути совершенствования нормативной
базы, основанной на использовании сигнатурных
методов анализа кода
III. Развитие нормативной базы возможно в рамках
использования новых стандартов и руководящих
документов по линии «Общих критериев»
ВЫВОДЫ
IV.
При выборе необходимой глубины анализа
программных продуктов руководствоваться
результатами анализа рисков, проводимого в
соответствии с рекомендациями современных
стандартов в области управления информационной
безопасностью (серия 27000).
Спасибо за внимание!
Источник:
Выявление уязвимостей в программном коде / А. С. Марков,
С.В.Миронов, В.Л.Цирлов // Открытые системы, 2005. - №12.
С.64-69.
Алексей Сергеевич Марков
Валентин Леонидович Цирлов
mail@npo-echelon.ru
www.npo-echelon.ru
www.cnpo.ru