ЛОМАТЬ И СТРОИТЬ,

И СНОВА ЛОМАТЬ

Алексей КачалинЗАО «Перспективный

Мониторинг»

104

ЕСЛИ нас «сломают»

КОГДА нас «сломают»

ПОЛЬЗОВАТЕЛЬ

ПРОИЗВОДИТЕЛЬ

РЕГУЛЯТОРИССЛЕДОВАТЕЛЬ

НЕН

АВИ

СТЬ

О себе/О нас

О себе:

Занимаюсь исследованиями и разработкой в ИБ

ЗАО «ПМ»

Аналитический и инструментальный анализ ПО и ИС

С 2012 года – работаем по направлению повышения безопасности разработки

В 2014 запустили ЦМПринимаем участие в работе с регуляторами ИБ

О чём речь?

Наш опыт проведения работ по взлому повышению защищённости разработки

Проблемы интеграции исследований ИБ в цикл работ по созданию и обслуживанию ПО/ИС

Дополнительные процессы и системы, полезные в нашей борьбе

ИБ-портрет: Разработчик СЗИ

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

Отрасль ИБ – активно вовлечен в противоборство ИБ

Клиенты – информация о СЗИ, доступ, доверие

Продукт – системный, инфраструктурный компонент ИС

04/15/2023 10

Жизненный цикл разработки ПО*: где ИБ?

ПроектированиеТребования

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

ВыпускЭксплуатация

Сертификация

Вывод из эксплуатации

*Аналогичная ситуация с• Итеративными моделями разработки• Моделью непрерывного размещения

Безопасная разработка продукта

Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка и обучение

разработчиков Внедрение практик разработки

Что «вкусного» есть в ИС разработчика?

Системы учёта ошибок и улучшений

Системы версионного хранения кода

Системы хранения жалоб потребителей

Системы подготовки обновлений

------------------------------------------------------

Идеально для инжинерии атак

Открытость инфраструктуры

Подключение к сетям заказчиков

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

Необходимость загружать и тестировать недоверенное ПО

Организация методов обновления Продукта

Разработчик СЗИ - ценная мишень

Интересны для атакующих «высоких классов», воспринимаются как активные участники государственной политики, представители интересов государства

Продукт : Исходники и собранное ПО для исследования, алгоритмы

Технологические мощности: сборочные сервера - возможность злоумышленнику собрать свою «подлинную» версию СЗИ, сетевые и серверные мощности

Эксплуатация доверия - Рассылка писем/переписка от имени доверенной организации, люди – сотрудники, внешние контакты

База установки Продукта: Контрактная документация, Сервисные подразделения

Собственная безопасность разработчика

Регулярный аудит ИБ ИС

Центр Мониторинга

Развитие мониторинга и реагирования

Технический анализ (состояние узлов, трафик, журналы)

Обнаружить публикацию информации об уязвимости

Публикация информации об уязвимости в компоненте/продукте

Сети обмена информацией об уязвимостях

Получить и интерпретировать обращения пользователей

Сообщения о «странном поведении программы» (нет явного подозрения на проблемы ИБ)

Попытки шантажа и ультиматумы, оскорбления и троллинг

Готовый метод компрометации ИБ (пошаговый, в виде PoCE)

Внутренние сообщение от разработчика – обратить внимание

Указания на строчку кода

Развёрнутый анализ с обоснованием неизбежности уязвимости

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

Анализ ИБ – безусловно один из видов тестирования продуктов

Свои методики и тест-планы

Автоматизация

Инструментарий (инструкции к общему инструментарию)

Работающий вариант: разработка автотестов для передачи в отдел тестирования

Ловушки для исследователя

Не читать документацию

Переписать документацию

Не согласовывать цели/прогресс с заказчиком

Не осознать зоны ответственности заинтересованных лиц

Готовы ли разработчики?

Выбор инструментов и компонентов

Удобство среды разработки

Использование знакомых компонентов

Борьба с унаследованным кодом

«Безопасное программирование» это достаточное ИБ?

Утечки памяти, переполнение буфера, падения/повисания

Безопасные опции компилятора

Инструменты те же, а сценарии нет

Практики управления

Менеджер форсирует: бюджет, сроки, функционал

Безопасная разработка: есть рецепты

Опыт«первопроходцев»

Теория

Практика Инструменты

22

Полнота требований: Ваш лог не вреден полезен для ИБ?

Модель угроз и нарушителя. Теперь в 3D

24

Цели внедрения безопасной разработки

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

Возврат инвестиций

ПО финансовых, подверженных фроду систем – возможно

Снижение количества инцидентов и уязвимостей

Снижение «стоимости» уязвимости

Оперативность реагирования на инциденты

Встраивание в существующий процесс разработки (заказа и эксплуатации ПО)

Существующие продукты и компоненты

Вовлечение команды (мотивация исполнителя и легитимизация затрат) на дополнительные практики ИБ

25

Стратегия внедрения безопасной разработки (наивный алгоритм)

Вот и договоритесь о приоритетахПроекты разработки

Продукты

Клиентские проекты

Безопасность 2.0

Необходимая скорость реакции

Сократить окно уязвимости (Window of Vulnerability)

Локализовать и ограничить инцидент

Выявить первопричину уязвимости (ошибку)

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

Не позволяющее «обойти» себя

Или атаковать аналогичную уязвимость

Надежно устранить уязвимости, «не вернуть» ошибку в будущем

Что блокирует внедрение исследований ИБ

Слабая прогнозируемость по срокам

Непредсказуемость по результатам

Отсутствие гарантий полноты исследований

Отсутствие сходимости исследований

Проблема повторных исследований

Потребность: непрерывный адаптируемый процесс с управляемыми характеристиками

Цикл Безопасной Разработки Свод Знаний

Домены (Разделы) практик Мониторинг и реагирование

Проверка и выпуск продукта

Разработка

Проектирование

Требования

Сторонние компоненты

Соответствие требованиям регуляторов

Инструменты и системы разработки

Подготовка команды

Безопасность – командный вид спорта?

Менеджер продукта

Руководитель разработки

Аналитик

Архитектор

Программист

Тестировщик

Специалист сопровождения

Хакер

Хакер

Хакер

Хакер

Хакер

Хакер

Хакер

Не только сертификация

УБИ ФСТЭК СОПКА

ФСБ

ГОСТ поРазработкеФСТЭК

Знать «свои» слабости

32

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

Выстроить чтобы ломать

Исследователи и программисты

Инструменты и методика

База знаний и терминология (язык общения)

Автоматизация консистентных процессов

Процесс безопасной разработки

Средства и процесс мониторинга

Начать с того что имеете

Использовать доступное

Делать возможное

Качалин АлексейДиректор ЗАО «ПМ»

@kchln Kachalin@advancedmonitoring.ru