Download to read offline
Uploaded byAlexey Kachalin
Безопасная разработка (СТАЧКА 2015)
Документ рассматривает важность безопасной разработки программного обеспечения и внедрения практик по обеспечению безопасности на всех этапах жизненного цикла разработки. Обсуждаются различные риски, связанные с уязвимостями технологий и методы анализа безопасности, включая использование инструментов тестирования и реагирования. Представлены рекомендации по оптимизации процессов разработки с учетом требований безопасности, а также обсуждаются мифы и предвзятости относительно затрат и сложности внедрения безопасных практик.
More Related Content
Similar to Безопасная разработка (СТАЧКА 2015)
Безопасная разработка (СТАЧКА 2015)
- 1. «Безопасная разработка: это неплоходля тебя» Практика внедрения в организациях цикла безопасной разработки программного обеспечения Качалин Алексей Зам. Генерального директора ЗАО «Перспективный мониторинг»
- 2. О себе/О нас •О себе: – занимаюсь ИБ/ПО с 2000 года • ЗАО «ПМ» – Аналитические и инструментальный анализ ПО и ИС – С 2012 года – работаем по направлению повышения безопасности разработки – Принимаем участие в работе с регуляторами ИБ
- 3. Жизненный цикл ПО*:где ИБ? 30.05.2017 3 Проектирование Требования Разработка Тестирование Выпуск Эксплуатация Сертификация Вывод из эксплуатации *Аналогичная ситуация с • Итеративными моделями разработки • Моделью непрерывного размещения
- 4. Угрозы-2015: ИБ вшироком смысле • Уязвимость технологий (мобильные, облака),… • Безопасность приложений – проблемы внешних сервисов (связанных облачных сервисов) • ИБ-катастрофы – ИБ-провалы платформ-2014 Apple iOS, MS – Shellshock, уязвимости TLS/SSL : Goto Fail, Heartbleed, POODLE, WinShock – Мегаутечки из торговых сетей • Риски инноваций – Снижение эффективности СЗИ: «облачные атаки на СКЗИ» – норма – Атаки на Интернет Вещей, АСУ ТП – мейнстрим – Новые сценарии потребления – норма BYOx • Проблемы обработки уязвимостей – Неловкое саморазоблачение Drupal – Проблема политики раскрытия уязвимостей • Обучение Растущий разрыв в потребностях и уровне/количестве специалистов ИБ • Вмешательство государств – Гос. Программы по кибервооружениям (Китай, США) – Санкции и запреты Если нас «сломают» Когда нас «сломают»
- 5. Если нас «сломают» Когда нас «сломают»
- 6. В условиях допустимойнебезопасности Насколько часты будут попытки атак? Как часто будут атаки успешны? Каковы будут последствия успешной атаки? Когда обнаружим атаку/последствия? Сможем эффективно противодействовать?
- 7. Насколько часты будутпопытки атак? • Условия эксплуатации – Доступность для атак – Надежность окружения – Агрессивность среды • Ценность «цели» – Случайная (массовая) цель – Промежуточная цель – Конечная цель Необходим анализ требований безопасности • Аналогичные системы, прогноз • Опыт/Статистика
- 8. Как часто будутатаки успешны? Уязвимость • Свойство системы – Наличие ошибки, недочета, слабости – Наличие возможности эксплуатации – Наличие метода, инструмента • Компенсация ненадежности окружения – Не обязательно программная Необходимо учитывать при проектировании • Уязвимости технологий, платформ, сторонних компонентов • Превентивные механизмы, «security controls» – Ограничение возможности доступа или эксплуатации
- 9. Каковы будут последствияуспешной атаки? • Отказ или несанкционированные действия • Атака – редко «атомарна» • Развитие успешной атаки – «Закрепление» в системе – Устранение следов атаки и несанкционированных активностей – Поиск новых целей и векторов атак «Безопасная по построению» или полная компрометация?
- 10. Когда обнаружим атаку/последствия? •Фиксация изменения состояния • Возможность анализа изменения состояния • Наблюдение: проведение такого анализа Встроенные механизмы защиты, позволяющие обнаружить компрометацию • Самозащита механизмов защиты
- 11. Сможем эффективно противодействовать? •Скорость реакции – Сократить окно уязвимости (Window of Vulnerability) • Локализовать инцидент – Выявить первопричину компрометации – Выявить первопричину уязвимости (ошибку) • Разработать исправление – Не позволяющее «обойти» себя – Или атаковать аналогичную уязвимость • Надежно устранить уязвимости – Улучшить процесс разработки, не повторять ошибку в будущем Культура разработки, надёжный целостный базовый уровень ИБ • Практика, методики и инструменты • Осведомленность и понимание методов атак
- 12. Безопасность– это тяжело •Дорого – Дополнительные требования – Проектирование, разработка • Сдвиги сроков – Дополнительное тестирование и доработка • Инструменты и методики • Компетенции в ИБ Почему же тогда нужно заниматься безопасностью? «…мы делаем сервис… в случае возникновения проблем мы обратимся за анализом уязвимостей» Руководитель службы эксплуатации сервиса
- 13. Если компрометация неизбежна– думать о безопасности выгодно Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки «…мы хотим сделать новый сервис:…, насколько это будет безопасно?»
- 14. Мифы и предубеждения •Дорого и долго – Дороже переделывать – Заказчик может оплатить, если объяснить ему возможные риски • Сложно, не понятно как – Есть описания практик, паттернов/антипаттернов – Есть (бесплатные) инструменты – Есть «с кем поговорить об этом» • Никому не нужно – Требования регуляторов отраслевых, государственных – Обеспокоенность правообладателей контента • Да никому наш продукт и не интересен – Не планируете его успех и тиражирование? – Каждый раз начинаете «с нуля»? Вы хотите управлять рисками и спать по ночам и продуктивно работать или тушить пожары?
- 15. Безопасная разработка: осознание проблем Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки
- 16. Как «читать» уязвимость 16 TheCVE Identifier CVE-2014-0160 was released on April 7, 2014—the same day the Heartbleed bug was made public. This type of weakness is described in detail by CWE-130: Improper Handling of Length Parameter Inconsistency. The second weakness is an out-of-bounds memory read, which is described inCWE-125: Out-of- Bounds Read. These CWEs were first defined more than eight years ago CAPEC-540: Overread Buffers defines the general pattern commonly used by an attacker including how the attack is crafted, its potential severity and consequences
- 17.
- 18. Развитие мониторинга иреагирования • Обнаружить публикацию информации об уязвимости – Публикация уязвимости в используемом компоненте – Публикация информации об уязвимости в Интернет – Сети обмена информацией об уязвимостях – Технический анализ (состояние узлов, трафик, журналы) • Интерпретировать обращения пользователей – Сообщения о «странном поведении программы» (нет явного подозрения на проблемы ИБ) – Попытки шантажа и ультиматумы, оскорбления и троллинг – Готовый метод компрометации ИБ (пошаговый, в виде PoCE) … • Внутренние сообщение от разработчика – обратить внимание – Указания на строчку кода – Развёрнутый анализ с обоснованием неизбежности уязвимости
- 19. Анализ рисков ИБготового продукта Обработка ИБ-рисков 1. Избегать – Организационные меры 2. Передать – Регламенты для сотрудников – Ответственность внешнего аудитора 3. Минимизировать – Исследовать безопасность готовой системы 4. Стабилизация – Фиксация практик 5. Своевременность процессов Вероятность Критичность Повышение уровня защищенности Пентесты Фиксация практик Контроль компонентов??? Контроль разработчика??? Процессы разработки ИС разработчика
- 20. Безопасная разработка: осознание проблем Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки
- 21. Модель действий атакующего Общаямодель • Разведка • Вооружиться • Доставка • Эксплуатировать уязвимость • Установка • Получить канал управления • Действовать согласно целям 21 Методы анализа ПО • Статические – Аудит исходного кода – Реверс-инжиниринг • Динамические – Фаззинг – Ручное тестирование • Комбинированные • Анализ архитектуры ПО (Логические ошибки)
- 22. Инструменты и средства •Инструменты – Языки программирования – Расширяемые инструменты (скрипты) • Python for hackers – Фреймворки – Специализированные средства – Дистрибутивы ИБ ОС – Сервисы – Заказная разработка • Разрушающие • Этические/не этические методы • Источники информации – Методики – Базы уязвимостей – Закрытые форумы – Репозиторий кода – Форумы, переписка • Заметные/скрытые – Через сервисы (3rd party) – Стенд – Атака на клиента – Атака на площадку • В определенный момент
- 23. Цели, задачи, средства? Инструменты:отладка • Возможности по отладке кода, предоставляемые процессором Отладочные регистры и Last Branch Recording в IA-32 и Intel 64 • Отладчики и отладочный API ptrace(), Debugging Tools for Windows • Dynamic Binary Instrumentation (DBI, динамическое инструментирование бинарного кода) – PIN, DynamoRIO, Valgrind • Intermediate Representation (IR, промежуточное представление кода) – Valgrind, LLVM и инструменты на их базе (Fuzzgrind, KLEE, S²E) • Эмуляция PIN, Ether, S²E Инструменты: фаззинг • Scapy- интерактивное средство манипуляции сетевыми пакетами с функцией smart-фаззинга. Позволяет описывать форматы сетевых сообщений и на основании описанных форматов проводить интеллектуальное фазз-тестирование. Используемые способы манипуляции данными - генерация. • Sulley- фаззинг-фреймворк, позволяющий описывать сложных структуры данных, но нами больше используется для фаззинга несложных полнотекстовых протоколов, к примеру, MFTP. • FuzzDB- база данных готовых векторов атак. Используется нами при интеллектуальном генерационном фаззинге. Количество векторов 35845 в 23-х категориях. • Zzuf- многоцелевой прозрачный мутирующий фаззер. Библиотеки данного инструмента используется нами при слепом (black-box) фаззинге - мутация набора собранных с помощью сетевого сниффера сообщений. • BurpIntruder - утилита входящая в набор Burp Suite использующийся для пентеста веб-приложений.
- 24. Пример подхода: Фаззинг •Обвязка/инструментация • Профилировка данных • Шаблон и мутация • Прогон, обнаружение сбоя • Анализ данных сбоя Данные по интерфейсам: – Пользовательский ввод – Файлы – Сетевые порты – API 24 Fuzztime 0 tn Fuzzing tn Dump tn tn DumpFuzzing tn Analysis Armed OK CORRUPTED Data D’ … Mutator D’’ Dump
- 25. Безопасная разработка: осознание проблем Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки
- 26. Безопасная разработка: естьрецепты Практики «первопроходцев» Доклады и презентации Инструменты
- 27. Ловушки инструментов ипрактик “as is” «Статический анализ кода? Мы конечно делаем» • Выбор инструментов и компонентов – Удобство среды разработки – Использование знакомых компонентов – Борьба с унаследованным кодом • «Безопасное программирование» это достаточное ИБ? – Утечки памяти, переполнение буфера, падения/повисания – Безопасные опции компилятора • Инструменты безопасности при разработке – Анализаторы кода – Генераторы нагрузки без тонкой настройки – Системы автоматизированного тестирования • Практики управления – Менеджер форсирует: бюджет, сроки, функционал
- 28. Безопасная разработка: осознание проблем Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки
- 29. Пример: OWASP. Содержаниеметодики OWASP Testing Guide 4.0 (2014) 1. Сбор информации 2. Анализ конфигураций 3. Идентификации пользователей 4. Аутентификации пользователей 5. Авторизации пользователей 6. Управление сессиями 7. Фильтрация переданных данных 8. Обработка ошибок 9. Анализ используемых криптографических алгоритмов 10. Анализ бизнес-логики приложения 11. Анализ клиентской части приложения OWASP TOP 10 • A1 Внедрение кода • A2 Некорректная аутентификация и управление сессией • A3 Межсайтовый скриптинг (XSS) • A4 Небезопасные прямые ссылки на объекты • A5 Небезопасная конфигурация • A6 Утечка чувствительных данных • A7 Отсутствие контроля доступа к функциональному уровню • A8 Подделка межсайтовых запросов (CSRF) • A9 Использование компонентов с известными уязвимостями • A10 Невалидированные редиректы 29
- 30. Модели Системы исценариев для ИБ • Модель позволяет – Формализовать и согласовать представление о предмете – Удобно обсуждать предмет (в идеале – всем) • Договариваться и доносить точку зрения • Анализ и описания для анализа ИБ – Не должны быть «плохой копией КД» – свой угол рассмотрения – Не должны быть «калькой с НПА» – адекватные модели
- 31. Требования: а вашлог полезен для ИБ? 31
- 32. Достаточное и необходимая информация в ПО 32 •Метаданные • Отладочная информация • Старые копии модулей • Избыточное логирование Для некоторых задач атакующему не требуется преодолевать криптографию Passwords. Don’t hardcode them mmkey? Твит != 140 символов
- 33. Heartbleed яркий пример «Внешний»компонент >> Разработка >> Публикация уязвимости >> Патч? >> Доступные цели • Полный поиск HTTPS на всём IPv4 • 89.1% - неуязвимы (нет openssl) • 6.0% support heartbeat messages, not vulnerable, • 4.9% уязвимы 1 400 000 уязвимых серверов 33
- 34. Безопасная разработка: осознание проблем Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки Заинтересованность Порядок внедрения Документированность Польза от практик
- 35.
- 36. Цикл Безопасной Разработки Свод Знаний Детализация 1. Перечень практик 1.1. Домен практик 1.1.1. Описание практики 1.1.1.1. Методика проверок 1.1.1.1.1. Инструкция Домены (Разделы) практик Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Сторонние компоненты Соответствие требованиям регуляторов Инструменты и системы разработки Подготовка команды
- 37. Cвой SDL. Такпросто? Basic Standardized (Activities are expert led) Advanced (Activities are led by central security team) Dynamic (Activities are co- led by product teams and central security team) Training, Policy Organizational Capabilities + Setting baseline and goals for SDL + Executive support: Tacit + Enterprise coverage: Few SDL pilot project +/- Training: Basic concepts +/- Basic security bug tracking - Executive support: Explicit - Enterprise coverage: New, high risk project - Training: Common baseline - Central security team exists - Executive support: SDL mandated and enforced - Enterprise coverage: All project with meaningful risk +/- Training: Custom training - SDL is adopted to the development methodology Requirements Design Undefined or inconsistent - Risk assessment +/- Threat models: Piloted to high-risk modules - Functional requirements for security and privacy - Standard security solutions +/- Threat models: Created with expert assistance - Threat models: Independently created by product group Implementation Undefined or inconsistent + Compiler defense - Banned functions - Cross-site scripting and SQL injection defenses +/- Static analysis tools - In-house, product-specific security tools development and customization Verification Undefined or inconsistent - File fuzzing - Basic Web application scanning + Penetration testing by third party as appropriate +/- Comprehensive fuzzing and Web application scanning - Threat model validated - In-house development and customization tools to: + Detect vulnerabilities - Audit compliance with SDL Release Response Undefined or inconsistent - Final Security Review: Verify internal and external compliance + Project archiving + Response: Basic + Response plan in place, incident tracking - Basic root-cause analysis - Real-time incident tracking - Advanced root-cause analysis and formal feedback into policy
- 38. Процесс внедрения ЦБР •Модель зрелости должна быть – Подходящая этапность внедрения • Методика – Домены – Соответствующая области практика построения моделей • Инструменты, лучшие практики
- 39.
- 40.
- 41. Измеримость – взглядразработчика • Продуктовый менеджмент – Интенсивность разработки • База внедрений – перспективы развития • Разработка: технологические тренды, тех.долг и архитектура • Установка и сопровождение – «Агрессивность среды» – Инциденты
- 42. Итого: ЦБР иИБ – во имя добра • Реагирование дороже предотвращения – Игнорирование проблем – ещё дороже • Чем компактнее коллектив и «моложе» продукт – тем больше шансов внедрить безопасную разработку • Внедрение процесса полезно само по себе – Осведомленность о методах и инструментах ИБ • Небольшие дополнения к введённым практикам – Улучшение процессов разработки • Снятие критических рисков и «пожаров» 42
- 43. худшая из угроз- Неведение Инструментальный анализ ПО и ИС Внедрение практик безопасной разработки Мониторинг ИБ Качалин Алексей @kchln kachalin@advancedmonitoring.ru
- 44. Безопасность: Риски иКачество • Типы рисков – Известные Известные - типовые риски в предметной области идентифицируемы, оцениваемы достаточно точно – Известные Неизвестные- идентифицируемы, не оцениваемы – Неизвестные Неизвестные – неидентифицируемые, сложно оценить по степени влияния • 3 метода обработки – Избегать– переработать план, снизить вероятность реализации – Передать - третья сторона – Минимизировать последствия. Остаточные риски • «Цена» качества – Соответствие • Стоимость предотвращения/гарантии качества • Стоимость проверки – Несоответствие • Внутренняя цена (переделки, ненужная работа) • Внешняя цена (репутация, иски, обработки обращений)
- 45. Связь со стратегическимуправлением Предотвращение Реагирование Обвинение Прощение Количественная Качественная Достоверное знание Приближенная, неполная информация Независимость Взаимозависимость (безопасности и других свойств) Ограничение Открытость (в обмене информацией) Структура и продукт Люди и процессы
Editor's Notes
- #2 «Опасная разработка. Дорожная карта движения к катастрофе» «Безопасная разработка: это неплохо для тебя» Абстракт: Активное развитие программного обеспечения и интернет-сервисов было бы не возможно без магического заклинания «поставляется как есть», «разработчик не несёт ответственности» и так далее. Однако, привлечение в информационные системы персональных данных, возможности совершать финансовые операции значительно повышает потенциальный ущерб и заинтересованность злоумышленника в поиске и эксплуатации уязвимостей. С другой стороны, обеспечение и контроль безопасности программного обеспечения процедура сложная, дорогая, требующая дополнительной экспертизы. Обсудим преимущества для продуктов и проектов извлекаемые от повышения уровня безопасности, с учётом ограниченного бюджета и сроков. Какие методики, средства и инструменты доступны как злоумышленникам, так и квалифицированным разработчикам. И, наконец, как внедрение практик безопасной разработки оказывает мотивирующее и организующее влияние на управление разработкой в целом. Начнём с цитаты: «… при реализации первой версии нашего продукта мы не занимались вопросами информационной безопасности, мы планируем заняться ими после запуска пилотной версии сервиса.» Общение с разработчиком программного обеспечения об уязвимостях продукта начинается, как правило, на этапе эксплуатации. На этом этапе все активности, связанные с реагированием и устранением проблем максимально дороги как для разработчика, так и для всех участников «цепочки поставки». Сложившаяся практика делегирования ответственности приводит к тому, что ответственным назначается компания-разработчик, который в свою очередь, в полном соответствии с лицензионным соглашением, имеет право поставлять изделие «как есть» и по факту не несёт обязательств (кроме моральных) по устранению выявленных проблем. Может ли быть изменена установившаяся тупиковая практика, приводящая к отсутствию у участников процесса позитивных стимулов обратить внимание на безопасность итогового решения? Если абсолютная безопасность не может быть достигнута, то какие приёмы на этапах формирования требований и проектирования могут принести пользу и какова допустимая цена этих мер? Как могут повлиять на разработчика заказчики, поставщики, исследователи и пользователи решений? Готового ответа на эти вопросы, пригодного на все случаи жизни очевидно нет, но даже внесение этих вопросов в обсуждение может стать существенным шагом вперёд. О докладчике: Алексей Качалин, директор ЗАО «Перспективный Мониторинг», ГК ИнфоТеКС. Руководит коллективом исследователей и аналитиков информационной безопасности. Опыт участия и руководства проектами исследования и разработки – более 15 лет. Ключевые слова: вопросы безопасной разработки, практика проверки продуктов на уязвимости, разработка программного обеспечения, сопровождение разработки заказчиком, регулирование разработки программного обеспечения
- #17 Cybersecurity Security Standards Help Stop Heartbleed May 7, 2014Software Assurance: Post by Drew Buttner PRINT The Heartbleed bug (CVE-2014-0160) is a critical vulnerability that first came to the attention of the public in early April and has been making headlines ever since. The vulnerability exists in certain versions of OpenSSL where it enables remote attackers to obtain sensitive information, such as passwords and encryption keys. Many popular websites have been affected or are at risk, which in turn, puts countless users and consumers at risk. Cybersecurity experts have mounted an aggressive and multi-faceted global response to Heartbleed, and security automation standards have played an important role in this effort. These standards were created to categorize and share information about system vulnerabilities and attacks to help the security community communicate consistently. Having a common language helps in understanding these issues and determining appropriate mitigation strategies. Effective communication about bugs also helps developers prevent them from reappearing in other applications. Specifically, these three security automation standards have been particularly helpful in dealing with Heartbleed: Common Vulnerabilities and Exposures (CVE®) provides unique identifiers for known information security vulnerabilities. CVE enables the fast, efficient, and effective correlation and sharing of information related to critical and time sensitive vulnerability. Common Weakness Enumeration (CWE™) provides an index of different types of software code weaknesses and serves as an information repository for the types of security problems found in a software application’s architecture, design, code, and setup. CWE helps developers prevent these mistakes from being repeated. Common Attack Pattern Enumeration and Classification (CAPEC™) is a publicly available catalogue of common attack patterns, along with a classification taxonomy that identifies relationships among attack patterns. An attack pattern is an abstraction mechanism for describing how an attack is executed. Many successful attacks are conducted in multiple, discrete, identifiable steps. CVE and Heartbleed The CVE Identifier CVE-2014-0160 was released on April 7, 2014—the same day the Heartbleed bug was made public. The existence of this identifier has enabled the worldwide community to converse and share information about this bug at an astonishingly rapid pace. The CVE Identifier (ID) quickly became so ubiquitous (with more than 100,000 lookups in the first few days alone) that simply entering its name into any search engine resulted in thousands of hits and a range of useful information including the official OpenSSL Security Advisory, major application vendors, details from industry experts, and guidance from security organizations. All of these search results underscores the main purpose of CVE: to allow people to correlate information. For example, using the CVE identifier in a search engine could lead system administrators to the blog post at Fox-It with information on how to test for the Heartbleed vulnerability and what to do if it they find it. The CVE identifier could also further help system administrators ensure that they are using the appropriate security tools and vendor patches to address the issue. Without CVE, there would likely be a surfeit of proprietary and non-standard names—such as Heartbleed, Heartbeat, and SOL15159—making it difficult to track down critical information in a timely manner. For example, the official OpenSSL Security Advisory doesn't even mention the term “Heartbleed.” CWE and Heartbleed The Heartbleed bug exists because of two separate mistakes in the code. The first is an inconsistency between the stated length of the message body and its actual length. This type of weakness is described in detail by CWE-130: Improper Handling of Length Parameter Inconsistency. The second weakness is an out-of-bounds memory read, which is described inCWE-125: Out-of-Bounds Read. These CWEs were first defined more than eight years ago and both provide information about the respective problem—how to detect it, why it occurs, how to fix it, and how to prevent it from happening again. In the case of Heartbleed, developers could use CWE to quickly determine if they have the types of code analysis tools needed to ferret out these types of mistakes. Many tools can check for instances of CWE-125. CWE also helps developers know why Heartbleed occurred and how to avoid this type of mistake in future development. Without CWE, developers would be forced to perform hours of research to understand the root of the issue and how to correct it in their code. If you don't want your software to have the same issue as Heartbleed, ask your vendors about these weaknesses and educate your developers about CWE-130 and CWE-125. CAPEC and Heartbleed To prevent future attacks, security professionals need to know how an attacker thinks and operates. CAPEC helps expose the attacker mindset by shedding light on how a particular vulnerability has been exploited to launch an attack. Without CAPEC, organizations are likely to be stuck in a reactionary mode, addressing known vulnerabilities, while being blind-sided when the next "Heartbleed" arrives. Software designers, testers, and assessment teams can use CAPEC to sleuth out the next piece of software that might be similarly susceptible and eliminate it as a target. They can also look for the underlying weaknesses that make such attacks possible. CAPEC-540: Overread Buffersdefines the general pattern commonly used by an attacker including how the attack is crafted, its potential severity and consequences, as well as possible solutions and mitigating factors. CAPEC continually adds new attack patterns, such as the specific pattern used in Heartbleed, so be sure to visit the website for updates. Future Heartbleeds Security automation efforts such as CVE, CWE, and CAPEC can help reduce the possibility of similar severe vulnerabilities such as Heartbleed in the future. But it is incumbent upon developers and other security professionals to actively leverage resources such as these to be better prepared for the next Heartbleed. About Drew Buttner Drew Buttner leads a software assurance group at MITRE specializing in secure code review. He has worked on improving application security for both MITRE and its customers since joining the organization in 2001. An expert in the field of source code weaknesses, Drew is also involved in a number of research efforts related to secure software development and
- #22 Reconnaissance (1) The first step that has to be taken is the reconnaissance step. In this step you will gather all the possible information that you can use. There are various tools and techniques which allow you to reconnaissance on a target. The NMAP or ZENMAP tool can be used to perform network scans on the selected target. These scans will provide the attack vital information about the security settings of the selected target. In the reconnaissance step you will be able to investigate the target for weak spots (vulnerabilities). Remember that these vulnerabilities to not have to be ‘cyber’ vulnerabilities. The weak spot of a target can also be a ‘physical’ weak spot. For example, people that leave the door open, after they have smoked a cigarette outside. Cyberwarzone cyber attack chain Weaponize The next step is to (2) categorize the found information, and take a look at the CVE database if there are any (3) known vulnerabilities available. Weaponize these vulnerability to a malicious package. Deliver There are various methods and techniques to (4) deliver malicious packages to the selected target. Take a look at the following listed cyber delivery attacks: Malicious e-mail (Gmail) Infected usb-stick Infected picture Infected pdf-file – Take a look at the PDF Exploit Generator which has been developed by the Security Expert Claes Spett. Exploit Once the malicious package has been delivered at the designated target, you will be able to(5) exploit the environment. The most used hacking framework is the Metasploit Framework. This framework contains various codes and methods to perform a successful cyber-attack. Install If it is needed, you will be able to exploit the environment to gain further access to the environment. Hackers and security experts, (6) install backdoor applications as these will allow them to reconnect to the infected device. Command and Control The infected machine(s) will be viewable in the (7) Metasploit Command and Control center. This allows the hackers to manage their infected devices. Infect other machines Infect the network Delete traces of infection Download / Upload files Act on objectives Each successful cyber-attack had a direct objective. (8) Stick to the objective. Flaw in Martin Lockheed ‘Cyber Kill chain’ Lockheed Martin published a similar attack chain titled ‘The Cyber Kill Chain‘. The Lockheed Martin chain misses one important factor. The ‘find vulnerabilities’ factor. This factor is needed as it will provide the attacker insight on the weak spots of the environment. Doing reconnaissance, is not a specific search for vulnerabilities.
- #23 Не нарушать работу Нагрузка на сеть, процессор Перезагрузка системы Оставить систему в изначальном состоянии Проблема вносимых данных Удаление данных Анализ ПО на полигоне Доступ к полигону Нет полной свободы действий - другие тестирующие (функционал) Отсутствие данных Не финальная версия (в разных компонентах отставание разное) Нет хотфиксов из боевой системы Нет конфигов боевой системы Не все ресурсы из боевой системы присутствуют Анализ ПО на тестовом стенде исполнителя Получен дистрибутив Надо ещё его установить Как проверить его отличия от боевой системы? Как правило нет тестовых данных Боевая система живёт своей жизнью
- #24 - Уязвимости в архитектуре Сложно предугадать, где найдёшь следующую - В результате фаззинга не всегда происходит падение Особенно при pool corruption - Не все найденные уязвимости эксплуатабельны А ведь уникальных воспроизводимых падений может насчитываться сотни и тысячи! Сложности: Объем кода, модульность Наличие обфускации Использование приемов анти-отладки Использование приемов анти-фаззинга Memory corruptions Buffer overflow Integer overflow Heap overflow Using un-owned memory Using uninitialized memory Memory leak Arbitrary file reading Arbitrary command execution Web application vulnerabilities Local file inclusion Remote file inclusion SQL injections XSS, CSRF Susceptible to flooding Business logic vulnerability (отклонения от заявленного/ожидаемого поведения)
- #25 http://www.vr-online.ru/?q=content/fuzzing-tehnologija-ohoty-za-bagami-752 Веб-приложения Сетевые протоколы Уязвимости при обработке файлов Драйверы режима ядра Различные интерфейсы (RPC, ActiveX компоненты) Показано на примере бинарщины и исходного кода на .C. отдел тестирования на этапе белого ящика плотно сканирует код статическими анализаторами , но после компиляции, на этапе серого ящика мы получаем ~40000 падений при фаззинге. Данные из последнего проекта по : Средний размер core-дампа: 90Mb Среднее количество дампов: ~40000 штук Время работы фаззера: 3-е суток Число потоков: 3 штуки
- #30 https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents OWASP Testing Guide v4 Table of Contents This project is part of the OWASP Breakers community. Feel free to browse other projects within the Defenders, Builders, and Breakers communities. This is the FINAL table of content of the New Testing Guide v4. At the moment the project is in the REVIEW phase. You can download the stable version v3 here Back to the OWASP Testing Guide Project: http://www.owasp.org/index.php/OWASP_Testing_Project Updated: 1st April 2014 Contributors List Table of Contents Foreword by Eoin Keary 1. Frontispiece 1.1 About the OWASP Testing Guide Project 1.2 About The Open Web Application Security Project 2. Introduction 2.1 The OWASP Testing Project 2.2 Principles of Testing 2.3 Testing Techniques Explained 2.4 Deriving Security Test Requirements 2.5 Security Tests Integrated in Development and Testing Workflows 2.6 Security Test Data Analysis and Reporting 3. The OWASP Testing Framework 3.1. Overview 3.2. Phase 1: Before Development Begins 3.3. Phase 2: During Definition and Design 3.4. Phase 3: During Development 3.5. Phase 4: During Deployment 3.6. Phase 5: Maintenance and Operations 3.7. A Typical SDLC Testing Workflow 4. Web Application Penetration Testing 4.1 Introduction and Objectives 4.1.1 Testing Checklist 4.2 Information Gathering 4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)" 4.2.2 Fingerprint Web Server (OTG-INFO-002) formerly "Testing for Web Application Fingerprint (OWASP-IG-004)" 4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) formerly "Spiders, Robots and Crawlers (OWASP-IG-001)" 4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) formerly "Application Discovery (OWASP-IG-005)" 4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) formerly "Review webpage comments and metadata(OWASP-IG-007)" 4.2.6 Identify application entry points (OTG-INFO-006) formerly "Identify application entry points (OWASP-IG-003)" 4.2.7 Map execution paths through application (OTG-INFO-008) formerly "Map execution paths through application (OWASP-IG-009)" 4.2.8 Fingerprint Web Application Framework (OTG-INFO-009) formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" 4.2.9 Fingerprint Web Application (OTG-INFO-010) formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" 4.2.10 Map Network and Application Architecture (OTG-INFO-011) formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" 4.3 Configuration and Deploy Management Testing 4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" 4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)" 4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) formerly "Testing for File Extensions Handling (OWASP-CM-003)" 4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) formerly "Testing for Old, Backup and Unreferenced Files (OWASP-CM-004)" 4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)" 4.3.6 Test HTTP Methods (OTG-CONFIG-006) formerly "Testing for Bad HTTP Methods (OWASP-CM-006)" 4.3.7 Test HTTP Strict Transport Security (OTG-CONFIG-009) formerly "Testing for Missing HSTS header (OWASP-CM-009)" 4.3.8 Test RIA cross domain policy (OTG-CONFIG-011) formerly "Testing for RIA policy files weakness (OWASP-CM-010)" 4.4 Identity Management Testing 4.4.1 Test Role Definitions (OTG-IDENT-001) 4.4.2 Test User Registration Process (OTG-IDENT-002) 4.4.3 Test Account Provisioning Process (OTG-IDENT-003) 4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) formerly "Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)" 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005) formerly "Testing for Weak or unenforced username policy (OWASP-AT-009) 4.5 Authentication Testing 4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001) formerly "Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)" 4.5.2 Testing for default credentials (OTG-AUTHN-002) formerly "Testing for default credentials (OWASP-AT-003)" 4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003) formerly "Testing for Weak lock out mechanism (OWASP-AT-004)" 4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004) formerly "Testing for bypassing authentication schema (OWASP-AT-005)" 4.5.5 Test remember password functionality (OTG-AUTHN-005) formerly "Testing for vulnerable remember password functionality (OWASP-AT-006)" 4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006) formerly "Testing for Browser cache weakness (OWASP-AT-007)" 4.5.7 Testing for Weak password policy (OTG-AUTHN-007) formerly "Testing for Weak password policy (OWASP-AT-008)" 4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008) 4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009) formerly "Testing for weak password change or reset functionalities (OWASP-AT-011)" 4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010) 4.6 Authorization Testing 4.6.1 Testing Directory traversal/file include (OTG-AUTHZ-002) formerly "Testing Directory traversal/file include (OWASP-AZ-001)" 4.6.2 Testing for bypassing authorization schema (OTG-AUTHZ-003) formerly "Testing for bypassing authorization schema (OWASP-AZ-002)" 4.6.3 Testing for Privilege Escalation (OTG-AUTHZ-004) formerly "Testing for Privilege Escalation (OWASP-AZ-003)" 4.6.4 Testing for Insecure Direct Object References (OTG-AUTHZ-005) formerly "Testing for Insecure Direct Object References (OWASP-AZ-004)" 4.7 Session Management Testing 4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001) formerly "Testing for Bypassing Session Management Schema (OWASP-SM-001)" 4.7.2 Testing for Cookies attributes (OTG-SESS-002) formerly "Testing for Cookies attributes (OWASP-SM-002)" (Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity) 4.7.3 Testing for Session Fixation (OTG-SESS-003) formerly "Testing for Session Fixation (OWASP-SM-003)" 4.7.4 Testing for Exposed Session Variables (OTG-SESS-004) formerly "Testing for Exposed Session Variables (OWASP-SM-004)" 4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005) formerly "Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)" 4.7.6 Testing for logout functionality (OTG-SESS-007) formerly "Testing for logout functionality (OWASP-SM-007)" 4.7.7 Test Session Timeout (OTG-SESS-008) 4.7.8 Testing for Session puzzling (OTG-SESS-010) 4.8 Data Validation Testing 4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001) formerly "Testing for Reflected Cross Site Scripting (OWASP-DV-001)" 4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002) formerly "Testing for Stored Cross Site Scripting (OWASP-DV-002)" 4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003) formerly "Testing for HTTP Verb Tampering (OWASP-DV-003)" 4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) formerly "Testing for HTTP Parameter pollution (OWASP-DV-004)" 4.8.5 Testing for SQL Injection (OTG-INPVAL-006) formerly "Testing for SQL Injection (OWASP-DV-005)" 4.8.5.1 Oracle Testing 4.8.5.2 MySQL Testing 4.8.5.3 SQL Server Testing 4.8.5.4 Testing PostgreSQL (from OWASP BSP) 4.8.5.5 MS Access Testing 4.8.5.6 Testing for NoSQL injection 4.8.6 Testing for LDAP Injection (OTG-INPVAL-007) formerly "Testing for LDAP Injection (OWASP-DV-006)" 4.8.7 Testing for ORM Injection (OTG-INPVAL-008) formerly "Testing for ORM Injection (OWASP-DV-007)" 4.8.8 Testing for XML Injection (OTG-INPVAL-009) formerly "Testing for XML Injection (OWASP-DV-008)" 4.8.9 Testing for SSI Injection (OTG-INPVAL-010) formerly "Testing for SSI Injection (OWASP-DV-009)" 4.8.10 Testing for XPath Injection (OTG-INPVAL-011) formerly "Testing for XPath Injection (OWASP-DV-010)" 4.8.11 IMAP/SMTP Injection (OTG-INPVAL-012) formerly "IMAP/SMTP Injection (OWASP-DV-011)" 4.8.12 Testing for Code Injection (OTG-INPVAL-013) formerly "Testing for Code Injection (OWASP-DV-012)" 4.8.12.1 Testing for Local File Inclusion 4.8.12.2 Testing for Remote File Inclusion 4.8.13 Testing for Command Injection (OTG-INPVAL-014) formerly "Testing for Command Injection (OWASP-DV-013)" 4.8.14 Testing for Buffer overflow (OTG-INPVAL-015) formerly "Testing for Buffer overflow (OWASP-DV-014)" 4.8.14.1 Testing for Heap overflow 4.8.14.2 Testing for Stack overflow 4.8.14.3 Testing for Format string 4.8.15 Testing for incubated vulnerabilities (OTG-INPVAL-016) formerly "Testing for incubated vulnerabilities (OWASP-DV-015)" 4.8.16 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) formerly "Testing for HTTP Splitting/Smuggling (OWASP-DV-016)" 4.9 Testing for Error Handling 4.9.1 Analysis of Error Codes (OTG-ERR-001) formerly "Analysis of Error Codes (OWASP-IG-006)" 4.9.2 Analysis of Stack Traces (OTG-ERR-002) formerly "Analysis of Stack Traces" 4.10 Testing for weak Cryptography 4.10.1 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002) formerly "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)" 4.10.2 Testing for Padding Oracle (OTG-CRYPST-003) formerly "Testing for Padding Oracle (OWASP-EN-003)" 4.10.3 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007) 4.11 Business Logic Testing (OWASP-BL-001) Business Logic 4.11.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001) 4.11.2 Test Ability to Forge Requests (OTG-BUSLOGIC-002) 4.11.3 Test Integrity Checks (OTG-BUSLOGIC-003) 4.11.4 Test for Process Timing (OTG-BUSLOGIC-004) 4.11.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005) 4.11.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006) 4.11.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007) 4.11.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008) 4.11.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009) 4.12 Client Side Testing 4.12.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001) formerly "Testing for DOM based Cross Site Scripting (OWASP-CS-001)" 4.12.2 Testing for JavaScript Execution (OWASP-CS-002) 4.12.3 Testing for HTML Injection (OWASP-CS-003) 4.12.4 Testing for Client Side URL Redirect (OWASP-CS-004) 4.12.5 Testing for CSS Injection (OWASP-CS-005) 4.12.6 Testing for Client Side Resource Manipulation (OWASP-CS-006) 4.12.7 Test Cross Origin Resource Sharing (OTG-CLIENT-007) formerly "Testing for HTML5 (OWASP CS-002)" 4.12.8 Testing for Cross Site Flashing (OTG-CLIENT-008) formerly "Testing for Cross Site Flashing (OWASP-CS-003)" 4.12.9 Testing for Clickjacking (OTG-CLIENT-009) formerly "Testing for Clickjacking (OWASP-CS-004)" 4.12.10 Testing WebSockets (OTG-CLIENT-010) 4.12.11 Test Web Messaging (OTG-CLIENT-011) 4.12.12 Test Local Storage (OTG-CLIENT-012) 5. Writing Reports: value the real risk 5.1 How to value the real risk 5.2 How to write the report of the testing Appendix A: Testing Tools Black Box Testing Tools Appendix B: Suggested Reading Whitepapers Books Useful Websites Appendix C: Fuzz Vectors Fuzz Categories Appendix D: Encoded Injection Input Encoding Output Encoding
- #34 Отслеживаемость встроенных библиотек и их версий
- #40 Проекты по развитию существующих продуктов Критичность Распространение на рынке Критичность сценариев Пилотные и исследовательские проекты Новые продукты «Агрессивность» среды Модель угроз/нарушителя Статистика инцидентов Подверженность атакам на распространённые заимствованные компоненты
- #41 Проекты по развитию существующих продуктов Критичность Распространение на рынке Критичность сценариев Пилотные и исследовательские проекты Новые продукты «Агрессивность» среды Модель угроз/нарушителя Статистика инцидентов Подверженность атакам на распространённые заимствованные компоненты
- #42 Проекты по развитию существующих продуктов Критичность Распространение в организации Критичность сценариев «Агрессивность» среды Подверженность атакам на распространённые заимствованные компоненты Возможность доступа для анализа Компактность системы Скорость изменения Новые продукты Пилотные и исследовательские проекты Все проекты со значимыми угрозами
- #43 Осознание проблем безопасности: Разработчики, Менеджмент, Стейкхолдеры: топ-менеджеры, заказчик Улучшение отношений в команде, с заказчиком Информация для анализа рисков Упреждение требования исправления уязвимостей Выстроенный процесс реагирования на уязвимости Без паники, обвинений, истерик Разрозненные практики ИБ часто расходы на иллюзию безопасности – должна быть поставлена цель Синергия безопасной разработки и соответствия требованиям Стратегический план реалистичный по ресурсам и времени Поддержка заинтересованных лиц, заказчика Очень многое зависит от автоматизации и инструментов – но они не панацея
- #46 Доктрины риск менеджмента (Hood and Jones, 1996)