Аудит безопасности программного кода: Подходы, стандарты, технологии выявления дефектов безопасности

Безопасность программного обеспечения

Подходы, стандарты, технологии выявления дефектов безопасности

программных систем.

ИУ-8, МГТУ им. Баумана, Москва, 2012 г.

Фадин Андрей, CISSP Департамент программных разработок

ЗАО «НПО «Эшелон»

Цель семинара

Изучить терминологию, стандарты в области безопасности приложений

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

2

План занятия

Проблема обеспечения безопасности ПО

Актуальность проблемы

Технологии создания ПО

Основные понятия безопасности ПО

Угрозы безопасности ПО

Примеры

Стандартизация дефектов, угроз, уязвимостей

Аудит безопасности ПО

Материалы, методы, процедуры

3

ПРОБЛЕМА НАДЕЖНОСТИ И БЕЗОПАСНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Актуальность вопроса, базовые понятия и определения

4

Надежность программного обеспечения

Если бы строители строили здания также, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию. Второй закон Вейнберга из книги Блох А. Закон Мерфи //ЭКО. 1983. N1-3.

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

Актуальность проблемы

6

0

1000

2000

3000

4000

5000

6000

7000

19

88

19

89

19

90

19

91

19

92

19

93

19

94

19

95

19

96

19

97

19

98

19

99

20

00

20

01

20

02

20

03

20

04

20

05

20

06

20

07

20

08

20

09

20

10

20

11

20

12

Число уязвимостей зарегистрированных в NVD

Число уязвимостей зарегистрированных в NVD

National Vulnerability Database, 2012

Актуальность проблемы (2)

7

WhiteHat Security, 2010

Актуальность проблемы (3)

IDC Consulting, 2008 8

72%

19%

6% 3%

Факторы, обеспечивающие успешную реализацию компьютерных преступлений

Человеческий фактор

Уязвимости программного обеспечения

Нарушения логической структуры информационных систем

Другие факторы

Базовые понятия индустрии ПО Виды распространения ПО

предустановленное

носители

сетевые каналы

ПО как услуга (SaaS)

Виды лицензирования ПО Бесплатное

Freeware/Donationware

Условно-бесплатное Shareware/Adware

Коммерческое Commercial

С открытым кодом Open Source (GPL, LGPL, MIT, BSD, MPL)

9

Производство программных продуктов

Исходные материалы • Исходные тексты на языке программирования

• Файлы проектов, манифесты, конфигурация,

• Ресурсы, внешние зависимости (библиотеки, исполняемые модули)

Промежуточные материалы • Машинный код/байт-код

• Конфигурация: начальные настройки

Релиз ПО • Дистрибутив, пакет, установочный комплект

Инсталляция ПО • Инсталлированная версия/удаленный сервис

• Конфигурация

10

Поколения языков программирования

11

Языки первого поколения (1GL)

• Машинный код (команды x86, ARM, MIPS, GPU)

Языки второго поколения (2GL)

• Языки ассемблера (fasm, gas, PTX)

Языки третьего поколения (3GL)

