SEC_DEVOPS Telegram 614
AppSec != DevSecOps

Нашу команду часто подключают к процессам выстраивания безопасной разработки в компаниях. В свете продолжающихся изменений регуляторики будут ещё чаще. Помимо вопросов относящихся к специфике HR, существует пул hard skills задач, которые начинаются с четкого определения зоны ответственности человека и требуемых компетенций. Сегодняшний пост посвящен рефлексии и размышлениям о разнице между AppSec, DevSecOps и ProdSec на фоне неоднозначного видения этих ролей в компаниях, что часто приводит к недопониманию на интервью и затрудняет подбор подходящего сотрудника.

Все, что вы прочитаете далее, является субъективным рассуждением на основе эмпирики.

AppSec

Цель: Обеспечение безопасности приложения. Это отражено в KPI, включая количество найденных уязвимостей, охват тестируемых приложений и глубину анализа. В задачи входят анализ архитектуры, моделирование угроз, ревью кода и тестирование безопасности. Роль AppSec существует достаточно давно, с начала 2000-х годов, когда появилась организация OWASP. Хотя о результативности этой роли можно порассуждать, подробнее писали в относительно старом посте.

DevSecOps

Цель: Автоматизация процессов безопасности и интеграция безопасности в DevOps. В KPI входит адаптация инструментов безопасности в SDLC и автоматизация проверок безопасности на уровне CI/CD. Сюда часто включается безопасность платформ Kubernetes и облачных сервисов. Концепция DevSecOps начала формироваться в 2012-2014 годах.

Несмотря на явные различия в целях и задачах, часто можно встретить распределение ролей в командах, где AppSec-инженер в крупной компании, способной разделить ответственность, занимается встраиванием инструментов в CI/CD. При этом у инженера явный уклон именно в безопасность веба и мобильных приложений. В итоге мы видим, что внедрение произошло, но нередко оно выполнено неэффективно, не учитывая многие аспекты, к которым приходят опытные DevOps-инженеры. На рынке AppSec также существует множество кандидатов, приходящих на интервью с единственным опытом встраивания сканеров, многие из которых никогда не работали с инструментами вроде Burp Suite.

Product Security

Кто такие Product Security, о которых мы слышим все чаще последние 2-3 года, особенно на интернациональной рынке? Это команды, занимающиеся безопасностью продукта в целом, включая управление уязвимостями продукта и его инфраструктуры, а также облачную безопасность. Некоторые компании даже имеют команды Product Security как единственных специалистов по безопасности. ProdSec также тесно взаимодействует с Product Management, что нечасто встречается в AppSec. ProdSec интегрирует безопасность в жизненный цикл пользователя, внедряя MFA, историю входов, CAPTCHA и другие механизмы, тесно сотрудничая не только с dev и product, но и с маркетингом и другими бизнес-направлениями. Команде ProdSec, как и AppSec, не обязательно иметь в составе DevSecOps-инженера, который может существовать отдельно в команде DevOps.

Это зарождающееся разделение, где ProdSec получает больше доменов ИБ под управление, обусловлено, на мой взгляд, как и тесным переплетением слоев абстракций (cloud-native инфраструктура) так и непониманием старой школы инфраструктурных безопасников особенностей разработки и того, что нужно делать, чтобы быть гармоничным участником процесса. Любое изменение конфигурации в облаке, применение патча или правила на WAF может сильно повлиять на работу пользователя. Поэтому любое изменение для продуктов, независимо от инфраструктурного или прикладного слоя, может проходить аналогичный цикл SDLC, как и любое изменение кода.

P.S. И в этом процессе возникновения новых ролей можно разглядеть интересный элемент, дополняющий наш любимый shift left. Этакий shift right: когда приложения и процессы становятся все более сложными и запутанными, а мы чтобы приоритезировать необъятное фокусируемся прежде всего на опыте клиента, на том, что находится максимально справа. А затем "раскручиваем" то необходимое, что нужно для того чтобы его опыт состоялся (включая требования к ИБ и соответствие регуляторике).

#имхо



tgoop.com/sec_devops/614
Create:
Last Update:

AppSec != DevSecOps

