Почему DevSecOps приходится бороться за принятие эффективных мер

0
89

This post is also available in: Английский Французский Немецкий Итальянский Португальский, Бразилия Испанский

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

1. Определение эффективной защиты

Не нужно каждый раз изобретать колесо. Развитие современных приложений, архитектуры доставки и платформа разработки приложений предоставляют максимум гибкости специалистам по исследованиям и разработкам. Кроме того, доступны готовые сервисы, модули и функции, которые легко интегрировать. Однако все усложняет необходимость гарантировать доступность приложений, а также целостность и конфиденциальность данных.

Купить решение для защиты довольно просто — стоит только выбрать технологию, устраняющую те или иные угрозы. Управлять этим решением уже сложнее. Прежде всего, новые технологии меняют баланс между безопасностью и производительностью, что должны учитывать разработчики приложений. Предприятия могут ускорить вывод приложений на рынок и выпуск их версий с меньшими затратами, предоставив специалистам по разработке и поставке приложений (AD&D) больше полномочий в принятии решений по обеспечению безопасности. Эффективная защита должна быть частью вашей стратегии. Другими словами, она не должна нарушать процессы, приводить к сбоям или вызывать снижение производительности.

[Возможно, вам будет интересно: Почему DevSecOps должны добиваться эффективного принудительного принятия мер безопасности.]

2. Эффективная защита должна обнаруживать угрозы

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

1. Решение не полностью покрывает поверхность атаки.

2. Решение не обеспечивает активного приведения в исполнение мер безопасности.

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

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

Помимо защиты API, для многих услуг, основанных на интеграции или обслуживании ботов, требуется четко различать полезных и зловредных ботов. Технология RASP (Runtime Application Self Protection) уязвима к некоторым атакам (например, атакам типа отказ в обслуживании) из-за того, что ее используют специалисты AD&D. И это только один пример.

2. С точки зрения DevOps, рискованно принимать принудительные меры безопасности. Это может повлиять на работу пользователей или даже нарушить технологический процесс, что приведет к ошибкам выполнения. Жизненный цикл разработки программного обеспечения (SDLC) содержит много слепых зон в отношении безопасности, особенно в современной гибридной мультиоблачной архитектуре. Именно поэтому во многих системах есть оповещения, что весьма полезно.

[Возможно, вам будет интересно: Почему DevSecOps должны добиваться эффективного принудительного принятия мер безопасности.]

3. «Эффективная защита» должна работать

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

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

4. «Эффективная защита» должна оставаться эффективной

Динамическая природа гибкого цикла SDLC с частыми изменениями и ежедневными обновлениями приложений может делать политики безопасности все менее точными. Этот процесс не масштабируется. Штатный сотрудник должен обновлять правила, составлять белые списки и обрабатывать исключения.

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

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here