• ЯВУ (COBOL, Java, C/C++, BASIC, ADA, C#, Python, Perl, PHP, Algol)

Языки четвертого поколения (4GL)

• ПОЯ, DSL (SQL, 1С, ABAP, XUL, CLIPPER, Oracle Reports, а также LISP, Forth)

Языки пятого поколения (5GL)

• Логическое программирование, естественный язык, визуальное программирование (Prolog, РЕФАЛ, OPS5, Mercury, Yahoo! Pipes)

Компиляция/интерпретация Исходные тексты, исполняемый код, ассемблер

Интерпретаторы, компиляторы, линковщики, байт-код

12

Компиляция/интерпретация (2)

13

Жизненный цикл разработки программного обеспечения (SDLC)

14

Жизненный цикл разработки систем Концептуальное описание

•Conceptual Definition

Определение функциональных требований

•Functional requirements determination

Разработка спецификаций контролей

•Control Specifications Development

Рецензирование архитектуры

•Design review

Общий обзор программного кода

•Code review walk-through

Тестирование и приемка системы

•System test review

Поддержка и управление изменениями

•Maintenance and Change Management

Каскадная модель разработки (Waterfall Development Model)

16

Оригинальная

Unmodified

Модифицированная

Modified

Модель «Сашими»

Sashimi Model

Верификация/валидация

17

Спиральная модель (Spiral Model)

Связанные концепции Итеративная разработка (Iterative development) Прототипирование (Prototyping) Подходы к разработке (Top-Down, Bottom-Up) RAD

GUI builders, CASE, DBMS, code generators

Структурное программирование Модули, слои

Стандарты SDLC NIST SP 800-14 DOJ SDLC (10 шагов)

18

Гибкие модели (Agile Software Development)

Scrum

Agile Unified Process (AUP)

Dynamic Systems Development Model (DSDM)

Extreme Programming (XP)

Crystal Clear

Feature driven development

Adaptive software development

Pragmatic Programming

19

Парадигмы программирования Императивное программирование (C/C++, Java, Perl, JavaScript)

Процедурное программирование (ALGOL, C, BASIC)

Структурное программирование (ALGOL, PASCAL) Объектно-ориентированное программирование (C++, Smalltalk, Eiffel, Object Pascal, C#, io, OCaml)

Аспектно-ориентированное (Cobol, Java, Objective-C, C#, Ada)

Декларативное программирование (HTML, XSLT, PostScript, Haskell) Функциональное программирование (Common Lisp, Scheme, F#, JavaScript, Ocaml) Логическое программирование (Prolog, РЕФАЛ, Mercury)

Метапрограммирование (C, C++, MacroML) Компонентно-ориентированное программирование (EJB, COM+, Corba) Событийно-ориентированное программирование (HDL, Objective-C, C++, JavaScript)

20

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

Надежность (программного средства) – совокупность свойств, характеризующая способность программного средства сохранять заданный уровень пригодности в заданных условиях в течение заданного интервала времени . ГОСТ 28806-90 Качество программных средств. Термины и определения.

21

Качество и надежность ПО (2) Качество программного обеспечения (software quality) – весь объем признаков и характеристик программной продукции, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.

Характеристика качества. Надежность (Reliability) – набор атрибутов, относящихся к способности программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени.

ГОСТ Р ИСО/МЭК 9126-93 Оценка программной продукции

22

Дефекты безопасности программного обеспечения

Дефект – каждое отдельное несоответствие продукции установленным требованиям

ГОСТ 27.002-89 Надежность в технике основные понятия. Термины и определения.

Дефект безопасности ПО – ошибка в программном продукте, вследствие которой потенциально возможно нарушение целостности, доступности или конфиденциальности при функционировании продукта.

23

Дефекты, изъяны и уязвимости программного обеспечения

Дефект (Defect)

Функциональность (поведение)

Отказ работы

Масштабируемость

Сопровождение

Архитектура

Правила кодирования

Дефект безопасности

Изъян (Weakness по CWE)

Уязвимость (Vulnerability) 24

Стоимость устранения дефектов

25

Недекларированные возможности

26

Недекларированные возможности (программного обеспечения) – функциональные возможности программного обеспечения, не описанные в документации.

ГОСТ Р 50.1.053—2005. Основные термины и определения в области технической защиты информации.

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

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

Уязвимость информационной системы

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

ГОСТ Р 50922-2006. Защита информации. Основные термины и определения Унифицированные системы документации.

27

Информационная система

Взаимосвязь понятий

28

Программное (компонент ИС)

Недекларированные возможности ПО

Дефекты ПО

Компонент ИС

Компонент ИС

Внешний мир

Уязвимости ИС

Безопасность ПО в жизненном цикле программных систем

29

Анализ требований к ПО

Дизайн архитектуры ПО

Написание кода ПО

Тестирование ПО Развертывание

ПО Эксплуатация ПО

Дефект ПО Уязвимость ПО Угроза

безопасности ПО

Инцидент с безопасностью

ИС

Методы обеспечения безопасности ПО в SDLC

30

Анализ требований и вариантов использования

Варианты злоупотреблений

Требования по безопасности

Анализ рисков

Проектирование Анализ рисков

Внешний аудит требований и архитектуры

Формирование тест-планов

Разработка тестов на основе рисков по

безопасности

Написание кода Статический анализ кода

Рецензии (инспекции) кода

Выполнение тестов

Динамический анализ кода

Анализ рисков

Рецензии (инспекции) кода

Внедрение продукта

Анализ отзывов

Тестирование на проникновение

Патчи Ограничение на использование

31

Контакты докладчика:

Вопросы?

УГРОЗЫ БЕЗОПАСНОСТИ ПО

Примеры, подходы к классификации и стандартизации

Основные тезисы раздела

Что присутствует в компонентах ИС?

Дефекты безопасности/НДВ

Программные закладки

Скрытые каналы

Вредоносное ПО

Чем грозит?

Угроза реализация той или иной уязвимости ИС

Программные закладки Программная закладка: внесенные в программное обеспечение

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

ГОСТ Р 51275-99 Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения.

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

ГОСТ Р 50.1.053—2005. Основные термины и определения в области технической защиты информации.

34

Программные закладки (2) Программные закладки – преднамеренно внесенные в ПО

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

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

35

Распространенные виды программных закладок

лазейка (trapdoor, backdoor)

бомба

логическая бомба (logic bomb)

временнАя бомба (time bomb)

пасхальное яйцо (easter egg)

36

Скрытые каналы

Скрытый канал (covert channel) – непредусмотренный разработчиком системы информационных технологий и автоматизированных систем коммуникационный канал, который может быть применен для нарушения политики безопасности.

ГОСТ Р 53113.1-2008. Защита информационных технологий и автоматизированных систем от угроз информационной безопасности реализуемых с использованием скрытых каналов. Часть 1. Общие положения.

37

Виды скрытых каналов Скрытые каналы по памяти (storage channel)

Скрытые каналы по времени (timing channel) Скрытые статистические каналы по ГОСТ Р 53113.1-2008

Примеры реализаций скрытых каналов : сохранение информации в области между разделами на жестком диске

нестандартного использование времени отклика в сетевом протоколе ICMP

стеганографическая запись в графический файл стандартного отчёта, генерируемого программой

38

Вредоносное ПО (malware) Программный вирус: исполняемый программный код или интерпретируемый набор инструкций, обладающий свойством несанкционированного распространения и самовоспроизведения (репликации). В процессе распространения вирусные субъекты могут себя модифицировать. Некоторые программные вирусы могут изменять, копировать или удалять программы или данные..

ГОСТ Р 51275-99 Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения.

39

Классификация вредоносного ПО По назначению

Вирусы-инфекторы (произвольных файлов, master boot record, системных модулей)

Инъекторы сервисов (Service injection viruses)

Макровирусы (Macro virus) Скрипт-вирусы (Script viruses) E-mail Spyware Черви (Worms) Трояны (Trojan horses) Троян удаленного доступа (Remote Access Trojans) Сети агентов(ботнеты)

По механизмам маскировки Многосекционные (multipartite) Стелс-вирусы (stealth viruses) Полиморфные вирусы (Polymorphic viruses) Метаморфные вирусы (Metamorphic viruses) Шифрованные вирусы (Encrypted viruses) 40

Классификация вредоносного ПО (2) По активации

Бомба (логическая/временная)

По действию Порча данных (data diddling)

Воровство (Theft)

Обман (Hoax)

Шутки (Pranks)

Классификации Kaspersky Lab http://goo.gl/Razkj

Symantec Corporation http://goo.gl/pBCLC

Mitre MAEC https://maec.mitre.org/ (на примере Conficker.B)

41

http://goo.gl/Razkj

http://goo.gl/pBCLC

http://goo.gl/pBCLC

https://maec.mitre.org/

https://maec.mitre.org/

Реестры и классификации уязвимостей

42

Современные реестры MITRE Common Vulnerabilities and Exposures (CVE) NVD (National Vulnerability Database)

Национальная база уязвимостей США

OSVDB (Open Security Vulnerability Database) База уязвимостей открытого доступа

US-CERT Vulnerability Notes Database

Бюллетени вендоров Microsoft Bulletin ID Secunia ID VUPEN ID

Устаревшие классификации Бишоп-Бэйли. Системные и сетевые уязвимости Unix-систем

Классификации угроз и методов атак

Реестры актуальных угроз и дефектов

OWASP Top Ten

10 самых больших угроз для веб-приложений

2011 CWE/SANS Top 25 Most Dangerous Software Errors

Классификации атак

MITRE Common Attack Pattern Enumeration and Classification (CAPEC)

Описание атак

Microsoft STRIDE

43

Десятка OWASP (OWASP Top Ten) A1 – Межсайтовый скриптинг (Cross Site Scripting, XSS)

A2 – Изъяны при внедрении (Injection Flaws)

A3 – Злонамеренный запуск файла (Malicious File Execution)

A4 – Небезопасная прямая ссылка на объект (Insecure Direct Object Reference)

A5 – Подделка HTTP-запросов (Cross Site Request Forgery, CSRF)

A6 – Утечка информации и неправильная обработка ошибок (Information Leakage and Improper Error Handling)

A7 – Нарушенная аутентификация и управление сессиями (Broken Authentication and Session Management)

A8 – Небезопасное криптографическое хранилище (Insecure Cryptographic Storage)

A9 – Небезопасные коммуникации (Insecure Communications)

A10 – Ошибка в запрете доступа к URL (Failure to Restrict URL Access) 44

Стандартизация процессов безопасности ПО

OWASP CLASP (Complex Lightweight Application Security Process)

Microsoft Security Development Life Cycle

Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use

45

Оценка критичности уязвимостей и дефектов и качества работы средств анализа

CVSS (Common Vulnerability Scoring System)

CCSS (Common Configuration Scoring System)

NIST IR7517 The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities

SAMATE (Software Assurance Metrics And Tool Evaluation)

46

Классификации дефектов (defects), изъянов (weaknesses)

Дефекты на этапе создания Fortify Seven Pernicious Kingdoms

7 разрушительных "царств" компании Fortify

MITRE Common Weaknesses Enumeration (CWE) Общая классификация изъянов ПО

DoD Software Fault Patterns Дефекты на этапе эксплуатации

MITRE Common Configuration Enumeration (CCE) DPE - Default Password Enumeration

Устаревшие RISOS и PA Таксономия Ландвера Таксономия Аслама Таксономия Макгоу Таксономия Вебера PLOVER 47

7 разрушительных царств (7 Pernicious Kingdoms)

1. Валидация ввода и представление

2. Эксплуатация API

3. Механизмы безопасности

4. Время и Состояние

5. Обработка ошибок

6. Качество кода

7. Инкапсуляция

*Окружение

48

Уязвимости и изъяны

CVE (Common Vulnerability Enumeration)

CWE - Common Weakness Enumeration

49

50

Common Weakness Enumeration http://cwe.mitre.org

метаязык для описания всех недостатков ПО, схем защиты и атаки

Структура типа «дерево» Категории

Составные элементы

Элементы

Сгруппировано по «отображениям» Research View

Development View

C/C++ Developer View

Java Developer View

… 51

Классификация Mitre CWE вид для разработки

Сравнение ведущих классификаций уязвимостей и дефектов ПО

53

Название классификации Описание Достоинства Недостатки

Fortify Taxonomy семь разрушительных царств.

Классификация недостатков ПО на основе анализа исходных текстов

Поддержка одного из ведущих разработчиков средств для аудита кода. Простая для понимания структура. Существует достаточно давно.

Нет разграничения по языкам программирования. Классификация чересчур упрощена и не отвечает в полной мере требованиям систематизации значительного количества уязвимостей.

OWASP Top 10

Десятка наиболее актуальных уязвимостей веб-приложений за последний год.

Актуальность, удобство использования.

Всего десять уязвимостей. Учитываются только уязвимости веб-приложений.

OWASP CLASP

Методы введения безопасности в разработку приложений. Проект содержит теоретическую базу, в частности, лексикон уязвимостей.

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

Рассматриваются только веб-приложения, в классификации не учитываются ошибки конфигурации.

CWE

Система классификации изъянов ПО. Учитывает более ранние аналогичные разработки.

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

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

Разработка отечественного стандарта классификации уязвимостей (в рамках ТК 362)

ГОСТ Р «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем»

http://goo.gl/jgqf4

54

Текущее состояние разработки ГОСТа

Классы:

Уязвимости кода,

Группы: Уязвимости в микропрограммах, ПЗУ,

Уязвимости ОС и ПО.

Уязвимости конфигурации.

Группы: Технических средств ИС,

Общесистемного ПО ИС,

Специального и прикладного ПО ИС.

Типы уязвимостей определяются дефектами кода или конфигурации и связаны с возможными атаками

Фрагмент перечня уязвимостей в соответствии с их классификацией по стандарту

Класс Группа Вид Тип

Класс 1 – уязвимости кода

Группа 1.1 – уязвимости в микропрограммах, ПЗУ

Тип 1.1.1.1 – уязвимости, связанные с ошибками формата данных,

приводящие к переполнению буфера

Тип 1.1.1.2 – уязвимости, связанные с ошибками структуры и действий

Тип 1.1.1.3 – уязвимости, связанные с ошибками специальных элементов

(символов или зарезервированных слов)

Тип 1.1.1.4 – уязвимости, связанные с ошибками путей перехода и

источников

Тип 1.1.1.5 – уязвимости, связанные с ошибками очищения и сравнения

Тип 1.1.1.6 – уязвимости, связанные с ошибками процессов и потоков

Тип 1.1.1.7 – уязвимости, связанные с ошибками обработчика


Класс 2 – уязвимости конфигурации

Группа 2.1 – уязвимости конфигурации технических средств ИС

Вид 2.1.1 – уязвимости в конфигурации микропрограмм, ПЗУ

Тип 2.1.1.1 – уязвимости, связанные с функциями, процедурами,

изменение параметров которых определенным образом позволяет

использовать их для несанкционированного доступа без обнаружения

таких изменений операционной системой

Тип 2.1.1.2 – уязвимости, связанные с наличием фрагментов кода

программ, введенных разработчиком, позволяющих обходить

процедуры идентификации, аутентификации, проверки целостности и

др.

Тип 2.1.1.3 – уязвимости, связанные с наличием ошибок в программах (в

объявлении переменных, функций и процедур, в кодах программ),

которые при определенных условиях приводят к сбоям, в том числе, к

сбоям функционирования средств и систем защиты информации

Вид 2.1.2 – уязвимости конфигурации интерфейсов управления




таких изменений операционной системой 57


Вид 2.1.3 – уязвимости конфигурации контроллеров управления




таких изменений операционной системой

Тип 2.1.3.2 – уязвимости, связанные с наличием фрагментов кода

программ, введенных разработчиком, позволяющих обходить

процедуры идентификации, аутентификации, проверки целостности и

др.

Тип 2.1.3.3 – уязвимости, связанные с наличием ошибок в программах (в

объявлении переменных, функций и процедур, в кодах программ),

которые при определенных условиях приводят к сбоям, в том числе, к

сбоям функционирования средств и систем защиты информации

Вид 2.1.4 – уязвимости ПО организации взаимодействия с ОПО

Группа 2.2 – уязвимости конфигурации общесистемного ПО

Вид 2.2.1 – уязвимости конфигурации операционной системы

Тип 2.2.1.1 – уязвимости в средствах ОС, обеспечивающих выполнение

функций управления процессами

Тип 2.2.1.2 – уязвимости в средствах ОС, обеспечивающих выполнение

функций управления памятью 58

Общее видение типов уязвимостей и дефектов

59

Предложение по отображению элементов отечественных стандартов на международные системы

60

Предложение по стандарту классификации:

61

Тип 1 - Уязвимости вызванные дефектами кода и проектирования системы

Класс 1 - Обработка и представление данных

Класс 2 - Внутренняя структура и зависимости

Класс 3 - Обработка событий и состояний

Класс 4 - Ресурсы и внутренние механизмы системы

Класс 5 - Внедренные объекты (закладки)

Класс 6 - Качество проектирования, реализации, документирования

Тип 2 - Уязвимости вызванные дефектами конфигурирования и управления системой, а

также её окружением

Класс 7 - Конфигурация

Класс 8 - Окружение

Обсуждение и развитие стандарта

Предварительная версия документа и обсуждение:

http://s3r.ru/it-sec-std/

Рабочие материалы и результаты:

https://github.com/it-sec-std/

62














63


Вопросы?

АНАЛИЗ БЕЗОПАСНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Материалы, методы, процедуры

64

Уязвимость информационной системы

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

ГОСТ Р 50922-2006. Защита информации. Основные термины и определения Унифицированные системы документации.

65

Типовые уязвимости. Переполнение буфера

Переполнения буфера (buffer overrun) представляют собой наиболее известный и распространённый класс уязвимостей программного обеспечения. Первые попытки применения переполнения буфера относятся к 60-м годам прошлого века. Первая атака с применением данной уязвимости использовалась в вирусе-черве Морриса в 1988 году. С тех пор их число увеличивается с каждым годом.

66

Подготовка кода, который будетвыполняться в контексте

привилегированной программы

Изменение последовательностивыполнения программы с передачейуправления подготовленному коду

Типовые уязвимости. Переполнение буфера

Схема атаки «Срыв стека»

67

Методы борьбы с переполнениями буфера

корректировка исходных текстов

использование неисполняемых буферов

использование динамических систем проверки выхода за границы

применение статических проверок выхода за границы

68

Использование систем квази-постоянства (Quasi-invariant)

PointGuard. StackGuard

69

Ошибки, связанные с форматной строкой

#include <stdio.h>

int main(int argc, char* argv[])

{

if(argc > 1)

printf(argv[1]);

return 0;

}

70

Запуск на выполнение:

E:\prog\format_bug.exe “%x %x”

12ffc0 4011e5

71

Валидация пользовательского ввода

Фильтрация пользователского ввода

72

Борьба с ошибками форматной строки

Подходы к анализу безопасности ПО

73

Аудит безопасности ПО

(application security audit)

Структурное тестирование

(white-box testing) Пример: РД НДВ

Статический анализ (static analysis)

Анализ архитектуры системы (design review)

Рецензирование, инспекция кода (code

review, code inspection)

Поиск потенциально опасных конструкций с

помощью анализаторов кода

Динамический анализ (dynamic analysis)

Taint-mode analysis

Контроль выполнения функциональных

объектов (РД) Функциональное

тестирование (black-box testing)

Пример: РД НСД, РДВ

Тестирование работы механизмов

безопасности

Фаззинг (fuzzing testing)

Требования проведения структурного тестирования

РД по НДВ Гостехкомиссии (1999) 3.3.3 Статический анализ исходных текстов программ 3.3.4 Динамический анализ исходных текстов программ

ГОСТ Р МЭК 61508-7-2007 (IEC 61508) Функциональная безопасность (Safe Integrity Level)

B .6.4 Статический анализ Анализ управления потоком, интерфейсов, потока данных

PCI DSS Requirement 6.6 “Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes”

PA DSS 5.1.7 Review of payment application code prior to release ... -

NISTIR 4909: Software Quality Assurance 4.6.2.Source Code Documentation : B.2.3.Source Code Review

Статический анализ объекты исследования

исходные тексты ПО

исполняемый код ПО

материалы производства ПО (отладочная информация, логи сборки, вывод внешних средств)

параметры программного проекта (проектные файлы, манифесты)

особенности подхода не требует запуска ПО

ограниченный набор проверяемых свойств ПО (проблема «останова», теорема Райса)

сложность анализа нелинейно возрастает с ростом объема анализируемого ПО

75

Области применения статического анализа

компиляция, интерпретация

исследование архитектуры (CASE-средства) и алгоритмов программы, автодокументирование

форматирование кода

вычисление программных метрик, общая оценка качества

оптимизация, распараллеливание, профилировка

преобразования (трансформации) программ, метапрограммирование

обфускация/деобфускация программ

обнаружение дефектов

76

Направления статического анализа

77

1.1 Декомпозиция и анализ структуры ПО В рамках анализа архитектуры системы (design review)

В рамках рецензирования, инспекции кода (code review)

1.2 Проверка стиля программирования, подсчет метрик

Рецензирование, инспекции кода

1.3 Проверка свойств (ограничений) программы на моделях

Поиск потенциальных дефектов ПО с помощью анализаторов кода

1.4 Поиск багов/дефектов по образцу (cигнатурный анализ)

Поиск потенциальных дефектов ПО с помощью анализаторов кода

78

Выполняемые проверки Уровень контроля

4 3 2 1

1.Контроль состава и содержания документации + + + +

2.Контроль исходного состояния + = = =

3.1.Контроль отсутствия избыточности исходных текстов + + + =

3.2.Контроль соответствия исходных текстов загрузочному коду + = = +

3.3.Контроль связей функциональных объектов по управлению - + = =

3.4.Контроль связей функциональных объектов по информации - + = =

3.5.Контроль информационных объектов - + = +

3.6.Контроль наличия заданных конструкций - - + +

3.7.Формирование перечня маршрутов выполнения ФО - + + =

3.8.Анализ критических маршрутов выполнения ФО - - + =

3.9.Анализ алгоритма работы на основе блок-схем, построенных по исходным текстам контролируемого ПО

- - + =

4.1.Контроль выполнения функциональных объектов - + + =

4.2.Сопоставление фактических маршрутов и маршрутов, построенных в процессе проведения статического анализа

- + + =

http://www.fstec.ru/_docs/doc_3_3_010.htm

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

(Гостехкомиссия России, 1999).

http://www.fstec.ru/_docs/doc_3_3_010.htm

Этапы построения модели программы

1) Исходный текст программы

2) Лексический анализ

79

Этапы построения модели программы 3) Синтаксический анализ. Дерево разбора

80

Этапы построения модели программы

4) Абстрактное дерево разбора (AST)

