15
Ольга Макарова Руководитель направления ИБ в УрФО Департамента информационной безопасности Методические рекомендации по проведению анализа защищённости систем ДБО

Методические рекомендации по техническому анализу. О. Макарова

Embed Size (px)

Citation preview

Page 1: Методические рекомендации по техническому анализу. О. Макарова

Ольга МакароваРуководитель направления ИБ в УрФОДепартамента информационной безопасности

Методические рекомендации по проведению анализа защищённости систем ДБО

Page 2: Методические рекомендации по техническому анализу. О. Макарова

Анализ защищенности «в законе»

Постановление № 1119: «проверка кода системного и (или) прикладного программного обеспечения на отсутствие недекларированных возможностей с использованием автоматизированных средств;проверка кода системного и (или) прикладного программного обеспечения на отсутствие недекларированных возможностей без использования автоматизированных средств;тестирование информационной системы на проникновения»

Проект Приказа №21 ФСТЭК: «Выявление, анализ и устранение уязвимостей и иных недостатков в программном обеспечении»

Page 3: Методические рекомендации по техническому анализу. О. Макарова

Анализ защищенности «в законе»

СТО БР ИББС 1.0 от 2010: «7.3.5 ….. документация на

разрабатываемые АБС или приобретаемые готовые АБС и их компоненты должна содержать описание реализованных защитных мер, предпринятых разработчиком относительно безопасности разработки и безопасности поставки»;

PCI DSS разделы 6.3, 6.5 и 6.6; PA DSS

Page 4: Методические рекомендации по техническому анализу. О. Макарова

Задачи Бизнеса:От чего защищаемся?

НенаправленныеНаправленные

Внутренние Внешние

Page 5: Методические рекомендации по техническому анализу. О. Макарова

Методика тестирования

Формальных методов не существует!Но существуют рекомендации Обычно включает в себя 7 этапов

Определение границ тестирования Сбор информации Обнаружение уязвимостей Анализ найденного и планирование Проведение атак Анализ результатов и отчёты «Уборка»

ПОВТОР

Page 6: Методические рекомендации по техническому анализу. О. Макарова

Мифы и реальность

Автоматические сканеры безопасности помогут определить реальный уровень защищенности…

Пример - сканеры Web-приложений Общего назначения:

W3AF, Skipfish, Grendel-Scan, Arachni, Wapiti, Secubat

Специализированные: sqlMap, hexjector, SQLiX

Коммерческие: IBM AppScan, Acunetix, HP WebInspect

Page 7: Методические рекомендации по техническому анализу. О. Макарова

Реальность*

Лишь 29% уязвимостей XSS и 46% уязвимостей SQLi были обнаружены автоматическими сканерами

Из 615 обнаруженных уязвимостей контроля доступа (insufficient authorization) при автоматическом сканировании обнаружено всего 14, т.е. около 3%

* По статистике Web Application Security Consortium за 2008 год (самая последняя доступная редакция)

Page 8: Методические рекомендации по техническому анализу. О. Макарова

Accorute – автоматическое обнаружение уязвимостей авторизации

Разработка команды SolidLab

На вход: роли и их привилегии

На выходе: перечень возможных неавторизованных действий между ролями

С помощью Accorute автоматически найдены ранее неизвестные уязвимости в WordPress, Easy JSP Forum, PyForum

Page 9: Методические рекомендации по техническому анализу. О. Макарова

Уровни защиты клиентов

Security Level клиента

Описание

Уровень 0. Незащищенный Незащищенный

Уровень 1. Защита от ненаправленных атак

Система защищена от простых ненаправленных атак. Угрозы, как правило, исходят от вирусов, червей и хакеров-любителей.

Уровень 2. Защита от направленных атак.

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

Уровень 3. Защита от направленных атак + социальной инженерии.

Система защищена от направленных атак + социальной инженерии.

Page 10: Методические рекомендации по техническому анализу. О. Макарова

Наша модель сервисовСервис Security Level

клиентаОписание сервиса

SL SecurityBaseline

Уровень 0 Уровень 1

Цель: определить security baseline (базовый уровень ИБ). Сканирование с помощью инструментов, ручной анализ результатов.

SL SecurityAssessment

Уровни 2,3 Цель: найти как можно больше уязвимостей. Анализ исходного кода/анализ методом «черного ящика», комплексный технический аудит, эксплуатация уязвимостей и т.п.

SL Penetration testing

Уровни 2,3 Цель: достижение поставленной задачи.Проект заканчивается как только поставленная задача будет достигнута (например, получение административных прав или нарушение работоспособности сервиса).

SL Code Analysis

Для всех уровней

Цель: поиск уязвимостей в исходном коде.

SL Compliance

Для всех уровней

Цель: выполнение требований какого-либо стандарта (например, PCI DSS).

Page 11: Методические рекомендации по техническому анализу. О. Макарова

Вот получен отчет. А дальше что? Ключевой вопрос: как в экосистему критичного

приложения были привнесены эти уязвимости? Варианты обратной связи на процессы:

Место проекта по анализу защищенности в программе обеспечения ИБ

инициация/корректировка SDLC пересмотр подхода к аутсорсу ПО пересмотр подхода к аутсорсу

обслуживания пересмотр внутренних регламентов инициация/корректировка

инфраструктурных решений (WAF/протоколирование/анализ событий) 11 из 14

Page 12: Методические рекомендации по техническому анализу. О. Макарова

Какая методика будет использована в проекте? Есть ли обоснование того, что данная методика позволит

решить задачи проекта? Какое место в этой методике занимают инструменты и

какие? Наличие каких классов недостатков будет устанавливаться

при анализе? Как будут обнаруживаться логические ошибки (в т.ч.

уязвимости авторизации)? Какие классы недостатков, открытых в последнее время,

будут исследоваться в рамках проекта и каким образом? Как будет оцениваться критичность найденных недостатков?

Выбор исполнителя

12 из 14

Page 13: Методические рекомендации по техническому анализу. О. Макарова

Критичное приложение рассматривается отдельно от экосистемы

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

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

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

Типичные ошибки

13 из 14

Page 14: Методические рекомендации по техническому анализу. О. Макарова

Тест-драйв тестирования на проникновение

Этапы:Первый этап. SL Penetration testing или Baseline. При достижении цели, переходим ко второму этапу.

Второй этап. SL Security Assessment.

Page 15: Методические рекомендации по техническому анализу. О. Макарова

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

Вопросы, пожалуйста ;)

Ольга МакароваРуководитель направления ИБДепартамента информационной безопасности[email protected]