Методика проведения оценки безопасности аппаратно-программных средств

1.

Методика проведения оценки
безопасности аппаратно-программных
средств

2.

Как производится оценка соответствия объекта?
• Согласно ИСО 17000 базовыми видами деятельности по оценке соответствия
являются: испытание, контроль, сертификация, аккредитация органов по
оценке соответствия. Каждому объекту для достижения определённого ОУД
требуется необходимо выполнить заданные требования, чтобы быть
допущенным к итоговой проверке и получить подтверждение соответствия.
• Испытание – определение ФБО
• Контроль – проверка ФБО заданным требованиям
• Сертификация – подтверждение соответствия в виде документа
• Подтверждение соответствия – выдача заявления, основанного на принятом
после итоговой проверки решении о том, что выполнение заданных
требований доказано

3.

Как производится оценка соответствия объекта?

4.

ОУД – Оценочный Уровень Доверия
(ГОСТ 15408)
• Оценочный уровень доверия (ОУД) – Набор требований доверия,
представляющий некоторое положение на предопределенной шкале доверия
и составляющий пакет доверия;
• Класс – Совокупность семейств, объединенных общим назначением;
• Семейство – совокупность компонентов, которые направлены на достижение
сходной цели, но отличаются акцентами или строгостью;
• Компонент – наименьшая выбираемая совокупность элементов, на которой
могут основываться требования;
• ГОСТ 15408 выделяет 7 ОУД и 6 классов доверия

5.

Обзор оценочных уровней доверия

6.

Разработка
• Разработка – цель разработки состоит в подробном описании ФБО ОО, а также показать архитектуру
безопасности и её конкретные функции.

7.

Руководство
• Руководство – содержит требования к содержанию «Руководства администратора», «Руководства
пользователя», «Подготовительных процедур». Для безопасного администрирования и использования ОО
необходимо описать все аспекты, относящиеся к безопасному применению ОО.

8.

Поддержка жизненного цикла
• Поддержка жизненного цикла – Поддержка жизненного цикла является аспектом установления дисциплины и
контроля в процессе уточнения ОО во время его разработки и сопровождения.

9.

Оценка задания по безопасности
• Оценка задания по безопасности – цель оценки ЗБ состоит в демонстрации того, что ЗБ является полным,
непротиворечивым, технически правильным и поэтому пригодно в качестве основы для оценки
соответствующего ОО.

10.

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

11.

Как происходит процесс тестирования?
ГОСТ 58143
• 1.
Планирование тестирования проникновения:
• a. область применения процесса определения угроз безопасности информации
• b. идентификацию потенциальных уязвимостей;
• c. описание возможностей и мотивации нарушителя.
• 2.
Разработка тестов проникновения:
• a. разработку тестов проникновения, используя идентифицированные шаблоны атак;
• b. разработку тестов проникновения с использованием метода гипотез (предположений) о недостатках;
• c. документирование тестов проникновения.
• 3.
Проведение тестирования проникновения:
• 4.
a. выполнение тестов проникновения;
b. анализ результатов тестов;
c. уточнение тестов с учетом полученных результатов;
d. документирование результатов тестирования проникновения.
Разработка отчетности по результатам тестирования проникновения:
• a. условия проведения тестирования проникновения;
• b. обобщенные результаты тестирования проникновения;
• c. детализацию результатов тестирования проникновения по отношению к каждой потенциальной уязвимости.
• 5.
Анализ процесса разработки программного обеспечения в части:
• a. управления версиями;
• b. предварительного тестирования;
• c. организации процесса разработки.

12.

Органы по оценке соответствия ФСТЭК и ФСБ
Согласно 960 и 1085 указу президента:
• ФСТЭК России формирует требования и производит контроль
мероприятий по защите информации некриптографическими
методами (разграничение прав пользователей, защита
информации от побочных электромагнитных излучений, защита
речевой информации и др.);
• ФСБ России формирует требования и производит контроль
мероприятий по защите информации криптографическими
методами (защита каналов связи, электронная подпись).

13.