81

Граф потока управления (CFG) и граф зависимостей по данным (DFG)

82

1 int m(int x, int y) {

2 while (x > 10) {

3 x -= 10; // x = x - 10;

4 if (x == 10) {

5 break;

6 }

7 }

8 x = square(x);

9 if (y < 20 && x%2 == 0) {

10 y += 20; // y = y + 20;

11 }

12 else {

13 y -= 20; // y = y - 20; 14 }

15 return 2*x + y;

16 }

Однократное статическое присваивание (SSA)

83

Абстрактный семантический граф

84

Сигнатурный анализ Происхождение термина «сигнатурный анализ» (signature analysis)

диагностика электронных схем путем сопоставления входного и выходного сигнала

метод анализа подчерка в графологии

Сигнатурный анализ программного кода

Поиск программных дефектов в исходных текстах или исполняемых модулях путем сопоставления фрагментов кода или его представления с образцами из базы шаблонов (сигнатур)

85

Требования руководящего документа Для второго уровня контроля необходимо выполнять синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций.

Для первого уровня контроля необходимо выполнять семантический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций.

86

87

Выполняемые проверки Уровень контроля

4 3 2 1

1.Контроль состава и содержания документации + + + +

2.Контроль исходного состояния + = = =

3.1.Контроль отсутствия избыточности исходных текстов + + + =

3.2.Контроль соответствия исходных текстов загрузочному коду + = = +

3.3.Контроль связей функциональных объектов по управлению - + = =

3.4.Контроль связей функциональных объектов по информации - + = =

3.5.Контроль информационных объектов - + = +

3.6.Контроль наличия заданных конструкций - - + +

3.7.Формирование перечня маршрутов выполнения ФО - + + =

3.8.Анализ критических маршрутов выполнения ФО - - + =

3.9.Анализ алгоритма работы на основе блок-схем, построенных по исходным текстам контролируемого ПО

- - + =

4.1.Контроль выполнения функциональных объектов - + + =

4.2.Сопоставление фактических маршрутов и маршрутов, построенных в процессе проведения статического анализа

- + + =

Нормативная база применения метода сигнатурного анализа РД. Защита от НСД к информации. ПО СЗИ. Классификация по уровню контроля отсутствия недекларированных

возможностей (Гостехкомиссия России, 1999).

Процесс работы статического анализатора кода

Предварительный обзор материалов

проекта и формирование пакетов задач

Препроцессинг Лексический анализ

Синтаксический анализ

Семантический анализ

Сигнатурный анализ

Построение отчетов и последующие преобразования •Отчеты по структуре

•Отчеты по сигнатурному анализу

•Экспорт моделей (e.g. UML)

•Преобразование (e.g. XMLVM)

Динамический анализ ПО Динамический анализ ПО (англ. Dynamic program analysis) — анализ программного обеспечения, выполняемый при помощи выполнения программ на реальном или виртуальном процессоре. Dowson, M. (March 1997). "The Ariane 5 Software Failure". Software Engineering Notes 22 Динамический анализ исходных текстов программ – совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на идентификации фактических маршрутов выполнения функциональных объектов с последующим сопоставлением маршрутам, построенным в процессе проведения статического анализа. Руководящий документ Защита от несанкционированного доступа к информации Часть 1. Программное обеспечение средств защиты информации Классификация по уровню контроля отсутствия недекларированных возможностей.

Методы проведения динамического анализа Внедрение датчиков в исходные тексты Внедрение датчиков в исполняемый код (до или после загрузки кода в ОЗУ) Установка точек останова (breakpoints) или перехватчиков вызовов (hooks)

Степень покрытия, метрики структурные и функциональные критерии Взаимодействие статического и динамического анализа (Tainted mode)

89

Понятия CWE Продукт (PRODUCT)

Функ. возможность (FEATURE)

Ресурс (RESOURCE)

Поведение (BEHAVIOR)

Манипуляции (MANIPULATIONS)

Свойства (PROPERTIES)

Деятели (ACTORS)

Роли (ROLES)

Директивы (DIRECTIVES)

Каналы (CHANNELS)

Топология (TOPOLOGY)

Сфера контроля (CONTROL SPHERE)

Политика безопасности (SECURITY POLICY)

Механизм защиты (PROTECTION MECHANISM)

Атака, Атакующий (ATTACK, ATTACKER)

Последствие (CONSEQUENCE)

Изъян (WEAKNESS)

Уязвимость (VULNERABILITY)

Цепь (CHAIN)

Композиция (COMPOSITE)

Слои (LAYERS)

Отказы защитного механизма, ОЗМ (Protection Mechanism Failures, PMF)

Санация (SANITIZATION)

90

Понятия CWE(1)

Продукт (PRODUCT)

Функ. возможность (FEATURE)

Ресурс (RESOURCE)

Поведение (BEHAVIOR)

Манипуляции (MANIPULATIONS) Изменение ресурса деятелем

Свойства (PROPERTIES) Связанный с безопасностью атрибут данных, поведений, кода, который в определенных случаях меняется во время работы продукта.

Деятели (ACTORS) Типы деятелей: Пользователь, Сервис, Посторонний(Outsider), Информатор (Consultant), Наблюдатель (Monitor/Observer)

91

Характеристики свойств Корректность (VALIDITY)

GET index.html (no version) non-existent username "<SCRIPT" without closing tag inconsistent length/payload packet with length field inconsistent with actual length "US3R" token when only A-Z characters are expected

Эквивалентность (EQUIVALENCE) "../.." == "%2e%2e/%2e%2e" (in URIs) "filename.txt" == "FileName.txt." (in Windows) $_GET['x'] == $_REQUEST['x'] (in PHP) step equivalence: (A->B->C) == (A->C) "/tmp/abc" and a symlink to /tmp/abc "localhost" and "localhost.example.com" (fully qualified domain name) 127.0.0.1 and "hostname.example.com" (IP address and its domain name)

Изменчивость (MUTABILITY)

Доступность (ACCESSIBILITY)

Доверенность(TRUSTABILITY)

Уникальность (UNIQUENESS)

Предсказуемость (PREDICTABILITY)

92

Измерения корректности (dimensions of validity)

Оригинал: GET index.html HTTP/1.1

Лексическая некорректность:

G#T index.html HTTP/1.a

Синтаксическая некорректность:

Доменная некорректность

GITCHY index.html ABCD/1.1

Относительная некорректность

POST запрос с полем Content-Length, несовпадающим с реальным размером запроса

93

Понятия CWE(2) Роли (ROLES)

Жертва, атакующий, свидетель, сообщник, проводник

Директивы (DIRECTIVES)

запрос, команда, сигнал и др.

Каналы (CHANNELS)

Топология (TOPOLOGY) SQL-инъекция: пользователь (роль: атакующий) отправляет сфабрикованный запрос к веб-приложению (роль: проводник) по одному каналу (TCP порт 80), а веб-сервер

отправляет SQL-запрос по другому каналу к серверу БД (роль: жертва)

Сфера контроля (CONTROL SPHERE)

94


Цепь (CHAIN) Пример: целочисленное переполнение (CWE-190) при вычислении объема выделяемой памяти, что приводит к меньшему объему буфера и его переполнению (CWE-120)

Композиция (COMPOSITE) Атака «следование символическим ссылкам» (CWE-61) требует одновременно:

предсказуемось имен файлов (CWE-340)

неправильные права доступа (CWE-275)

гонка условий (CWE-362)

95


Политика безопасности (SECURITY POLICY)

Механизм защиты (PROTECTION MECHANISM)

Атака, Атакующий (ATTACK, ATTACKER)

Последствие (CONSEQUENCE)

Изъян (WEAKNESS)

Уязвимость (VULNERABILITY)

96

Понятия CWE(5) Слои (LAYERS)

Слой Системы (память, диски, файлы, процессор; поведения: систем вызовы, запуск процессов)

Слой Кода (переменные, структуры, сокеты, дескрипторы, строки; поведения: присваивания,вызовы функций, обработка исключений)

Слой Приложения ( cookies, сообщения, профили, базы данных; поведения: хранение данных, аутентификация, отправка сообщений).

97

Пример использования слоёв в анализе кода

98

/* ignore group ID for this example */

old_id = getuid();

setuid(0);

AttachToPrivilegedDevice();

/* CWE-252 [code layer], CWE-273

[application layer] */

setuid(old_id);

filename = GetUntrustedFilename();

WriteToFile(filename, "Hello world");

На уровне кода (CWE-252) отсутствие проверок возвращаемых значений.

На уровне приложений (CWE-273) – недостаточная проверка оставленных привилегий

Понятия CWE(5) Отказы защитного механизма, ОЗМ (Protection Mechanism Failures, PMF)

Отсутствие реализации

Некорректная реализация

Санация (SANITIZATION), виды:

Верификация (VERIFICATION)

Косвенный выбор (INDIRECT SELECTION)

Очистка (CLEANSING)

Приведение по конвертированию (ENFORCEMENT BY CONVERSION)

Использование «песочницы» (sandboxing) Пример: web-application firewall

99

Механизмы используемые в санации

Приведение (enforcement)

Фильтрация

Abdk*fff? -> Abdkfff

Выдача сообщений об ошибке

Стандартизация (canonicalization)

../xyz -> /home/xyz

100

Пример кода (comments.cgi)

Какие есть изъяны в этом коде?

101

1 printf("<title>Blissfully Ignorant,

Inc.</title>");

2 ftype = Get_Query_Param("MessageType");

3 strcpy(fname, "/home/cwe/");

4 strcat(fname, ftype);

5 strcat(fname, ".dat");

6 handle = fopen(fname, "r");

7 while(fgets(line, 512, handle)) {

8 if (strncmp(line,"<script>",8)) {

9 printf(line); } }

10 return(200);

Размещение на сайте: http://foo.com/comments.cgi?MessageType=3

102

CWE-120: Классическое переполнение буфера (Classic Buffer Overflow)


Inc.</title>");








9 printf(line); } }

