Я тогда миддлом был и уже имел больше 300k в месяц. А как оказалось, 300k это у них сениорский паек был, который чтобы получить надо быть гуру и как принято в таком бигтехе, делать в одиночку космолет раз в несколько месяцев. По итогам собеседования мне конечно же не смогли предложить такое. Хотя с таким процессом трудоустройства, должны предлагать выше рынка, сколько кандидатов отсекается только на этом этапе
PR в master могут создавать все Но Aprove/Decline PullRequest (фактически мерж) в мастер, со стороны ИБ ставит бот
Если все хорошо автоматический Aprove на мерж в мастер, дальше разработчик мержит и новый релиз попадает в master
Если плохо по результатам сканирования, то режект/decline (заблокировать но не удалять) PR и уведомление секьюрити инженеров, где aprove будет решаться в частном порядке. Возможно договориться с командой, что уязвимость пофикситься через n дней и завезти задачу. Или AppSec возьмут эту уязвимость на триаж, чтобы оценить насколько страшный крит, и может пометить его false positive или скажут насколько можно ее отложить
Прошу прощения, может я отстал от мейнстримов.. Почему эта позиция называется "SecOps" ? Конечно роли от компании в компанию могут отличаться..
Имхо на мой взгляд, повышением безопасности в коде должны заниматься AppSec, интерпретировать/триажить результаты сканирований уязвимостей. Автоматизировать сканирования в cicd - DevSecOps. А ходить и агитировать в команды и говорить, как надо безопасно разрабатывать, проводить аудит того что у вас уже есть, как это соотносится с текущим законодательством и если что связать с юристами компании и сообщить им о рисках - должны SecBP.
Отдельный юнит в ИБ и отдельные роли под безопасность, позволяют стандартизировать подходы безопасности в разработке на все команды в компании, будет накладываться одна политика и одни процессы на всех, а не так что в разрозненных командах видят безопасность по-разному и по итогу у всех все свое.
Точно такой опыт общения и описанный процесс трудоустройства ) Ну и конечно зп в грандиозные 300k/месяц, насколько я понял в Озоне такой паек еще нужно заслужить, бедолаги у них в застенках, должны удвоить свои усилия налегания на весло ! Компания по официальным отчетам в минусе, вот так и пытаются сокращать и экономить на всем, в том числе и на IT блоке.
На схеме нарисовано, что идет "promote" тэга докер образа со stage енва в prod енв. В свою очередь кодовая база в stage ветке уже была просканирована статикой и без изменений попадает в master(prod) ветку. Как-будто результаты сканирования будут идентичными.
Да конечно, только AppSec имеет навыки интерпритировать результаты работы сканирования и выполнять триаж. Но ситуация такая, что сервисов настолько много, что делать триаж всего, будет неподъемной задачей. Поэтому принято, что: "все критикалы - зло", без оценки насколько эти уязвимости эксплуатируются, а если уже нет фикса уязвимости или разработчики не успевают пофиксить в срок, тогда уже начинается триаж таких уязвимостей.
Тут забыл уточнить, что нам важно чтобы в продакшене не было сервисов с образом, который старше 30/45 дней. Продакшен, потому что как правило только там сервисы транслируются из приватной сети наружу, поэтому остальные енвы не так критичны. Поэтому мы ищем докер образы сервисов, старше 30 дней с тэгом :"hash_commit"-master. Просто прокатить сборки до мастера, мы не можем, так как разработчики могут готовить новый релиз в продакшен и он может быть не готов, так что пересборка на их усмотрение.
В этом сценарии хотелось показать, что если по какому-то из критериев был не пройден SecurityGate, а значит не был поставлен автоматический approve на мерж PR, то приходит нотификация Security инженерам, которые смог ли бы ознакомиться/оценить и заблокировать/разрешить merge вручную
У нас очень много сервисов, их число уходит за несколько тысяч и сканировать их нон-стоп будет накладно. К тому же по каким критериям отправлять тот или иной сервис на дополнительный перескан, одни сервисы активно выкатываются и регулярно проходят security gate, другие могут месяцами не обновляться. Поэтому было решено, пару раз в неделю парсить наше локальное докер реджестри, где находим сервисы, билд которых старше 30 дней. И автоматически заводим Jira таски на пересборку (прохождение Security Gate) и перевыкатку сервиса. Таким образом, есть правило, при котором не должно быть сервисов, билд которых был старше 30 дней.
При таком подходе, источником истины становиться докер реджестри, поэтому там должен быть наведен порядок, чтобы четко понимать, какие репозитории мы сканируем, а какие игнорируем, потому что к примеру нам не нужно отправлять на перескан образы экспериментал/тест/песочница.
Как альтернативный вариант, можно внедрить stackrox. У него есть image scanner, который сканирует только те образы что находятся прямо сейчас в k8s кластерах, то есть источник истины смещается с докер реджестри в k8s кластера. И мы не зависим от порядка и чистоты в нашем докер реджестри. Так же у него есть admission controller, который умеет отслеживать, такие сценарии как: "30/45/90 дней докер образу" и даже их блокировать, чтобы не запускались в кластерах.
Возможно я не так понял мысль.. а никто не соединяет. У каждого свои задачи.
Есть отдел мониторинга, который следит за метриками доступности сервиса, доступности серверов и состоянием сети. Это эксплуатация и инфровая часть.
Есть SIEM, который уже собирает со всех серверов события/events: системные вызовы в ядро; audit/auth логи; сетевая активность; данные с сетевых устройств и т.д. А SOC уже в свою очередь "мониторинг" подозрительной активности. Он должен понимать выше перечисленные потоки данных, которые собрал SIEM, чтобы создавать "рулы", нарушения которых детектировали бы подозрительную активность и создавали инцидент. Это уже ИБ, и их метрики не волнует доступность сервиса/сервера, главное чтобы не был задетектирован какой-либо секьюрити инцидент
Понятно, что часть наших рисков митигирует WAF поверх всего, но как показывает практика не все компании считают нужным его настраивать. Да оно и понятно, из местных решений, не так уж и много выбора и они недешевые. А те же CloudFlare или Imperva не подходят, как минимум потому что IP пулы могут быть в бане "сами знаете кого" и часть местных пользователей на которых ориентирован сервис, просто на просто не смогут его переодически получать, что ухудшит опыт и т.д.
Из известных случаев этой весной: - местный хостинг ломанули через вывешенный не обновленный gitlab наружу - еще одна местная компания, пострадала от nginx-nightmare
Никто не говорит, что критиклы в сервисах это максимальный риск и тем самым набивает себе цену )) Есть ряд других вещей, я бы даже сказал база, которые по-моему мнению более важны, та же сетевая сегментация и организация сетевого периметра.
Но этот риск от уязвимых сервисов на продакшене есть и насколько он велик зависит от ряда некоторых факторов: - насколько прибыльный у вас бизнес (чем больше, тем лакомее добыча) - используете ли вы WAF (если self-hosted решение, чтобы оно актуализировало CVE базы) - насколько много у вас сервисов (чем больше, тем больше площадь поражения и сложнее за всеми следить. Вот тут Security Gate и должен спасти) - насколько оперативно пересобираются и перераскатываются ваши сервисы, если в нем нашлись уязвимости
Я тогда миддлом был и уже имел больше 300k в месяц.
А как оказалось, 300k это у них сениорский паек был, который чтобы получить надо быть гуру и как принято в таком бигтехе, делать в одиночку космолет раз в несколько месяцев.
По итогам собеседования мне конечно же не смогли предложить такое.
Хотя с таким процессом трудоустройства, должны предлагать выше рынка, сколько кандидатов отсекается только на этом этапе
Благодарю за разъяснение SecOps в названии !
Если отдельная команда под всю компанию, то супер !
PR в master могут создавать все
Но Aprove/Decline PullRequest (фактически мерж) в мастер, со стороны ИБ ставит бот
Если все хорошо автоматический Aprove на мерж в мастер, дальше разработчик мержит и новый релиз попадает в master
Если плохо по результатам сканирования, то режект/decline (заблокировать но не удалять) PR и уведомление секьюрити инженеров, где aprove будет решаться в частном порядке. Возможно договориться с командой, что уязвимость пофикситься через n дней и завезти задачу. Или AppSec возьмут эту уязвимость на триаж, чтобы оценить насколько страшный крит, и может пометить его false positive или скажут насколько можно ее отложить
Прошу прощения, может я отстал от мейнстримов..
Почему эта позиция называется "SecOps" ? Конечно роли от компании в компанию могут отличаться..
Имхо на мой взгляд, повышением безопасности в коде должны заниматься AppSec, интерпретировать/триажить результаты сканирований уязвимостей.
Автоматизировать сканирования в cicd - DevSecOps.
А ходить и агитировать в команды и говорить, как надо безопасно разрабатывать, проводить аудит того что у вас уже есть, как это соотносится с текущим законодательством и если что связать с юристами компании и сообщить им о рисках - должны SecBP.
Отдельный юнит в ИБ и отдельные роли под безопасность, позволяют стандартизировать подходы безопасности в разработке на все команды в компании, будет накладываться одна политика и одни процессы на всех, а не так что в разрозненных командах видят безопасность по-разному и по итогу у всех все свое.
Точно такой опыт общения и описанный процесс трудоустройства )
Ну и конечно зп в грандиозные 300k/месяц, насколько я понял в Озоне такой паек еще нужно заслужить, бедолаги у них в застенках, должны удвоить свои усилия налегания на весло !
Компания по официальным отчетам в минусе, вот так и пытаются сокращать и экономить на всем, в том числе и на IT блоке.
На схеме нарисовано, что идет "promote" тэга докер образа со stage енва в prod енв.
В свою очередь кодовая база в stage ветке уже была просканирована статикой и без изменений попадает в master(prod) ветку.
Как-будто результаты сканирования будут идентичными.
Да конечно, только AppSec имеет навыки интерпритировать результаты работы сканирования и выполнять триаж.
Но ситуация такая, что сервисов настолько много, что делать триаж всего, будет неподъемной задачей.
Поэтому принято, что: "все критикалы - зло", без оценки насколько эти уязвимости эксплуатируются, а если уже нет фикса уязвимости или разработчики не успевают пофиксить в срок, тогда уже начинается триаж таких уязвимостей.
Тут забыл уточнить, что нам важно чтобы в продакшене не было сервисов с образом, который старше 30/45 дней.
Продакшен, потому что как правило только там сервисы транслируются из приватной сети наружу, поэтому остальные енвы не так критичны.
Поэтому мы ищем докер образы сервисов, старше 30 дней с тэгом :"hash_commit"-master.
Просто прокатить сборки до мастера, мы не можем, так как разработчики могут готовить новый релиз в продакшен и он может быть не готов, так что пересборка на их усмотрение.
Прошу прощения, что пропал.. уезжал в отпуск и делал детоксикацию )
В ранбуке StackStorm "pr_approve", зашит API вызов допустим в bitbucket
curl -X POST-H "Authorization: Bearer $OAUTH_TOKEN"
https://api.bitbucket.org/2.0/repositories/myteam/myrepo/pullrequests/42/approveВ этом сценарии хотелось показать, что если по какому-то из критериев был не пройден SecurityGate, а значит не был поставлен автоматический approve на мерж PR, то приходит нотификация Security инженерам, которые смог ли бы ознакомиться/оценить и заблокировать/разрешить merge вручную
У нас очень много сервисов, их число уходит за несколько тысяч и сканировать их нон-стоп будет накладно. К тому же по каким критериям отправлять тот или иной сервис на дополнительный перескан, одни сервисы активно выкатываются и регулярно проходят security gate, другие могут месяцами не обновляться.
Поэтому было решено, пару раз в неделю парсить наше локальное докер реджестри, где находим сервисы, билд которых старше 30 дней. И автоматически заводим Jira таски на пересборку (прохождение Security Gate) и перевыкатку сервиса. Таким образом, есть правило, при котором не должно быть сервисов, билд которых был старше 30 дней.
При таком подходе, источником истины становиться докер реджестри, поэтому там должен быть наведен порядок, чтобы четко понимать, какие репозитории мы сканируем, а какие игнорируем, потому что к примеру нам не нужно отправлять на перескан образы экспериментал/тест/песочница.
Как альтернативный вариант, можно внедрить stackrox. У него есть image scanner, который сканирует только те образы что находятся прямо сейчас в k8s кластерах, то есть источник истины смещается с докер реджестри в k8s кластера. И мы не зависим от порядка и чистоты в нашем докер реджестри. Так же у него есть admission controller, который умеет отслеживать, такие сценарии как: "30/45/90 дней докер образу" и даже их блокировать, чтобы не запускались в кластерах.
Возможно я не так понял мысль.. а никто не соединяет. У каждого свои задачи.
Есть отдел мониторинга, который следит за метриками доступности сервиса, доступности серверов и состоянием сети. Это эксплуатация и инфровая часть.
Есть SIEM, который уже собирает со всех серверов события/events: системные вызовы в ядро; audit/auth логи; сетевая активность; данные с сетевых устройств и т.д.
А SOC уже в свою очередь "мониторинг" подозрительной активности.
Он должен понимать выше перечисленные потоки данных, которые собрал SIEM, чтобы создавать "рулы", нарушения которых детектировали бы подозрительную активность и создавали инцидент. Это уже ИБ, и их метрики не волнует доступность сервиса/сервера, главное чтобы не был задетектирован какой-либо секьюрити инцидент
Ну мы не стали дожидаться и ловить на живца )
Понятно, что часть наших рисков митигирует WAF поверх всего, но как показывает практика не все компании считают нужным его настраивать.
Да оно и понятно, из местных решений, не так уж и много выбора и они недешевые.
А те же CloudFlare или Imperva не подходят, как минимум потому что IP пулы могут быть в бане "сами знаете кого" и часть местных пользователей на которых ориентирован сервис, просто на просто не смогут его переодически получать, что ухудшит опыт и т.д.
Из известных случаев этой весной:
- местный хостинг ломанули через вывешенный не обновленный gitlab наружу
- еще одна местная компания, пострадала от nginx-nightmare
Никто не говорит, что критиклы в сервисах это максимальный риск и тем самым набивает себе цену )) Есть ряд других вещей, я бы даже сказал база, которые по-моему мнению более важны, та же сетевая сегментация и организация сетевого периметра.
Но этот риск от уязвимых сервисов на продакшене есть и насколько он велик зависит от ряда некоторых факторов:
- насколько прибыльный у вас бизнес (чем больше, тем лакомее добыча)
- используете ли вы WAF (если self-hosted решение, чтобы оно актуализировало CVE базы)
- насколько много у вас сервисов (чем больше, тем больше площадь поражения и сложнее за всеми следить. Вот тут Security Gate и должен спасти)
- насколько оперативно пересобираются и перераскатываются ваши сервисы, если в нем нашлись уязвимости