- Контрольных списков безопасности приложений больше недостаточно
- Основы эффективного DevSecOps
- Найти все риски
- Быстро исправить
- Работать с проверенными и действенными данными
- Всегда работать над улучшением: идеального уровня защиты программ не существует
- Основы гигиены кибербезопасности
- Как Invicti внедряет AppSec
Контрольных списков безопасности приложений больше недостаточно
Контрольных списков безопасности приложений больше недостаточно
Выпуск OWASP Top 10 2021 года вызвал споры среди специалистов по безопасности, так как в нём намеренно отошли от списка конкретных уязвимостей безопасности. Вместо этого OWASP перешёл к более стратегическому подходу и даже добавил небезопасный дизайн (insecure design) как категорию уязвимостей безопасности приложений. Это дало понять, что с такой скоростью и масштабами разработки приложений безопасность веб-приложений уже нельзя рассматривать как отдельный процесс, который можно свести к вычеркиванию SQL-инъекций и других распространённых уязвимостей из списка.
Любая крупная организация разрабатывает по крайней мере часть своего программного обеспечения собственными силами, поэтому использование AppSec, понимаемое как ручная проверка наиболее распространённых уязвимостей приложений время от времени, является дорогим и неэффективным. Это также опасно, так как уязвимости могут оставаться в производстве месяцами, подвергая организацию риску атак до следующего тестирования и исправления.
Лучшей практикой безопасности веб-приложений является надёжное создание приложений, которые не имеют известных уязвимостей перед запуском в производство, а это значит, что безопасное кодирование, тестирование безопасности приложений и исправление ошибок должны быть неотъемлемой частью процесса разработки.
Основы эффективного DevSecOps
Хотя DevSecOps стало модным словом в индустрии, оно идеально отражает идею интеграции безопасности в процесс разработки и эксплуатации, а не рассматривает её как отдельную фазу. Подобно тому, как DevOps разрушил традиционные барьеры между разработкой и эксплуатацией, так и DevSecOps должен (в идеале) сделать безопасность приложений неотъемлемой частью DevOps. Сложность заключается в том, чтобы сделать это для реальных сред, команд разработчиков и графиков выпусков.
Основываясь на вызовах, с которыми сталкивались клиенты Invicti, можно определить четыре стратегических столпа для построения наилучшей стратегии безопасности веб-приложений для реального мира.
Найти все риски
В идеальном мире разработчики всегда предоставляли бы безопасный код, а все веб-активы в организации были бы тщательно каталогизированы и управляемы. На самом деле же, ничто не является 100% защищённым, и вся информация, получаемая о веб-среде, всегда несёт в себе определённую неопределённость. Даже одной уязвимости может быть достаточно для причинения значительного ущерба, поэтому единственный способ быть уверенным, что делается всё возможное, — это постоянно контролировать веб-среды, тестировать всё и никому не доверять.
Хотя, безусловно, лучшей практикой является ведение централизованного реестра всех веб-сайтов, приложений и API для упрощения ввода в эксплуатацию, обслуживания и вывода из эксплуатации, большинство организаций всё ещё имеют лишь поверхностное представление о реальном состоянии их поверхности веб-атак. Крупная организация может иметь сотни или даже тысячи веб-активов, включая веб-сайты, веб-приложения, веб-сервисы и веб-интерфейсы. Современные приложения, ориентированные на сервис, часто подключаются к десяткам сервисов и предоставляют собственную функциональность через интерфейсы, увеличивая поверхность атаки. Это делает автоматизированное и непрерывное обнаружение веб-активов важной частью любой программы веб-безопасности.
Что касается самого тестирования, можно выбрать из множества подходов и инструментов. Конечная цель состоит в том, чтобы убедиться, что в производстве нет известных проблем с безопасностью, и подход будет различаться для каждой организации. Чтобы получить комплексное сканирование уязвимостей в различных приложениях, технологиях, архитектурах и этапах разработки, потребуется по крайней мере качественное динамическое тестирование безопасности приложений (DAST) с автоматизацией рабочих процессов, чтобы не отставать от конвейера разработки.
Быстро исправить
Современные команды разработчиков находятся под давлением необходимости внедрять инновации и выполнять работу вовремя, обычно работая в коротких, гибких спринтах, не имея времени ждать на безопасность. Чтобы быть эффективными, тестирование безопасности приложений и исправление ошибок должны быть встроены в жизненный цикл разработки программного обеспечения (SDLC) и работать эффективно, не нарушая темп разработки. А поскольку весь конвейер разработки в значительной мере автоматизирован, процесс тестирования и устранения уязвимостей безопасности должен быть интегрирован в него с таким же уровнем автоматизации.
Эффективное и долговременное исправление ошибок является настоящим ключом к созданию более безопасных веб-приложений и улучшению качества кода в долгосрочной перспективе. Возьмём конкретный пример: XSS является наиболее распространённой уязвимостью веб-приложений, и если о них сообщается разработчикам без рекомендаций по исправлению, они будут появляться и множиться бесконечно из-за частичных исправлений, которые работают только в определённом контексте. Ещё один способ уменьшить количество XSS в долгосрочной перспективе — это помочь разработчикам понять и устранить первопричину, которая заключается в отсутствии или неполной проверке данных, введённых пользователем.
Автоматизация процесса тестирования и устранения уязвимостей требует инструментов, которые непосредственно взаимодействуют с существующими инструментами разработки и тестирования. Разработчики полагаются на трекеры для планирования и выполнения задач, поэтому внесение актуальных проблем безопасности в трекер является критичным для того, чтобы их увидели и решили. Самое главное, какие бы инструменты безопасности ни использовались, они должны сообщать о реальных рисках безопасности, не заваливая разработчиков ложноположительными результатами.
Работать с проверенными и действенными данными
Достижение правильного баланса между нахождением всех важных уязвимостей и минимизацией шума в отчётах об уязвимостях является основой любого процесса сканирования безопасности. Это выходит далеко за рамки обычных дискуссий о ложных срабатываниях. Хотя ложные срабатывания абсолютно точно создают дополнительную работу, которая может свести на нет многие или все преимущества автоматизации, фундаментальным вопросом является уверенность в том, что данные, которые вы передаёте в рабочие процессы, являются корректными и пригодными для использования.
Чтобы получить точные результаты, которые отражают реальное состояние безопасности в текущей среде угроз, необходимо тщательно подойти к выбору инструментария. Подобно тому, как защита веб-сайтов и приложений сейчас — это гораздо больше, чем тестирование на наличие конкретных уязвимостей, так и решение по инструментам тестирования безопасности больше не является простым вопросом проставления галочек в технических полях. Лучше спросить, какие улучшения безопасности инструмент внесёт в уникальную среду и рабочие процессы. Просто добавление ещё одного источника отчётов о безопасности не всегда приводит к улучшению безопасности приложений — и может даже ухудшить её, если команды безопасности и разработчики будут перегружены нерелевантной информацией.
Обратной стороной работы только с проверенными данными является неявное недоверие ко всему, что не было проверено. На практике это означает не только тестирование каждой части имеющейся среды веб-приложений, но и тестирование всех новых сборок и каждого исправления уязвимостей. Неполные или поверхностные исправления являются лишь временным решением безопасности приложений, поскольку основные проблемы рано или поздно появятся снова и приведут к большему количеству работы, чем было сэкономлено благодаря быстрому исправлению. Таким образом, лучшая практика AppSec должна включать инструменты и рабочие процессы, которые автоматически и неустанно тестируют и повторно тестируют всё, что движется к производству.
Всегда работать над улучшением: идеального уровня защиты программ не существует
Кибератаки – это круглосуточная угроза безопасности, которая может привести к все более дорогостоящим утечкам данных, потере конфиденциальной информации, развертыванию вредоносного ПО и разрушительным простоям. Ручное тестирование на проникновение, хотя и является жизненно важной периодической задачей, недостаточно для постоянного поддержания согласованной позиции безопасности всех веб-активов. Поэтому, помимо тестирования безопасности в SDLC, необходимо регулярно проверять сайты и приложения, которые уже запущены в производство. Это особенно важно для сторонних ресурсов и всего, что не находится в активной разработке, а значит, не охвачено каким-либо тестированием безопасности, проводимым в конвейере разработки.
Даже если приложения, которые использует компания, не изменялись в последнее время, ежедневно обнаруживаются десятки новых уязвимостей и векторов атак. То, что считалось безопасным на прошлой неделе или даже вчера, может оказаться уязвимым сегодня. Безопасное, но точное сканирование уязвимостей для производственных приложений – это отдельная тема. Вместе с тем, частой рекомендацией является клонировать текущее производственное окружение и сканировать клон, а не реальное развертывание. Таким образом, можно охватить полный набор потенциальных проблем в производственном коде и настройках, включая любые неправильные настройки безопасности, но не влияя на реальную рабочую среду.
Чтобы сделать такой уровень тестирования возможным, а также минимизировать время и усилия, необходимые для исправления, следует построить надежный и полностью автоматизированный процесс тестирования безопасности, который начинается с первых строк исходного кода и охватывает каждую часть и фазу разработки и эксплуатации, вплоть до производства. Это делает решение DAST необходимым для тестирования всего приложения на стадии разработки и производства. С помощью современных платформ на основе DAST, таких как Invicti, можно продолжить тестирование на этапе разработки, чтобы дополнить текущее статическое тестирование безопасности приложений (SAST) или даже использовать его как единственную технологию тестирования приложений – особенно полезно для начала работы с AppSec.
Основы гигиены кибербезопасности
остроение процесса DevSecOps заключается в том, чтобы сделать безопасность делом каждого, поэтому радар безопасности приложений должен выходить за рамки самого приложения и охватывать также операционную безопасность. Это включает реализацию иногда необходимых мер безопасности как в приложениях, так и на веб-сервере. Например, серверы должны отправлять правильные заголовки безопасности, включая HSTS для обеспечения шифрования SSL/TLS для всего трафика и CSP (Content Security Policy) для ограничения потенциально вредоносных источников контента. Также команды должны знать, как установить безопасные атрибуты файлов cookie, чтобы минимизировать риск атак перехвата сеансов.
Если смотреть еще шире, то веб-аппликационный брандмауэр (WAF) необходим и как дополнительная линия защиты, и как способ временного устранения уязвимостей до тех пор, пока не будет готов патч или исправление. (Напоминание: Правила WAF – это всего лишь временное решение, а не постоянное устранение проблем безопасности). Эффективный процесс исправления также имеет решающее значение для минимизации векторов атак, связанных с библиотеками с открытым исходным кодом и другими сторонними компонентами в веб-стеке, хотя, в отличие от сетевой безопасности, патчи – это лишь один из аспектов процесса исправления.
Возвращаясь к тому, что OWASP считает категорию “незащищенный дизайн” слабой стороной безопасности, команды разработчиков программного обеспечения должны учитывать безопасность во всем, что они делают и планируют.
Вот конкретный пример: обеспечение надлежащего контроля доступа имеет решающее значение для минимизации риска неавторизованного доступа, который может привести к получению злоумышленниками конфиденциальной информации или эскалации от незначительного начального нарушения до полной компрометации системы. Но безопасный и эффективный контроль доступа – это не только надежные пароли или многофакторная аутентификация (хотя и то, и другое важно) – он начинается с безопасного дизайна ролей и привилегий пользователей, который соответствует как необходимой бизнес-логике, так и принципу наименьших привилегий. И это не то, что можно добавить в последнюю минуту.
Как Invicti внедряет AppSec
Каждая организация уникальна, поэтому существует множество способов эффективно настроить безопасность приложений. Обычно поиск, развертывание и настройка всех инструментов и рабочих процессов занимает много времени, которое теряется без пользы. Invicti разработала первое решение DAST, которое интегрируется в любой рабочий процесс разработки веб-приложений и поддерживает максимальное покрытие с возможностью углубленного анализа с помощью интегрированных IAST и SCA. Это не единственный способ реализации AppSec, но это один из ведущих.