Приказ 76 ФСТЭК
• ФСТЭК выделяет 6 Оценочных Уровней Доверия, начиная с
самого низшего 6 и заканчивая самым высшим 1. ОУД 1-3
относятся к Государственной тайне, поэтому именно на
требования к ОУД 4-6 и делается акцент в приказе 76.
• Самое важное отличие ГОСТ 15408 от требований ФСТЭК является
дополнительные требования к САВЗ и СОВ, описанные в таблице 1!

14.

Требования к ОУД 4-6 по ФСТЭК
Разрабатывать модель безопасности средства нужно только для ОУД4

15.

Требования к ОУД 4-6 по ФСТЭК
Только для ОУД 4 нужно проводить анализ скрытых каналов утечки информации

16.

Что должно быть в документации и как это
определить?
За конкретику содержания документации отвечает пометка С, D – действия разработчика, Е – оценщика, в
качестве примера привожу Таблицу ALC_CMC.4

17.

Анализ Уязвимостей
• Оценка уязвимостей – обеспечивает обнаружение возможностей преодоления
вероятностных или перестановочных механизмов безопасности и использованием
уязвимостей, вносимых при разработке или эксплуатации ОО.
• AVA_VAN.4.2E Испытательная лаборатория должна выполнить поиск
информации в общедоступных источниках в целях идентификации
потенциальных уязвимостей в ОО.
• AVA_VAN.4.3E Испытательная лаборатория должна провести независимый
методический анализ уязвимостей ОО с использованием документации
руководств, функциональной спецификации, проекта ОО, описания архитектуры
безопасности и представления реализации, чтобы идентифицировать
потенциальные уязвимости в ОО.

18.

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

19.

Подходы к анализу кода
Подходы к обнаружению ошибок:
1.
Аудит кода
• a) - Требует экспертов высокого уровня
• b) - Большие трудозатраты
2.
Динамический анализ, Фаззинг
• a) + Не требует наличия исходного кода
• b) + Определяют входные данные при обнаружении ошибки
• c) - Могут пропускать редкие пути выполнения
• d) - Ограниченная масштабируемость
Сложно построить динамический анализ, которые будут исследовать входные ВСЕ варианты входных данных.
3.
Методы формальной верификации программ
• a) + Гарантирует отсутствие пропущенных ошибок
• b) - Имеют ограниченную масштабируемость
• c) - Нуждаются в ручном задании модели окружения программы
• d) - Накладывают ограничения на анализируемые программы (ЯП)
В этом методе очень точно строится модель программы и описывается семантика (значение фрагмента кода) программы и
с помощью математических доказательств можно программа не содержит ошибки. Предпочтительнее использовать на
малых программах по объёму кода
4.
Методы статического анализа
• a) + Масштабируются на программы из миллионов строк кода
• b) + Не требуют специальной подготовки кода
• c) - Могут пропускать ошибки и выдавать ложные срабатывания

20.

Статический анализ
• Статический анализ кода – технология для исследования программного кода
без его запуска.
• В статическом анализе присутствуют ошибки 1 и 2 рода. Ошибка 1 рода (FP):
Анализатор – ошибка есть, на самом деле её нет. Ошибка 2 рода (FN) –
ошибки нет, на самом деле она есть (сложно считать). Нужно считать
количество ошибок.
• 1. Поиск ошибок кодирования – как можно меньше FP. Выдаётся
предупреждение, если анализатор уверен в ошибке (Время – выгода
использования)
• 2. Поиск уязвимостей – как можно меньше FN. Не выдаётся
предупреждение, если анализатор уверен в отсутствии ошибки (1 Ошибка –
эксплуатация уязвимости)

21.

Примеры ошибочных сценариев

22.

1. Разыменование нулевого указателя
• Разыменование нулевого указателя – это ситуация, когда на некотором пути
выполнения разыменуется потенциально некорректный указатель (может
быть равен NULL)
Простой пример отказа в обслуживании

23.

2. Потоково-чувствительный анализ
Усложнённый пример отказа в обслуживании с несколькими переменными

24.

3. Чувствительный к путям анализ

25.

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

26.

