OWASP (Open Web Application Security Project) – международное открытое сообщество, нацеленное на улучшение безопасности программного обеспечения. Миссией OWASP является предоставление информации о безопасности приложений в доступном для всех виде, чтобы люди и компании могли принимать осознанные решения о рисках безопасности в веб-приложениях. Каждый имеет право участвовать в OWASP и все их материалы свободно распространяемы.

Работа OWASP Testing Guide v4 состоит из следующих глав:

1. Фронтиспис (о версии работы и её авторах)
2. Введение (о проекте, о тестировании и техниках тестирования)
3. Фреймворк для тестирования (способы тестирования на различных этапах жизненного цикла приложения)
4. Тестирование веб-приложений (как тестировать уязвимости)
5. Составление отчёта о тестировании

На текущий момент на портале выпускается перевод главы 4. В данной статье представлен перевод не менее значимой главы 2 оригинальной работы. Из-за объема глава будет разделена на несколько частей.

Введение

Оценка безопасности: экономика незащищённого ПО

Оценка безопасности связана не только с конкретными техническими проблемами (например, насколько распространена уязвимость), но и с тем, какое экономическое влияние оказывают эти проблемы. Большинство людей технических профессий могут определить только первое, и лишь немногие могут перевести техническую информацию в денежный эквивалент, чтобы оценить потенциальную стоимость уязвимости для владельца приложения. А пока этого не случится, бизнес не сможет посчитать возврат от инвестиций и, соответственно, не сможет точно оценить необходимый бюджет для обеспечения безопасности приложения.

OWASP предлагает оценивать безопасность приложения на каждом этапе его жизненного цикла. Таким образом, компания сумеет соотнести стоимость уязвимого приложения с тем, как оно может повлиять на бизнес и, впоследствии, скорректировать бизнес-процессы, выделить дополнительные ресурсы для управления рисками.

Что такое тестирование?

Тестирование – это процесс сверки состояния системы или приложения со списком критериев. Обычно этот список является субъективным и зависит от тестировщиков, но данное руководство призвано изменить этот устоявшийся подход и сделать процесс проще для людей, не обладающих глубокими знаниями в области ИБ.

Зачем нужно проводить тестирование?

Целью данной работы является объяснение того, что включает в себя программа тестирования веб-приложения и что нужно сделать, чтобы разработать и провести её. Данное руководство предоставляет широкий обзор элементов, из которых создаётся всесторонняя программа тестирования. Оно может быть использовано как справочник и как методология, которая помогает определить разрыв между существующими практиками и лучшими практиками вашей отрасли.

Когда проводить тестирование?

Многие компании не проводят тестирование ПО до тех пор, пока оно не выпущено. В большинстве случаев это оказывается неэффективной и дорогостоящей практикой. Одним из лучших методов предотвращения появления угроз безопасности в приложении является включение проверки безопасности на каждую стадию жизненного цикла программного обеспечения (далее – ЖЦ ПО). Примером модели ЖЦ ПО может является модель SDLC, которая включает в себя 5 стадий (см. рис.1). На данной модели, её внешнем круге, также отмечена необходимая доля проверок безопасности на каждой стадии.

Рисунок 1. Модель жизненного цикла SDLC

Что тестировать?

Важно понимать, что в создании ПО участвуют 3 составляющие: технологии, процессы и люди. Логично предположить, что если эти факторы участвуют в разработке ПО, то их и необходимо тестировать, причём по отдельности. Сегодня же большинство компаний проверяют либо технологию, либо само приложение.

Эффективной программой тестирования можно назвать ту, которая будет содержать проверки:

• Людей – с целью убедиться в том, что они компетентны и дают отчёт в собственных действиях;
• Процессов – убедиться, что существующие политики и стандарты соответствуют требованиям, и люди знают, как им следовать;
• Технологий – убедиться, что процессы были эффективно реализованы.

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

Денис Вердон, выступая на OWASP AppSec 2004, привёл отличную аналогию к этой проблеме:

«Если бы машины делали как приложения […] проверки безопасности подразумевали бы только лобовые удары. Машины бы не проверяли на устойчивость, стабильность в экстренных манёврах, на эффективность торможения, боковой удар и попытку угона.»

Принципы тестирования

Не существует «серебряной пули»

Если вы думаете, что сканер уязвимостей или фаервол обеспечивают защиту вашего приложения или находят в нём все слабости, то мы вынуждены вас огорчить. В этом деле не существует «серебряной пули», способной обезопасить приложение. ПО для проверки уязвимостей в приложениях может быть полезным в качестве первого этапа проверки для нахождения очевидных уязвимостей, но для полноценного тестирования этого недостаточно. Помните: безопасность – это процесс, а не продукт.

Думайте стратегически, а не тактически

Время показало, что общепринятая модель исправления багов, когда вслед за обнаруженной уязвимостью выпускается новый патч, неэффективна, поскольку при этом не происходит должного изучения корня проблемы. Данную модель можно представить по рисунку, представленному ниже (см. рис.2).