10 return(200);

Пример кода

CWE-23: Обход относительного пути (Relative Path Traversal)

103


Inc.</title>");








9 printf(line); } }

10 return(200);


104


CWE-79: Отказ в сохранении структуры веб-страницы. Межсайтовый скриптинг. Failure to Preserve Web Page Structure (XSS)


Inc.</title>");








9 printf(line); } }

10 return(200);

105


CWE-134: Неконтролируемая форматная строка. Uncontrolled Format String


Inc.</title>");








9 printf(line); } }

10 return(200);

106


CWE-476: Разыменование нулевого указателя. NULL Pointer Dereference (6->7)


Inc.</title>");








9 printf(line); } }

10 return(200);

107


CWE-20: Неверная проверка входных значений Improper Input Validation (2 & 8)


Inc.</title>");








9 printf(line); } }

10 return(200);

108


CWE-116: Неправильное кодирование или экранирование вывода Improper Encoding or Escaping of Output (7->9)


Inc.</title>");








9 printf(line); } }

10 return(200);

109


CWE-73: Внешний контроль имени файла или всего пути External Control of File Name or Path (2->4->6)


Inc.</title>");








9 printf(line); } }

10 return(200);

110


CWE-404: Неправильное освобождение или отключение ресурса. Improper Resource Shutdown or Release (6->10)