5. Анализ указателей

27.

6. Чувствительный к полям анализ

28.

7. Анализ значений

29.

8. Анализ циклов
Одна из наиболее распространённых ошибок – использование циклов, что вызывает переполнение буфера
после завершения цикла.

30.

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

31.

Реальный пример возможного анализа
уязвимостей по ФСТЭК

32.

33.

Сканирование открытых портов

34.

Анализ уязвимости

35.

Тестирование проникновения
• В рамках ССЗИ будет рассмотрен антивирус ESET NOD-32. Для реализации
угрозы установим программу Inrercepter-NG и проведём сканирование
портов.

36.

ARP-spoofing
На рисунке видно, что пользователь посещал сайт kremlin.ru, government.ru и вошёл на сайт komissy.ru по
небезопасному протоколу HTTP с логином alexbol57 и паролем alexbol57.

37.

Окончание тестирования ССЗИ
В данном случае мы не можем исправить уязвимость так как не имеем доступа к коду, но мы можем нейтрализовать её с
помощью нашего САВЗ, следовательно потенциальный злоумышленник не сможет воспользоваться данной уязвимостью
в МЭ, что доказывает состоятельность нашего ПО. Тест завершён успешно!

38.

Проблемы сертификации по ФСТЭК
• 1. Анализ по ФСТЭК производится с помощью сертифицированных программ,
поэтому их обновление или перенастройка очень затруднительна, так как
сертифицированным ПО можно являться только когда контрольная сумма всех
файлов будет идентична сертификационной версии. Если хотя бы 1 файл из ПО
будет изменён или удалён, то ПО теряет сертификацию и больше не является
сертифицированным, а следовательно, с его помощью нельзя проводить оценку
соответствия по ФСТЭК;
• 2. Для сертификации программы в системе ФСТЭК необходимо обратиться в
специализированную аккредитованную организацию – испытательную
лабораторию. На данный момент таких лабораторий на территории РФ всего 39
штук. Беря во внимание такое маленькое количество лабораторий, цена услуг
очень высокая, так как спрос большой, а конкуренции мало.
• 3. ФСТЭК может не принять программное обеспечение на сертификационные
испытания, потому что сертификация в системе ФСТЭК подразумевает
сертификацию средств защиты информации.

39.

Сертифицированные средства защиты
информации

40.

Примеры CСЗИ
• Программный комплекс «Стахановец»: НДВ 4
• Аппаратно-программный комплекс шифрования «Континент». Версия 3.9:
МЭ 3А, 3Б, СОВ 3
• Программное изделие Kaspersky Endpoint Detection and Response: САВЗ 4Б,
4В
• Операционная система специального назначения «Astra Linux Special
Edition»: ОС А1, А2
• Программное изделие «Сетевой сканер безопасности XSpider 7.8.25»: ОУД 4
• Программное изделие «Анализатор защищенности исходного кода
приложений Positive Technologies Application Inspector»: ОУД 4

41.

Заключение:
• В ходе данной курсовой работы была проанализирована методика
проведения оценки безопасности аппаратно-программных средств с точки
зрения тестирования и анализа уязвимостей. Были рассмотрены такие
нормативные документы как ГОСТ 17000, ГОСТ 15408, ГОСТ 58143, Приказ
ФСТЭК 76, Указ президента №960 и 1085. Согласно ГОСТ 15408 были
рассмотрены 6 классов доверия: Разработка, Руководство, Поддержка
жизненного цикла, Оценка задания по безопасности, Тестирование и Анализ
уязвимостей. Рассмотрены компоненты доверия и откуда брать о них
информацию. Также были рассмотрены требования к ОУД по ГОСТ и
ФСТЭК соответственно. Выделены отличия по между ОУД 4-6 по ФСТЭК.
Произведён разбор Статического анализа для идентификации уязвимостей и
смоделирован возможный процесс поиска, анализа уязвимостей и
тестирования на предполагаемом ОО. Выявлены проблемы сертификации по
ФСТЭК, а также рассмотрен реестр ССЗИ ФСТЭК.

42.

Спасибо за внимание