Защита веб-приложений: мифы и реальность

Веб-сайт, доступный в интернете, автоматически становится мишенью для кибератаки. Атака на сайт — это не только DDoS. Есть ли различие между интернет-безопасностью и веб-безопасностью, почему атаки на веб-сайты стали массовыми, защищает ли фаервол БД и как защищать веб-приложения — ответы на эти вопросы есть в предлагаемой статье.

 

 

 

 

1. Введение
2. Миф №1: шлюз безопасности
3. Миф №2: фаерволл веб-приложений (WAF)
4. Миф №3: cетевой сканер защищенности веб-приложений
5. Как защищать веб-приложения?
6. Выбор сканера защищенности веб-приложений
7. Выводы

 

Введение

Интернет — глобальная система объединенных компьютерных сетей для хранения и передачи данных. Сам дизайн и основы функционирования интернета открыли двери между нашими «защищенными» корпоративными сетями и самой Сетью. Это все та же сеть, построенная на TCP/IP. И руководители ИБ, и специалисты по сетевой безопасности хорошо знают, как сделать интернет безопасным для своей организации.

Всемирная паутина (www), веб — это распределенная система связи «документов», расположенных на сотнях миллионов веб-серверов, подключенных к интернету. Это давно уже не просто веб-страницы и веб-сайты, а полноценные информационно-коммуникационные системы с веб-интерфейсом. В минимальной конфигурации есть веб-сервер (например, Apache или IIS), операционная система веб-сервера (Windows/Linux), сервер БД (MySQL/MS SQL) и сетевая служба обновления веб-сайта (FTP/SFTP). Все эти компоненты должны быть безопасными, поскольку в случае взлома любого из них злоумышленники могут получить доступ к данным. Веб — всего лишь транспорт, платформа, сервис.

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

Предлагаемые решения проблемы не всегда очевидны, понятны и доступны — от противоречия друг другу до потери доступности и полного хаоса. Пример популярного подхода:

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

Веб-уязвимости сегодня превосходят по количеству и связанным рискам любые другие проблемы информационной безопасности. 20% веб-приложений 10 лет назад — это уже почти 80% общего числа корпоративных приложений сегодня. Веб не только в интернете, ERP, АБС, управление сетями и многое другое используют веб-технологии. Подавляющее большинство внешних атак на корпоративные информационные системы нацелены именно на уязвимости веб-приложений, и с кратным ростом рисков пристальное внимание стало уделяться выявлению и устранению уязвимостей именно в них. И если внутри сети злоумышленнику доступен веб, его задачи упрощаются на порядок.

 

Рисунок 1. Уязвимости веб-приложений

 

 

Миф №1: шлюз безопасности 

Безопасность веб-приложений отличается от безопасности сети, даже если не брать в расчет единую точку отказа UTM и его возможное влияние на время отклика и пропускную способность сети, и, как следствие, снижение доступности. Веб-приложения должны быть доступны всем, поэтому остается только разрешить весь входящий трафик на порты 80 (HTTP) и 443 (HTTPs) и надеяться, что все будут играть по правилам. Мониторинг сессий на наличие, идентификацию и блокирование исполняемого кода не заменяет анализ трафика веб-приложений, поэтому эксплуатация уязвимости посредством легитимного веб-запроса не составляет труда при наличии шлюза безопасности «всё в одном».

 

Миф №2: фаервол веб-приложений (WAF)

Фаервол веб-приложений (WAF) анализирует HTTP/HTTPs веб-трафик на предмет обнаружения вторжений. Например, если злоумышленник пытается использовать известную уязвимость веб-приложения, WAF может заблокировать соединение, но есть нюансы:

