Download to read offline
Uploaded byAlexey Kachalin
Внедрение безопасной разработки (Infosecurity 2014)
Документ описывает практику внедрения цикла безопасной разработки (SDL) в организациях, акцентируя внимание на методах повышения безопасности информационных систем и взаимодействии с атакующим сообществом. Основные темы включают необходимость реагирования на инциденты, требования к безопасности и вовлечение команды разработки. Внедрение SDL рассматривается как сложный процесс, требующий поддержки со стороны руководства и системы ценностей менеджмента.
More Related Content
Similar to Внедрение безопасной разработки (Infosecurity 2014)
Внедрение безопасной разработки (Infosecurity 2014)
- 1. Практика внедрения ворганизациях «Цикла безопасной разработки» Качалин Алексей Зам. Генерального директора ЗАО «ПМ» ЗАО «Перспективный мониторинг»
- 2. Анализ ИБ Инф. Систем АнализПО Практики SDL Исследования и Разработка О Компании • Исследовательское подразделение ГК ИнфоТеКС • Специализация: исследования и инструментальный анализ ИБ, методы и средства атак на информационные системы • Услуги ЗАО «ПМ» – Инструментальный анализ ИБ – Тест на проникновение – Анализ ПО – Расследование инцидентов
- 3.
- 4. Безопасность разработки -требование рынка • Уязвимости и инциденты ИБ – Больше не «приватный вопрос», не всегда возможно контролировать раскрытие информации – Раскрытие информации об уязвимостях используемых компонентов – Обращения к регулятору с вопросами от пользователей • Необходимость реакции на обращение об уязвимости, инцидентах – Взаимодействие с «атакующим» сообществом • Требования НПА и регуляторов • Требования 3-их лиц по гарантиям ИБ
- 5. Условия внедрения безопасной разработки •Осязаемые результаты: отдача от инвестиций – Возврат инвестиций – Снижение количества инцидентов – Оперативность реагирования на инциденты • Встраивание в существующий процесс разработки (заказа и эксплуатации ПО) • Применение к имеющимся продуктам • Вовлечение команды (мотивация исполнителя) на дополнительные практики ИБ 5
- 6. Безопасная разработка: этапы осознанияпроблем Реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки
- 7. Реагирование на инциденты •Продукт эксплуатируется – «Отключить» нельзя – Обслуживаются процессы (в т.ч. критические) • Подрядчик/команда разработки работы сдали • Анализ проблемы? – В системе «боевые» данные – нельзя «передать» на исследование/воспроизведение проблемы Даже самый «безобидный» сценарий – сработал сканер уязвимостей уже достаточно плохо
- 8. Источники сигналов обинцидентах ИБ в ПО • Публикация уязвимости в используемом компоненте • Публикация «обращения» в Интернет • Внешние обращения – звонки/письма: – Сообщения о «странном поведении программы» (нет явного подозрения на проблемы ИБ) – Попытки шантажа и ультиматумы – Оскорбления и троллинг – Готовый метод компрометации ИБ (пошаговый, в виде PoCE) • Внутренние обращения – Указания на строчку кода – Развёрнутый анализ с обоснованием неизбежности уязвимости Система учета обращений/багов необходима, но нужно выстраивать процесс реагирования! 8
- 9. Пример: Взаимодействие сисследователями ИБ 9
- 10. Проверка и выпуск- «Обречены на релиз» На этом этапе никто не рассматривает возможность отказаться от выпуска продукта или существенно сдвинуть сроки • Релизное тестирование – исправить нельзя убрать • Дорогие и длительные работы с сюрпризами – Сертификация продукта – Проверки сторонними ИБ-экспертами • Внезапно - проблемы – Уязвимость сторонних компонентов – Быстрые исправления выявленных ошибок – костыли и проблемы «на будущее» – Отключение «проблемных» сценариев
- 11. Разработка: ловушки инструментови практик • Безопасность не в приоритете – Удобство среды разработки – Использование знакомых компонентов – Борьба с унаследованным кодом • Безопасный продукт? – Утечки памяти, переполнение буфера, падения/повисания – Архитектор потребует «безопасные» опции компилятора • Ловушка – бессистемное использование инструментов не- специалистами ИБ – Анализаторы кода – Генераторы нагрузки без тонкой настройки – Системы автоматизированного тестирования • Менеджер форсирует: бюджет, сроки, функционал – Унаследованный долг: было 500 предупреждений, будет 507 – ок?
- 12. Проектирование • «Безопасные решения»мешают красивой архитектуре – лёгкая жертва – Ограничения гибкости и расширяемости – Дополнительные операции (журналирование) – Затруднение сопровождения (обфускация) • Исправление известных проблем дорого и «не оплачено» – Удаление «вшитых» паролей • Ревью дизайна архитектуры – не частая процедура – Ревью безопасности? На это нет времени – Моделирование угроз – Анализ рисков ИБ
- 13. Требования (на развитиепродукта) Требования от заказчика на развитие функциональных характеристик продукта могут не учитывать текущего состояния продукта и реализованных сценариев • Анализ требований – Моделирование актуальных и возможных угроз • Анализ сценариев с точки зрения ИБ - предложение дополнительных «контролей» ИБ – Обоснованность (необходимость) и достаточность набора мер ИБ • Оценка уровня безопасности продукта после реализации требований – Прозрачность управления уровнем ИБ продукта/продуктовой линейки – Ранжирование известных уязвимостей и исправление – Группировка и привязка к релизам исправления уязвимостей – Возможность построения «общей картины» по срезу (проект/продукт/менеджер) • Прогноз - как изменится окружение (использование) продукта с точки зрения ИБ? • Менеджера продукта формирует требования на проект – Унаследованный продукт, технологический долг – Динамика развития функционала, архитектурные компромиссы – Внешние и внутренние ИБ-риски предлагаемого проекта и продукта в целом – Факторы ИБ как элемент оценки качества работы (обоснования необходимости затрат)
- 14. Обучение и мотивация:примеры Каждой роли в создании продукта, проекте, компании необходима информация о специфичных аспектах безопасной разработки • Демонстрация эксплуатации уязвимостей – для разработчиков • Обзор комплексных атак на аналогичные системы – для архитекторов • Планирование работ по анализу продуктов – для менеджеров разработки • Практика выработки метрик для оценки состояния ИБ продукта – для менеджеров продуктов Обучение позволяет повысить компетенцию и, что часто важнее - осведомлённость о проблемах ИБ
- 15. Выбор проектов длявнедрения безопасной разработки • Проекты по развитию существующих продуктов – Критичность • Распространение на рынке • Критичность сценариев – «Агрессивность» среды • Подверженность атакам на распространённые заимствованные компоненты • Возможность доступа для анализа – Компактность продукта • Новые продукты • Пилотные и исследовательские проекты • Все проекты со значимыми угрозами 15
- 16. Итого: • Внедрение SDL- это сложный процесс, должен быть организован и поддержан руководством • Разрозненные практики ИБ – расходы на иллюзию безопасности • Многое зависит от автоматизации и инструментов – Инструменты определяют отдельные сценарии – Корректность и взаимосвязь процессов определяются практиками • Реагирование дороже предотвращения – Дополнительные риски – непрогнозируемые сроки • Предотвращение не бесплатно – Корректное бюджетирование – Безопасность – в «системе ценностей» менеджмента 16
- 17. Безопасная разработка: этапы осознанияпроблем Реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки
- 18. худшая из угроз- Неведение Инструментальный анализ и аналитика ИБ ИС Расследование инцидентов ИБ Разработка инструментов сбора и анализа данных в ИС Центр компетенций ИБ Исследования и аналитика технологий ИБ Тренинги по практике ИБ
Editor's Notes
- #2 Процесс обеспечения безопасности ПО – затратная процедура: по ресурсам, прямым расходам, по влиянию на сроки выполнения проекта. Однако, в ситуации, когда обеспечение безопасности не является опциональным, особенно остро встаёт вопрос оптимизации затрат и управления уровнем гарантируемой безопасности конечного продукта. В крупных компаниях-вендорах (Microsoft, Cisco, SAP, Oracle и других) активное внедрение практик безопасной разработки для оптимизации затрат на обеспечение безопасности ведётся с начала 2000-х годов, – т.к. к этому времени стали очевидны коммерческие и репутационные риски, а также экспоненциальный характер роста стоимости исправления ошибок в зависимости от этапа локализации проблемы. Общепринятое название практик безопасной разработки - жизненный цикл безопасной разработки ПО (Security Development Lifecycle, SDL) – совокупность практик и инструментов, позволяющих управлять безопасностью разрабатываемых программных продуктов на всех этапах – от подготовки сотрудников, занятых в разработке, до сопровождения готового продукта. В российских реалиях разработки ПО мы часто сталкиваемся как с «классическими» проблемами обеспечения безопасности разработки, так и со сложившейся практикой использования недоверенных компонентов: инструментов разработки, программно-аппаратных платформ, подключаемых библиотек. В некоторых случаях такие компоненты могут быть исследованы, но зачастую максимальным результатом может быть лишь ограничение степени и характера негативного воздействия. С особой тщательностью надо подходить к процессу разработки в тех компонентах, где этот процесс управляем; а также лучше вводить дополнительные практики – например, мониторинг публикации информации об уязвимостях в используемых компонентах. С другой стороны – значительно возросли потребности пользователей систем (доступ через сети общего доступа, доступ с мобильных платформ) и масштабы внедрения систем, а как следствие – и объемы разработок. Учитывая мировой опыт, можно констатировать: проблемы, не решённые сейчас, на этапе активного развития индустрии разработки ПО, не уйдут, а будут накапливаться и неминуемо решаться позже, когда отказ от технологии станет невозможен. Такая альтернатива, как отказ от информационных технологий и возврат, например, к пишущим машинкам (как это происходит не только у нас, но и в Германии) – хотя и может быть рассмотрена в ряде особых случаев, но вряд ли послужит развитию эффективного общества и государства. Возможным способом борьбы с этой проблемой может стать совокупность мер: «драйвер» - активно развиваемые в настоящее время требования регулятора как по безопасной эксплуатации, так и по разработке информационных систем; долгосрочная стратегия безопасности заказчика систем (инвестиции в безопасность); взвешенная стратегия компаний разработчиков, позволяющая объективно подходить к уровню безопасности предлагаемых систем, так как абсолютно-безопасная система будет настолько же абсолютно непригодна к использованию (не говоря уже о сроках и цене её производства). В докладе развернуто представлен опыт по внедрению практик безопасной разработки и сопровождению проектов, проводимых ЗАО «Перспективный Мониторинг» как в ГК «ИнфоТеКС», так и в компаниях, выполняющих продуктовую и заказную разработку ПО для систем массового использования и критически-важных объектов инфраструктуры.