Inc.</title>");








9 printf(line); } }

10 return(200);

111


CWE-252: Отсутствие проверки возвращаемого значения. Unchecked Return Value (2->4->6)


Inc.</title>");








9 printf(line); } }

10 return(200);

Инструментарий Статический анализ (static analysis)

Open-source OWASP SWAAT http://goo.gl/LO5C8

RIPS http://goo.gl/ZVPs9

FindBugs http://goo.gl/b057

Flawfinder http://goo.gl/mCViy

Коммерческие IBM AppScan, HP Fortify, VeraCode Static http://goo.gl/BwtOr

АК-ВС http://goo.gl/SMmOJ

PVS-Studio http://goo.gl/Btg6y

Инспекции кода (code review) Gerrit http://goo.gl/ES2xp

Rietvield http://goo.gl/P3ri

Groogle http://goo.gl/hrxKF 112

http://goo.gl/LO5C8

http://goo.gl/LO5C8

http://goo.gl/ZVPs9

http://goo.gl/ZVPs9

http://goo.gl/b057

http://goo.gl/b057

http://goo.gl/mCViy

http://goo.gl/mCViy

http://goo.gl/BwtOr

http://goo.gl/BwtOr

http://goo.gl/BwtOr

http://goo.gl/SMmOJ

http://goo.gl/SMmOJ

