Методические рекомендации по техническому анализу. О....
Post on 15-Jun-2015
123 Views
Preview:
TRANSCRIPT
Ольга МакароваРуководитель направления ИБ в УрФОДепартамента информационной безопасности
Методические рекомендации по проведению анализа защищённости систем ДБО
Анализ защищенности «в законе»
Постановление № 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
top related