Нашу команду часто подключают к процессам выстраивания безопасной разработки в компаниях. В свете продолжающихся изменений регуляторики будут ещё чаще. Помимо вопросов относящихся к специфике HR, существует пул hard skills задач, которые начинаются с четкого определения зоны ответственности человека и требуемых компетенций. Сегодняшний пост посвящен рефлексии и размышлениям о разнице между AppSec, DevSecOps и ProdSec на фоне неоднозначного видения этих ролей в компаниях, что часто приводит к недопониманию на интервью и затрудняет подбор подходящего сотрудника.

Все, что вы прочитаете далее, является субъективным рассуждением на основе эмпирики.

AppSec

Цель: Обеспечение безопасности приложения. Это отражено в KPI, включая количество найденных уязвимостей, охват тестируемых приложений и глубину анализа. В задачи входят анализ архитектуры, моделирование угроз, ревью кода и тестирование безопасности. Роль AppSec существует достаточно давно, с начала 2000-х годов, когда появилась организация OWASP. Хотя о результативности этой роли можно порассуждать, подробнее писали в относительно старом посте.

DevSecOps

Цель: Автоматизация процессов безопасности и интеграция безопасности в DevOps. В KPI входит адаптация инструментов безопасности в SDLC и автоматизация проверок безопасности на уровне CI/CD. Сюда часто включается безопасность платформ Kubernetes и облачных сервисов. Концепция DevSecOps начала формироваться в 2012-2014 годах.

Несмотря на явные различия в целях и задачах, часто можно встретить распределение ролей в командах, где AppSec-инженер в крупной компании, способной разделить ответственность, занимается встраиванием инструментов в CI/CD. При этом у инженера явный уклон именно в безопасность веба и мобильных приложений. В итоге мы видим, что внедрение произошло, но нередко оно выполнено неэффективно, не учитывая многие аспекты, к которым приходят опытные DevOps-инженеры. На рынке AppSec также существует множество кандидатов, приходящих на интервью с единственным опытом встраивания сканеров, многие из которых никогда не работали с инструментами вроде Burp Suite.

Product Security

Кто такие Product Security, о которых мы слышим все чаще последние 2-3 года, особенно на интернациональной рынке? Это команды, занимающиеся безопасностью продукта в целом, включая управление уязвимостями продукта и его инфраструктуры, а также облачную безопасность. Некоторые компании даже имеют команды Product Security как единственных специалистов по безопасности. ProdSec также тесно взаимодействует с Product Management, что нечасто встречается в AppSec. ProdSec интегрирует безопасность в жизненный цикл пользователя, внедряя MFA, историю входов, CAPTCHA и другие механизмы, тесно сотрудничая не только с dev и product, но и с маркетингом и другими бизнес-направлениями. Команде ProdSec, как и AppSec, не обязательно иметь в составе DevSecOps-инженера, который может существовать отдельно в команде DevOps.

Это зарождающееся разделение, где ProdSec получает больше доменов ИБ под управление, обусловлено, на мой взгляд, как и тесным переплетением слоев абстракций (cloud-native инфраструктура) так и непониманием старой школы инфраструктурных безопасников особенностей разработки и того, что нужно делать, чтобы быть гармоничным участником процесса. Любое изменение конфигурации в облаке, применение патча или правила на WAF может сильно повлиять на работу пользователя. Поэтому любое изменение для продуктов, независимо от инфраструктурного или прикладного слоя, может проходить аналогичный цикл SDLC, как и любое изменение кода.

P.S. И в этом процессе возникновения новых ролей можно разглядеть интересный элемент, дополняющий наш любимый shift left. Этакий shift right: когда приложения и процессы становятся все более сложными и запутанными, а мы чтобы приоритезировать необъятное фокусируемся прежде всего на опыте клиента, на том, что находится максимально справа. А затем "раскручиваем" то необходимое, что нужно для того чтобы его опыт состоялся (включая требования к ИБ и соответствие регуляторике).

#имхо

BY Security Wine (бывший - DevSecOps Wine)




Share with your friend now:
tgoop.com/sec_devops/614

View MORE
Open in Telegram


Telegram News

Date: |

The Standard Channel “Hey degen, are you stressed? Just let it all out,” he wrote, along with a link to join the group. 6How to manage your Telegram channel? The Channel name and bio must be no more than 255 characters long How to build a private or public channel on Telegram?
from us


Telegram Security Wine (бывший - DevSecOps Wine)
FROM American