ЛОМАТЬ И СТРОИТЬ, И СНОВА ЛОМАТЬ
Post on 24-Jul-2015
104 Views
Preview:
TRANSCRIPT
Сколько можно исследовать ИБ?
2011 2012 2013 20140
5
10
15
20
25
30
35
Примерно любой отчет о периодическом АНАЛИЗЕ ИБ
Критических уязвимостей Найдено новых Закрыто уязвимостей
О себе/О нас
О себе:
Занимаюсь исследованиями и разработкой в ИБ
ЗАО «ПМ»
Аналитический и инструментальный анализ ПО и ИС
С 2012 года – работаем по направлению повышения безопасности разработки
В 2014 запустили ЦМПринимаем участие в работе с регуляторами ИБ
О чём речь?
Наш опыт проведения работ по взлому повышению защищённости разработки
Проблемы интеграции исследований ИБ в цикл работ по созданию и обслуживанию ПО/ИС
Дополнительные процессы и системы, полезные в нашей борьбе
ИБ-портрет: Разработчик (СЗИ)
Компания – актуальны все угрозы для организаций и сотрудников
Отрасль ИБ – активно вовлечен в противоборство ИБ
Клиенты – информация о СЗИ, доступ, доверие
Продукт – системный, инфраструктурный компонент ИС
04/14/2023 11
Жизненный цикл разработки ПО*: где ИБ?
ПроектированиеТребования
РазработкаТестирование
ВыпускЭксплуатация
Сертификация
Вывод из эксплуатации
*Аналогичная ситуация с• Итеративными моделями разработки• Моделью непрерывного размещения
Безопасная разработка продукта
Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка и обучение
разработчиков Внедрение практик
разработки
Что «вкусного» есть в ИС разработчика?
Системы учёта ошибок и улучшений
Системы версионного хранения кода
Системы хранения жалоб потребителей
Системы подготовки обновлений
------------------------------------------------------
Идеально для инжинерии атак
Можно грабить караваныTM
Подключение к сетям заказчиков
Тестовые устройства на периметре
Необходимость загружать и тестировать недоверенное ПО
Организация методов обновления Продукта
Продукт в конце концов
Разработчик СЗИ – интересная мишень
Интересны для атакующих «высоких классов», воспринимаются как активные участники государственной политики, представители интересов государства
Продукт : Исходники и собранное ПО для исследования, алгоритмы
Технологические мощности: сборочные сервера - возможность злоумышленнику собрать свою «подлинную» версию СЗИ, сетевые и серверные мощности
Эксплуатация доверия - Рассылка писем/переписка от имени доверенной организации, люди – сотрудники, внешние контакты
База установки Продукта: Контрактная документация, Сервисные подразделения
Собственная безопасность разработчика
Регулярный аудит ИБ ИС
Центр Мониторинга*
* Нет мы не делаем “свой SIEM”, не умеем видеть невидимые вещи, спасибо за понимание
Развитие мониторинга и реагирования
Технический анализ (состояние узлов, трафик, журналы)
Обнаружить публикацию информации об уязвимости
Публикация информации об уязвимости в компоненте/продукте
Сети обмена информацией об уязвимостях
Получить и интерпретировать обращения пользователей
Сообщения о «странном поведении программы» (нет явного подозрения на проблемы ИБ)
Попытки шантажа и ультиматумы, оскорбления и троллинг
Готовый метод компрометации ИБ (пошаговый, в виде PoCE)
Внутренние сообщение от разработчика – обратить внимание
Указания на строчку кода
Развёрнутый анализ с обоснованием неизбежности уязвимости
Тестирование и тестирование
Анализ ИБ – безусловно один из видов тестирования продуктов
Свои методики и тест-планы
Автоматизация
Инструментарий (инструкции)
Работающий вариант: разработка автотестов для передачи в отдел тестирования
Ловушки для исследователя
Не читать документацию
Переписать документацию
Не согласовывать цели/прогресс с заказчиком
Не осознать зоны ответственности заинтересованных лиц
…
Готовы ли разработчики?
Выбор инструментов и компонентов
Удобство среды разработки
Использование знакомых компонентов
Борьба с унаследованным кодом
«Безопасное программирование» это достаточное ИБ?
Утечки памяти, переполнение буфера, падения/повисания
Безопасные опции компилятора
Инструменты те же, а сценарии нет
Практики управления
Менеджер форсирует: бюджет, сроки, функционал
Безопасная разработка продукта
Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка и обучение
разработчиков Внедрение практик
разработки
26
Условия внедрения безопасной разработки
Осязаемые результаты: отдача от инвестиций в безопасность
Возврат инвестиций
ПО финансовых, подверженных фроду систем – возможно
Снижение количества инцидентов и уязвимостей
Снижение «стоимости» уязвимости
Оперативность реагирования на инциденты
Встраивание в существующий процесс разработки (заказа и эксплуатации ПО)
Существующие продукты и компоненты
Вовлечение команды (мотивация исполнителя и легитимизация затрат) на дополнительные практики ИБ
Безопасность 2.0
Необходимая скорость реакции
Сократить окно уязвимости (Window of Vulnerability)
Локализовать и ограничить инцидент
Выявить первопричину уязвимости (ошибку)
Разработать исправление
Не позволяющее «обойти» себя
Или атаковать аналогичную уязвимость
Надежно устранить уязвимости, «не вернуть» ошибку в будущем
Что блокирует внедрение исследований ИБ
Слабая прогнозируемость по срокам
Непредсказуемость по результатам
Отсутствие гарантий полноты исследований
Отсутствие сходимости исследований
Проблема повторных исследований
Потребность: непрерывный адаптируемый процесс с управляемыми характеристиками
Цикл Безопасной Разработки Свод Знаний
Домены (Разделы) практик Мониторинг и реагирование
Проверка и выпуск продукта
Разработка
Проектирование
Требования
Сторонние компоненты
Соответствие требованиям регуляторов
Инструменты и системы разработки
Подготовка команды
Безопасность – командный вид спорта?
Менеджер продукта
Руководитель разработки
Аналитик
Архитектор
Программист
Тестировщик
Специалист сопровождения
Хакер
Хакер
Хакер
Хакер
Хакер
Хакер
Хакер
Осознать «свои» слабости
33
The CVE 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
Выстроить чтобы ломать
Исследователи и программисты
Инструменты и методика
База знаний и терминология (язык общения)
Автоматизация консистентных процессов
Процесс безопасной разработки
Средства и процесс мониторинга
top related