1. Проблемы безопасности веб-приложения WAF не решает, он лишь остановит часть запросов злоумышленника к приложению.
2. Несмотря на заверения об интеллекте, эвристике решения, полном и глубоком сканировании трафика, WAF определяет только известные ему уязвимости, так как имеет заранее сконфигурированные паттерны/сигнатуры. Он не сможет защитить от вариаций уязвимостей и эксплойтов.
3. Насколько хорош администратор WAF, настолько и эффективен сам инструмент, являющийся тонко конфигурируемым ПО/appliance. И снова самым слабым звеном цепи является пользователь. Не сможет помочь фаервол, если его профессионально и постоянно не конфигурировать/ обучать.
4. WAF — обычное программное обеспечение, имеющее собственные уязвимости и баги. Эксперты по безопасности регулярно идентифицируют все новые уязвимости WAF, позволяющие получить доступ к консоли администрирования, отключить или обойти фаервол, представляющий дополнительный слой защиты, но не обеспечивают решение проблемы.
5. Имеет смысл применять WAF после оценки защищенности веб-приложений.

 

Миф №3: сетевой сканер защищенности веб-приложений 

Сетевые сканеры безопасности предназначены для выявления небезопасных конфигураций, отсутствия необходимых обновлений и наличия уязвимостей серверов и сетевых устройств, а не уязвимостей веб-приложений. Архитектура решений, огромное количество правил и признаков, подлежащих проверке при сканировании сети, все же иногда позволяют производителям сетевых сканеров предлагать дополнительную функциональность по поиску уязвимостей веб-приложений в рамках отдельной лицензии (например, у Qualys, Tenable и др.) или даже бесплатно. Но удобство использования и качество их работы далеки даже от среднего уровня профессиональных сканеров веб-приложений, и доверие к таким продуктам не может быть восстановлено после нахождения критических уязвимостей там, где универсальный сканер отработал на 100%. Средства фаззинга, тестирования протоколов, поиска эксплойтов, генераторы атак, анализаторы памяти и дебаггеры также не являются полноценными средствами анализа защищенности веб-приложений.

 

Как защищать веб-приложения?

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

Существует несколько технологий обнаружения уязвимостей в веб-приложениях:

• автоматическое сканирование по принципу белого ящика (white box);
• проверка исходного кода вручную;
• тест на проникновение (penetration test);
• автоматическое сканирование по принципу черного ящика (black box).

Лучшего из них не существует — каждый имеет свои плюсы и минусы. По версии Gartner (Magic Quadrant for Application Security Testing 2018 от 19 марта 2018) различаются:

• статическое тестирование (SAST, Static Application Security Testing);
• динамическое тестирование (DAST);
• интерактивное тестирование (IAST);
• тестирование мобильных приложений (MAST).