http://goo.gl/Btg6y

http://goo.gl/Btg6y

http://goo.gl/ES2xp

http://goo.gl/ES2xp

http://goo.gl/P3ri

http://goo.gl/P3ri

http://goo.gl/hrxKF

http://goo.gl/hrxKF

Компонентный анализ ПО

особенности современного ПО

разделено на компоненты (подкомпоненты)

четко заданные интерфейсы

разные уровни доверия и требования к безопасности компонентов

анализ архитектуры

сокращение расходов на рецензирование и тестирование

парадигмы программирования. структуры.

113

Виды аудита безопасности программных систем

Этап жизненного цикла Анализа архитектуры системы (design review)

Инспекции кода (code review)

Время проведения Тематические инспекции

Регулярные инспекции «Парное» программирование

Pre-commit review

Post-commit review

Стандарты и руководства OWASP Code Review Guide

OWASP Application Security Verification Standard (ASVS)

114

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

От верификации до системы контроля качества.

Метрическое пространство

Метрика - числовое значение, инструмент оценки показателей системы или ее отдельных компонентов

115

Повышение эффективности существующих руководящих документов.

С момента введение в действие РД по НДВ прошло около десяти лет, время не стоит на месте.

Каких проверок нам не хватает?

Антивирусная проверка

Проверка лицензионной чистоты

