По статистике 90% инцидентов безопасности возникают в результате использования злоумышленниками известных программных ошибок. Естественно, что устранение уязвимостей на этапе разработки ПО значительно снижает риски информационной безопасности.
Для этого в помощь разработчикам был создан целый ряд технологий, позволяющих выявлять недостатки безопасности на ранних этапах, избавляясь от них до релиза продукта. К таким технологиям можно отнести:
- SAST
- DAST
- IAST
- RASP
SAST и DAST
SAST (Static Application Security Testing) — тестирование «белого ящика», существует уже более десяти лет. Позволяет разработчикам находить уязвимости безопасности в исходном коде приложения на ранних этапах жизненного цикла разработки ПО. SAST также обеспечивает соответствие руководствам и стандартам кодирования без фактического выполнения базового кода.
DAST (Dynamic Application Security Testing) — тестирование «черного ящика», может обнаруживать уязвимости и слабые места в работающем приложении, обычно веб-приложениях. Это достигается за счет использования методов внедрения ошибок в приложении, таких как передача вредоносных данных в программное обеспечение, для выявления распространенных уязвимостей безопасности, например, SQL-инъекций и межсайтовых сценариев.
DAST также может пролить свет на проблемы времени выполнения, такие как:
- проблемы аутентификации и конфигурации сервера
- недостатки, видимые только при входе известного пользователя
Обнаружить это с помощью статистического анализа нельзя.
SAST и DAST часто используются в тандеме, так как:
- SAST не будет обнаруживать ошибки времени выполнения
- DAST не будет отмечать ошибки кодирования, по крайней мере, до номера строки кода
SAST хорошо работает, когда дело доходит до обнаружения ошибки в строке кода, например, слабой генерации случайных чисел, но обычно не очень эффективен при обнаружении недостатков потока данных. Кроме того, решения SAST известны большим количеством ложноположительных или ложноотрицательных результатов.
Абстрактная интерпретация
Некоторый успех в уменьшении или полном исключении ложных срабатываний был достигнут с помощью так называемой абстрактной интерпретации. Однако для получения наилучших результатов алгоритмы абстрактной интерпретации должны быть адаптированы к:
- кодам, использующим домен приложения, который включает его архитектуру
- способам использования определенных числовых алгоритмов
- типам структур данных, которыми оно манипулирует
Несмотря на все недостатки SAST, он и по сей день остается фаворитом среди команд разработчиков.
Основной критерий выбора – возможность сканировать проект на уровне кода.
Это позволяет находить недостатки на ранних этапах разработки продукта, что способствует снижению затрат на их устранение.
Более того, SAST можно автоматизировать и прозрачно интегрировать в рабочий процесс проекта. Это устраняет некоторые проблемы, обычно связанные с тестированием приложений на безопасность. Данная особенность сильно контрастирует с DAST, где для крупных проектов придется создавать отдельную инфраструктуру, выполнять специальные тесты и запускать несколько экземпляров приложения параллельно с различными входными данными.
Зато DAST понимает аргументы и вызовы функций, чего не скажешь о SAST.
IAST
IAST (Interactive Application Security Testing) — интерактивное тестирование безопасности приложений. SAST и DAST являются относительно старыми технологиями, поэтому бытует мнение, что они не лучший выбор для тестирования современных:
- Веб-приложений
- Мобильных приложений
Например, SAST плохо работает с:
- Библиотеками
- Фреймворками
А все это присутствует практически в каждом современном приложении.
Статические инструменты видят только исходный код приложения, которому они могут следовать. Более того, библиотеки и сторонние компоненты часто приводят к зависанию статических инструментов, создавая сообщения:
- «lost sources»
- «lost sinks»
Аналогично и с фреймворками. Статический инструмент не обнаружит ничего неправильного в:
- API
- веб-сервисе
- конечной точке REST
Все потому, что он не может понять их структуру.
IAST разработан для устранения недостатков SAST и DAST путем объединения элементов обоих подходов. IAST выполняет весь анализ в режиме реального времени:
- в любом месте процесса разработки IDE
- непрерывной интегрированной среде
- производственной среде
Поскольку IAST работает внутри приложения, он может анализировать:
- код приложения
- потоки данных
- конфигурации
- HTTP-запросы и ответы
- библиотеки, фреймворки и другие компоненты
- информацию о внутреннем подключении
По сравнению с SAST или DAST доступ ко всей этой информации позволяет механизму IAST:
- покрывать больше кода
- выдавать более точные результаты
- проверять более широкий спектр правил безопасности
RASP
RASP (Run-time Application Security Protection) — защита безопасности приложений во время выполнения. Как и IAST работает внутри приложения, но это скорее инструмент безопасности, а не тестирования. Он подключается к приложению или его среде выполнения и может контролировать выполнение приложения. Это позволяет RASP защитить приложение, даже если защита периметра сети нарушена, а приложения содержат уязвимости безопасности.
RASP позволяет приложению проводить непрерывные проверки безопасности и отвечать на атаки в реальном времени, завершая сеанс злоумышленника и предупреждая защитников об атаке.
Недостатки RASP
Главная проблема RASP заключается в том, что он может создать у команды разработчиков ощущение ложной безопасности. Некоторые меры безопасности могут игнорироваться по причине, — «Если мы что-то упустим, RASP это исправит».
Еще к недостаткам технологии RASP можно отнести ухудшение производительности приложений. Такой же минус есть и у IAST. Несмотря на то, что с ускорителями технологий можно свести снижение производительности к минимуму, неприятный осадок все равно остается.
У всех вышеперечисленных технологий есть свои достоинства и недостатки, поэтому их комбинация друг с другом обеспечит более высокий уровень безопасности. Однако использование даже одной технологии на ранних этапах разработки позволяет создать более безопасное ПО, а главное сделать это быстрее и с меньшими затратами, чем привязывать все тесты уже столкнувшись с проблемой на поздних этапах.
