Динамическое тестирование безопасности приложений (DAST)

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

Инфраструктура

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

Когда кто-то говорит «провести оценку уязвимости», он, как правило, имеет в виду запуск автоматизированного сканирования какой-либо инфраструктуры на наличие уязвимостей. Результаты, полученные с помощью этих инструментов, как правило, точнее, чем у других инструментов: пропущенное обновление или неудачно выбранная конфигурация являются проблемой, которая может возникнуть на любой другой копии этой версии данного типа инфраструктуры. Windows 10 – это Windows 10. Компьютеры с одинаковой операционной системой могут быть настроены по-разному, но все они имеют одинаковый набор параметров, исправлений и других компонентов. В этом заключается отличие инфраструктуры от пользовательского программного обеспечения.

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

Пользовательские приложения

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

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

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

СОВЕТ. Довольно часто возможности веб-прокси, фаззинга и автоматического «сканирования» DAST объединяются в одном инструменте. Для тестировщика безопасности подобное сочетание – просто находка, так как в идеале при проведении тестирования безопасности нужны все эти три возможности. Тем не менее существует несколько названий инструментов, обладающих одной или несколькими из этих функций, что может запутать новичков. Если кто-то просит вас использовать сканер веб-приложения, DAST или сканер оценки уязвимости, скорее всего, он имеет в виду комбинированный инструмент.

Оценка уязвимости, оценка безопасности, пентестирование

Зачастую, когда клиенты просят провести тест на проникновение, на самом деле они хотят получить оценку безопасности или оценку уязвимости (эти два термина часто используются как взаимозаменяемые. В дальнейшем до конца книги мы будем говорить «оценка безопасности»). Давайте разберемся в этом.

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

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

ПРИМЕЧАНИЕ. Когда мы говорим об эксплойте или проникновении в систему, мы подразумеваем использование преимуществ системы не предусмотренным ее создателями способом. Это может быть сброс значений таблицы в базе данных, запуск скрипта, который не является частью системы, повышение привилегий в системе (например, переход от обычного пользователя к суперпользователю), получение доступа к смежным нетестируемым системам и т. д. Можно также выполнить проверку концепции, чтобы доказать, что в систему можно проникнуть, например, для кражи учетных данных или отправки команд в базу данных.

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

Тесты на проникновение – это оценка безопасности с добавлением эксплуатации уязвимостей для доказательства их наличия.

Данный вид тестирования обладает большей известностью, чем любой другой вид деятельности по обеспечению безопасности приложений. Это объясняется как вниманием СМИ к «хакерству», так и тем, что, откровенно говоря, взлом системы может быть действительно захватывающим процессом. Когда человек часами трудился над достижением цели и результатом его работы становится утечка данных из системы, он может почувствовать себя сильным, умным и успешным. А что может быть приятнее такого ощущения на работе? Конечно, это лучше, чем заполнять формы запросов на изменения.

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

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

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

Возвращаясь к тому, с чего мы начали данный раздел: как клиенту выбрать между этими двумя видами тестирования? Именно здесь стоит показать себя экспертом, совету которого можно доверять: задайте клиенту вопросы, касающиеся того, каких целей он хочет достичь и какие риски готов принять, а затем предложите соответствующий вариант. В любом случае необходимо заранее объяснить, какие действия будут произведены при оценке или проникновении, а затем изложить эту информацию в письменном виде. Как всегда, независимо от выбранного варианта до начала тестирования следует убедиться, что были созданы резервные копии всех систем.

НАНЯТЬ ХАКЕРА

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

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