Контроль платформы

Контроль зависимостей

Проверка всех этапов эксплуатации и развертывания ПО

Компоненты и структура связей ПО

Контроль исходного состояния. Проблемы существующего ПО в этой области.

116

Литература: монографии Методы оценки несоответствия средств защиты информации / Марков А.С.,Цирлов В.Л.,Барабанов А. В. - Изд-во "Радио и связь", 2012. — 192 с.

CISSP Study Guide 6th Edition / J.M. Stewart, M. Chapple, D. Gibson, 2012.

Official (ISC)2 Guide to the CISSP CBK, 3rd Edition / (ISC)2 Press, 2012.

Основы информационной безопасности: Краткий курс / В.Л. Цирлов. – Изд-во «Феникс», 2008. – 172 с.

117

Литература: публикации Фадин А.А. Рекомендации по контролю наличия заданных конструкций. // Методы оценки несоответствия средств защиты информации. / под.ред.А.С.Маркова. М.: Радио и связь. 2012. C.180-185. ISBN 5-89776-0152.

Барабанов А.В., Марков А.С., Фадин А.А. Сертификация программ без исходных текстов // Открытые системы. СУБД. 2011. № 4. С.38-41.

Марков А.С., Барабанов А.В., Фадин А.А. Выявление недекларированных возможностей в декомпилированных текстах программного обеспечения.// Известия Института инженерной физики. 2010. Т. 4. № 18. С. 24-26.

