Как раскрасить граф активности любому пользователю GitHub
Любой пользователь GitHub может нарисовать себе «граффити» на своем графе активности. А еще он может сделать это на графе другого пользователя. Для этого должны быть выполнены три условия:
1. Пользователь, чей граф будет раскрашен, должен открыть issue или сделать push кода в репозиторий, в который у другого пользователя (назовем его «редиска») также есть возможность сделать push или принять pull request.
2. Этот репозиторий не должен быть форком.
3. Редиска должен знать email, который пользователь использовал при регистрации.
Эта уязвимость возникает из-за некорректной проверки email, который указан в git-коммите, и email пользователя. Если два email совпадают, то GitHub отображает коммит на графике активности.
Эту проблему уже используют не только редиски, но и исследователи, которые рисуют граффити в аккаунтах злодеев.
Любой пользователь GitHub может нарисовать себе «граффити» на своем графе активности. А еще он может сделать это на графе другого пользователя. Для этого должны быть выполнены три условия:
1. Пользователь, чей граф будет раскрашен, должен открыть issue или сделать push кода в репозиторий, в который у другого пользователя (назовем его «редиска») также есть возможность сделать push или принять pull request.
2. Этот репозиторий не должен быть форком.
3. Редиска должен знать email, который пользователь использовал при регистрации.
Эта уязвимость возникает из-за некорректной проверки email, который указан в git-коммите, и email пользователя. Если два email совпадают, то GitHub отображает коммит на графике активности.
Эту проблему уже используют не только редиски, но и исследователи, которые рисуют граффити в аккаунтах злодеев.
🔥7👍2😁2🤔2🙏1
Обзор перспективных исследований 2024 года
Результаты и идеи, полученные из чужого исследовательского опыта — незаменимый инструмент в арсенале security-инженера. Понимать новые поверхности атак, способы повышения наблюдаемости событий, внедрять инновационные инструменты — всё это супер-сила исследователя и ключевые элементы для построения эффективной стратегии защиты.
Давай разберем отчеты, чтобы понять, что можно применить прямо сейчас, а что требует дальнейшего изучения.
Результаты и идеи, полученные из чужого исследовательского опыта — незаменимый инструмент в арсенале security-инженера. Понимать новые поверхности атак, способы повышения наблюдаемости событий, внедрять инновационные инструменты — всё это супер-сила исследователя и ключевые элементы для построения эффективной стратегии защиты.
Давай разберем отчеты, чтобы понять, что можно применить прямо сейчас, а что требует дальнейшего изучения.
Denis Makrushin
Advanced Research Review 2024 · Denis Makrushin
Let’s talk about last year’s perspective research. Researchers have gathered a wealth of interesting material. Let’s go through the reports to see what can be applied in practice and what…
👍4🔥2
Adversary-in-the-Middle: эволюция фишинга
В новом материале для авторской колонки рассказал про актуальные инструменты проведения фишинга, в эпоху средств мультифакторной аутентификации. О том, как технологии AitM (Adversary-in-the-Middle) меняют процессы социотехнического тестирования, и почему кража пароля - больше не основная задача атакующего.
В новом материале для авторской колонки рассказал про актуальные инструменты проведения фишинга, в эпоху средств мультифакторной аутентификации. О том, как технологии AitM (Adversary-in-the-Middle) меняют процессы социотехнического тестирования, и почему кража пароля - больше не основная задача атакующего.
xakep.ru
Adversary-in-the-Middle: эволюция фишинга. Колонка Дениса Макрушина
Типичный сценарий социотехнического пентеста: собрал список корпоративных email-адресов, настроил инструмент для проведения фишинговых рассылок, провел рассылку, получил учетные данные сотрудников для доступа в корпоративную инфраструктуру.
👍2
Иногда нам надо снова вспоминать, что мы тут делаем и знакомиться друг с другом. Особенно с теми, кто недавно к нам присоединился. Меня зовут Денис Макрушин, и здесь я рассказываю про кибербезопасность, технологии и людей.
Если ты читаешь это сообщение, то знаешь, что информационная безопасность сегодня — критический навык для каждого профессионала в IT. Независимо от текущей позиции, постоянное совершенствование компетенций в области кибербезопасности становится не просто преимуществом, а профессиональной необходимостью. Гигиеническим навыком.
Вместе с командой мы собрали три ценных материала, которые помогут:
Вот, чем мы делимся:
Чтобы забрать материалы — не забудь подписаться на канал, и нажимай кнопку для получения контента
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥5⚡2😁2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
APPSEC-01
Сегодня первый поток курса Безопасность Приложений начинает свое обучение.
Первое занятие начинаем с целеполагания. Каждый отвечает себе на вопросы: “зачем я собираюсь инвестировать свой ресурс в обучение и как представляю образ результата?”.
Затем, после знакомства с процессом обучения, знакомимся друг с другом и разворачиваем тестовый стенд для анализа защищенности, чтобы освоить инструменты. Для тех, кто хочет повторить упражнение, набор стандартный:
1. Kali Linux с утилитами для анализа поверхности атаки
2. OWASP Juice Shop для знакомства с наиболее распространенными уязвимостями (OWASP Top 10)
3. OWASP Zap или Burp Suite в качестве прокси.
Кстати, в блогах исследователей все чаще встречаю скриншоты интерфейса caido, который пытается подвинуть Burp на рынке. Если кто-то уже использует его для своих задач - поделитесь опытом.
Для тех, кто откладывал решение о начале обучения на последний момент, мы продлили возможность записаться в первый поток до 15 февраля.
Сегодня первый поток курса Безопасность Приложений начинает свое обучение.
Первое занятие начинаем с целеполагания. Каждый отвечает себе на вопросы: “зачем я собираюсь инвестировать свой ресурс в обучение и как представляю образ результата?”.
Затем, после знакомства с процессом обучения, знакомимся друг с другом и разворачиваем тестовый стенд для анализа защищенности, чтобы освоить инструменты. Для тех, кто хочет повторить упражнение, набор стандартный:
1. Kali Linux с утилитами для анализа поверхности атаки
2. OWASP Juice Shop для знакомства с наиболее распространенными уязвимостями (OWASP Top 10)
3. OWASP Zap или Burp Suite в качестве прокси.
Кстати, в блогах исследователей все чаще встречаю скриншоты интерфейса caido, который пытается подвинуть Burp на рынке. Если кто-то уже использует его для своих задач - поделитесь опытом.
Для тех, кто откладывал решение о начале обучения на последний момент, мы продлили возможность записаться в первый поток до 15 февраля.
🔥7👍6❤1✍1🤔1🥱1💯1🤣1
Один год вместе с LLM в кибербезопасности: как ИИ менял индустрию
В 2024 году большие языковые модели (LLM) кардинально изменили многие сферы, включая кибербезопасность. LLM научились не только помогать в поиске уязвимостей, но и предлагать их исправления. От симуляции атак и анализа уязвимостей до создания правил детектирования — LLM постепенно становятся незаменимым инструментом для разработчиков и специалистов по безопасной разработке.
В этой статье разберём, какие инновации принесли LLM в кибербезопасность, выделим инсайты и ключевые технологические ограничения, с которыми будем разбираться в 2025 году.
В 2024 году большие языковые модели (LLM) кардинально изменили многие сферы, включая кибербезопасность. LLM научились не только помогать в поиске уязвимостей, но и предлагать их исправления. От симуляции атак и анализа уязвимостей до создания правил детектирования — LLM постепенно становятся незаменимым инструментом для разработчиков и специалистов по безопасной разработке.
В этой статье разберём, какие инновации принесли LLM в кибербезопасность, выделим инсайты и ключевые технологические ограничения, с которыми будем разбираться в 2025 году.
Denis Makrushin
Один год вместе с LLM в кибербезопасности: как ИИ менял индустрию · Denis Makrushin
В 2024 году большие языковые модели (LLM) кардинально изменили многие сферы, включая кибербезопасность. LLM научились не только помогать в поиске уязвимостей, но и предлагать их исправления. От симуляции атак и анализа уязвимостей до создания правил детектирования —…
👍5❤2🔥2👏1
Дневник DevSec: спасти разработчика
Представим: у нас стоит задача придумать продукт, который должен спасти разработчика, и при этом он должен не мешать ему создавать. “Не мешать” - это одно из ключевых требований к ИБ-решениям. Заменим это требование: “он должен ускорять процесс разработки”.
Мы изучили атаки и убедились, что проблемы могут прилететь из разных мест в конвейере: начиная от атак на сам пайплайн и заканчивая конкретными библиотеками, которые используются в кодовой базе.
На рынке Application Security существует достаточное количество продуктовых категорий, которые решают одну и ту же задачу, но с разных сторон. Создавать еще одно решение - риск потратить ресурс. Только если результат не будет кардинально менять расстановку сил на поле “attack-defense”. Поэтому уточним задачу: разработать продукт, который спасет разработчика, и который будет эффективно использовать уже имеющуюся технологическую базу.
Эффективно - это значит, мы не будем собирать новые велосипеды, если старые еще работают. Мы будем добавлять инкрементальные изменения в существующие знания и подходы. Как минимум, нам предстоит разобраться во всех этих велосипедах.
Платформы вроде ASPM решают задачу эффективности, собирая под капотом актуальные appsec-технологии и добавляя инкремент: снижают шум от всех этих продуктов. И все же это не решает основную задачу: не тратить внимание разработчика на исправление security-проблем.
Мир движется к автономным и самовосстанавливающимся системам. Autonomous и self-healing в задачах кибербезопасности идут рука об руку. Например, недавно DARPA (то самое агентство, которое создало ARPANET) объявило грант на разработку self-healing системы для защиты прошивок. То есть DARPA предложила пересмотреть фундаментальные принципы защиты на уровне компьютерной шины.
Аналогичным образом для решения нашей задачи потребуется еще раз посмотреть на фундаментальные принципы безопасности в разработке приложений.
Представим: у нас стоит задача придумать продукт, который должен спасти разработчика, и при этом он должен не мешать ему создавать. “Не мешать” - это одно из ключевых требований к ИБ-решениям. Заменим это требование: “он должен ускорять процесс разработки”.
Мы изучили атаки и убедились, что проблемы могут прилететь из разных мест в конвейере: начиная от атак на сам пайплайн и заканчивая конкретными библиотеками, которые используются в кодовой базе.
На рынке Application Security существует достаточное количество продуктовых категорий, которые решают одну и ту же задачу, но с разных сторон. Создавать еще одно решение - риск потратить ресурс. Только если результат не будет кардинально менять расстановку сил на поле “attack-defense”. Поэтому уточним задачу: разработать продукт, который спасет разработчика, и который будет эффективно использовать уже имеющуюся технологическую базу.
Эффективно - это значит, мы не будем собирать новые велосипеды, если старые еще работают. Мы будем добавлять инкрементальные изменения в существующие знания и подходы. Как минимум, нам предстоит разобраться во всех этих велосипедах.
Платформы вроде ASPM решают задачу эффективности, собирая под капотом актуальные appsec-технологии и добавляя инкремент: снижают шум от всех этих продуктов. И все же это не решает основную задачу: не тратить внимание разработчика на исправление security-проблем.
Мир движется к автономным и самовосстанавливающимся системам. Autonomous и self-healing в задачах кибербезопасности идут рука об руку. Например, недавно DARPA (то самое агентство, которое создало ARPANET) объявило грант на разработку self-healing системы для защиты прошивок. То есть DARPA предложила пересмотреть фундаментальные принципы защиты на уровне компьютерной шины.
Аналогичным образом для решения нашей задачи потребуется еще раз посмотреть на фундаментальные принципы безопасности в разработке приложений.
👍10❤3👏2💯2
Инструмент для поиска проблем в GitHub Actions CI/CD
Изучили сценарии атак, в которых можно закрепиться в GitHub Actions, выполнить произвольный код и извлечь секреты. Ознакомились с рекомендациями от OWASP по защите процессов CI/CD. Поняли, что значительная часть этих рекомендаций отдается на откуп разработчику. Но все же нашли инструмент, который поможет ему выявить значительную часть уязвимостей.
В правилах для выявления есть сигнатуры для основных проблем:
* внедрение шаблонов для выполнения произвольного кода в процессе CI/CD;
* утечка секретов;
* избыточные права для GitHub Runners;
* Actions с существующими известными уязвимостями.
Еще один статический анализатор в нашем пайплайне. Кстати, сигнатуры можно адаптировать к другим платформам разработки.
Изучили сценарии атак, в которых можно закрепиться в GitHub Actions, выполнить произвольный код и извлечь секреты. Ознакомились с рекомендациями от OWASP по защите процессов CI/CD. Поняли, что значительная часть этих рекомендаций отдается на откуп разработчику. Но все же нашли инструмент, который поможет ему выявить значительную часть уязвимостей.
В правилах для выявления есть сигнатуры для основных проблем:
* внедрение шаблонов для выполнения произвольного кода в процессе CI/CD;
* утечка секретов;
* избыточные права для GitHub Runners;
* Actions с существующими известными уязвимостями.
Еще один статический анализатор в нашем пайплайне. Кстати, сигнатуры можно адаптировать к другим платформам разработки.
👍5🔥3👏2💯1
Ежегодные антифишинг-тренинги неэффективны
А еще:
* не выявлено существенной связи между недавним прохождением обучения и вероятностью успеха фишинга;
* существующие программы повышения осведомленности имеют низкую практическую ценность для снижения риска фишинг-атак (риск снижается всего на 1.7%);
* значительная часть пользователей (56%), которые прошли обучение, кликнули на фишинговую ссылку. Ну бывает, сначала прокликаешь слайды в тренинге, а затем прокликаешь все фишинговые ссылки🙃
Такие выводы можно сделать после изучения результатов исследования, в котором 19500 сотрудников в течение 8 месяцев получали фишинговые письма. Можно с этим не согласиться, но точно следует обратить внимание на то, как авторы предлагают повысить эффективность тренингов:
⭐️ повышать интерактивность тренингов и увеличивать степень вовлеченности пользователей;
⭐️ разрабатывать персонализированные сценарии, которые учитывают контекст пользователя;
⭐️ вместо формального «механического» прохождения тренинга, развивать «культуру безопасности», в которой пользователь осознанно оценивает риски.
А еще:
* не выявлено существенной связи между недавним прохождением обучения и вероятностью успеха фишинга;
* существующие программы повышения осведомленности имеют низкую практическую ценность для снижения риска фишинг-атак (риск снижается всего на 1.7%);
* значительная часть пользователей (56%), которые прошли обучение, кликнули на фишинговую ссылку. Ну бывает, сначала прокликаешь слайды в тренинге, а затем прокликаешь все фишинговые ссылки
Такие выводы можно сделать после изучения результатов исследования, в котором 19500 сотрудников в течение 8 месяцев получали фишинговые письма. Можно с этим не согласиться, но точно следует обратить внимание на то, как авторы предлагают повысить эффективность тренингов:
Please open Telegram to view this post
VIEW IN TELEGRAM
👻6😁4✍2👏2👍1🤔1😱1💯1
Алгоритмы автономного поиска уязвимостей
Пока готовился к заключительному модулю, в котором разбираем сценарии использования LLM в appsec-задачах, встретил еще одно успешное внедрение ИИ для поиска уязвимостей.
В прошлом году мы изучили результаты работ, в которых система смогла самостоятельно определить категорию уязвимости и даже пробовала их эксплуатировать. В этот раз исследователи интегрировали анализ исполнения программы с агентами, которые подключаются на каждом отдельном этапе атаки:
1. Сбор контекста о приложении.
2. Генерация промежуточного представления в виде AST, чтобы лучше оценивать контекст и повысить точность анализа. Из AST можно получить граф вызовов, который упрощает навигацию по коду приложения.
3. Обогащение графа дополнительным контекстом, например, HTTP-методами и состоянием механизмов аутентификации и авторизации.
4. Поиск уязвимостей и их валидация. Вот тут самое интересное: авторы применяют свой фреймворк Tree of Thoughts (ToT), который основан на “цепочке мыслей” (Chain of Thoughts, CoT). То есть шаг за шагом модель рассуждает об уязвимости, разбивая сложную задачу на последовательность более простых логических шагов.
Фреймворк ToT дает цепочку решений, и уже эта цепочка передается в алгоритм самоулучшения дерева Монте-Карло. Основа успеха в применении этого алгоритма - четко определенная и описанная “функция победы”. Функция определяет, является ли текущее состояние в дереве поиска выигрышным, проигрышным или нейтральным. И эта функция становится еще одним объектом рассуждения для LLM.
LLM рассуждает о функции победы 👉 LLM рассуждает о способах достижения этой победы 👉 LLM собирает контекст исполнения для этих способов 👉 Исследователь собирает деньги на покупку видеокарт😎
Пока готовился к заключительному модулю, в котором разбираем сценарии использования LLM в appsec-задачах, встретил еще одно успешное внедрение ИИ для поиска уязвимостей.
В прошлом году мы изучили результаты работ, в которых система смогла самостоятельно определить категорию уязвимости и даже пробовала их эксплуатировать. В этот раз исследователи интегрировали анализ исполнения программы с агентами, которые подключаются на каждом отдельном этапе атаки:
1. Сбор контекста о приложении.
2. Генерация промежуточного представления в виде AST, чтобы лучше оценивать контекст и повысить точность анализа. Из AST можно получить граф вызовов, который упрощает навигацию по коду приложения.
3. Обогащение графа дополнительным контекстом, например, HTTP-методами и состоянием механизмов аутентификации и авторизации.
4. Поиск уязвимостей и их валидация. Вот тут самое интересное: авторы применяют свой фреймворк Tree of Thoughts (ToT), который основан на “цепочке мыслей” (Chain of Thoughts, CoT). То есть шаг за шагом модель рассуждает об уязвимости, разбивая сложную задачу на последовательность более простых логических шагов.
Фреймворк ToT дает цепочку решений, и уже эта цепочка передается в алгоритм самоулучшения дерева Монте-Карло. Основа успеха в применении этого алгоритма - четко определенная и описанная “функция победы”. Функция определяет, является ли текущее состояние в дереве поиска выигрышным, проигрышным или нейтральным. И эта функция становится еще одним объектом рассуждения для LLM.
LLM рассуждает о функции победы 👉 LLM рассуждает о способах достижения этой победы 👉 LLM собирает контекст исполнения для этих способов 👉 Исследователь собирает деньги на покупку видеокарт
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9⚡4❤2🍌1
Дневник DevSec #2: когнитивное топливо
Оказывается, что продукт должен спасать разработчика не только от угроз, но и от других продуктов. Если спросить appsec-инженера, работающего в какой-нибудь BigTech-компании, сколько инструментов он использует в работе, то он перечислит десяток утилит. Коммерческих и опенсорс. Если быть точнее: 16 инструментов.
Представь, что твой рабочий день начинается с изучения дашборда, в котором накопились уязвимости. Тебе нужно убедиться, что эти уязвимости не дублируются, имеют правильный приоритет. Затем разобраться в причинах возникновения каждой приоритетной баги. Для этого, нужно пробежать марафон по нескольким разным инструментам с разным контекстом. После того, как этот этап завершен, нужно пробежать новый марафон по другим инструментам, чтобы уже исправить обнаруженные проблемы или передать их разработчику. Когнитивное изнасилование.
Когнитивная нагрузка - одна из ключевых, неочевидных метрик,которая меняется при добавлении нового инструмента в рабочий процесс. В некоторых исследованиях эта метрика описана как когнитивные затраты на принятие решений.
Представим, что у нас в рамках рабочего дня есть определенный запас когнитивного топлива - ресурса, который тратится на выполнение задачи, принятие каких-либо решений, переключение контекста между задачами, пролистывание ленты в соц сети. Когнитивное топливо безопасника уходит на анализ статистики, триажинг уязвимостей, их исправление, изучение вайтпейперов и TI-репортов. Ему не нужен еще один продукт с информативным интерфейсом и «без ложных срабатываний». Ему в принципе не нужен еще один источник срабатываний, когда есть 16 других.
AppSec-инженер хочет построить процесс, автоматизировать его и больше не тратить свое когнитивное топливо.
Оказывается, что продукт должен спасать разработчика не только от угроз, но и от других продуктов. Если спросить appsec-инженера, работающего в какой-нибудь BigTech-компании, сколько инструментов он использует в работе, то он перечислит десяток утилит. Коммерческих и опенсорс. Если быть точнее: 16 инструментов.
Представь, что твой рабочий день начинается с изучения дашборда, в котором накопились уязвимости. Тебе нужно убедиться, что эти уязвимости не дублируются, имеют правильный приоритет. Затем разобраться в причинах возникновения каждой приоритетной баги. Для этого, нужно пробежать марафон по нескольким разным инструментам с разным контекстом. После того, как этот этап завершен, нужно пробежать новый марафон по другим инструментам, чтобы уже исправить обнаруженные проблемы или передать их разработчику. Когнитивное изнасилование.
Когнитивная нагрузка - одна из ключевых, неочевидных метрик,которая меняется при добавлении нового инструмента в рабочий процесс. В некоторых исследованиях эта метрика описана как когнитивные затраты на принятие решений.
Представим, что у нас в рамках рабочего дня есть определенный запас когнитивного топлива - ресурса, который тратится на выполнение задачи, принятие каких-либо решений, переключение контекста между задачами, пролистывание ленты в соц сети. Когнитивное топливо безопасника уходит на анализ статистики, триажинг уязвимостей, их исправление, изучение вайтпейперов и TI-репортов. Ему не нужен еще один продукт с информативным интерфейсом и «без ложных срабатываний». Ему в принципе не нужен еще один источник срабатываний, когда есть 16 других.
AppSec-инженер хочет построить процесс, автоматизировать его и больше не тратить свое когнитивное топливо.
🤣6👍5🔥3💯2
На охоту за когнитивным топливом ❄️
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👏5🤨2😎1
Необычные домены ловят необычные DNS-запросы
Если зарегистрировать домен, который совпадает с названием AWS-инстанса, то можно поймать интересный трафик.
Люблю исследования, в которых автор поднимает ханипот, чтобы собрать в нем аномалии и изучить какие-то неочевидные сценарии атак. Например, можно зарегистировать домен us-east-1.com, который совпадает с названием инстанса AWS us-east-1 и поймать следующие DNS-запросы:
1. от внутренних систем облачного провайдера, которые из-за мисконфигураций обращаются к внешнему ресурсу вместо внутренней инфраструктуры AWS
2. от почтовых security-шлюзов, которые в ответе ожидают какие-либо данные, влияющие на их конфигурацию
3. от сервисов хранения данных, которым также возможно что-то ответить.
Можно поймать не только DNS-запросы, но и внутренние автоматические почтовые рассылки от других AWS-систем. Эти письма также могут раскрыть информацию о конфигурации инфры.
Если бы домен us-east-1.com контролировал злодей, то он мог бы собирать интересную информацию о внутренних ресурсах и использовать ее для рассылки фишинга, в котором подготовил бы ссылку на вредоносную копию AWS Console.
Архитектор безопасности, проверь, что твои внутренние ресурсы не ходят по сторонним доменам.
Если зарегистрировать домен, который совпадает с названием AWS-инстанса, то можно поймать интересный трафик.
Люблю исследования, в которых автор поднимает ханипот, чтобы собрать в нем аномалии и изучить какие-то неочевидные сценарии атак. Например, можно зарегистировать домен us-east-1.com, который совпадает с названием инстанса AWS us-east-1 и поймать следующие DNS-запросы:
1. от внутренних систем облачного провайдера, которые из-за мисконфигураций обращаются к внешнему ресурсу вместо внутренней инфраструктуры AWS
2. от почтовых security-шлюзов, которые в ответе ожидают какие-либо данные, влияющие на их конфигурацию
3. от сервисов хранения данных, которым также возможно что-то ответить.
Можно поймать не только DNS-запросы, но и внутренние автоматические почтовые рассылки от других AWS-систем. Эти письма также могут раскрыть информацию о конфигурации инфры.
Если бы домен us-east-1.com контролировал злодей, то он мог бы собирать интересную информацию о внутренних ресурсах и использовать ее для рассылки фишинга, в котором подготовил бы ссылку на вредоносную копию AWS Console.
Архитектор безопасности, проверь, что твои внутренние ресурсы не ходят по сторонним доменам.
🔥8👍6👻3👏1
«Спасаем разработчика» на Кавказе
Мы уже рассказывали про атаки на разработчика и изучали уязвимости платформ разработки. Теперь исследуем методы и инструменты защиты конвейера и придумываем автоматизации, которые можно отдать AI-AppSec-инженеру (это тот, который не просит еду, только GPU-ресурсы).
И повод тоже есть: на Кавказе как раз на мероприятии «Код ИБ» собираются директора ИБ, которые смогут приземлить эти идеи в своем бизнесе.
Мы уже рассказывали про атаки на разработчика и изучали уязвимости платформ разработки. Теперь исследуем методы и инструменты защиты конвейера и придумываем автоматизации, которые можно отдать AI-AppSec-инженеру (это тот, который не просит еду, только GPU-ресурсы).
И повод тоже есть: на Кавказе как раз на мероприятии «Код ИБ» собираются директора ИБ, которые смогут приземлить эти идеи в своем бизнесе.
❤🔥4👍3👏2
Безопасная разработка и какие вызовы несет AI
Дубай. Вечер. Глеб рассказывает кому-то из участников CTO Day, почему он не расстается со своей кепкой, на козырьке которой написано <head>. Можно догадаться, что это намек на фронтендерский бэкграунд Глеба, который уже давно с позиции технического директора смотрит на разработку, катит фичи в продукты, и рассказывает о нюансах управления R&D в своем подскасте.
И вот, спустя год, в гостях у Уставшего техдира мы говорим про безопасность в разработке, про роль AI в этом процессе, чтобы потом поделиться этим мыслями со всеми, кто неравнодушен к созданию продуктов, кибербезопасности и теме ИИ.
⭐ Выпуск доступен на YouTube, ВК, Rutube, Spotify, Apple Podcast, Яндекс.Музыка.
Дубай. Вечер. Глеб рассказывает кому-то из участников CTO Day, почему он не расстается со своей кепкой, на козырьке которой написано <head>. Можно догадаться, что это намек на фронтендерский бэкграунд Глеба, который уже давно с позиции технического директора смотрит на разработку, катит фичи в продукты, и рассказывает о нюансах управления R&D в своем подскасте.
И вот, спустя год, в гостях у Уставшего техдира мы говорим про безопасность в разработке, про роль AI в этом процессе, чтобы потом поделиться этим мыслями со всеми, кто неравнодушен к созданию продуктов, кибербезопасности и теме ИИ.
Please open Telegram to view this post
VIEW IN TELEGRAM
👾7❤🔥3👍2👏1
База симуляций атак и правил для их обнаружения
Кто запускал инструменты симуляции атак, тот знает, насколько они бывают полезными для оценки способностей Blue Team. Автор репозитория AttackRuleMap пробует закрыть пробел между сценариями атак инструмента Atomic Red Team и Sigma-правилами для их обнаружения.
Полезная база, которая пригодится аналитику SOC, чтобы не дожидаться, когда к нему прийдет пентестер или Red Team, а самостоятельно оценить свои возможности.
Кто запускал инструменты симуляции атак, тот знает, насколько они бывают полезными для оценки способностей Blue Team. Автор репозитория AttackRuleMap пробует закрыть пробел между сценариями атак инструмента Atomic Red Team и Sigma-правилами для их обнаружения.
Полезная база, которая пригодится аналитику SOC, чтобы не дожидаться, когда к нему прийдет пентестер или Red Team, а самостоятельно оценить свои возможности.
⚡5👍5👏2
Провинциальный OSINT: определяем место
Обычный пользователь видит просто фото. А что на нем видит OSINT-исследователь?
Фотка сделана на крыше здания, которое расположено где-то на окраине крупного города. Задача: определить страну.
⭐️ Задача со звездочкой: определить город.
Обычный пользователь видит просто фото. А что на нем видит OSINT-исследователь?
Фотка сделана на крыше здания, которое расположено где-то на окраине крупного города. Задача: определить страну.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤓6👏3
Правила для выявления атак небезопасной распаковки архивов
Мы изучали уязвимость Zip Slip в Golang, когда атакующий может загрузить специально сформированный архив и выйти за пределы каталога, в который производится распаковка.
Проект Unsafe Unpacking Research собирает сценарии небезопасной распаковки в разных языках программирования и предлагает соответствующие semgrep-правила для их выявления в коде. Возможно, с помощью этих правил, AppSec-инженер, который уже устал находить в своих рабочих проектах тривиальные уязвимости, сможет разбавить рутину трудовых будней своих разработчиков.👾
Мы изучали уязвимость Zip Slip в Golang, когда атакующий может загрузить специально сформированный архив и выйти за пределы каталога, в который производится распаковка.
Проект Unsafe Unpacking Research собирает сценарии небезопасной распаковки в разных языках программирования и предлагает соответствующие semgrep-правила для их выявления в коде. Возможно, с помощью этих правил, AppSec-инженер, который уже устал находить в своих рабочих проектах тривиальные уязвимости, сможет разбавить рутину трудовых будней своих разработчиков.
Please open Telegram to view this post
VIEW IN TELEGRAM
✍6❤3👍2🔥1
Новая AI-модель для задач кибербезопасности
На прошлой неделе первый поток APPSEC-01 завершил свое обучение и передал эстафету новому потоку. На заключительном вебинаре мы рассмотрели сценарии использования ИИ для задач AppSec-инженера.
Пока мы обменивались идеями, Google опубликовал экспериментальную модель Sec-Gemini, которая предназначена для автоматизации SecOps-процессов. В бенчмарке CTI-RCM (Cybersecurity Threat Intelligence-Root Cause Mapping) эта модель опередила конкурентов. Фреймворк CTI-RCM позволяет оценить способности LLM в задачах определения контекста угроз, поиска связи между угрозой и уязвимостями, которые к ней привели.
Для AppSec-инженера интересна интеграция Sec-Gemini с источником данных об уязвимостях OSV. Теперь можно следить за зависимостями в своем ПО еще тщательнее.
Кажется, что уже участники второго потока будут изучать не только сценарии автоматизации рутинных AppSec-задач, но и способов интеграции AI-AppSec-инженера в свою работу.🤖
На прошлой неделе первый поток APPSEC-01 завершил свое обучение и передал эстафету новому потоку. На заключительном вебинаре мы рассмотрели сценарии использования ИИ для задач AppSec-инженера.
Пока мы обменивались идеями, Google опубликовал экспериментальную модель Sec-Gemini, которая предназначена для автоматизации SecOps-процессов. В бенчмарке CTI-RCM (Cybersecurity Threat Intelligence-Root Cause Mapping) эта модель опередила конкурентов. Фреймворк CTI-RCM позволяет оценить способности LLM в задачах определения контекста угроз, поиска связи между угрозой и уязвимостями, которые к ней привели.
Для AppSec-инженера интересна интеграция Sec-Gemini с источником данных об уязвимостях OSV. Теперь можно следить за зависимостями в своем ПО еще тщательнее.
Кажется, что уже участники второго потока будут изучать не только сценарии автоматизации рутинных AppSec-задач, но и способов интеграции AI-AppSec-инженера в свою работу.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥3❤2
Forwarded from Кибербез образование | cybersecurity-roadmap.ru
Media is too big
VIEW IN TELEGRAM
Какие навыки прокачивать, чтобы зайти в кибербез сегодня, и зачем писать код на листке бумаги? 🤔
Новый выпуск подкаста с Денисом Макрушиным, директором по продуктам безопасной разработки в Яндекс , автором канала Makrushin👨🏫
Таймкоды:
00:26 - Денис о своем пути в кибербез, о журнале Хакер и обучении в МИФИ
04:21 - Почему остался в кибербезе после окончания вуза?
07:45 - Формирование аналитического мышления в вузе
09:47 - Путь к преподаванию, аспирантура, специфика деятельности преподавателя
13:37 - Как удается разрабатывать курсы и где находить для этого время?
16:40 - Инструменты для анализа научных статей
19:08 - ИИ заменит программистов
20:49 - ИИ в QA
21:33 - ИИ как напарник программиста
22:29 - Роль системных архитекторов
24:23 - Как сформировать современную программу обучения для программистов?
31:05 - Как преодолеть стереотипы в преподавании?
34:56 - Про формирование системного мышления, организация и коммуникация в процессе обучения
40:14 - Зачем писать код на листке бумаги без ПК?
44:16 - Мотивация преподавателя и язык ассемблера для ИБ сегодня
47:25 - Какие навыки прокачивать, чтобы зайти в кибербез?
👉 Запись также доступна в VK📺 RuTube 📺 и Яндекс.Музыке 🎵
Дополнительные материалы:
- The Fastest Research Platform Ever
#подкаст
Новый выпуск подкаста с Денисом Макрушиным, директором по продуктам безопасной разработки в Яндекс , автором канала Makrushin
Таймкоды:
00:26 - Денис о своем пути в кибербез, о журнале Хакер и обучении в МИФИ
04:21 - Почему остался в кибербезе после окончания вуза?
07:45 - Формирование аналитического мышления в вузе
09:47 - Путь к преподаванию, аспирантура, специфика деятельности преподавателя
13:37 - Как удается разрабатывать курсы и где находить для этого время?
16:40 - Инструменты для анализа научных статей
19:08 - ИИ заменит программистов
20:49 - ИИ в QA
21:33 - ИИ как напарник программиста
22:29 - Роль системных архитекторов
24:23 - Как сформировать современную программу обучения для программистов?
31:05 - Как преодолеть стереотипы в преподавании?
34:56 - Про формирование системного мышления, организация и коммуникация в процессе обучения
40:14 - Зачем писать код на листке бумаги без ПК?
44:16 - Мотивация преподавателя и язык ассемблера для ИБ сегодня
47:25 - Какие навыки прокачивать, чтобы зайти в кибербез?
👉 Запись также доступна в VK
Дополнительные материалы:
- The Fastest Research Platform Ever
#подкаст
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍6👏2🍌1
Forwarded from South HUB
Вашей компании нужен герой — и он уже среди ваших разработчиков!
(#соавтор 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.
Культивируете ли чемпионов в своих командах?
👍8❤5🔥3😭2😁1🏆1