Причем Gartner авторитетно не различает технологии, сравнивая не связанные по функционалу и по целям применения решения, но, похоже, сравнивая объемы клиентских баз производителей. Например, отдает лидирующую позицию HP и исключает из обзора PortSwigger (кто не знает Burp), проводит аналогию между Qualys, хорошо известным сетевым сканером Web Application Scanning (WAS), с ПО поиска веб-уязвимостей Rapid7 AppSpider. Приятно, что отечественный Positive Technologies Application Inspector попал в обзор. Только в их описании честно сделано различие между SAST и DAST. Не должно вводить в заблуждение позиционирование некоторыми производителями своих решений как интерактивные сканеры (IAST), как правило, реализуемые в виде агентов среды выполнения программных тестов. IAST якобы объединяет лучшие возможности SAST и DAST, но это продукты разных классов по сути («… as an add-on to the DAST, but can't be delivered as a stand-alone product» (С)). Также не должны выделяться в отдельную технологию сканеры мобильных приложений (MAST), так как для сканирования мобильных приложений подходят почти все современные SAST и DAST. Тем не менее, постараемся придерживаться предложенной терминологии.

Cтатические анализаторы исходного кода (SAST, white box scanner) проверяют исходные (и/или двоичные) коды приложений на предмет обнаружения преднамеренных (НДВ) и непреднамеренных ошибок в программном обеспечении. Успешно применяются разработчиками, имеющими доступ ко всему коду, но усложняют процедуры разработки. Использовать их заказчикам для эксплуатируемых систем уже поздно. В настоящем обзоре не рассматриваются:

• Micro Focus (HP до сентября 2017) Fortify Static Code Analyzer
• IBM Security AppScan Source
• Checkmarx CxSAST
• CA Technologies (Veracode до апреля 2017) Veracode Static Analysis.

Что касается Contrast Security, SiteLock Synopsys (Black Duck до декабря 2017), Trustwave и WhiteHat Security, упомянутых Gartner, автору не удалось установить их применимость и позиции на рынке.

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

 

Рисунок 2. Уровни критичности уязвимостей

 

 

Сканеры защищенности/безопасности веб-приложений (DAST, black box scanner, Web Application Security Scanner, Web Application Vulnerability Scanner) имитируют атаки и анализируют реакции приложения в автоматическом режиме для выявления уязвимостей и проблем безопасности уже запущенных в эксплуатацию приложений. Необходимо понимать, что динамическое сканирование должно включать минимум три основных этапа:

1. Поиск (Crawl) — идентификация точек входа в приложение и ветвлений/ поверхностей атаки, наиболее важный этап, так как уязвимость не может быть обнаружена, если не будет идентифицирована точка входа.
2. Атака (Attack) — проведение множества проверок по всем поверхностям атаки.
3. Проверка (Proof) — определение реальности эксплуатации уязвимостей, их критичности при наличии эксплойта.

В отчет Gartner 2018 не попали два популярных DAST-продукта: Burp и Acunetix, хотя они были в отчете 2017 года и заслуженно сравниваются Шай Ченом, признанным экспертом по кибербезопасности, проводящим ежегодные сравнения DAST с 2010 года:

• Micro Focus (HP) Fortify WebInspect
• IBM AppScan Standard/Enterprise
• PortSwigger Burp Suite
• Rapid7 AppSpider
• Netsparker
• Acunetix

 

Рисунок 3. Сравнение наиболее популярных сканеров защищенности веб-приложений

 

 

Эксперты по веб-безопасности и пентестеры всегда используют DAST для упрощения процесса тестирования на проникновение с целью обеспечения быстрой и правильной проверки всех поверхностей атаки. Например, для совсем небольшого приложения со 100 видимыми параметрами только по межсайтовому скриптингу (xss) необходимо произвести около 800 тестов вручную. Если каждый тест занимает около 2 минут, и если все проходит гладко, такой тест займет около 12 дней, при работе тестера 24 часа в сутки. И это только видимые параметры. Как правило, в веб-приложении их гораздо больше. Автоматический сканер отработает тот же объем тестов и определит все невидимые параметры примерно за 2-3 часа.

Динамический анализ может расширить возможности статического анализа или применяться самостоятельно, когда доступ к исходным текстам отсутствует, например заказчиком, QA, менеджерами и т. д. Сканеры безопасности веб-приложений стали очень популярны, потому что они автоматизируют большую часть процесса обнаружения уязвимостей и, как правило, очень просты в использовании. Выбрать такой, который отвечал бы всем требованиям как среди коммерческих, так и бесплатных сканеров, непросто. Чтобы узнать, какой из них является лучшим, придется проверить их все.

 

Выбор сканера защищенности веб-приложений

В течение 5 минут поиска в интернете можно обнаружить более 30 бесплатных сканеров. Кстати, у Шай Чена в обзорах есть наиболее популярные из них. Возникает вопрос, зачем за что-то платить, когда бесплатно есть такой выбор?

Большинство бесплатных продуктов не предлагают в автоматическом режиме поиск, атаки, проверки и требуют много ручного труда: должны быть настроены прокси-серверы для записи трафика, запуска сценариев анализа записанного сеанса и прочее, в отличие от коммерческих, использование которых является очень простым процессом. Каковы гарантии, что ручной тест будет иметь доступ ко всем областям и входам в веб-приложении и все сеансы будут записаны? Кроме того, иногда физически невозможно вручную просканировать веб-приложение, такое как современная ERP-система. Возможно, коммерческий сканер не сможет просканировать все 100% областей веб-приложения и определить все векторы атак, но автоматизация процесса всегда эффективнее, чем сканирование веб-приложения вручную.

Сканер безопасности веб-приложений — это то, от чего которого зависит бизнес. Сканеры должны интегрироваться со средствами разработки и средствами совместной работы, что придает им статус универсального корпоративного инструмента. Поэтому здесь должны быть средства интеграции, техническая документация и профессиональная поддержка. Сильно расстраивает, когда сталкиваешься с проблемой, а поддержка недоступна или просто не существует. Иногда в критической ситуации мы готовы заплатить за поддержку даже бесплатного программного обеспечения. Интеграция DAST cо средствами разработки (CI/CD), системами обработки заявок (ticketing system), другими корпоративными системами должна быть доступна через API командной строки (CLI) или веб (REST API).

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

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

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

 

Рисунок 4. Детектирующая способность сканеров

 

Чем выше степень автоматизации сканера, тем лучше. Безопасность веб-приложений не является массовой отраслью, и не всегда можно найти специалиста, который тонко настроит сканер. Поэтому предпочтение нужно отдавать тем сканерам, которые могут автоматически определять сценарии и подстраиваться под них. Например, Netsparker поддерживает anti-CSRF-токены, перезапись URL и адаптируются к сценарию, в отличие от сканера, обнаруживающего лишь ограниченное число самых популярных уязвимостей.

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

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

• постановка целей и задач проекта;
• сбор информации;
• поиск уязвимостей;
• идентификация и проверка уязвимостей;
• подготовка отчетов;
• исправление.

В любой компании эти этапы потребуют участия большого количества сотрудников: разработчиков, аналитиков QA, менеджеров проектов, сетевых администраторов, разработчиков веб-приложений, ИБ, аудиторов и управленцев. Часто к проектам по оценке веб-безопасности привлекаются сторонние организации. С таким количеством высокооплачиваемых сотрудников, работающих для достижения общей цели, каждый бизнес должен автоматизировать как можно больше, чтобы избежать ошибок и расходов. При выполнении тестов возникает риск дублирования усилий. При наличии большого количества сложных веб-приложений это может привести к значительному объему ненужной работы, что негативно скажется на времени и управлении проектами. Если тестирование безопасности веб-приложений не автоматизировано, некоторые (если не все) серьезные уязвимости веб-приложений могут быть пропущены. Например, ERP имеет 200 точек входа, которые должны быть проверены по 100 различным вариантам. 20 000 тестов по 5 минут займут у специалиста 208 рабочих дней только на поиск. Автоматический сканер выдаст отчеты за нескольких часов, и в отличие от человека, не забудет отсканировать входной параметр, не прекратит перебор вариантов конкретной атаки. При оценке возможностей автоматизации необходимо обращать внимание на возможность коллективной работы по обеспечению безопасности веб-приложений. Так явный приоритет имеют многопользовательские сканеры: различные роли, управление доступом и правами к сканеру, его возможностям, результатам работы (многопользовательские платформы).

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

Следующим критерием при выборе сканера безопасности веб-приложений, является количество найденных уязвимостей, которые не являются ложными срабатываниями. Ложное срабатывание (false positive) похоже на ложную тревогу —  сигнализация срабатывает, а взломщика нет; сканер указывает на уязвимость, но на самом деле это не так. Уязвимость, найденная сканером, далеко не всегда требует срочных действий, а та, что подтверждена существующим эксплойтом, действительно требует срочной реакции. К сожалению, некоторые сканеры могут идентифицировать сотни критических уязвимостей, более 70% из которых будут ложными срабатываниями. При отсутствии ложных срабатываний не придется тратить время на проверку обнаруженных уязвимостей вместо исправлений реально существующих. Тест на проникновение может потребовать значительного количества времени, так как тестировщики должны проверить каждую уязвимость на возможность ее эксплуатации. По своей природе люди склонны игнорировать ложные тревоги. Пентестеры делают то же самое: если первые 20 вариантов из 200 уязвимостей являются ложными срабатываниями, тестер предполагает, что все остальные также являются ложными срабатываниями, и игнорирует их. При этом вероятность наличия реальной уязвимости остается высокой. Если специалист не сможет эксплуатировать уязвимость из-за недостатка знаний или опыта, такая уязвимость считается ложным срабатыванием и не будет устранена.

Наиболее продуктивной и экономически эффективной для обеспечения безопасности веб-приложений является технология сканирования на основе доказательств (Proof-Based Scanning Technology). Сканер должен автоматически проверить найденные уязвимости и представить доказательства возможности их  эксплуатации. В этом случае тестирование займет гораздо меньше времени, и для его проведения не потребуется присутствие специалистов с многолетним опытом «этического взлома». Единицы из представленных на рынке сканеров имеют такую технологию. При ней также безопасна эксплуатация уязвимостей и нет никаких шансов нарушить целостность данных или доступность сервисов.

 

Рисунок 5. Технология Proof-Based Scanning Technology

 

Не последним критерием выбора является экономичность выбранного решения. Здесь важны следующие моменты:

1. Компоненты решения.

Стоит обратить внимание, что далеко не все производители предлагают интересующее нас решение в виде готового продукта:

• самодостаточен ли предложенный продукт или потребует для работы других продуктов производителя (платформы, сервиса, связи с уже имеющимся решением);
• все ли требуемые (продемонстрированные) функции выполняются продуктом или некоторые из них требуют отдельных лицензий;
• какая редакция продукта требуется и предлагается: Enterprise, Professional, Standard и пр. могут иметь существенные ограничения и различия.

2. Лицензирование.

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

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

Ежегодная подписка по количеству сканирований скорее менее выгодна, чем по количеству сканируемых объектов, адресов или сайтов.

Лицензия на несколько лет выгоднее по сравнению с годовой.

3. Техническая поддержка

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

4. Форм-фактор решения.

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

5. Конфиденциальность

Сервис из облака (SaaS) хранит и использует конфиденциальные данные пользователя (информацию о приложениях, связанных системах, уязвимостях и пр.) вне контролируемого периметра пользователя. В случае полного контроля над решением (on-premise) конфиденциальность может быть обеспечена самим владельцем.

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

Системные требования или требуемая для решения инфраструктура могут потребовать дополнительных расходов.

 

Выводы

Владельцы бюджетов и сотрудники служб ИБ задают вопрос, какой вариант является лучшим: инвестировать в сканер безопасности веб-приложений, который может быть использован собственными сотрудниками, или нанять профессиональную команду пен-тестеров? И если сканер уже есть, то существует ли «правильный» сотрудник, чтобы проверить результаты его работы? Сканеры безопасности никогда не заменят профессионалов, но и профессионалы никогда не будут такими эффективными, как автоматические сканеры. Благодаря автоматизации и современным технологиям мы можем автоматизировать больше, поэтому тесты на проникновение требуют меньше вмешательства человека. Gartner прогнозирует, что рынок автоматических сканеров приложений достигнет 14% всех средств обеспечения безопасности к 2021 году, оставаясь самым быстрорастущим среди всех сегментов ИБ. Но нельзя полагаться только на сканеры. Мы подготовили для вас краткую памятку по защите веб-приложений:

1. Регулярно проводите сканирование веб-приложений автоматическим сканером.
2. Отключите не используемые в среде веб-приложения функции операционной системы (сетевые службы/демоны, например, SMTP).
3. Запретите локальный вход на веб-сервер. Если не возможно, используйте RDP или SSH с шифрованием.
4. Ограничьте удаленный доступ к IP-адресам корпоративной сети.
5. Используйте отдельные учетные записи с ограниченными правами для каждой роли администраторов (резервные копии, управление журналами, обновления БД, настройка служб и т. д.).
6. Предоставьте минимально возможные привилегии каждому приложению, службе и пользователю.
7. Отделяйте веб-окружение, среды разработки и тестирования. Включенная отладка среды веб-приложения формирует журналы, содержащие конфиденциальную информацию о настройке баз данных. Не загружайте файлы журналов или файлы исходного кода в среду «боевого» веб-приложения.
8. Несвязанную информацию (номера счетов клиентов и активность пользователей веб-сайта) храните в разных БД, с разными пользователями.
9. Примените ту же концепцию сегрегации к файлам ОС и веб-приложений. В идеале файлы веб-приложения, т. е. каталог, который публикуется на веб-сервере, должны находиться на отдельном от ОС и файлов журнала диске.
10. Всегда используйте самую последнюю версию программного обеспечения и устанавливайте исправления безопасности.
11. Проводите регулярный мониторинг и аудит серверов и журналов, анализируйте лог-файлы серверов.
12. Помимо сканера безопасности веб-приложений, обязательно используйте сканер безопасности сети другого производителя.