Лекция
Это продолжение увлекательной статьи про .
...
Разработчики должны понимать принципы работы эксплойтов, то
как их протестировать и, конечно же, способы устранения недостатков. Понимание – это ключ к
созданию безопасных приложений, поэтому очень хорошо, если ваша компания инвестирует в
образование сотрудников, организуя внутренний учебный процесс, проводя образовательные
мероприятия, или оплачивает обучение в сторонних учебных центрах. Моделирование угроз,
принципы безопасной разработки , снижение поверхности атак, требования функциональной
безопасности и тестирование являются ядром принципов безопасной разработки приложений и
легко интегрируются во все процессы и этапы разработки.
Процесс также играет важную роль в разработке приложения и влияет на безопасность также
как на производительность сотрудников и качество продукта. Если спецификации продукта
не содержит требований к безопасности, вы не можете надеяться на то, что продукт будет
безопасным. Продукт, который не подвергается тестированию на безопасность, также как и
продукт, который не проходит тестирование функциональности, будет страдать от недостатков и
ошибок. Модификация жизненного цикла разработки приложений (Software Development Lifecycle) включающая требования безопасности называется Secure SDLC и включает в себя простые
проверки на протяжении всего процесса разработки для того чтобы выявлять проблемы как
можно раньше. Secure SDLC - достаточно серьезная тема для углубленного обсуждения, но самое
главное, что мы хотели бы донести – это необходимость внедрения требований безопасности в
каждый этап разработки.
Инструменты и тестовые случаи, которые мы обсудим позже, могут быть использованы для
автоматизации тестирования и контроля, но знания и образование имеют важное значение для их
правильного использования. С их помощью можно улучшить процесс разработки и тестирования,
а также снизить расходы по сравнению с наложенной безопасностью, одновременно снижая
количество уязвимостей в коде. Члены команды, имеющие образование в сфере безопасности
способны создавать библиотеки тестов, которые помогают выявить типичные уязвимости в новых
версиях кода. Причем, пригодных не только для внутреннего тестирования на этапе разработки,
но и полезных при тестировании уже работающего приложения. Экстремальные методики
программирования могут помочь подтвердить, что модули и компоненты отвечают требованиям
безопасности в рамках тестирования, наряду с проверкой функциональными возможностями,
не относящимися к безопасности напрямую. Помните: вы разработчик и ваша команда должна
знать код лучше, чем кто-либо еще включая его недостатки.
Есть целый ряд специально разработанных инструментов сторонних разработчиков, которые
помогают проверить код на безопасность, Статический анализ анализирует исходный код webприложения для выявления распространенных уязвимостей, ошибок и упущений в пределах
конструкций самого языка программирования. Это своего рода, автоматизированный аналог
экспертной оценки. Помимо всего прочего, эти средства в основном используются для
сканирования необработанных условий ошибок, наличия объекта и/или определения размера, а
также потенциально возможного переполнения буфера.
Эти инструменты используются на стадии разработки для того чтобы выявить недостатки до
перехода к более формализованным процедурам тестирования. Ведь чем раньше становится
известно о проблеме, тем проще ее исправить. Статический анализ кода выполняется самими
разработчиками, что значительно ускоряет поиск ошибок и делает это заметно дешевле, чем
если бы анализом занимались отдельные люди. Эти инструменты могут быть интегрированы с
управлением исходным кодом для автоматизированного выполнения анализа, опять же. Для того
чтобы выявить недостатки в коде как можно раньше.
Статистический анализ эффективен для обнаружения проблем связанных непосредственно с
ошибками в коде, которые допускают программисты. Лучшие инструменты хорошо интегрируются
с разными средами разработки (предоставление дополнительной информации о выявленных
недостатках кода и предоставление вариантов их исправления), расставляют приоритеты
обнаруженных уязвимостей на основе заданных критериев, предлагают подробную отчетность
и отслеживание тенденций, а также способны взаимодействовать с группой безопасности,
участвующей в процессе разработки, не отвлекая других разработчиков.
Но инструменты статического анализа не учитывают все пути в коде, а также не может выявить
некоторые типы уязвимостей, которые проявляются только во время использования приложения.
Чтобы восполнить этот пробел, в последние несколько лет стали активно развиваться инструменты
для динамического и гибридного анализа.
Инструменты динамического анализа
Динамический анализ используется для выявления проблем и уязвимостей, которые не могут
быть выявлены при анализе исходного кода или которые намного проще заметить в тот момент,
когда приложение запущено. Один из типов анализа называется “fuzzers” которые направляет
приложению заведомо вредные или фиктивные материалы для приложения и отслеживает
результаты этих действий, а также сбои в работе приложения. На рынке предлагается много
разных вариаций, но в целом их можно разделить на три группы:
White Box или Black Box. Тестовое приложение может не иметь никаких начальных знаний
о приложении и изучает его в качестве “черного ящика” (Black Box) и с соответствующим
подходом. Но в большинстве случаев используется подход “White Box”, когда тестирование
проводится по поиску подходящих уязвимостей в соответствии с особенностями приложения
известных авторизованному пользователю. Тестирование методом “Black Box” является более
представительным, так как оно повторяет принципы работы внешнего хакера, который не знаком
с внутренней организацией приложения. Но при тестировании web-приложений важны оба
подхода. Ведь многие уязвимости могут быть не видны неавторизованному пользователю, но
прекрасно видны тому, кто прошел авторизацию.
Отправка запросов. Запросы могут быть случайными, генерироваться на лету на основе ответов,
а также быть целевыми. Случайные запросы являются хорошей возможностью для проверки
эффективности проверки целостности и поиска общих недостатков в коде, а целевые могут быть
использованы для проверки на наличие уже известных уязвимостей.
Выходные данные и действия по окончании тестирования. После тестирования методами
White Box и Black Box требуется экспертиза результатов тестов специалистами, которые выделят в
них реальные недостатки и ложные срабатывания. Условия появления ошибок найти достаточно
легко и большая часть инструментов для динамического анализа обнаруживает и сообщает об их
наличии. Некоторые средства мониторинга не только выявляют ошибки, но и указывают на то, в
какой именно части кода они находятся. Подобно отладчикам, динамический анализатор может
контролировать внутренние ресурсы приложения, когда оно находится в процессе тестирования,
наблюдая за памятью, указателями, очередями запросов и переменными. Тесты могут выявить
специфические эффекты модели использования системы и проблемные области.
Отчасти из-за этих переменных инструменты для динамического анализа отличаются по скорости,
эффективности и автоматизации. Так как они сфокусированы на поведении приложения, они
дают конкретные результаты для сценариев “а что если…”, чего статические инструменты не
могут. Динамический и статический анализ являются взаимодополняющими технологиями, но
предназначены для разных аудиторий. Некоторые вендоры предлагают обе возможности в одном
инструменте, что позволяет получить более всеобъемлющую оценку.
Хорошо структурированная система безопасности web-приложений начинается с хорошего
образования и интеграции безопасности в жизненный цикл разработки приложений – с
моделированиемугроз,безопаснымдизайном,учетомбезопасностифункциональныхтребований,
надлежащимиспользованиемстатическогоидинамическогоанализа,использованиембезопасных
методов кодирования, непрерывным обучением и формализованным тестированием.
Сохраняя последовательность повествования, мы переводим фокус нашего внимания с разработки
на развертывание web-приложения. На стадии развертывания, после проверки качества и
безопасности приложения, мы переходим к оценке уязвимости и тестированию на проникновение
для того чтобы убедится в соответствии нашего приложения современным требованиям и его
устойчивости к атакам. Помните, что мы смотрим на безопасность web-приложений как на
непрерывный процесс с перекрывающимися этапами. Хотя мы и делим процесс на отдельные
этапы, чтобы сделать повествование более понятным и структурированным, это совсем не
значит, что один этап заканчивается, когда начинается другой. К примеру, вы должны продолжать
использовать динамический анализ на этапе развертывания, а также продолжать поиск
уязвимостей и тесты на проникновение на всех этапах. Также помните, что мы показываем вам
общую картину и имеющиеся возможности. Приоритезацию и моменты, на которых стоит особо
сфокусироваться, если ваш бюджет ограничен, мы обсудим чуть позже – ведь мы не настолько
наивны, чтобы думать, что вы можете позволить себе все решения, которые есть на рынке.
При оценке уязвимости, мы сканируем web-приложение для идентификации любых моментов,
которые потенциально могут быть использованы против нас атакующими (также мы оцениваем
соответствие требования и стандартам, но фокусируемся именно на поиске уязвимостей).
Сканирование может быть выполнено посредством инструментов, сервисов или их комбинации.
Оценка уязвимости web-приложений очень отличается от стандартной оценки уязвимости,
которая фокусируется на сетях и хостах. В том случае мы фокусируемся на сканировании портов,
подключениях к сервисам и используем другие методы для сбора информации и выявления
уровней патчей. Как мы уже говорили, даже “стандартные” web-приложения во многом являются
самописными, а потому нам необходимо изучать их более внимательно, проверяя функции и
логику приложения, а также использовать индивидуальные проверки, чтобы выявить уязвимости
web-приложения. При большом количестве самописного кода мы должны меньше полагаться на
поиск стандартных уязвимостей и стараться проводить больше тестов путем атаки. Как мы уже
говорили, пользовательский код создает пользовательские уязвимости.
При оценке уязвимости web-приложений мы пропускаем традиционные тесты хостов и сетей и
фокусируемся на сторонних web-приложениях и фреймворках, а также на технических и бизнес
недостатках пользовательских приложений.
Рынок решений для оценки уязвимости web-приложений предлагает как специальные
инструменты, так и сервисы. Если вы выберете пусть самостоятельного тестирования, то, кроме
подбора правильных инструментов, вы должны быть уверены, что они окажутся в руках опытного
оператора, который сможет правильно интерпретировать результаты тестов. Важны использовать
обе методики тестирования, когда оператор имеет разные уровни доступа к web-приложению и
не имеет таковых вообще.
Имеется целый ряд коммерческих, бесплатных и основанных на открытом коде инструментов
и решений для оценки уязвимости web-приложений с широким функционалом. Некоторые
инструменты используют очень ограниченный набор эксплойтов, а потому опытные тестировщики
используют не один, а целый набор инструментов, дополняя его ручными методами проверок.
Например, есть приложения сфокусированные на поиске и тестировании только уязвимостей
связанных с SQL-инъекциями. Инструменты корпоративного класса должны быть более
многофункциональными и включать ряд критически важных для web-приложения классов
уязвимостей, таких как SQL-инъекции, межсайтовое исполнение скриптов и т.д. OWASP Top 10
является отличным базовым списком основных уязвимостей, но приложения корпоративного
класса не должны ограничиваться проверкой только по одному списку или категории уязвимостей.
Решение корпоративного класса также должно иметь возможность проверки нескольких
приложений, поддерживать отслеживание в течение длительного времени и обеспечивать
адекватной отчетностью (особенно в той части, что касается исполнения требований), а также
быть настраиваемым для оценки выполнения локальных требований.
Инструменты для оценки уязвимостей, как правило, являются программными, но могут иметь
и аппаратную часть. Также они могут работать либо под контролем оператора, либо проводить
сканирование в автоматическом режиме по расписанию. Так как web-приложения изменяются
достаточно активно, то очень важно сканировать их после внесения любых изменений или новые
версии перед развертыванием, а также контролировать действующие приложения на постоянной
основе.
Не все организации имеют ресурсы (включая экспертизу) для оценки уязвимости собственных
приложений. В таком случае есть два варианта – покупка необходимых инструментов или внешняя
оценка.
Существует три основные категории услуг по оценке уязвимости web-приложений:
Полностью автоматическое сканирование. Полностью автоматизированное сканирование без
участия оператора. Цена такой оценки минимальна, но она дает гораздо больше ошибок. Такие
проверки достаточно эффективны для постоянного мониторинга, но их возможности довольно
ограничены для проверок перед развертыванием.
Автоматическое сканирование с обработкой результатов оператором. В данном варианте
большая часть проверок проводится в автоматическом режиме, после чего результаты
расшифровываются человеком, которые, по необходимости проводит дополнительные тесты.
По сравнению с полностью автоматической проверкой, данный вариант дает более глубокое
исследование и более точные результаты, но стоит, естественно дороже.
Ручное обследование. В данном варианте оценку проводят подготовленные специалисты,
которые используют свои собственные инструменты для поиска уязвимостей и их проверки,
после чего предоставляют развернутые отчеты. Этот вариант самый эффективный и позволяет
выявить больше уязвимостей, чем предыдущие, но он и самый дорогой.
Тестирование на проникновение
Целью оценки уязвимости является поиск путей, которые потенциальные злоумышленники могут
использовать, а тест на проникновение это еще более глубокое исследование, которое позволяет
понять – действительно ли найденные уязвимости несут риски для компании в случае атаки. В
тесте на проникновение мы пытаемся атаковать наши приложения аналогично злоумышленнику,
чтобы понять какие могут быть последствия у данных действий.
Оценка уязвимостей и тесты на проникновение отлично дополняют друг друга и часто
используются вместе, так как первый шаг в любой атаке – это поиск уязвимостей, которые можно
было бы эксплуатировать. Целью на этапе оценки уязвимостей является поиск недостатков
web-приложения, а при тестировании на проникновение эти недостатки проверяются с точки
зрения возможности их использовать, оценить потенциальный ущерб каждой из них и расставить
приоритеты по исправлению этих недостатков.
Ключевая ценность теста на проникновение в том, чтобы определить связь между уязвимостью
и рисками, которая она несет и принять обоснованное решение о необходимости и срочности ее
устранения. Оценка уязвимости дает только информацию о наличии пробелов в безопасности, но
не позволяет представить общую картину потенциальных последствий их эксплуатации. Например,
при поиске уязвимостей вы выявили, что web-приложение уязвимо для SQL-инъекций, но при
попытке эксплуатации это уязвимости может оказаться, что с ее помощью злоумышленник может
получить конфиденциальную информацию, изменить функциональность или и вовсе вывести
web-приложение из строя. Может оказаться, что незначительные уязвимости могут привести к
тому, что злоумышленник получит полный контроль над всем web-приложением.
Некоторые эксперты считают, что тесты на проникновение важны, так как используют те же
методы и преследуют те же цели, что и реальный злоумышленник, но мы считаем, что эти тесты
очень полезны как инструмент определения приоритетности рисков. Впрочем, обе этих цели
тестов являются важными и нельзя отказываться от одной из них, отдавая приоритет другой.
Как и в случае с оценкой уязвимости, тесты на проникновения могу не ограничиваться только
web-приложением, но, также включать проверку уязвимостей окружения – операционных систем,
сетей, пользовательских приложений и т.д. Инструменты и услуги этого направления доступны на
рынке. Но, учитывая, что мы говорим о web-приложениях, мы не будем углубляться в окружение
и инфраструктуру, и ограничимся обсуждением аспектов тестирования на проникновение
характерных для web-приложений.
Решения для тестов на проникновение дают возможность выявления и проверки возможности
эксплуатации уязвимостей web-приложения, а также оценки возможных последствий атак
с их использованием. Специалисты по тестам на проникновение используют множество
разных инструментов при работе, но большая их часть является узкоспециализированной и не
предоставляет широкого функционала. Они запускаются до развертывания web-приложения с
использованием тестовых данных, так как эксплуатация некоторых уязвимостей может привести
к повреждению хранящихся данных или самого приложения. Решения корпоративного класса
имеет дополнительные функции, которые помогают более эффективно управлять рисками и
имеют внутреннюю систему оценок уязвимостей, что позволяет снизить затраты при проведении
внутренних тестов на проникновение. Также они обычно имеют более широкий охват классов
уязвимости, поддерживают “безопасные”для данных и web-приложения методы проверки, что
позволяет использовать их в действующих приложениях, а также предоставляют обширную
отчетность и автоматизацию текущих оценок. Одним из преимуществ решений для тестирования
на проникновения является возможность их использования не только для проверки уже
действующего приложения, но и на разных этапах разработки и развертывания web-приложения.
Инструменты и решения всегда поставляются в виде программного обеспечения и должны
использоваться только подготовленными специалистами. Ведь, несмотря на то, что значительная
часть процесса автоматизирована, только хорошо подготовленный и опытный специалист
может проанализировать результаты автоматического тестирования и эффективно исследовать
уязвимость, сделав выводы о последствиях е возможной эксплуатации.
При использовании инструментов для тестирования на проникновение (также как и в случае
с инструментами для поиска уязвимостей) у вас есть возможность запускать их в безопасном
режиме, что заметно снижает риск возникновения проблем с работающим web-приложением.
Но если приложение действительно работает в “боевом” режиме, то будьте осторожны даже при
работе в безопасном режиме, так как и в этом случае имеется определенный риск перебоев в
работе web-приложения, а также захламления баз данных. Поэтому такое тестирование нужно
проводить под максимальным контролем.
Вотличиеот того,чтомывиделиприизучениипоискауязвимостей,полностьюавтоматизированных
сервисов по тестированию на проникновение нет. Из-за гибкой и постоянно меняющейся природы
web-приложений, тесты на проникновение всегда требуют контроля со стороны человека. Услуги
по тестированию на проникновения предлагаются либо в качестве разовых услуг либо в качестве
подписки, которая подразумевает проведение тестов с определенной периодичностью. Частота
тестирования варьируется в зависимости от потребностей бизнеса, критичности и задач webприложений. Внутренние приложения могут проверяться всего раз в год в рамках регулярного
тестирования инфраструктуры.
Перед использованием услуг тестирования на проникновение, необходимо внимательно
изучить опыт знания и возможности поставщика услуг. Некоторые компании предлагают
немного больше, нежели удаленное сканирование, но не в состоянии предоставить адекватные
результаты, которые вы сможете эффективно использовать в риск менеджменте. Другие просто
останавливаются после того, как получают доступ, к приложению используя одну уязвимость,
не проводя полную проверку. Поэтому при выборе поставщика услуг вы должны предпочтение
организациям с отработанным процессам, которые могут предоставить образцы отчетов и будут
соответствовать вашим ожиданиям. Большая часть тестов на проникновения структурированы
и имеют фиксированное время и глубину исследования. В случае с фиксированным временем
(самый распространенный вариант) тестировщики пытаются найти так много уязвимостей как
могут в пределах ограниченного по взаимной договоренности времени. Работа также может быть
разбита на фазы, к примеру: слепой поиск, поиск под аккаунтом авторизованного пользователя
и т.д. Тестирование с фиксированной глубиной подразумевает остановку тестирования только
при достижении определенной цели (например, получение прав администратора или доступ к
номерам платежных карт) и не зависит от затраченного времени.
Интеграция оценки уязвимости и тестирования на проникновение в
безопасное развертывание
Несмотря на то, что большая часть компаний фокусируется на оценке уязвимости и тестировании
на проникновении уже действующих внешних web-приложений, на самом деле этот процесс
должен начинаться на этапе развертывания и не должны ограничиваться только теми webприложениями, которые доступны извне. Очень важно провести проверку приложения до того,
как вы предоставите доступ к нему внешними или даже внутренним пользователям. Также нет
никаких причин, кроме, пожалуй, ресурсов, чтобы не внедрить оценку рисков и тестирование на
проникновение в процесс развития приложения на основных этапах.
Перед развертыванием web-приложения создается тестовая среда, которая аналогична той,
в которой будет работать “боевая” система. Все ее элементы, включая версии продуктов и
подключенияквнешнимсервисамдолжнобытьидентичным.Затемпроводитсяоценкауязвимости
и тестирование на проникновение. Если вы используете собственные инструменты, то у вас должен
быть и обученный персонал, который умеет эти инструменты применять. Если вы пользуетесь
услугами сторонней компании, вам необходимо обеспечить удаленный доступ к тестовой среде
– изучить и выполнить требования доступа имеющиеся у подрядчиков. Не каждая компания
может обеспечить полное и всеобъемлющее тестирование каждого своего приложения, поэтому
необходимо приоретизировать список ваших web-приложений, основываясь на критичности
приложения для бизнес-операций, использовании приложением конфиденциальных данных и
т.д.
Длянекоторыхкрупныхиособоважныхweb-приложений,вымоглибыпровестиоценкууязвимости
и тестирование на проникновение у сторонних компаний еще до начала развертывания. Если
же ваше web-приложение критично для бизнеса или рассчитано на публичный доступ, то такая
проверка просто необходима.
После того как web-приложение уже развернуто, вашей задачей будет выполнение хотя бы
основных проверок при внесении каких-либо изменений в его код, еще до того, как обновление
будет установлено на “боевую” систему. Для критически важных приложений периодически
пользуйтесь услугами по внешней оценке уязвимости и тестированию на проникновение (по
крайней мере, раз в год, или при выпуске крупных обновлений) в дополнение к проведению
собственных тестов.
Мы знаем, что у разных компаний имеются разные ресурсы на содержание актуальных
инструментов для тестирования и услуги сторонних компаний, а потому вам нужно адаптировать
эти рекомендации к реалиям вашей организации. Мы предоставили лишь достаточно общие
данные в расчете на достижение лучшего результата и некоторые данные, которые позволят
правильно расставить приоритеты.
В предыдущих частях мы рассказывали о безопасной разработке и безопасном развертывании,
а теперь настала пора переходить к безопасному использованию. Этот этап настает, когда
разработка и тестирование уже полностью закончены и web-приложение переходит в режим
активного использования. Помните, что большая часть того, о чем мы говорили на предыдущих
этапах, пригодится вам и на этом, так что не торопитесь выбрасывать использовавшиеся
инструменты и забывать полученные навыки. Обновления для web-приложения по-прежнему
должны безопасно разрабатываться и проходить всестороннее тестирование перед установкой,
оценка уязвимости и тесты на проникновения также должны быть регулярными, а управление
конфигурацией и постоянный контроль безопасности становятся даже более важными, чем были
до этого.
В фазе безопасного использования мы добавим две новых категории технологий для поддержки
двух новых процессов – Web Application Firewall (WAF) в качестве щита отражающего разные
типы атак и решения по мониторингу web-приложения и/или базы данных, которое обеспечит
контроль и информирование об угрозах безопасности.
Web Application Firewall (WAF)
Задача WAF состоит в том, чтобы находясь перед web-приложением или в стороне, обеспечивать
мониторинг активности приложения и предупреждать об угрозах безопасности или блокировать
их. Таким образом WAF выполняет две функции –контроль активности в web-приложении и
превентивный контроль безопасности.
WAF – это межсетевой экран (Firewall), который изначально спроектированный с прицелом на
контроль HTTP-запросов и блокирование тех из них, которые могут быть потенциально опасными
или не соответствуют заданным правилам. Задача WAF в том, что перехватывать SQL-инъекции,
межсайтовый скриптинг (XSS), попытки обхода каталогов и другие попытки атак посредством
HTTP-запросов, включая их подмену, то есть пресекать любые попытки несанкционированного
использования web-приложения. Правила и политики задаваемые WAF позволяют эффективно
обеспечить контроль HTTP-трафика в соответствии с функционалом web-приложения. WAF
предупреждает или блокирует подозрительную активность на основе имеющихся сигнатур (уже
известных атак) или на основе специфических требований web-приложения.
Современные WAF изучают входящие и исходящие запросы, сравнивает их с заданными правилами
и выдает оповещения в случае обнаружения какого-либо отклонения. По итогам анализа
подозрительных запросов, WAF выбирает один из четырех вариантов действий: 1) пропустить
запрос, 2) пропустить, но зафиксировать факт нестандартного поведения, 3) заблокировать передачу
запроса, 4) сбросить соединение.
WAF – это, обычно, сетевое устройство. Как правило, его размещают непосредственно перед
приложением (режим прокси) или в стороне от приложения, зеркалируя на него трафик, которым
обменивается web-приложение. В первом варианте установки все входящие и исходящие запросы
перехватываются и проверяются до того как они попадут к web-приложению или пользователю, что
позволяет снизить нагрузку на web-приложение. В том случае, если для связи с web-приложением
используется SSL-соединение, установленный перед ним WAF должен иметь возможность его
расшифровки и анализа. При установке WAF в стороне от приложения, проблема работы с SSL-
трафиком решается посредством выдачи ему копии серверного сертификата, либо установкой после
SSL-концентратора. Некоторые разработчики также предлагаютWAF в виде плагинов для конкретных
платформ, то есть не имеющих своей аппаратной базы.
Эффективность некоторых WAF ограничена качеством политик. Политики являются важными не
только для выявления и блокирования известных типов атак, но и для гибкого решения в случае
выявления неизвестных типов атак, сохраняя при этом функциональность для нормальных запросов.
Сложность web-приложений в комбинации с необходимостью постоянного обновления политик
и разными вариантами развертывания, являются непростой задачей для всех разработчиков WAF.
При этом просто установка WAF перед web-приложением и активация всех его возможностей – это
верный рецепт катастрофы. Нет никаких шансов, что WAF сам поймет все особенности вашего webприложения, а потому при его развертывании требуется тщательная и внимательная настройка для
сохранения возможности пропуска “хороших” запросов и эффективной блокировки “плохих”.
Когда WAF разворачивается в режиме мониторинга, то он функционирует по тому же принципу, что
и система обнаружения вторжений (IDS). В данном режиме WAF используется только для анализа
активности и выдачи предупреждений о нарушениях. В таком режиме обычно разворачивается WAF
даже в том случае, если вы планируете использовать возможность блокирования запросов. Это дает
возможность настроить WAF и лучше понять особенности функционирования web-приложения до
того как вы перейдете к попыткам блокирования запросов. Преимущества этого режима заключается
в возможности наблюдать за широким кругом потенциальных атак не беспокоясь о том, что ложные
срабатывания приведут к неадекватной блокировке. К недостаткам данного режима можно отнести
то, что ваши сотрудники будут тратить больше времени на решение появляющихся инцидентов и
ложных срабатываний, а также то, что “плохая” будет блокировать с большей задержкой.
В режиме блокирования WAF будет останавливать соединения, разрывая их (в режиме прокси) или
отправляя пакеты сброса TCP (если установлен в стороне). После сброса соединения WAF может
заблокировать IP временно или постоянно для того чтобы предотвратить повторные атаки. Режим
блокировки является самым эффективным в том случае, если имеется известная уязвимость в вашем
приложении, но обновление с исправлением этой уязвимости еще не готово.
Когда уязвимость найдена в вашем приложении, вы можете создать специфическое правило для
блокирования атак использующих эту уязвимость в WAF. Это защитит ваше приложение от атак, пока
вы будете исправлять код приложения или дожидаться выхода патча от разработчика программного
обеспечения. Данная стратегия позволяет достаточно эффективно защищать приложение, сохраняя
его функциональность и повышая производительность, но она сработает только в том случае, если у
вас есть отлаженные процессы по выявлению и анализу уязвимостей.
Учитывая все вышесказанное, стоит отметить, что отношение к WAF у профессионалов
информационной безопасности остается неоднозначным. Хотя WAF очень эффективны против
известных угроз, они гораздо менее эффективны в борьбе с новыми угрозами и не всегда адекватно
обрабатывают сомнительные запросы. Некоторые продукты класса WAF решают эту проблему за
счет более плотной интеграции с инструментами оценки уязвимостей. Независимо от того в каком
режиме используется WAF и как эффективно настроены политики, вы должны помнить, что вам
потребуются дополнительные инвестиции в эту область.
Мониторинг
Мониторинг в основном предназначен для контроля использования web-приложения реальными
пользователями, а также для выявления нестандартных запросов, которые могу оказаться
“плохими”. Принципиальная ценность мон6иторинга в возможности узнать те особенности
приложения, с которыми вы не знакомы
продолжение следует...
Часть 1 Web-приложения. Безопасная разработка , развертывание и использование
Часть 2 Инструменты статического анализа - Web-приложения. Безопасная разработка , развертывание и
Часть 3 Подводим итоги - Web-приложения. Безопасная разработка , развертывание и использование
Комментарии
Оставить комментарий
Криптоанализ, Виды уязвимости и защита Информации
Термины: Криптоанализ, Виды уязвимости и защита Информации