Makrushin
Reposted from:
South HUB
19.04.202512:37
Вашей компании нужен герой — и он уже среди ваших разработчиков!
(#соавтор South HUB, Денис Макрушин.)
Если кто-то до сих пор слышит и соглашается с тезисом «безопасность замедляет разработку и душит инновации», то он плохо осознает с какой скоростью двигается прогресс. Раньше управленец C-level в технологической компании мог надеяться, что его бизнес или продукт не будут интересны кибер-преступникам, и они обойдут его стороной. Теперь же, когда злодеи повсеместно используют автоматизацию и регулярно мониторят возможности запрыгнуть в инфраструктуру компании любого масштаба — нельзя надеяться на «да кому я нужен».
Атаки, утечки и различные кибер-инциденты реально тормозят развитие. Иногда останавливают его полностью. Потому что когда «зашифрован прод», а данные клиентов текут в паблик — это не про развитие. А еще, оказывается, что недостаточно завернуть в свой пайплайн все необходимые security-инструменты. Недостаточно даже их правильно настроить и получать только важные результаты их работы.
Как обычно, секретный соус кибербезопасной компании — в ее людях и культуре. Уязвимость всегда проще и дешевле исправлять, когда она обнаружена в IDE разработчика, а не в проде у клиента. Практики и инструменты ИБ нужно двигать «влево» — ближе к началу жизненного цикла системы. Ближе к тому этапу, на которых рождается идея, гипотеза, бизнес-план, дизайн системы. А для этого, нужно понимать “кибербез” на уровне культуры топ-менеджмента и разработки.
В индустрии есть такое термин: Security-чемпион. Это не всегда выделенная роль. Это может быть сотрудник, который прокачивает себя в вопросах ИБ и приземляет экспертизу в своих повседневных задачах. Например, разработчик или тим лид, который понимает риски некачественного кода. CTO, который не ждет, когда появится CISO и принесет контроли в SDLC. CEO и CPO, которые знают, для чего проводить дополнительные security design review.
Чтобы запустить чемпионскую программу в своих командах разработки, нужно предварительно ответить на ключевые вопросы вопроса:
1. Как я создам внутреннюю мотивацию? Что будет драйвить разработчика развиваться в направлении безопасной разработки?
2. Какой ресурс я выделю для реализации программы? Смогу ли обеспечить реальное влияние security-чемпионов на SDLC-процессы?
3. Как буду постоянно развивать и поддерживать сообщество security-чемпионов?
И как только появятся конкретные ответы на эти вопросы, можно будет приступать к тактике. Кстати, отправной точкой для запуска программы может стать вот этот плейбук, подготовленный моим товарищем и поддержанный сообществом OWASP.
Культивируете ли чемпионов в своих командах?
(#соавтор South HUB, Денис Макрушин.)
Если кто-то до сих пор слышит и соглашается с тезисом «безопасность замедляет разработку и душит инновации», то он плохо осознает с какой скоростью двигается прогресс. Раньше управленец C-level в технологической компании мог надеяться, что его бизнес или продукт не будут интересны кибер-преступникам, и они обойдут его стороной. Теперь же, когда злодеи повсеместно используют автоматизацию и регулярно мониторят возможности запрыгнуть в инфраструктуру компании любого масштаба — нельзя надеяться на «да кому я нужен».
Атаки, утечки и различные кибер-инциденты реально тормозят развитие. Иногда останавливают его полностью. Потому что когда «зашифрован прод», а данные клиентов текут в паблик — это не про развитие. А еще, оказывается, что недостаточно завернуть в свой пайплайн все необходимые security-инструменты. Недостаточно даже их правильно настроить и получать только важные результаты их работы.
Как обычно, секретный соус кибербезопасной компании — в ее людях и культуре. Уязвимость всегда проще и дешевле исправлять, когда она обнаружена в IDE разработчика, а не в проде у клиента. Практики и инструменты ИБ нужно двигать «влево» — ближе к началу жизненного цикла системы. Ближе к тому этапу, на которых рождается идея, гипотеза, бизнес-план, дизайн системы. А для этого, нужно понимать “кибербез” на уровне культуры топ-менеджмента и разработки.
В индустрии есть такое термин: Security-чемпион. Это не всегда выделенная роль. Это может быть сотрудник, который прокачивает себя в вопросах ИБ и приземляет экспертизу в своих повседневных задачах. Например, разработчик или тим лид, который понимает риски некачественного кода. CTO, который не ждет, когда появится CISO и принесет контроли в SDLC. CEO и CPO, которые знают, для чего проводить дополнительные security design review.
Чтобы запустить чемпионскую программу в своих командах разработки, нужно предварительно ответить на ключевые вопросы вопроса:
1. Как я создам внутреннюю мотивацию? Что будет драйвить разработчика развиваться в направлении безопасной разработки?
2. Какой ресурс я выделю для реализации программы? Смогу ли обеспечить реальное влияние security-чемпионов на SDLC-процессы?
3. Как буду постоянно развивать и поддерживать сообщество security-чемпионов?
И как только появятся конкретные ответы на эти вопросы, можно будет приступать к тактике. Кстати, отправной точкой для запуска программы может стать вот этот плейбук, подготовленный моим товарищем и поддержанный сообществом OWASP.
Культивируете ли чемпионов в своих командах?
19.03.202508:13
«Спасаем разработчика» на Кавказе
Мы уже рассказывали про атаки на разработчика и изучали уязвимости платформ разработки. Теперь исследуем методы и инструменты защиты конвейера и придумываем автоматизации, которые можно отдать AI-AppSec-инженеру (это тот, который не просит еду, только GPU-ресурсы).
И повод тоже есть: на Кавказе как раз на мероприятии «Код ИБ» собираются директора ИБ, которые смогут приземлить эти идеи в своем бизнесе.
Мы уже рассказывали про атаки на разработчика и изучали уязвимости платформ разработки. Теперь исследуем методы и инструменты защиты конвейера и придумываем автоматизации, которые можно отдать AI-AppSec-инженеру (это тот, который не просит еду, только GPU-ресурсы).
И повод тоже есть: на Кавказе как раз на мероприятии «Код ИБ» собираются директора ИБ, которые смогут приземлить эти идеи в своем бизнесе.
01.04.202508:11
Правила для выявления атак небезопасной распаковки архивов
Мы изучали уязвимость Zip Slip в Golang, когда атакующий может загрузить специально сформированный архив и выйти за пределы каталога, в который производится распаковка.
Проект Unsafe Unpacking Research собирает сценарии небезопасной распаковки в разных языках программирования и предлагает соответствующие semgrep-правила для их выявления в коде. Возможно, с помощью этих правил, AppSec-инженер, который уже устал находить в своих рабочих проектах тривиальные уязвимости, сможет разбавить рутину трудовых будней своих разработчиков. 👾
Мы изучали уязвимость Zip Slip в Golang, когда атакующий может загрузить специально сформированный архив и выйти за пределы каталога, в который производится распаковка.
Проект Unsafe Unpacking Research собирает сценарии небезопасной распаковки в разных языках программирования и предлагает соответствующие semgrep-правила для их выявления в коде. Возможно, с помощью этих правил, AppSec-инженер, который уже устал находить в своих рабочих проектах тривиальные уязвимости, сможет разбавить рутину трудовых будней своих разработчиков. 👾
30.03.202508:11
Провинциальный OSINT: определяем место
Обычный пользователь видит просто фото. А что на нем видит OSINT-исследователь?
Фотка сделана на крыше здания, которое расположено где-то на окраине крупного города. Задача: определить страну.
⭐️Задача со звездочкой: определить город.
Обычный пользователь видит просто фото. А что на нем видит OSINT-исследователь?
Фотка сделана на крыше здания, которое расположено где-то на окраине крупного города. Задача: определить страну.
⭐️Задача со звездочкой: определить город.
20.03.202508:11
Безопасная разработка и какие вызовы несет AI
Дубай. Вечер. Глеб рассказывает кому-то из участников CTO Day, почему он не расстается со своей кепкой, на козырьке которой написано . Можно догадаться, что это намек на фронтендерский бэкграунд Глеба, который уже давно с позиции технического директора смотрит на разработку, катит фичи в продукты, и рассказывает о нюансах управления R&D в своем подскасте.
И вот, спустя год, в гостях у Уставшего техдира мы говорим про безопасность в разработке, про роль AI в этом процессе, чтобы потом поделиться этим мыслями со всеми, кто неравнодушен к созданию продуктов, кибербезопасности и теме ИИ.
⭐ Выпуск доступен на YouTube,ВК,Rutube,Spotify,Apple Podcast,Яндекс.Музыка.
Дубай. Вечер. Глеб рассказывает кому-то из участников CTO Day, почему он не расстается со своей кепкой, на козырьке которой написано . Можно догадаться, что это намек на фронтендерский бэкграунд Глеба, который уже давно с позиции технического директора смотрит на разработку, катит фичи в продукты, и рассказывает о нюансах управления R&D в своем подскасте.
И вот, спустя год, в гостях у Уставшего техдира мы говорим про безопасность в разработке, про роль AI в этом процессе, чтобы потом поделиться этим мыслями со всеми, кто неравнодушен к созданию продуктов, кибербезопасности и теме ИИ.
⭐ Выпуск доступен на YouTube,ВК,Rutube,Spotify,Apple Podcast,Яндекс.Музыка.
Shown 1 - 6 of 6
Log in to unlock more functionality.