Безопасность по замыслу (“security by design”) – это подход к созданию приложений, который учитывает аспект кибербезопасности на каждом этапе жизненного цикла разработки ПО (SDLC). Его суть заключается в выявлении и устранении уязвимостей еще до продакшна для обеспечения проактивной стратегии AppSec.
В контексте веб-приложений безопасность по замыслу смещает фокус с реактивных мер к созданию надежных систем с самого начала. Это является шагом к внедрению безопасности в основу программного обеспечения, что включает эффективное преодоление угроз.
Разработка vs безопасность
Традиционно процессы безопасности и разработки должны находить компромиссы, но они могут быть сложными. Разработчики, как правило, склоняются к приоритизации нового функционала, тогда как безопасность отходит на второй план. Однако внедрение этого подхода может приводить к успешным кибератакам на ресурсы компании.
По принципу “secure by design” требования безопасности важно учитывать с самого начала. Разработчики и команды безопасности работают вместе на ранних этапах, чтобы как создавать инновации, так и соответствовать требованиям и защищать конфиденциальную информацию.
7 принципов безопасности по замыслу
1. “Безопасность как код” (“security as code”)
Когда команды способны автоматизировать политики безопасности и встраивать их в конвейеры CI/CD, они имеют более масштабируемое и эффективное управление рисками. С помощью инструментов “инфраструктуры как кода” (IaC) конфигурации могут быть протестированы, безопасно развернуты и иметь контролируемые версии.
2. Безопасные настройки по умолчанию
По умолчанию системы должны использовать самые безопасные конфигурации. Например, это включает в себя использование надежных паролей, применение протокола HTTPS и предотвращение чрезмерного доступа. Когда команды могут свести к минимуму потребность в ручном вмешательстве, безопасные конфигурации уменьшают фактор человеческой ошибки и улучшают управление рисками.
3. Принцип наименьших привилегий
Пользователи и системы должны иметь только те разрешения, которые нужны им для выполнения своих задач. Внедрение принципа наименьших привилегий помогает защитить конфиденциальную информацию и предотвратить утечки данных из-за проблем безопасности.
4. Распределение обязанностей
Распределение ответственности уменьшает риск злоупотребления или ошибок. К примеру, можно требовать одобрение критических действий несколькими людьми или системами, что можно внедрить для добавления изменений в продакшн.
5. Уменьшение поверхности атаки
Каждая функция, конечная точка или служба представляют собой потенциальную точку атаки. Ограничивая их количество, можно значительно усложнить злоумышленникам эксплуатацию уязвимостей. Это включает удаление устаревших API, закрытие ненужных портов и извлечение ненужных функций.
6. Проверка запросов на доступ
Каждый запрос на доступ должен проверяться. Следует внедрять механизмы контроля, которые оценивают выявленные угрозы и избегать кэширования с правами доступа. Это помогает команде убедиться, что изменения в ролях или привилегиях выполняются быстро и эффективно.
7. Правильное поведение во время сбоя
Когда системы выходят из строя, они должны по умолчанию переходить в безопасное состояние. Например, если при аутентификации произошла ошибка, доступ должен быть запрещен, а не предоставлен. Это позволяет убедиться, что неожиданные проблемы не повлияют на общую безопасность.
Безопасность по замыслу и проактивная защита с помощью DAST
Динамическое тестирование безопасности приложений (DAST) играет решающую роль в достижении безопасной разработки программного обеспечения путем обнаружения уязвимостей в запущенных приложениях. В отличие от SAST, который проверяет сам код, DAST может имитировать атаки, анализируя программу и то, как она действует во время выполнения.
Этот подход соответствует наилучшим практикам безопасности и помогает разработчикам выявлять недостатки, которые могут быть найдены, только если приложение запущено. Например, неправильные конфигурации, слабые места аутентификации или проблемы с проверкой входных данных.
Роль DAST в безопасности по замыслу
Принцип безопасности по замыслу и DAST идут рука об руку, поскольку динамическое тестирование проверяет поверхность атаки программы при разработке и продакшне, что способствует проактивному подходу AppSec.
Минимизация поверхности атаки
Инструменты DAST позволяют определять уязвимости посредством тестирования интерфейсов программы, API и конечных точек. Благодаря этому разработчики могут устранить слабые места и уменьшить поверхность атаки (например, удалить проблемные API, если они больше не нужны) до того, как злоумышленники найдут их и осуществят кибератаки.
Кроме того, DAST-платформа Invicti (ранее Netsparker) способна предоставлять функционал обнаружения API и забытых веб-сайтов, доступных в Интернете, что позволяет иметь контроль над поверхностью атаки организации.
Правильное поведение во время сбоя
Тестирование того, как веб-приложение ведет себя в разных сценариях сбоя, является ключевой функцией DAST. Эти инструменты моделируют такие условия, как неожиданные входящие данные или ошибки сервера, чтобы проверить, переходит ли веб-сайт по умолчанию в безопасное состояние. Например, это может быть запрет доступа или предоставления общей информации об ошибках, не раскрывающей конфиденциальные данные.
Безопасные настройки по умолчанию и принцип наименьших привилегий
DAST определяет неправильные конфигурации, такие как чрезмерные разрешения или опасные настройки по умолчанию, которые могут привести к успешным атакам. Например, инструмент может обращать внимание на конфигурации, обходящие требования аутентификации.
Проактивная защита с помощью регулярного тестирования
Внедрение DAST и стандартов написания кода в конвейер разработки позволяет выявлять и устранять уязвимости практически в режиме реального времени. Вот как проактивное тестирование с помощью DAST улучшает безопасность программного обеспечения:
Раннее обнаружение уязвимостей
Когда инструмент DAST интегрирован в конвейеры CI/CD, сборки можно автоматически сканировать перед развертыванием. Благодаря такому проактивному подходу слабые места исправляются быстрее, а также экономятся ресурсы благодаря устранению первопричины потенциальных утечек данных.
Реалистичная симуляция атак
DAST имитирует поведение злоумышленников, пытаясь использовать такие эксплойты, как SQL-инъекции, межсайтовый скриптинг (XSS) и другие. Это позволяет понять, как веб-сайт будет работать перед лицом реальных угроз.
Комплексное покрытие
DAST обнаруживает проблемы с аутентификацией, управлением сессиями и процессами обработки данных, которые могут быть пропущены другими инструментами.
Лучшие практики использования DAST в разработке безопасного ПО
Внедрение на ранних этапах
Важно встраивать DAST в жизненный цикл разработки программного обеспечения (SDLC), чтобы обеспечить постоянный мониторинг и тестирование на разных стадиях.
Сочетание DAST с другими инструментами
DAST можно использовать вместе с SAST (статическое тестирование безопасности приложений) и IAST (интерактивное тестирование безопасности приложений) для достижения полного покрытия и уменьшения вероятности успешных атак. Эта комбинация позволяет определять уязвимости как в коде, так и во время выполнения.
Приоритизация исправлений
Решения DAST часто предоставляют информацию об уровне серьезности выявленных уязвимостей. Таким образом, можно сосредоточиться на устранении недостатков, которые представляют наибольший риск для ресурсов.
Обучение команды
Важно обучать разработчиков правильному анализу и интерпретации результатов сканирования DAST, а также применению принципов безопасности по замыслу при исправлении уязвимостей. Это помогает улучшать знания и усовершенствовать команду.
Усиление проактивной защиты
Используя DAST в разработке ПО, организации могут перейти от реактивного к проактивному подходу к безопасности. Таким образом, можно обнаруживать и устранять уязвимости в процессе разработки, а не после атаки, что позволяет создавать надежные программы.
