Практика использования Solar inCode

Solar inCode – практика
использования
Чернов Даниил
CISA, CISSP
Руководитель направления
Application Security
Александров Ярослав
Ведущий разработчик
14.10.2016

solarsecurity.ru +7 (499) 755-07-70
Особенности разработки приложений
с точки зрения ИБ
Дыры в софте:
 Уязвимости
 Недекларированные
возможности (закладки)
2

Как проверить софт?
3
Динамический анализ Статический анализ

Сложности
4
 Получить исходный код у разработчиков
 Убедиться, что код «собирается в проект» и не имеет
«неразрешенных зависимостей»
 Проверить код: корректно запустить скан
 Суметь понять, что написано в отчете
 Донести до разработчиков все найденные уязвимости
и объяснить их понятным языком

Solar inCode – сканер программного кода
• умеет работать без исходных кодов. Это значит, что не надо просить
исходные коды у разработчиков, а можно получить скомпилированные
файлы для анализа у системного администратора или скачать
мобильные приложения с Google Play или AppStore.
Практичность и удобство
• выдает детальные рекомендации по настройке наложенных средств
защиты: SIEM, WAF, Firewall
Настройка средств защиты
• выдает детальные рекомендации по устранению уязвимостей̆ кода на
русском языке с описанием способов их эксплуатации
Понятные рекомендации
5

Уязвимости
Уязвимость – особенность кода, нарушающая
целостность, доступность или конфиденциальность
Уязвимости возникают из-за:
ошибок использования языковых конструкций и библиотек
использования заимствованного кода
наличия уязвимостей сторонних компонент
Уязвимости web-приложений:
SQL Injection, XSS, Code Injection, Broken Cryptography, Data
Leakage, Other injections, Correctness
Уязвимости мобильных приложений:
Data Leakage (SSL, http), Data Storage, Broken Cryptography, IPC,
Injections, Correctness
6

Закладки
Закладка – уязвимость, внесенная намеренно
 Чаще всего – получение неавторизованного доступа
Автоматически невозможно определить намерение, но
можно выделить характерные логические конструкции
 Специальные учетные записи (логины, пароли, хеши, ключи, сравнения)
 Скрытая функциональность (невидимые параметры запроса, внедрение
кода, обфусцированный код)
 Недокументированная сетевая активность (внедрение в функции
работы с сетью, утечка ценных данных)
 Изменение параметров безопасности (подмена ключевых значений)
 Встроенные обращения к интерпретатору
 Временная бомба
 Мертвый код
7

Поиск уязвимостей и закладок
Поиск уязвимостей и закладок с помощью методов статического
анализа (анализ кода без выполнения)
Полное покрытие кода независимо от правил поиска
уязвимостей
Анализ по модели кода (внутреннему представлению)
Анализ распространения потока данных (dataflow)
• Taint-анализ, строковый, интервальный анализ (SQL Injection и т.п.)
Анализ потока управления (control flow)
Максимизация точности и полноты анализа
Углубление алгоритмов
Уточнение правил
Solar inCode - Enterprise система
Web-интерфейс, интеграция в процесс разработки
8

Настройка сканирования
Запуск сканирования
Источник кода (архив, репозиторий, магазин, исполняемый
файл)
Требования сборки (анализ исходного кода Java, Scala, C/C++,
ObjectiveC)
Настройки проекта
Исключение кода
Задание наборов правил поиска уязвимостей
Использование пользовательских правил
Перезапуск сканирования
9

Результаты сканирования
Оценка безопасности приложения
Локализация уязвимости в исходном коде
Информация об уязвимости
Подробное описание, примеры
Рекомендации по устранению
Ссылки на источники
Фильтрация по критичности уязвимости
Отображение по уязвимостям и по файлам/пакетам
Удаление уязвимости (одиночное и групповое)
Изменение критичности уязвимости (одиночное и групповое)
Комментарии к вхождениям уязвимостей
Отслеживание истории уязвимости (в том числе ложных
срабатываний)
10

Интеграция в процесс разработки
Инструмент командной строки (генерация REST-запросов,
аутентификация через токен)
Сервер CI (Continuous Integration) – Jenkins, TFS
Репозиторий разработки – git, svn, TFS
Система багтрекинга – JIRA, Redmine
Средство сборки и IDE – maven, gradle, sbt, Eclipse, Visual Studio
Пример
Запуск анализа из ветки репозитория, куда совершен коммит
По результатам анализа исправление критических уязвимостей
назначается исполнителям в систему багтрекинга
Разработчик запускает сканирования из IDE при разработке
11

Правила поиска уязвимостей
Xml-язык записи правил
Поддержка базы правил в
актуальном состоянии
Пользовательские правила
поиска уязвимостей
Специфика требования
разработки –
фреймворки, style guide
Документация по
разработке правил
12

Остальная функциональность
Межпроектная аналитика
Динамика результатов в группе
Сравнение результатов в группе
Состояние сканирований в группе
Рекомендации по настройке СЗИ
F5, Imperva, ModSecurity
Управление правилами
Редактирование описаний
Работа с наборами правил
Выгрузка pdf и html отчетов
Конструктор отчета
Выгрузка по PCI DSS 3.2, OWASP Top 10 / OWASP Mobile Top 10
13

Анализ без исходного кода
Анализ без исходного кода: Java, Android, iOS
jar, war
apk, Google Play
ipa, AppStore
Декомпиляция кода и отображение результатов на
восстановленный код
Комбинированная предобработка проектов на Java (и
исполняемый, и исходный код)
Анализ библиотек
Анализ собранного проекта (не зависит от поддержки средства
сборки)
14

Даниил Чернов
Руководитель направления
Application Security
d.chernov@solarsecurity.ru
Ярослав Александров
Ведущий разработчик
y.alexandrov@solarsecurity.ru
www.solarsecurity.ru

Практика использования Solar inCode

More Related Content

Практика использования Solar inCode