В сети можно встретить различные трактования понятия AppSec (Application Security). И в этой статье мы попробуем разобраться с тем, что же должно входить в AppSec и какие навыки требуются специалистам, работающим в данной отрасли и какие инструменты они должны применять.
В целом, методология AppSec помогает защитить данные и код приложений от кибератак и кражи данных. В методологии рассматриваются все аспекты безопасности при проектировании, разработке и развертывании приложений. AppSec включает в себя внедрение программного обеспечения, аппаратного обеспечения и процедур, которые выявляют и сокращают количество уязвимостей в системе безопасности и сводят к минимуму вероятность успешной атаки.
AppSec обычно включает в себя внедрение средств защиты и контроля в программные процессы. Например, автоматический статический анализ нового кода, тестирование новых версий программного обеспечения на наличие уязвимостей в системе безопасности или неправильных настроек, а также использование брандмауэра приложений для строгого определения разрешенных и запрещенных действий.
Рассмотрим более подробно составные части методологии AppSec.
SSDLC предполагает построение и анализ модели угроз для создаваемого приложения с учетом рисков, разработку дизайна приложения в соответствии с данными модели, разработку приложения с использованием различных средств анализа кода и тестирования, и собственно развертывание в безопасной конфигурации.
Обо всем этом мы и поговорим далее.
При выполнении моделирования угроз создаваемого приложения необходимо прежде всего идентифицировать все активы, которые будут участвовать в его работе. Мы должны не просто знать, сколько машин у нас работает под Windows, Linux, MacOS и сколько каких серверных ОС используется. Важно понимать, какие роли выполняют те или иные узлы, в каких бизнес процессах они участвуют. Важную роль играет критичность данных процессов. Ведь один сервер под управлением Ubuntu 22.04 может участвовать в критичном бизнес процессе, простой которого приведет к крупным финансовым убыткам. А другой сервер под управлением аналогичной ОС используется для обеспечения не слишком критичного процесса учета рабочего времени сотрудников.
Поэтому при инвентаризации важно не просто посчитать операционки узлов и образы контейнеров, на которых размещаются компоненты приложения, а нужно идентифицировать каждый узел в рамках бизнес-процессов и их критичности. После идентификации необходимо составить профиль безопасности, то есть понять, какие есть потенциальные угрозы для данного узла. Для этого необходимо, прежде всего, выявить те уязвимости, которые есть в ОС и приложениях, установленных на узле.
Найденные уязвимости необходимо приоритезировать, и конечно, постараться устранить, насколько это возможно.
Что касается средств для инвентаризации и поиска уязвимостей, то на рынке имеется множество коммерческих решений от российских вендоров. Но в простейшем случае найти узлы в сети можно с помощью nmap, а для идентификации уязвимостей можно воспользоваться, например, сканером Trivy.
На рисунке ниже представлен фрагмент результатов сканирования образа Nginx. Хотя утилита также может находить не только уязвимости, но и неправильные конфигурации, оставленные в проекте секреты и лицензии и работает как с файлами, так и с образами виртуальных машин, репозиториями GIT и облачными ресурсами.
Общий формат вызова утилиты:
trivy [global flags] command [flags] target
Статическое тестирование безопасности приложений (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
Эти действия должны выполняться, когда целевое приложение уже развернуто, в процессе эксплуатации. И проверки нужно проводить на регулярной основе, так как безопасность приложений — это процесс, а не результат.
habr.com
В целом, методология 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 и познакомились с некоторыми инструментами, которые могут использоваться для выполнения задач данного процесса.
Из чего состоит безопасность современных приложений
В сети можно встретить различные трактования понятия AppSec (Application Security). И в этой статье мы попробуем разобраться с тем, что же должно входить в AppSec и какие...
habr.com