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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПОВТОР

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

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

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

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

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

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

Реальность*

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

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

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

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

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

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

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

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

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

Security Level клиента

Описание

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

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

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

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

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

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

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

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

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

SL SecurityBaseline

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

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

SL SecurityAssessment

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

SL Penetration testing

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

SL Code Analysis

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

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

SL Compliance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12 из 14

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

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

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

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

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

13 из 14

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

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

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

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

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

Ольга МакароваРуководитель направления ИБДепартамента информационной безопасностиOlga.Makarova@softline.ru