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: когда приложения и процессы становятся все более сложными и запутанными, а мы чтобы приоритезировать необъятное фокусируемся прежде всего на опыте клиента, на том, что находится максимально справа. А затем "раскручиваем" то необходимое, что нужно для того чтобы его опыт состоялся (включая требования к ИБ и соответствие регуляторике).
#имхо
Нашу команду часто подключают к процессам выстраивания безопасной разработки в компаниях. В свете продолжающихся изменений регуляторики будут ещё чаще. Помимо вопросов относящихся к специфике 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: когда приложения и процессы становятся все более сложными и запутанными, а мы чтобы приоритезировать необъятное фокусируемся прежде всего на опыте клиента, на том, что находится максимально справа. А затем "раскручиваем" то необходимое, что нужно для того чтобы его опыт состоялся (включая требования к ИБ и соответствие регуляторике).
#имхо
👍25❤7
"Суровые истины, о которых ваш CISO не скажет"
Сегодня мы делимся довольно провокационным постом, основанным на материалах доклада "Hard Truths Your CISO Won’t Tell You"🌶.
Автор рассматривает множество "темных сторон" ИБ, с которыми в некоторых случаях можно согласиться, а в некоторых — нет. Предлагаем вам ознакомиться с основными тезисами:
Положительные моменты в ИБ:
А что вы думаете по этим тезисам? С каким согласны, а с какими нет? 🙃
#имхо
Сегодня мы делимся довольно провокационным постом, основанным на материалах доклада "Hard Truths Your CISO Won’t Tell You"🌶.
Автор рассматривает множество "темных сторон" ИБ, с которыми в некоторых случаях можно согласиться, а в некоторых — нет. Предлагаем вам ознакомиться с основными тезисами:
- Бизнес всегда будет важнее безопасности, независимо от того, какие приоритеты компании декларируют в своих публичных заявлениях о защите данных клиентов.
- Compliance поддерживает бизнес. Соответствие требованиям регуляторов всегда в приоритете, поскольку без этого бизнес часто не может функционировать (оставим в стороне мнение CISM, который рассматривает compliance как еще один вид риска).
- Опросники безопасности, используемые в B2B отношениях (TPRM), нередко основаны на вранье и предоставления ложной информации, чтобы вновь поддержать бизнес.
- Людям по своей природе сложно предсказывать и оценивать риски. Люди часто ошибочно полагают, что акулы опаснее бассейнов, хотя статистически больше людей погибает именно в бассейнах. Почему тогда мы берем риск-ориентированный подход за основу? Соответственно, так как безопасность строится на оценке абстрактных рисков, её можно скорее отнести к творчеству, а не к точным наукам.
- В информационной безопасности многое построено на светофоре - приоритизации по категориям критичности (critical, medium и т.д.). Но до сих пор нет однозначного понимания, как правильно работать с этими категориями. Два «желтых» риска — это лучше или хуже, чем один «красный»?
- Безопасность поглощает бюджеты под предлогом "минимизации рисков", но насколько это эффективно, никто не может точно оценить.
- Нет гарантии, что безопасность действительно сработает там где надо и поможет избежать серьезных последствий. Стоит ли компании ожидать утечки? (непонятно). Достаточно ли количество людей в безопасности или нужно больше/меньше? Все ли мы делаем правильно? Как оценить изменение в безопасности, если мы оставим только 1/5 команды ИБ?
- Влияние инцидентов на акции компаний минимально. Статистика показывает, что большинство компаний восстанавливаются через 2-6 месяцев после утечек данных.
- Защита данных потеряла свою значимость. Рынок дата-брокеров, торгующих информацией о людях, продолжает расти, а стоимость персональных данных составляет в среднем 0.00005$ на человека.
- Безопасность часто опирается на менеджеров среднего звена, которых не воспринимают всерьез. Аналогично руководство компании и разработчики предпочитают не уделять этому внимание, поскольку ROI от вложений в безопасность остается невысоким.
- Закупки решений ИБ часто базируются на личных связях CISO с основателями компаний, инвесторами и других неформальных факторах, далёких от рациональных обоснований.
- Большинство моделирований угроз неэффективны. Разработчики ненавидят этот процесс, а архитектура может измениться на следующий день после проведения моделирования — и вы об этом даже не узнаете.
Положительные моменты в ИБ:
- Сообщество специалистов по информационной безопасности выделяется своей сплоченностью на фоне общей борьбы против "них" - групп преступности.
- Все больше профессионалов ИБ понимают бизнес и начинают менять устаревшие парадигмы.
- Информационная безопасность медленно, но верно развивается и начинает напоминать точную науку.
- Разработчики также стремятся делать все правильно, и в условиях дефицита кадров волей-неволей "перехватывают на себя" все больше функций и задач ИБ.
А что вы думаете по этим тезисам? С каким согласны, а с какими нет? 🙃
#имхо
💯23👍8❤2🤡2👨💻1