В сети можно встретить различные трактования понятия AppSec (Application Security). И в этой статье мы попробуем разобраться с тем, что же должно входить в AppSec и какие навыки требуются специалистам, работающим в данной отрасли и какие инструменты они должны применять.
В целом, методология AppSec помогает защитить данные и код приложений от кибератак и кражи данных. В методологии рассматриваются все аспекты безопасности при проектировании, разработке и развертывании приложений. AppSec включает в себя внедрение программного обеспечения, аппаратного обеспечения и процедур, которые выявляют и сокращают количество уязвимостей в системе безопасности и сводят к минимуму вероятность успешной атаки.
AppSec обычно включает в себя внедрение средств защиты и контроля в программные процессы. Например, автоматический статический анализ нового кода, тестирование новых версий программного обеспечения на наличие уязвимостей в системе безопасности или неправильных настроек, а также использование брандмауэра приложений для строгого определения разрешенных и запрещенных действий.
Рассмотрим более подробно составные части методологии AppSec.
Secure Software Development Lifecycle
Начинать рассказ об AppSec стоит с рассмотрения концепции разработки ПО, заключающейся в формировании требований к приложению, безопасном программировании, тестировании, сертификации, эксплуатации и обновлении.
SSDLC предполагает построение и анализ модели угроз для создаваемого приложения с учетом рисков, разработку дизайна приложения в соответствии с данными модели, разработку приложения с использованием различных средств анализа кода и тестирования, и собственно развертывание в безопасной конфигурации.
Обо всем этом мы и поговорим далее.
Модель угроз
Очевидно, что для эффективного построения защиты приложения необходимо хорошо понимать, как злоумышленники могут попытаться его взломать. И в этом нам может помочь моделирование угроз. С его помощью мы можем оптимизировать безопасность систем, бизнес-процессов и приложений. Оно включает в себя выявление уязвимостей и целей, а также определение подходящих контрмер для смягчения и предотвращения воздействия угроз. Это фундаментальный компонент комплек��ной программы обеспечения безопасности приложений.
При выполнении моделирования угроз создаваемого приложения необходимо прежде всего идентифицировать все активы, которые будут участвовать в его работе. Мы должны не просто знать, сколько машин у нас работает под Windows, Linux, MacOS и сколько каких серверных ОС используется. Важно понимать, какие роли выполняют те или иные узлы, в каких бизнес процессах они участвуют. Важную роль играет критичность данных процессов. Ведь один сервер под управлением Ubuntu 22.04 может участвовать в критичном бизнес процессе, простой которого приведет к крупным финансовым убыткам. А другой сервер под управлением аналогичной ОС используется для обеспечения не слишком критичного процесса учета рабочего времени сотрудников.
Поэтому при инвентаризации важно не просто посчитать операционки узлов и образы контейнеров, на которых размещаются компоненты приложения, а нужно идентифицировать каждый узел в рамках бизнес-процессов и их критичности. После идентификации необходимо составить профиль безопасности, то есть понять, какие есть потенциальные угрозы для данного узла. Для этого необходимо, прежде всего, выявить те уязвимости, которые есть в ОС и приложениях, установленных на узле.
Найденные уязвимости необходимо приоритезировать, и конечно, постараться устранить, насколько это возможно.
Что касается средств для инвентаризации и поиска уязвимостей, то на рынке имеется множество коммерческих решений от российских вендоров. Но в простейшем случае найти узлы в сети можно с помощью nmap, а для идентификации уязвимостей можно воспользоваться, например, сканером Trivy.
На рисунке ниже представлен фрагмент результатов сканирования образа Nginx. Хотя утилита также может находить не только уязвимости, но и неправильные конфигурации, оставленные в проекте секреты и лицензии и работает как с файлами, так и с образами виртуальных машин, репозиториями GIT и облачными ресурсами.
Общий формат вызова утилиты:
trivy [global flags] command [flags] target
Тестирование
AppSec‑тестирование (AST) помогает выявлять и минимизировать уязвимости программного обеспечения. Это позволяет командам предотвращать уязвимости программного обеспечения перед развертыванием и быстро выявлять уязвимости в рабочей среде. Рассмот��им основные виды тестов.
Статическое тестирование безопасности приложений (SAST) помогает выявлять дефекты кода, анализируя исходные файлы приложений на предмет их первопричин. Оно позволяет сравнивать результаты сканирования в режиме статического анализа с решениями в режиме реального времени для быстрого обнаружения проблем безопасности, сокращения времени на устранение неполадок и совместного устранения неполадок.
Здесь для разных языков будут использоваться разные анализаторы. Так для C/C++ это может быть clang, для Python — Bandit и так далее. Общий смысл заключается в том, что анализатору на вход подается файл с исходным кодом и на выходе мы получаем отчет о найденных ошибках.
Динамическое тестирование безопасности приложений (DAST) имитирует нарушения безопасности в запущенном веб‑приложении для выявления уязвимостей, которые можно использовать. Эти инструменты оценивают приложения в рабочей среде, чтобы помочь обнаружить ошибки, связанные с выполнением или средой.
Интерактивное тестирование безопасности приложений (IAST) использует элементы SAST и DAST, выполняя анализ в режиме реального времени или на любом этапе SDLC из приложения. Инструменты IAST получают доступ к коду и компонентам приложения, что означает, что инструменты обеспечивают всесторонний доступ, необходимый для получения точных результатов.
Защита безопасности приложений во время выполнения (RASP) — это инструменты, которые работают непосредственно в приложении, обеспечивая непрерывную проверку безопасности и автоматически реагируя на возможные нарушения. Распространенные меры реагирования включают оповещение ИТ‑специалистов и завершение подозрительного сеанса.
Платформа защиты облачных приложений (CNAPP) централизует управление всеми инструментами, используемыми для защиты облачных приложений. Он объединяет различные технологии, такие как управление состоянием облачной безопасности (CSPM) и платформа защиты облачной рабочей нагрузки (CWPP), управление правами идентификации, автоматизация и безопасность оркестровки для контейнерных платформ оркестровки, таких как Kubernetes, а также обнаружение и защита API.
Рекомендации по обеспечению безопасности приложений
Далее рассмотрим несколько основных рекомендаций по обес��ечению безопасности приложений.
Прежде всего, это смещение уровня безопасности «влево». Современная динамично развивающаяся индустрия разработки программного обеспечения требует частых обновлений — иногда по нескольку раз в день. Тесты безопасности должны быть включены в процесс разработки, чтобы команды разработчиков и службы безопасности не отставали от спроса. Тестирование должно начинаться на ранней стадии SDLC (левее, если рассматривать диаграмму жизненного цикла SDLC), чтобы избежать препятствий для выпуска в конце конвейера.
Понимание существующего процесса разработки и взаимоотношений между разработчиками и тестировщиками безопасности важно для реализации эффективной стратегии «сдвиг влево». Следующим шагом является интеграция процессов обеспечения безопасности в существующий конвейер разработки, чтобы разработчики могли легко адаптироваться к новому подходу.
Конвейер CI/CD должен включать автоматизированные тесты безопасности на различных этапах. Интеграция средств автоматизации безопасности в конвейер позволяет команде самостоятельно тестировать код, не полагаясь на другие команды, что позволяет разработчикам быстро и просто устранять проблемы.
Также необходимо осуществлять эффективное управление привилегиями. Не каждому пользователю в организации требуются одинаковые привилегии доступа. Ограничение доступа к данным и приложениям в соответствии с требованиями безопасности является одним из основных методов обеспечения безопасности. Существуют две основные причины для ограничения привилегий.
Если хакеры могут получить доступ к системе с помощью украденных учетных данных (например, от сотрудника отдела маркетинга), должны быть предусмотрены средства контроля, предотвращающие доступ к другим данным. Средства контроля доступа с наименьшими привилегиями помогают предотвратить боковое перемещение и минимизировать поверхность атаки.
Внутренние угрозы становятся более опасными, когда у злоумышленника есть доступ к ресурсам внутренней сети. Эти угрозы могут быть злонамеренными или непреднамеренными, например, сотрудник может неправильно установить устройство или загрузить вредоносные файлы.
Управление привилегиями должно основываться на принципе наименьших привилег��й, чтобы сотрудники и внешние пользователи не могли получить доступ к ненужным им данным, что снижает общую уязвимость.
Провести анализ предоставляемых прав можно без помощи специальных инструментов. Достаточно посмотреть содержимое файлов /etc/sudoers, /etc/groups на наличие пользователей, входящих в привилегированные группы.
Также можно поискать в системе файлы, с правами SUID/SGID.
find "$DIRECTORY" -perm /u=s,g=s
Еще можно поискать файлы с полными правами 777:
find / -type f -perm 0777
Эти действия должны выполняться, когда целевое приложение уже развернуто, в процессе эксплуатации. И проверки нужно проводить на регулярной основе, так как безопасность приложений — это процесс, а не результат.
Заключение
Мы рассмотрели основы процесса обеспечения безопасности приложений AppSec и познакомились с некоторыми инструментами, которые могут использоваться для выполнения задач данного процесса.
Пользуясь случаем, напомню про открытые уроки по безопасности приложений:
7 октября — Погружение в правила и стратегии защиты: основные термины и практики в области безопасности, примеры уязвимостей и их классификация, актуальные тренды и новшества в кибербезопасности. Запись по ссылке
14 октября — Анализ сетевого трафика: основные методы, виды, инструменты анализа сетевого трафика; принцип работы Burp Suite. Запись по ссылке