Марков А.С., Миронов С.В., Цирлов В.Л. Выявление уязвимостей в программном коде. // Открытые системы. СУБД. 2005. № 12. С.64-69.

118

Литература: тезисы и выступления конференций

Марков А.С., Фадин А.А. К вопросу о выявлении дефектов безопасности методом статического сигнатурного анализа // Материалы XII Международной конференции "Информационная безопасность" - Таганрог: Изд-во ТРТУ, 2012.

Веряев А.С., Фадин А.А., Цирлов В.Л. К вопросу об аудите безопасности WI-FI сетей // Материалы XII Международной конференции "Информационная безопасность" - Таганрог: Изд-во ТРТУ, 2012.

Обзор таксономий уязвимостей программного обеспечения / Марков А.С., Фадин А.А. – II Международная конференция «ИТ-Стандарт 2011», 2011.

Подход к решению проблемы аудита информационной безопасности / Барабанов А.В. - Конференция "Студенческая научная весна 2011», МГТУ им.Н.Э.Баумана, 2011.

Средства и технологии анализа защищенности / А.С.Марков, А.А.Фадин, В.Л.Цирлов // XХ Конференции "Информатизация и информационная безопасность правоохранительных органов». – М.: Академия управления МВД России, 2011.

Специальные технологии анализа защищенности / А.С.Марков, А.А.Фадин // Межведомственная научная Юбилейная конференция «Современные тенденции развития теории и практики управления в системах специального назначения», ФГУП «Концерн «Системпром», 2011

119

120


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

Вопросы?

Technology

Аудит безопасности программного кода: Подходы, стандарты, технологии выявления дефектов безопасности