Жизнь уязвимости с момента её обнаружения до установки патча против неё называют «окном уязвимости», и подробнее об этом можно почитать здесь [https://www.schneier.com/crypto-gram-0009.html].

Анализ уязвимостей [https://www.symantec.com/security-center/threat-report] показал, что атака через уязвимость начинается раньше, чем установка патча, который её закрывает. Это происходит из-за того, что время между обнаружением уязвимости и написанием скрипта для атаки с её использованием уменьшается от года в год.

Есть ещё несколько причин, почему модель «проникновение-патч» не работает так, как бы хотелось. Во-первых, многие пользователи думают, что патчи могут повлиять на работу существующих приложений и поэтому боятся их устанавливать. Во-вторых, далеко не все пользователи вообще знают о недавно выпущенных патчах.

Именно поэтому так важно встраивать проверки безопасности во все стадии ЖЦ ПО: многие корневые причины проблем будут найдены ещё до выпуска ПО. Скорее всего организации нужно будет дополнить стандарты, политики и руководства, причём так, чтобы они не мешали основному процессу разработки. Моделирование угроз и другие техники тестирования тоже должны быть использованы для определения необходимых ресурсов по тем частям системы, которые наиболее всего подвержены риску.

Рис 2. Окно уязвимости в модели «проникновение-патч».

Тестируйте рано и часто

Чем раньше в ЖЦ ПО обнаруживается баг, тем дешевле и проще его устранить. Баг, влияющий на безопасность, такой же баг, как и все другие. Для их поиска нужно проводить обучение команды разработчиков и показывать им типичные проблемы безопасности, способы их обнаружить и устранить. Несмотря на то, что новые библиотеки, инструменты или языки могут помочь создать более безопасные программы, угрозы появляются постоянно и разработчики должны быть в курсе тех угроз, которые влияют на разрабатываемое ими ПО. Обучение тестированию угроз также может помочь сформировать у разработчиков взгляд на приложение со стороны злоумышленника. В целом, это позволяет сотрудникам компании рассматривать проблемы безопасности как часть существующих у них обязанностей.

Понимание границ безопасности

Важно понимать, насколько защищённым должен быть разрабатываемый проект. Информация и ресурсы, которые требуется защищать, должны быть классифицированы по уровню защищённости (например, конфиденциальные, секретные, совершенно секретные). При наличии дополнительного государственного регулирования такой информации и ресурсов необходимо убедиться в том, что все законные требования будут выполнены.

Развивайте нестандартное мышление

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

Более того, креативное мышление может помочь найти неверные допущения веб-разработчиков и способы их обхода. Одной из причин, почему автоматические инструменты плохо проверяют уязвимости — это то, что в каждом новом случае нужно рассуждать по-новому, так как большинство веб-приложений разрабатываются уникально (даже несмотря на использование общеизвестных фреймворков).

Понимание объекта защиты

Архитектура приложения, диаграмма потоков данных, сценарии использования – всё это, а также многие другие документы, должны быть готовы и доступны для проверки. Техническая спецификация и документация к приложению должна включать информацию не только о желаемых, но и о любых специально запрещённых сценариях использования. Кроме этого, неплохо иметь хотя бы простую систему, отслеживающую тенденцию атак на приложения и сеть компании (например, системы обнаружения атак), для понимания наиболее актуальных потенциальных угроз приложению.

Дьявол кроется в деталях

Проведение поверхностного тестирования безопасности может вселить ложное чувство уверенности, что может быть более опасным, чем не проведение тестирования совсем. Необходимо детально проанализировать полученные сведения и отсеять все ложные заключения. Нахождение несуществующей уязвимости чаще всего подрывает надёжность всего остального в отчёте. Вы должны быть уверены в том, что каждая доступная часть приложения была протестирована, и каждый сценарий использования был изучен на наличие возможных уязвимостей.

Анализируйте исходный код, если это возможно

Результаты тестирования на проникновение методом чёрного ящика могут быть впечатляющими и демонстрировать то, как уязвимости эксплуатируются на боевой среде. Однако это не самый эффективный способ обезопасить приложение. При динамическом тестировании сложно тестировать всю базу кода, если в ней существует множество условных конструкций. Если есть доступ к исходному коду приложения, он должен быть передан сотрудникам безопасности для проведения экспертизы. Они могут обнаружить уязвимости в коде приложения, которые были бы пропущены в ходе тестирования методом чёрного ящика.

Разработайте метрики

Важной частью хорошей программы тестирования является способность определить, становится ли приложение безопасней и насколько. Нужно отслеживать результаты тестирований и разрабатывать метрики, определяющие тенденции безопасности приложения внутри организации. Хорошие метрики могут указать на:

• необходимость обучения и тренингов;
• наличие механизма безопасности, неусвоенного командой разработчиков;
• уменьшение числа обнаруженных проблем ежемесячно.

Создание метрик – дело непростое. Но, в качестве стандартных метрик, например, можно использовать, представленные в OWASP Metrics Project.

Документируйте результаты тестирований

Для подведения итогов процесса тестирования важно документировать все действия: кем, когда, что тестировалось и детали того, что было обнаружено. Желательно договориться о едином формате отчёта, подходящем для всех заинтересованных сторон, которые могут включать разработчиков, менеджеров проекта, руководителей, IT департамент, аудиторов и юристов.

Отчёт должен быть понятен бизнесу. В нём должны быть выделены проблемы, где существует материальный риск и обоснована необходимость выполнения действий, смягчающих риск.

Отчёт должен быть понятен разработчику. В нём должны быть указания на конкретную функцию, на которую оказывает влияние уязвимость и связанные с этим рекомендации для решения проблем.

Отчёт должен позволять другому тестировщику воспроизвести полученные результаты самостоятельно.

Написание отчёта не должно быть чрезмерно тяжким и для самой команды тестировщиков. Специалисты по безопасности обычно не славятся хорошим писательским навыком, и поэтому, утверждение сложной структуры отчёта может привести к тому, что результаты проверки не будут должным образом задокументированы. Использование шаблона отчёта по тестированию может сэкономить время и обеспечить корректность и точность документации результатов в формате, доступном для его целевой аудитории.