Application security testing – что это такое и как работает
Application Security Testing (далее – AST) – это процесс (или комплекс мер) поиска уязвимых мест в исходном коде. Цель, преследуемая в рамках данного процесса — устойчивость ПО к различным угрозам. Реализация механизмов app security testing осуществляется на разных этапах жизненного цикла приложения: разработки, интеграции, ввода в эксплуатацию и приемки, использования программного обеспечения – с помощью определенного набора технологий, а также средств тестирования безопасности приложений, в том числе универсальных, применяющихся практически на всех этапах.
Технологии и инструменты AST, их особенности и применение
Технологии и инструменты тестирования безопасности по этапам жизненного цикла ПО можно представить в виде таблицы:
Стадия сборки
кода
Предвыпускная
стадия (Pre Prod)
Выпуск в
производство (Prod)
Из таблицы видно, что универсальная технология, которая может применяться на всех этапах жизненного цикла программного обеспечения, – это SAST. Static Application Security Testing, или статическое тестирование безопасности, принято еще называть методом белого ящика. Оно сводится к анализу исходного кода без запуска ПО. Именно это обуславливает универсальность такого подхода. Благодаря тому что для анализа не требуется исполнение кода, реализовать тестирование можно в любой момент:
- В процессе разработки ПО – путем встраивания таких решений в IDE.
- На этапе сборки кода, когда происходит подключение сторонних библиотек и ПО, с помощью которых анализируются подключаемые модули, библиотеки, файлы фреймворков, приложения, с которыми разрабатываемое ПО будет взаимодействовать. Это обеспечивается за счет возможности анализа SAST-инструментами некомпилированного и скомпилированного кода (при использовании анализаторов байтового, а также двоичного кода).
- На стадии верификации кода и на предвыпускном этапе с помощью SAST анализируется как уже готовый скомпилированный код, так и фрагменты, над которыми еще ведется работа.
- На стадии выпуска в производство SAST-анализаторы могут использоваться разработчиками, а также теми, кто эксплуатирует ПО. Главное преимущество этих инструментов для конечных пользователей – простота. Для работы с ними и анализа результатов не требуется опыт в разработке. Анализировать приложения сможет специалист по информационной безопасности компании или другой ответственный эксперт, на которого возложены такие функции.
При проведении app security test методом белого ящика выявляются различные виды угроз. SAST-анализаторы обнаруживают синтаксические и математические ошибки, проблемы с проверкой кода, небезопасные ссылки на сторонние приложения, библиотеки, модули и так далее.
При разработке Solar appScreener мы выбрали именно SAST-подход, чтобы решение могли использовать на всех этапах жизненного цикла не только разработчики, но и эксплуатирующие ПО компании.
Dynamic Application Security Testing, или динамическое тестирование, называют методом черного ящика. Данная технология позволяет обнаружить уязвимости в работающем приложении, выявляет его слабые места. Такие инструменты проверяют выполняемый код и выявляют широкий спектр проблем, связанных с запросами/ответами приложения, использованием памяти, уязвимостями при использовании cookies, сеансами пользователя, исполнением кодов внешних компонентов и модулей, аутентификацией пользователей, внедрением данных (инъекциями).
Таким образом, при выполнении application security test с помощью DAST-инструментов приложение (включая отдельные его компоненты, которые требуется проанализировать) должно быть запущено (код должен исполняться). Поэтому внедрить такой инструмент в процесс разработки можно не всегда (только в зависимости от используемой разработчиком модели). Кроме того, Dynamic Application Security Testing требует немалых временных затрат, в отличие от SAST, отчего на проверку может уйти значительно больше времени.
Инструменты DAST редко применяют пользователи ПО. Для работы с ними требуется персонал с опытом по проведению тестирования на проникновение. Специалист по информационной безопасности без соответствующей подготовки работать с ними не сможет.
Интерактивное тестирование безопасности, или Interactive Application Security Testing, сочетает черты двух предыдущих технологий, благодаря чему компенсируются недостатки, присущие каждой из них. Такие инструменты могут использоваться практически на всех этапах (при разработке – с оговорками, в зависимости от модели). IAST-анализаторы выполняют статический анализ, а также тестируют исполняемый код. Это реализовано за счет выполнения анализа потоков данных, конфигурации приложений, подключаемых компонентов, библиотек, фреймворков, запросов, внешних/внутренних подключений. IAST – довольно мощная, эффективная технология. Но все-таки конечные пользователи ПО могут испытывать трудности с ее внедрением – для работы с результатами динамического тестирования требуются специалисты с опытом проведения тестирования на проникновение. Таким образом, ее использование рекомендовано уже на более поздних этапах зрелости компании, задействованной в проверках кода.
Под SCA (Software Composition Analysis) понимают анализ сторонних компонентов ПО. Его цель – проверка уязвимостей в сторонних компонентах, используемых в составе ПО. Данная технология может применяться как на этапе разработки, так и при сборке приложений в завершенный экземпляр ПО. Для реализации SCA используются утилиты, а также иные решения, которые собирают информацию о зависимостях и находят возможные уязвимости, связанные с ними. В зависимости от инструмента, поиск уязвимостей происходит при непосредственном анализе сторонних компонентов (в том числе при использовании SAST-технологии) либо путем сбора информации из различных баз.
Run-time Application Security Protection – это обеспечение безопасности программы во время ее запуска (при выполнении кода). Эту технологию еще называют самозащитой приложений. Инструменты RASP внедряют в ПО при разработке, а используют уже на этапе эксплуатации. Они анализируют код, трафик, поведение пользователей, запросы, а также другие данные, обнаруживают и предотвращают киберугрозы. Тем самым обеспечивается выполнение application security testing в режиме реального времени при использовании ПО. Благодаря RASP реализуется эффективная защита приложений. Но есть минус – такие инструменты могут существенно влиять на быстродействие ПО, из-за чего их повсеместное внедрение вызывает проблемы.
Как мы видим, процесс RAST оказывается многоуровневым. Таким образом, можно сделать вывод, что в вопросах обеспечения безопасности приложений не стоит надеяться только на разработчиков. Пользователям есть смысл подумать и о внедрении инструментов для самостоятельного анализа, таких, например, как SAST.
Сам себе пентестер: как за пару дней проверить безопасность мобильного приложения
Разбираемся, какими инструментами пользоваться и на что обращать внимание, чтобы быстро найти несложные уязвимости в мобильном приложении.
В идеальном мире никто не проверил бы безопасность кода лучше тех, кто потратил дни и ночи на его написание. В нашем мире у разработчиков нет времени и опыта для такого аудита, и им занимаются отдельные люди — пентестеры.
Однако с хорошей инструкцией даже джуниор может сам провести базовый пентест за 1–2 дня.
Специалист по тестированию на проникновение компании BI.ZONE Олег Петраков расскажет, какими инструментами пользоваться и на что обращать внимание, чтобы быстро найти несложные уязвимости в мобильном приложении. Гайд поможет раньше узнавать о проблемах в коде, получать меньше правок на ревью и следить за безопасностью продукта, если никто больше этим не занимается.
Дисклеймер про термины Проверку приложения на уязвимости, которую в быту называют пентестом, эксперты по кибербезопасности назвали бы анализом защищенности. Пентест для них — другая задача: доказать, что в приложении есть хотя бы одна уязвимость, из-за которой его можно взломать. Однако наша статья написана не для экспертов по кибербезопасности, поэтому мы используем слово «пентест» в бытовом смысле.
Олег Петраков
специалист по тестированию на проникновение компании BI.ZONE
Готовим инструменты
На некоторых этапах экспресс-пентеста потребуются специальные инструменты. Большую часть из них вы, скорее всего, уже и так используете:
- для iOS — Finder, iTunes, iMazing, Console.app;
- для Android — adb;
- для обеих платформ — инструменты для отладки HTTP- и HTTPS-трафика вроде Fiddler или Charles.
Если работаете с Android, еще пригодится бесплатная утилита Android Backup Extractor.
Из специфически пентестерского арсенала вам хватит единственного инструмента — Mobile Security Framework (MobSF). Это автоматизированный универсальный фреймворк, который помогает проводить аудит безопасности мобильных приложений. Загрузив в него ipa-образ для iOS или apk-образ для Android, вы сможете провести динамический и статический анализ сборки. MobSF полезен и для целей безопасной разработки: к примеру, с помощью раздела Files удобно отслеживать, не попадают ли в релизную сборку лишние файлы.
Следим за лишней информацией в релизных сборках
Для начала проверим, не осталось ли в релизной сборке отладочной информации и журналов работы приложения.
В случае отладочной информации нас интересуют такие артефакты, как адреса тестовых стендов и других компонентов, API-ключи тестовых сервисов (например, аналитики) или сообщения, которые использовались при отладке приложения.
Их нежелательно оставлять по нескольким причинам.
- Во-первых, с отладочной информацией атакующему будет легче изучить логику работы приложения на стороне клиента.
- Во-вторых, изучив тестовый стенд — узнав, какие сервисы есть за фронтом на продакшне, какие базы данных используются на стороне сервера и пр. — атакующий может получить сведения для построения векторов атаки, обнаружения и эксплуатации уязвимостей.
План действий. Убедитесь, что в вашем приложении такой информации не остается. В этом поможет фреймворк MobSF. Загрузите в него релизную сборку вашего приложения и сделайте следующее:
- для iOS-клиента — просмотрите все строки, определенные в ipa-образе, в разделе Scan Options / View Strings;
- для Android-клиента — проверьте строки в разделе Reconnaissance / Strings, а также обратите внимание на раздел Security Analysis / Code Analysis.
В случае с журналами работы приложения мы проверяем, что логи, выручавшие на этапе тестирования, не станут подспорьем для атакующего.
Само по себе журналирование трудно проэксплуатировать. Однако, как и отладочная информация, логи и строковые константы помогают злоумышленнику изучать работу приложения: дают идеи, за что зацепиться при поиске уязвимостей, позволяют расширить поверхность атаки.
План действий. Воспользуйтесь инструментами Console.app для iOS и adb для Android, чтобы увидеть, включено ли логирование в релизной сборке приложения и что туда попадает.
Чтобы логи не уходили в релизную сборку, лучшее решение — грамотно спроектировать класс Logger. Если же исправление нужно быстро, настройте в скриптах релизной сборки удаление методов логирования из кода. Для iOS-приложений это делается через препроцессорный макрос, а для Android — с помощью применения правил ProGuard.
Проверяем ограничение на отправку СМС
Следующим шагом ищем уязвимость к SMS Abuse: она одновременно и очень распространена, и весьма критична.
Это важно для приложений, в которых часть действий завязана на СМС: двухфакторная аутентификация, восстановление пароля, перевод денег и так далее.
Сообщения закупают у провайдера пакетами: например, оплачивают сразу миллион СМС в месяц. При этом на стороне сервера обычно нет ограничений на отправку СМС за единицу времени. Если атакующий запросит миллион сообщений, сервер их все отправит и исчерпает оплаченный пакет. В итоге разработчик потеряет деньги, а в худшем случае еще и клиентов: пока СМС не приходят, пользователи не могут решать свои задачи и переключаются на другой сервис.
План действий. Вспомните все эндпоинты, где операции требуют отправки СМС, и попробуйте отправить сразу по 20 запросов к каждому с одного IP-адреса или от одного пользователя. Если сообщения придут — система подвержена этой атаке.
Полностью защититься от атаки не получится, но можно сделать ее экономически невыгодной для злоумышленника. Для этого введите капчу при множественных запросах для одного пользователя. А еще хорошо, когда неаутентифицированный пользователь не может запрашивать СМС (кроме как для входа, конечно).
Проводим ревизию библиотек
Шаг короткий, но важный: надо убедиться, что ваши фреймворки и библиотеки собраны со всеми мерами безопасности. В противном случае злоумышленнику будет легче эксплуатировать ряд бинарных уязвимостей (пусть и сложных и редких).
План действий. С помощью MobSF посмотрите, какие библиотеки собраны неправильно и чего не хватает: для этого зайдите в раздел Security Analysis / Binary Analysis.
Исследуем компоненты для работы с внешними ссылками
Внешние ссылки (App Links, Deep Links, Universal Links) могли вам потребоваться по разным причинам:
- чтобы обрабатывать возвращаемые значения при OAuth-авторизации и других подобных протоколах;
- чтобы пользователям было удобно работать с вашим приложением и другими системами — браузерами, почтовыми клиентами и пр.;
- чтобы вы могли получать информацию для аналитики, и так далее.
Однако при встраивании компонентов для работы с внешними ссылками надо помнить: по отношению к другим приложениям эти компоненты всегда открыты. Следовательно, атакующий может отправлять им на обработку вредоносное содержимое. А это путь к обходу бизнес-логики приложения.
План действий. Дать здесь общую инструкцию не получится: все зависит от конкретной платформы и технологии. Но в целом шаг сводится к тому, что вам нужно пройти в коде по всем компонентам, обрабатывающим данные из внешних ссылок, и удостовериться, что у вас есть проверки на соответствие этих данных ожидаемому формату.
При встраивании компонентов для работы с App Links отдельно убедитесь, что ваш сервер сконфигурирован для проверки подписи вашего приложения (подробнее об этом — в инструкциях для разработчиков на iOS и на Android). Иначе ссылку могут перехватить.
Наконец, если ваше приложение обрабатывает и Deep Links, и App Links, определите для них разные компоненты: в противном случае нивелируются собственные меры безопасности, которые есть у App Links.
Проверяем другие открытые компоненты
В Android-клиентах специально определяют открытые компоненты — activity, сервисы и другие компоненты, которые могут обрабатывать запросы от других приложений, установленных на том же устройстве.
С точки зрения злоумышленника, каждый открытый компонент — это дополнительная поверхность атаки на ваш продукт. Из-за этого специалисты по кибербезопасности рекомендуют придерживаться минимализма и не множить открытые компоненты без необходимости.
План действий. Только вы можете решить, какие компоненты вам действительно важны для работы с другими приложениями и компонентами ОС. А увидеть их все в одном окне можно с помощью MobSF — для этого зайдите в раздел Security Analysis / Manifest Analysis.
Ищем недочеты в работе с компонентом WebView
Этот шаг актуален для приложений, которые задействуют WebView:
- отображают с его помощью документы — условия использования приложения, документы о согласии обработки персональных данных и пр.;
- проводят авторизацию через сторонний сайт, например Google, Apple, «Яндекс»;
- целиком (или отдельный модуль) написаны на фреймворках наподобие React Native.
Для WebView нужны отдельные меры безопасности, а в некоторых ситуациях лучше вообще обойтись без таких компонентов. Сейчас все разберем.
План действий. Если вам нужно показать PDF-документ или статический HTML, не стоит добавлять компонент WebView. Лучше воспользоваться штатными возможностями системы: на iOS — UIDocumentInteractionController, на Android — ACTION_VIEW. Так ваш документ откроется в приложении, которое пользователь чаще всего использует для подобных задач. Это удобнее, проще и безопаснее.
Если задача чуть шире — например, вы показываете отчет, который наполняется динамически — WebView уместен. Главное — убедитесь, что при создании этого компонента вы отключили исполнение JavaScript-кода. Атакующий, как правило, не может повлиять на эти данные, однако отключить поддержку JavaScript-кода стоит из принципа минимальных привилегий.
Для сложных задач предпочтительнее использовать:
- на iOS — WKWebView-компонент. SFSafariViewController тоже допустим, но он менее универсален: в нем нельзя отключить обработку JavaScript-кода при необходимости;
- на Android — Chrome Custom Tabs вместо WebView. Если же вы используете WebView, включайте поддержку нескольких окон. Это нужно, чтобы защитить пользователей на старых версиях ОС от недавно найденной уязвимости CVE-2020-6506 (если кратко, то это выполнение произвольного JavaScript-кода в документе верхнего уровня).
Изучаем данные в резервных копиях телефона
Если атакующий получит доступ к резервной копии телефона, он завладеет и всей информацией, которую вы туда сохранили. Опасен ли этот сценарий и оправдан ли риск, зависит от приложения. Но точно стоит обдумать эту перспективу, прежде чем встраивать создание резервных копий. Важно ли вам, чтобы данные вашего приложения могли быть восстановлены на другом телефоне? А вашему пользователю это необходимо?
План действий. Чтобы принять решение, проверьте, какую информацию приложение хранит в резервной копии. На iOS проще всего использовать обычный Finder (или iTunes), на Android — adb. Просмотреть содержимое резервной копии можно с помощью программ iMazing и Android Backup Extractor соответственно.
Ориентируемся на лучшие практики
Заключительный шаг проверки посвятим трем так называемым best practices. Их отсутствие само по себе не говорит об уязвимостях — но если встроить эти практики, защищенность пользователя сильно вырастет. А встраивать их несложно.
SSL Pinning
Без SSL Pinning, то есть механизма привязки сертификата сервера, приложение будет использовать политику проверки сертификата сервера по умолчанию. Это небезопасно: подмена точки доступа и немного социальной инженерии — и ваша разработка станет уязвима к атаке типа «человек посередине» (MitM). В результате такой атаки злоумышленник сможет читать и даже изменять сообщения, которые передаются между мобильным приложением и сервером: конфиденциальность обеспечить не выйдет.
Если решите встроить механизм, не ограничивайтесь HTTP-соединениями. SSL Pinning настраивается вообще для любого протокола, обернутого в TLS: веб-сокетов, XMPP и так далее.
План действий. Чтобы уточнить, настроен ли у вас SSL Pinning, и на iOS, и на Android потребуются одинаковые инструменты — Fiddler, Charles и подобные программы для отладки HTTP- и HTTPS-трафика. Но схема работы будет немного отличаться.
- На iOS достаточно настроить перенаправление трафика с телефона на HTTP-прокси и установить на устройство сертификат для HTTP-прокси. Если трафик приложения будет зарегистрирован на стороне HTTP-прокси, значит, у вашего клиента SSL Pinning не настроен или настроен неправильно.
- На Android предварительно надо добавить в манифест network-security-config с настройкой доверия пользовательским сертификатам. После этого выполняйте ту же проверку, что и для iOS.
Размытие изображения в фоне
Применять размытие к приложению в фоне (использовать заставку) — рекомендация, которая подходит не всем. С одной стороны, размытие ухудшает опыт пользователей: им будет труднее переносить информацию в другое приложение, например браузер или блокнот. С другой стороны, размытие не даст захватить изображение в фоне не только пользователю, но и другим приложениям, в том числе вредоносным.
Для графического редактора этот механизм безопасности вряд ли будет актуален, а вот приложению для инвестиций его стоит рассмотреть.
План действий. Решить, подходит вам эта практика или нет, помогут ответы на два вопроса:
- Нужно ли пользователю одновременно работать с вашим и другими приложениями?
- Отображает ли ваше приложение конфиденциальную информацию, например финансовые транзакции?
А если не помните, есть ли у вас размытие, самый быстрый способ это проверить — встать на место пользователя: сверните приложение и перейдите к отображению всех запущенных приложений.
Аутентификация на телефоне
Этот пункт касается использования криптографии при аутентификации, поэтому актуален только для приложений на Android: на iOS механизм работает совсем иначе.
Если в вашем приложении есть аутентификация по отпечатку пальца или графическому ключу, убедитесь, что у вас есть привязка к BiometricPrompt.CryptoObject. С ней вы будете пользоваться всеми возможностями криптографии на Android: при успешной локальной аутентификации приложение будет получать доступ к ключу шифрования, на котором расшифровывается объект, соответствующий сессии пользователя (например, refresh-токен).
План действий. Смотрите пример из мануала для Android-разработчиков: тут в деталях показано, как встроить привязку к CryptoObject.
Резюмируя
Если инструкция вдохновила вас на подвиги, полистайте гайд OWASP по пентесту мобильных приложений. Он понятно и в деталях рассказывает, как проверять безопасность продуктов под iOS и Android.
Но пентест не серебряная пуля. Лучшая защита — у тех приложений, которые создаются в рамках подхода security by design: когда безопасность берут в расчет с самого начала разработки.
А как бы вы закрыли перечисленные уязвимости? Предлагайте примеры в комментариях и советуйте, какие еще проверки стоит добавить в список.
Новинка! Security Analytics обеспечивает комплексный обзор всего вашего трафика
Приложение, проксирующее трафик через Cloudflare, обладает широким спектром простых в использовании функций безопасности, включая WAF, управление ботами и нейтрализацию DDoS-атак. Чтобы понять, был ли трафик заблокирован Cloudflare, мы создали мощную панель управления Security Events, которая позволяет пользователю просматривать любые события по нейтрализации атак. Владельцы приложений часто задаются вопросом, что произошло с остальной частью их трафика. Удалось ли им блокировать весь трафик, который был признан вредоносным?
Сегодня, наряду с нашим объявлением о WAF Attack Score, мы также объявляем о запуске нашего нового продукта — Security Analytics.
Security Analytics обеспечит вам представление о безопасности всего вашего HTTP-трафика, а не только нейтрализованных запросов, позволяя сосредоточиться на том, что наиболее важно: трафик, признанный вредоносным, но потенциально не нейтрализованный.
Обнаружение, затем нейтрализация
Представьте, что вы только что подключили свое приложение к Cloudflare, и без каких-либо дополнительных усилий каждый HTTP-запрос анализируется сетью Cloudflare. Таким образом, аналитика расширяется за счет анализа атак, анализа ботов и любого другого сигнала о безопасности, предоставляемого Cloudflare.
Без какого-либо риска ложных срабатываний, вы можете просмотреть непосредственно весь свой трафик, чтобы узнать, что именно происходит, когда и где.
Это позволяет вам сразу же приступить к анализу результатов этих сигналов, сокращая время, необходимое для развертывания активных мер по нейтрализации атаки, и повышая вашу уверенность в принятии решений.
Мы называем такой подход «обнаружение, затем нейтрализация», и мы уже получили весьма положительные отзывы от клиентов, получивших ранний доступ.
Фактически, решение Cloudflare по управлению ботами — Bot Management — использует эту модель в течение последних двух лет. Мы постоянно получаем отзывы наших клиентов о том, что благодаря улучшенным возможностям мониторинга сети они больше доверяют нашему решению по оценке ботов. Для дальнейшей поддержки этого нового способа защиты ваших веб-приложений и объединения всех наших интеллектуальных сигналов мы спроектировали и разработали новую систему аналитики безопасности — Security Analytics, которая начинает получать сигналы от WAF и других продуктов безопасности, чтобы следовать этой модели.
Новая система Security Analytics
Созданная на основе нашего успешного опыта аналитики, новая система аналитики безопасности — Security Analytics — использует существующие компоненты, такие как лучшие статистические данные, быстрые контекстные фильтры, на новом макете страницы, обеспечивающем быстрое исследование и подтверждение. В следующих разделах этот новый макет страницы будет разбит на части, образующие рабочий процесс высокого уровня.
Ключевое различие между аналитикой безопасности (Security Analytics) и событиями безопасности (Security Events) заключается в том, что Security Analytics основана на HTTP-запросах, которые охватывают возможности мониторинга всего трафика вашего сайта, а Security Events используют другой набор данных, который визуализируется всякий раз, когда имеет место совпадение с любым активным правилом безопасности.
Определение фокуса
Новая система Security Analytics визуализирует набор данных выборочных HTTP-запросов на основе всего вашего приложения, аналогично аналитике ботов. При подтверждении модели «обнаружение, затем нейтрализация» с выбранными клиентами, как правило, наблюдается использование наилучших статистических данных N для быстрого сужения до либо очевидных аномалий, либо определенных частей приложения. Основываясь на этих аналитических данных, страница начинается с выбранной статистики наилучших данных N, охватывающей как источники запросов, так и назначения запросов, что позволяет выполнить расширение, с тем, чтобы просмотреть всю доступную статистику. Такие вопросы, как «Насколько хорошо защищена область администратора моего приложения?» отображается одним или двумя быстрыми щелчками по фильтру в этой области.
Выявление аномалий в тенденциях
После определения предварительного фокуса, ядро интерфейса предназначено для построения графиков тенденций с течением времени. Диаграмма временных рядов зарекомендовала себя как мощный инструмент, помогающий выявлять аномалии трафика, а также позволяющий строить графики на основе различных критериев. Всякий раз, когда возникает пик трафика, скорее всего, имела место атака или попытка атаки.
Как упоминалось выше, в отличие от Security Events, набор данных, используемый на этой странице, представляет собой HTTP-запросы, которые включают как нейтрализованные, так и не нейтрализованные запросы. Под нейтрализованными запросами здесь мы подразумеваем «любой HTTP-запрос, который имел «завершающее» действие, примененное платформой Cloudflare». Остальные запросы, которые не были нейтрализованы, либо обслуживаются кэшем Cloudflare, либо достигают источника. В таких случаях, как наличие пика в не нейтрализованных запросах, но при этом с равномерным уровнем нейтрализованных запросов, можно предположить, что имела место атака, которая не соответствует ни одному активному правилу WAF. В данном примере вы можете одним щелчком мыши отфильтровать не нейтрализованные запросы непосредственно на диаграмме, что инициирует обновление всех данных, визуализированных на этой странице, оказывая поддержку дальнейшим исследованиям.
В дополнение к отображению по умолчанию нейтрализованных или не нейтрализованных запросов вы также можете выбрать график тенденций либо анализа атак, либо анализа ботов, что позволит вам выявлять аномалии в отношении атак или поведения ботов.
Увеличение масштаба с помощью сигналов анализа
Одним из наиболее предпочитаемых и надежных аналитических сигналов для наших клиентов является оценка ботов. С последним добавлением WAF Attack Score и сканирования контента, мы объединяем их на одной странице аналитики, помогая вам еще больше увеличить масштаб своего трафика на основе некоторых из этих сигналов. Комбинация этих сигналов позволяет вам найти ответы на сценарии, которые до сих пор были невозможны:
- Запросы на атаку, выполненные (определенными) автоматическими источниками
- Запросы на вероятную атаку, выполненные людьми
- Содержимое, загруженное с вредоносным контентом, созданным ботами, или без него
После того как сценарий будет отфильтрован, визуализация данных всей страницы, включая статистику наилучших статистических данных N, тренд HTTP-запросов и журнал с выборкой, будет обновлен, что позволит вам обнаружить любые аномалии либо среди одного из наборов наилучших статистических данных N, либо среди тенденции HTTP-запросов, основанной на времени.
Просмотр журналов выборок
После увеличения масштаба определенной части вашего трафика, которая может являться аномалией, журналы выборок предоставляют подробное представление для проверки вашего обнаружения по HTTP-запросу. Это важнейший шаг в рабочем процессе исследования безопасности, подтвержденный высоким коэффициентом вовлеченности при изучении данных об использовании таких журналов, просматриваемых в событиях безопасности (Security Events). Хотя мы добавляем больше данных в каждую запись журнала, расширенное представление журнала со временем становится менее читаемым. Соответственно, мы переработали расширенное представление, начиная с реакции Cloudflare на запрос, затем наши сигналы анализа и, наконец, заканчивая ключевыми компоненты самого необработанного запроса. Изучая эти сведения, вы подтверждаете свою гипотезу об аномалии и принимаете решение о необходимости принятия каких-либо мер по ее нейтрализации.
Полезные информация для начала работы
При внутреннем тестировании прототипа этой аналитической панели мы выяснили, что степень гибкости приводит к увеличению кривой обучения. Чтобы помочь вам начать осваивать гибкость, разработана удобная панель аналитики. Эти аналитические данные созданы для того, чтобы выделить конкретные аспекты вашего общего трафика. Простым щелчком мыши на любом из результатов анализа применяется набор фильтров, увеличивающих масштаб непосредственно той части вашего трафика, которая вас интересует. Здесь вы можете просмотреть журналы выборок или дополнительно настроить любой из примененных фильтров. Данный подход был подтвержден дальнейшими внутренними исследованиями высокоэффективного рабочего процесса, который во многих случаях станет вашей отправной точкой при использовании этой информационной панели.
Как мне это получить?
Новая система Security Analytics постепенно развертывается для всех клиентов плана Enterprise, которые приобрели новые пакеты Application Security Core или Advanced. В ближайшем будущем мы планируем развернуть эту систему для всех других клиентов. Это новое представление будет находиться рядом с существующей информационной панелью Security Events.
Что дальше
Мы все еще находимся на ранней стадии перехода к модели «обнаружение, затем нейтрализация», которая обеспечит вам больше возможностей мониторинга и интеллектуальных функций для лучшей защиты ваших веб-приложений. Пока мы работаем над расширением возможностей обнаружения, поделитесь с нами своими мыслями и отзывами, чтобы помочь нам улучшить наши результаты. Если вы хотите получить доступ раньше, обратитесь к своим специалистам по работе с клиентами, чтобы приступить.
Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.
To learn more about our mission to help build a better Internet, start here. If you’re looking for a new career direction, check out our open positions.
Security Analysis in Finance
Анализ безопасности в финансах — образовательное приложение для студентов.
Основная тема анализа безопасности:
Торговля ценными бумагами
Долговые обязательства
Цели и подходы к анализу безопасности
Основы фундаментального анализа
Фундаментальный анализ на уровне компании
Анализ рисков безопасности
Уравновешивание риска
Начни учиться вместе с нами 🙂
Последнее обновление
19 нояб. 2019 г.
Безопасность данных
arrow_forward
Чтобы контролировать безопасность, нужно знать, как разработчики собирают ваши данные и передают их третьим лицам. Методы обеспечения безопасности и конфиденциальности могут зависеть от того, как вы используете приложение, а также от вашего региона и возраста. Информация ниже предоставлена разработчиком и в будущем может измениться.