Информационная безопасность
Прежде чем приступить к подробной расшифровке этих терминов, давайте разберёмся, зачем вообще заморачиваться с тестированием безопасности? В современных реалиях ПО встраивается в процессы автоматизации практически во всех сферах, количество строк кода приложений увеличивается. Как следствие, растёт число возможных уязвимостей и ошибок, что формирует потребность в эффективной проверке и тестировании исходного кода.
По данным исследования Positive Technologies в 2019 году, 82% всех зафиксированных уязвимостей вызваны ошибками, допущенными при написании исходного кода. По мнению экспертов, в среднем, в каждой второй системе есть дефект безопасности с высоким уровнем риска. Один из основных источников этой проблемы – отсутствие проверок исходного кода на наличие уязвимостей во время его написания. Также один из косвенных факторов – нежелание разработчиков уделять внимание безопасности, они чаще сосредотачиваются на функциональности приложения.
Тем не менее, рост числа уязвимостей и риск их использования злоумышленниками форсирует развитие рынка безопасности приложений. Это особенно заметно из результатов исследования, проведённого Grand View Research:
Рисунок 1. Рынок безопасности приложений США по конечному, 2014–2025 гг. (млн долл. США).
Есть мнение, что не все уязвимости потенциально опасны. Некоторые из них могут быть в исходном коде годами и так ни к чему и не привести. Для выставления приоритета исправления уязвимости разработчики ориентируются на стандарт CVSS (Common Vulnerability Scoring System), но:
- она не универсальна для различных сфер;
- часть экспертов в кибербезопасности считают эту систему устаревшей (ссылка недоступна для просмотра из России) и, как следствие, опасной.
Да, можно уверенно сказать, что качество тестирования кода с годами растёт благодаря многообразию инструментов, их развитию. Старые уязвимости закрываются, но, к сожалению, появляются новые. Кроме того, развиваются инструменты и методы злоумышленников для обнаружения неправильного кода, недостатками которого можно воспользоваться.
Кроме поиска уязвимостей злоумышленники придумываются новые способы атак. Немного отвлекусь от основной темы статьи и расскажу об интересном примере. В ноябре 2021 года исследовательская группа Кембриджского университета опубликовала итоги анализа новой атаки Trojan Source, открывающей возможность заражения ПО на стадии написания исходного кода. Методика этой атаки основана на применении в комментариях к коду специальных Unicode-символов, которые меняют порядок отображения двунаправленного текста. При использовании таких управляющих символов часть текста будет отображаться слева-направо, а другая – справа-налево. То есть, если комбинировать строки с различным направлением текста в одной строке, отрывки текста, отображаемые справа-налево, могут перекрыть уже имеющийся обычный текст, отображаемый слева-направо.
Этот метод позволяет добавить в код вредоносную конструкцию и сделать текст с этой конструкцией незаметным при просмотре кода. Для этого в идущий следом комментарий или внутрь литерала добавляются символы, показываемые справа-налево, что приводит к наложению на вредоносную вставку совершенно других символов. Подобный код останется семантически корректным, но будет по-разному интерпретироваться и отображаться. Подробнее об этом можно прочитать в статье "Атака Trojan Source для внедрения в код изменений, незаметных для разработчика".
Заражённый код может привести к критическим потерям – от утечки личных данных до падения спутника прямо на дом разработчика, который решил пренебречь тестированием кода на уязвимости.
Важно понимать, что любые проблемы с безопасностью влекут не только финансовые, но и репутационные потери для компании. Если появляется соблазн не заморачиваться и пустить решение проблемы на самотёк, то крайне рекомендую держать перед глазами историю о Chrysler Jeep Cherokee, который взломали прямо во время движения.
Если вам интересны другие исследования в области информационной безопасности, то советую ознакомиться с отчётами Gartner Magic Quadrant.
AST
Итак, вернемся к нашим терминам. В ответ на постоянно растущую угрозу и увеличение кодовой базы разработчики используют инструменты AST (Application Security Testing). AST – это процесс повышения безопасности приложений путём выявления уязвимостей в исходном коде. Изначально такое тестирование проводилось вручную. Однако рост количества строк кода и случаев применения стороннего открытого кода, который тоже нужно проверять, привели к необходимости автоматизации процесса.
Использование инструментов тестирования является важной частью концепции DevSecOps. А теперь немного подробнее. В отчёте "Application Security Testing Market — Global Industry Analysis, Size, Share, Growth, Trends, and Forecast 2017–2025" от Transparency Market Research рынок тестирования безопасности приложений сегментирован на следующие классы продуктов:
- Static Application Security Testing (SAST),
- Dynamic Application Security Testing (DAST),
- Interactive Application Security Testing (IAST),
- Mobile Application Security Testing (в данной статье этот класс рассматриваться не будет).
Далее я подробнее расскажу о трёх разновидностях AST, опишу их преимущества и слабые стороны. Отмечу, что данный материал не является рекомендацией к приобретению конкретных продуктов, а носит исключительно ознакомительный характер.
SAST
Несмотря на то, что расшифровку любой аббревиатуры можно легко найти на просторах сети, я всё же не буду игнорировать эту обязанность ознакомительной статьи. SAST (Static Application Security Testing) – это процесс тестирования приложения на наличие ошибок и уязвимостей в исходном коде с применением статического анализа.
Основная задача SAST – преодолеть разрыв между разработкой и безопасностью. На заре времён, когда технология SAST только начинала своё развитие, процесс работы по ней выглядел следующим образом:
- специалисты по безопасности тестировали код на наличие уязвимостей и после этого передавали результаты предварительного сканирования разработчикам для исправления;
- после получения результатов от "безопасников" разработчики пытались разобраться с большим объёмом неясных результатов и ложных срабатываний, часто появляющихся на поздних этапах SDLС (Software Development Life Cycle – жизненный цикл безопасной разработки).
К счастью, современные технологии SAST значительно упростили описываемый процесс, сместив акцент на разработчиков.
SAST по праву считается одним из основных методов для поиска уязвимостей в исходном коде приложения. Статический анализ проводится на этапе написания кода – это позволяет находить ошибки и уязвимости на ранних стадиях разработки продукта, что снижает затраты на их устранение. Кроме того, этот метод работает с большинством языков программирования.
В качестве плюсов SAST также выделю:
- возможность интеграции статического анализа в процесс разработки, в IDE;
- автоматическое выявление критических уязвимостей, таких как переполнение буфера, SQL-инъекция, межсайтовый скриптинг (XSS) и других;
- и самое классное – указание на точное расположение подозрительного фрагмента кода, что особенно актуально для крупных проектов с сотнями тысяч и миллионами строк кода.
Но, конечно же, не всё так радужно, как хотелось бы: у SAST есть недостатки. Одним из основных – считается большое количество ложных срабатываний. Из-за этого существует риск длительной проверки каждого такого результата. Разработчики статических анализаторов уделяют пристальное внимание работе с ложными срабатываниями и создают решения для их нивелирования.
Присутствие потенциальных уязвимостей в исходном коде несёт серьёзные риски для безопасности. Использование SAST-инструментов снижает эти риски и помогает контролировать качество разработки.
На мировом рынке представлено множество различных анализаторов — как от известных вендоров в области безопасности, так и от нишевых игроков, занимающихся только разработкой SAST:
- Checkmarx,
- PVS-Studio,
- Micro Focus,
- Synopsys,
- Veracode и другие.
DAST
В предыдущем разделе я писал о статическом тестировании, в этом – я уделю внимание динамическому тестированию. DAST (Dynamic Application Security Testing) – это процесс тестирования приложений, имитирующий вредоносные внешние атаки, пытающиеся использовать распространенные уязвимости.
Главная задача DAST – обнаружение уязвимостей до того, как их обнаружит кто-то, кроме разработчиков. Такие инструменты ищут проблемные места, проверяя точки доступа и моделируя работу пользователей. Динамическое тестирование позволяет выявлять уязвимости, обусловленные различного рода инъекциями кода в запрос (например, к веб-странице) или связанные с некорректной конфигурацией (самый простой пример – возможность аутентификации по пустому паролю).
Чем отличается DAST от SAST? Отсутствием доступа к исходному коду.
Расскажу о плюсах DAST:
- анализ позволяет разработчикам выявлять проблемы во время выполнения, на что SAST не способен. Это могут быть недостатки аутентификации и конфигурации сети или проблемы, возникающие только после входа в систему;
- находит ошибки, возникающие при работе пользователя с приложением;
- позволяет протестировать приложение и выявить недостатки, которые не были найдены обычными тестами;
- DAST не привязан к языкам программирования.
Изначально DAST-инструменты использовались реже статического анализа. Но в связи с увеличивающимся спросом на безопасность и высокую динамику распространения смартфонов, в которых становится всё больше приложений, связанных с конфиденциальной информацией, доля DAST-решений значительно увеличилась и продолжает расти. IndustryARC провели исследование "Dynamic Application Security Testing Market – Forecast (2020–2025)", согласно которому рынок DAST-решений в среднем увеличивается на 17,4 % за год.
Основные игроки этого сегмента, по мнению аналитиков IndustryARC:
- WhiteHat Security,
- Synopsys,
- Veracode,
- IBM,
- Accenture,
- Pradeo Security Solutions,
- Trustwave Holdings и другие.
SAST против DAST
Как думаете, какой из указанных типов AST наиболее распространён? Если вы скажете, что в данном вопросе очевидное преимущество у SAST, то будете неправы. Но если выберете вариант DAST, то снова ошибётесь.
Согласно данным Grand View Research о распределении типов анализаторов по долям продаж в масштабах мирового рынка доли SAST и DAST практически равны.
Почему именно эти два вида AST наиболее распространены? В первую очередь это связано с тем, что они существуют дольше остальных, множество начальных недостатков уже исправлено и большинство специалистов уверенно с ними работают.
Можно ли сказать, что равенство означает, что указанные инструменты являются альтернативой друг другу? Нет.
Для большей защищённости исходного кода и продукта в целом разработчики используют и SAST, и DAST, т. к. оба метода нивелируют слабые стороны друг друга:
- DAST работает с различными наборами входных данных, что позволяет выявить их некорректную/небезопасную обработку;
- SAST хорошо показывает себя при обнаружении ошибок в исходном коде, но печально известен большим числом ложных срабатываний;
- технологии DAST не позволяют отмечать ошибки кодирования точно до номера строки кода;
- SAST легко интегрировать в работу над проектом и автоматизировать процессы. Это помогает устранить часть проблем, связанных с тестированием кодовой базы на безопасность;
- DAST понимает вызовы функций и аргументы;
- SAST умеет работать с вызовами функций и аргументами, но лишь отчасти.
Самое главное – помнить, что для разработчика важно не количество отчётов по результатам тестирования, а проверка и исправление найденных уязвимостей.
IAST
Итак, я рассказал о том, что такое SAST и DAST. Но что такое IAST? IAST (Interactive Application Security Testing) – это относительно новый (в сравнении, опять же, с SAST и DAST) тип тестирования приложений, который фокусируется на обнаружении проблем безопасности в коде приложений. Технология интерактивного тестирования позволяет анализировать приложение изнутри во время его работы.
Т. е., говоря простым языком:
- SAST работает с кодом без запуска приложения;
- DAST может работать с функционирующим приложением, но без доступа к коду;
- IAST работает с кодом изнутри функционирующего приложения.
IAST отслеживает выполнение кода и ищет конкретные события, которые могут привести к уязвимости. Далее эти события анализируются с целью проверить, всё ли с ними хорошо и не закралась ли какая-либо ошибка.
IAST разрабатывался как современное решение, позволяющее устранить недостатки SAST и DAST благодаря объединению подходов к тестированию. Технология интерактивного тестирования обеспечивает обнаружение проблем безопасности в режиме реального времени, анализируя трафик и поток выполнения приложений.
Т. к. IAST работает внутри приложения, он может анализировать:
- код приложения;
- потоки данных;
- конфигурации;
- HTTP-запросы и ответы;
- библиотеки, фреймворки и другие компоненты;
- информацию о внутреннем подключении.
Доступ ко всей этой информации позволяет механизму IAST охватывать больший объем кода, давать более точные результаты и проверять более широкий набор правил безопасности, чем SAST или DAST.
Кроме того, благодаря точности IAST обнаруживает больше существующих рисков. Для наглядности приведу пример по работе с покрытием OWASP Benchmark:
- некоторые IAST-инструменты достигают 100 % покрытия без ложных срабатываний;
- в то время как SAST предлагают только частичное обнаружение (не лучше 80% от OWASP Benchmark) и выдают много ложных срабатываний;
- инструменты DAST обеспечивают низкий уровень обнаружения, около 10–15% от OWASP Benchmark.
Несмотря на определённое превосходство над SAST и DAST, у интерактивного тестирования безопасности также есть минусы.
Одним из основных недостатков принято считать то, что инструменты IAST могут замедлять работу приложения. Агенты, по сути, служат дополнительными инструментами, что приводит к снижению производительности кода.
Также крайне тяжело подготовить входные данные и сценарии работы, позволяющие достичь высокого покрытия кода. Т. е. теоретически IAST действительно позволяет покрыть 100 % кода, но на практике это может быть очень сложно и трудозатратно. В этом смысле SAST выглядит предпочтительнее, так как эти инструменты анализируют все ветки программы, независимо от вероятности их исполнения.
Заключение
Application Security Testing – важная часть концепции DevSecOps, которую нельзя игнорировать в современных реалиях разработки. AST необходимо использовать для проверки исходного кода на уязвимости, безопасности входов, соединений и интеграции между внутренними системами.
В заключении статьи хочу выделить несколько важных аспектов:
- нет универсального решения для обеспечения 100 % безопасности разработки. Тем не менее своевременное использование инструментов тестирования позволяет находить потенциальные уязвимости и исключать возможность превращения их в реальные угрозы безопасности;
- SAST и DAST не являются взаимоисключающими инструментами. Совместное применение обеих технологий на соответствующих этапах разработки позволит достичь лучших показателей безопасности исходного кода;
- инструменты SAST по своей природе предназначены для использования в рамках непрерывной интеграции. Инструменты DAST часто ошибочно воспринимаются как непригодные для автоматизации, но вопреки таким мнениям передовые решения DAST успешно используются в конвейерах CI/CD многими предприятиями;
- внедрение IAST в SDLC часто является более сложным, но оно того стоит ввиду универсальности инструмента;
- IAST совмещает в себе как достоинства, так и некоторые недостатки SAST и DAST;
- методы AST должны применяться к любому стороннему коду, используемому в разработке. Нет гарантий, что компонент от третьей стороны является безопасным, независимо от того, коммерческий он или с открытым исходным кодом.
0 комментариев