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

2. Анализ защищенности «в законе»
Постановление № 1119:
«проверка кода системного и (или) прикладного
программного обеспечения на отсутствие
недекларированных возможностей с использованием
автоматизированных средств;
проверка кода системного и (или) прикладного
программного обеспечения на отсутствие
недекларированных возможностей без использования
автоматизированных средств;
тестирование информационной системы на
проникновения»
Проект Приказа №21 ФСТЭК:
«Выявление, анализ и устранение уязвимостей и иных
недостатков в программном обеспечении»

3. Анализ защищенности «в законе»
 СТО БР ИББС 1.0 от 2010:
 «7.3.5 ….. документация на
разрабатываемые АБС или
приобретаемые готовые АБС и их
компоненты должна содержать
описание реализованных защитных
мер, предпринятых разработчиком
относительно безопасности
разработки и безопасности поставки»;
 PCI DSS разделы 6.3, 6.5 и 6.6;
 PA DSS

4. Задачи Бизнеса:
От чего защищаемся?
Направленные Ненаправленные
Внутренние Внешние

5. Методика тестирования
Формальных методов не существует!
Но существуют рекомендации
 Обычно включает в себя 7 этапов
 Определение границ тестирования
 Сбор информации
 Обнаружение уязвимостей
 Анализ найденного и планирование ПОВТОР
 Проведение атак
 Анализ результатов и отчёты
 «Уборка»

6. Мифы и реальность
Автоматические сканеры безопасности
помогут определить реальный уровень
защищенности…
Пример - сканеры
Web-приложений
 Общего назначения:
W3AF, Skipfish, Grendel-
Scan, Arachni, Wapiti,
Secubat
 Специализированные:
sqlMap, hexjector, SQLiX
 Коммерческие: IBM
AppScan, Acunetix, HP
WebInspect

7. Реальность*
 Лишь 29% уязвимостей
XSS и 46% уязвимостей
SQLi были обнаружены
автоматическими
сканерами
 Из 615 обнаруженных
уязвимостей контроля
доступа (insufficient
authorization) при
автоматическом
сканировании
обнаружено всего 14,
т.е. около 3%
* По статистике Web Application Security Consortium за 2008 год
(самая последняя доступная редакция)

8. Accorute – автоматическое обнаружение
уязвимостей авторизации
 Разработка команды
SolidLab
 На вход: роли и их
привилегии
 На выходе: перечень
возможных
неавторизованных действий
между ролями
С помощью Accorute автоматически найдены ранее неизвестные
уязвимости в WordPress, Easy JSP Forum, PyForum

9. Уровни защиты клиентов
Security Level Описание
клиента
Уровень 0. Незащищенный Незащищенный
Уровень 1. Защита от Система защищена от простых
ненаправленных атак ненаправленных атак. Угрозы, как правило,
исходят от вирусов, червей и хакеров-
любителей.
Уровень 2. Защита от Система защищена от направленных атак.
направленных атак. Угрозы, как правило, исходят от
квалифицированных хакеров, которые
имеют определенную мотивацию для атаки
на конкретную систему.
Уровень 3. Защита от Система защищена от направленных атак +
направленных атак + социальной инженерии.
социальной инженерии.

10. Наша модель сервисов
Сервис Security Level Описание сервиса
клиента
SL Security Уровень 0 Цель: определить security baseline
Baseline Уровень 1 (базовый уровень ИБ). Сканирование с
помощью инструментов, ручной анализ
результатов.
SL Security Уровни 2,3 Цель: найти как можно больше уязвимостей.
Assessment Анализ исходного кода/анализ методом
«черного ящика», комплексный технический
аудит, эксплуатация уязвимостей и т.п.
SL Penetration Уровни 2,3 Цель: достижение поставленной задачи.
testing Проект заканчивается как только поставленная
задача будет достигнута (например, получение
административных прав или нарушение
работоспособности сервиса).
SL Code Для всех Цель: поиск уязвимостей в исходном коде.
уровней
Analysis
SL Для всех Цель: выполнение требований какого-либо
уровней стандарта (например, PCI DSS).
Compliance

11. Место проекта по анализу
защищенности в программе
обеспечения ИБ
 Вот получен отчет. А дальше что?
 Ключевой вопрос: как в экосистему критичного
приложения были привнесены эти уязвимости?
 Варианты обратной связи на процессы:
 инициация/корректировка SDLC
 пересмотр подхода к аутсорсу ПО
 пересмотр подхода к аутсорсу
обслуживания
 пересмотр внутренних регламентов
 инициация/корректировка
инфраструктурных решений
(WAF/протоколирование/анализ
событий)
11 из 14

12. Выбор исполнителя
 Какая методика будет использована в проекте?
 Есть ли обоснование того, что данная методика позволит
решить задачи проекта?
 Какое место в этой методике занимают инструменты и
какие?
 Наличие каких классов недостатков будет
устанавливаться при анализе?
 Как будут обнаруживаться логические ошибки (в т.ч.
уязвимости авторизации)?
 Какие классы недостатков, открытых в последнее время,
будут исследоваться в рамках проекта и каким образом?
 Как будет оцениваться критичность найденных
недостатков?
12 из 14

13. Типичные ошибки
 Критичное приложение рассматривается отдельно
от экосистемы
 Тестирование рассматривается как проект, а не
элемент процесса
 Постановка цели и задач проекта по анализу
защищенности происходит в отрыве от модели
угроз и профилей нарушителя
 При выборе подрядчика на проведение анализа не
оценивается методика проведения работ
13 из 14

14. Тест-драйв тестирования на проникновение
 Этапы:
Первый этап. SL Penetration testing или Baseline.
При достижении цели, переходим ко второму
этапу.
 Второй этап. SL Security Assessment.

15. Спасибо за внимание!
Вопросы, пожалуйста ;)
Ольга Макарова
Руководитель направления ИБ
Департамента информационной
безопасности
Olga.Makarova@softline.ru