Сравнение методологий
Есть нескольких важных критериев, которые следует учитывать при выборе инструмента анализа безопасности приложения.
Первым и очень важным показателем является сложность внедрения (Implementation complexity). Хороший инструмент должен легко интегрироваться в существующую инфраструктуру разработки.
Второй критерий — влияние на время SDLC (Operation time). Определяет, насколько сканер замедляет жизненный цикл ПО.
Следующий параметр — ложноположительные срабатывания (False positives). Он означает, что инструмент сигнализирует о возможных проблемах там, где их нет.
И последний критерий — ложноотрицательные срабатывания (False negatives). Здесь рассматривается вероятность возникновения ошибок, которые инструмент не сумеет выявить.
Далее я сравню популярные решения по перечисленным выше параметрам.
Компонентный анализ (SCA)
Практически все компании используют компоненты c открытым исходным кодом в процессе разработки ради экономии денег и ресурсов специалистов. Такое ПО может содержать критические уязвимости, поэтому необходимо анализировать его состав и вовремя устранять проблемы.
SCA (Software composition analysis) — это мощная практика, основанная на сканировании и анализе компонентов open source на наличие известных уязвимостей. Такая методика помогает компаниям обеспечивать безопасность приложений и предотвращать атаки, реализуемые за счет наличия проблемных компонентов.
Компонентный анализ, как правило, выполняет следующие действия:
- проверяет код сторонних разработчиков;
- находит известные уязвимости;
- выявляет проблемы с лицензиями;
- обнаруживает вредоносные программы;
- ищет случаи модификации кода;
- выделяет слабые шаблоны кода.
Сложность внедрения. SCA легко внедряется в жизненный цикл разработки ПО (SDLC) — для этого достаточно лишь знать список зависимостей.
Влияние на время SDLC. Operation time данной практики зависит от уровня предоставленной оценки. Если найдено много проблем безопасности, весь процесс безусловно замедлится на время устранения ошибок.
Ложноположительные срабатывания. Они происходят нечасто, и их количество зависит от качества базы данных Common Vulnerabilities and Exposures (CVE).
Ложноотрицательные срабатывания. False negatives случаются чаще как раз из-за использования CVE и инструментов, сопоставляющих имена зависимостей с шаблоном. Применение более качественных инструментов SCA уменьшает вероятность получения ложноотрицательных результатов, что особенно важно для организаций, работающих с чувствительными данными.
Инструменты SCA позволяют просматривать импортируемые зависимости, но не используются для проверки своей кодовой базы. Конечно, тестирование с их помощью позволит выявить критические проблемы, но для выполнения остальных ИБ-требований нужны будут другие методики, о которых пойдет речь ниже.
Статическое тестирование безопасности приложений (SAST)
SAST (Static application security testing) — это тестирование приложения на этапе разработки с применением техники статического анализа. С помощью инструментов SAST мы получаем сведения о проблемах на ранних стадиях создания ПО, тем самым экономя ресурсы на проверку кода и безопасность в дальнейшем.
Используя различные алгоритмы и правила проверки, SAST сканирует исходный код и находит такие проблемы, как неправильное использование функций, недостаточная обработка ошибок или уязвимости ввода данных. Еще одна важная особенность статического анализа — возможность тестирования больших и сложных программных продуктов. Он может работать с различными языками программирования, такими как C, C++, Java, C#, Python и другими.
Сложность внедрения. Инструментарий требует настройки для исключения ложных срабатываний, поэтому имеет среднюю сложность внедрения.
Влияние на время SDLC. Делает построчный анализ кода, иногда может давать ложные срабатывания — всё это требует дополнительного времени и ресурсов команды, но не сильно тормозит процесс.
Ложноположительные срабатывания. Помимо того, что статический анализ находит уязвимости на ранних этапах разработки, нередко он заставляет нас беспокоиться напрасно, выдавая ложноположительные срабатывания. С ними можно справиться, если хорошо настроить SAST на игнорирование незначительных элементов. Сразу отмечу, что этот процесс займет некоторое время и потребует подключения разработчиков, поэтому рекомендую внедрять такое тестирование постепенно.
Ложноотрицательные срабатывания. Встречаются редко, так как практически невозможно обнаружить уязвимости, появляющиеся во время выполнения программы или вызванные сторонними зависимостями.
В отличие от SCA, SAST способен рассмотреть код полностью и подходит для продуктов, разрабатываемых командами различного масштаба и сложности. Он также эффективно совмещается с другими методами сканирования безопасности, что позволяет обеспечить высокий уровень защищенности приложений.
Динамическое тестирование безопасности приложений (DAST)
DAST (Dynamic application security testing) имитирует действия внешних злоумышленников, которые пытаются использовать распространенные уязвимости. Главная цель динамического анализа — найти проблемы до того, как они будут обнаружены хакерами.
В отличие от статического анализа безопасности, которое проводится на этапе разработки и проверяет исходный код, DAST проводит тестирование на рабочем приложении в реальном времени. Это позволяет выявить уязвимости, связанные с динамическим поведением приложения, включая инъекции кода или некорректную конфигурацию.
Преимущества DAST:
- Обнаруживает реальные уязвимости приложения на основе активного использования, а не только на базе анализа кода. Это приближает процесс тестирования к реальной среде эксплуатации.
- Дает возможность повторного выполнения тестов с теми же настройками, чтобы проверить исправленные уязвимости и убедиться, что проблемы были решены.
- Способен сканировать различные приложения, включая мобильные и веб-сервисы.
- Проводит активные атаки на приложение, чтобы идентифицировать потенциальные уязвимости. Это может предотвратить их эксплуатацию злоумышленниками.
Эта методология, безусловно, уникальна и ставит в приоритет не специфику выполняемого кода, а результат.
Сложность внедрения. Низкая или средняя, не требует знания целевого объекта или экосистемы за пределами конечной точки.
Влияние на время SDLC. Практически не имеет, так как весь процесс строится от симуляции независимых атак.
Ложноположительные срабатывания. А вот они встречаются довольно часто как раз за счет проводимых атак.
Ложноотрицательные срабатывания. Здесь показатели средние, так как не все уязвимости можно обнаружить в результате атак. Инструменты, как правило, не требуют особой настройки для начала работы. Они не будут генерировать много срабатываний, поскольку предоставляют только те возможности, которые доступны в данный момент.
Чаще всего динамический анализ используется перед развертыванием, но может применяться и для выявления ошибок в среде промышленной эксплуатации.
DAST можно сравнить с автотестом на проникновение, поскольку он имитирует действия киберпреступников. Инструментарий обычно представляет собой блоки, в которые вводятся значения. Далее запускается команда на выполнение. Такой анализ может выявить, например, уязвимости проверки ввода (SQL Injection, XSS), проблемы аутентификации, ошибки конфигурации или слабые шифры. Отмечу, что динамическое тестирование показывает обнаруженные проблемы, но не их причины.
Интерактивное тестирование безопасности приложений (IAST)
IAST (Interactive application security testing) — метод анализа, который ищет проблемы безопасности в коде приложений. Этот тип тестирования объединяет элементы подходов SAST и DAST, то есть имеет доступ одновременно к коду и работает с функционирующим ПО.
Методика дает конкретные результаты, помогая команде разработки внедрять исправления значительно быстрее. IAST не будет выдавать чересчур много ложных срабатываний, если его грамотно настроить.
Сложность внедрения. Высокая, так как требует всестороннего знания целевой системы.
Влияние на время SDLC. Дополнительный процессный уровень может оказать небольшое влияние на время выполнения целевой программы.
Ложноположительные срабатывания. Редки, поскольку обнаружение уязвимостей происходит как в коде, так и в среде выполнения.
Ложноотрицательные срабатывания. Аналогично ложноположительным срабатываниям, если инструмент настроен правильно.
Инструменты IAST могут быть активными или пассивными. Вторые предоставляют комплексный подход к тестированию, они более надежны и целостны. Это связано с тем, что активные инструменты IAST требуют от вас глубокого погружения и обработки ответов, в то время как пассивные справляются с задачей практически без вашего участия.
В обоих случаях IAST работает аналогично DAST и RASP, поскольку тестирует работающее приложение. Он также погрузится в кодовую базу и будет выполнять запросы извне. Различия между пассивным и активным IAST заключаются в том, где и как выполняется тестирование.
Активный IAST подобен DAST++. Контролируемое выполнение запускает тесты извне, а логика внутри приложения следит за тем, что происходит. DAST-тесты будут приходить в приложение, а IAST-логика будет отслеживать их по каждой строке кодовой базы. Как только произойдет что-то нетипичное, будет зафиксировано точное место в коде, где была обнаружена аномалия. Всё это будет отражено в результатах тестирования, которые помогут устранить уязвимость.
Независимо от того, какой подход вы решите применить, для внедрения инструментов потребуется достаточно большой ресурс, а сложность реализации будет зависеть от разных факторов. Например, может случиться так, что для кодовой базы потребуется построчная интеграция. Осуществить ее непросто, но вы будете получать конкретные результаты, и разработка сможет внедрять исправления значительно быстрее, чем с помощью DAST. При этом IAST не будет выдавать много ложных срабатываний.
Самозащита приложений во время выполнения (RASP)
RASP (Runtime application self-protection) — это технология безопасности, которая предлагает защиту приложений в реальном времени путем интеграции функций безопасности прямо в среду выполнения ПО. Это позволяет обеспечить собственную «самозащиту» автоматическим образом.
Одной из основных особенностей RASP является то, что она сфокусирована на предотвращении атак по умолчанию. Для ее работы не требуется доступ к исходному коду приложения, а политики безопасности легко настроить и адаптировать в соответствии с изменениями в приложении.
Большая часть анализа воздействия идентична пассивному IAST. Ключевое различие между методиками заключается в том, что интерактивное тестирование предупреждает нас, а RASP защищает.
Этот инструмент обладает высокой степенью контроля над окружением и сетевым трафиком. Это позволяет ему отмечать результаты активностей, отклонять запросы или исправлять любые изменения, которые были осуществлены в результате эксплуатации уязвимости.
Заключение
Я сравнил популярные методики тестирования безопасности по четырем критериям. Каждая из них имеет уникальные преимущества и недостатки, поэтому невозможно однозначно определить, какой способ лучше справится с анализом вашего продукта.
Например, SAST позволяет выявить потенциальные уязвимости на ранних этапах разработки, в то время как DAST осуществляет проверки в реальном времени и выявляет потенциальную угрозу.
Чтобы специалисты смогли проводить тестирование, получая исчерпывающие полезные отчеты, и разбираться с любыми трудностями, важно использовать хотя бы один инструмент с открытым исходным кодом: IAST, DAST или SAST. Также стоит уделить внимание настройке SCA — убедитесь, что он соответствует размеру, сложности и критичности вашей среды. При помощи комбинации различных методов можно полноценно проанализировать безопасность приложения и сделать его более защищенным. В свою очередь, это будет способствовать повышению качества разработки и снизит риск возникновения новых уязвимостей.
Правильно выбранные инструменты позволяют обеспечить безопасность приложений на всех этапах разработки, помогают снизить затраты и делают бизнес более зрелым и гибким.
