Фишинг для пользователей GitHub
Платформа ведет борьбу со спам-ботами, которые эксплуатируют ее репутацию и отправляют пользователям сообщения с вредоносными ссылками.
Особенность этого фишинга: пользователь платформы получает письмо от GitHub. Боты добавляют вредоносные ссылки в комментариях к существующим задачам (issues) открытых проектов. И затем, эти комментарии приземляются в почту в виде нотификации к пользователям этого проекта. Дальше уже все по классике: запуск вредоноса, захват GitHub-аккаунта и публикация аналогичного комментария со ссылкой в репозиториях, которые добавил в закладки этот аккаунт.
Red Team рассматривает эту особенность как дополнительный канал доставки импланта, потому что в комбинации с техникой загрузки вредоносных файлов в GitHub CDN он позволяет уверенно обходить спам-фильтры. А Blue Team теперь внимательнее следит за почтовыми уведомлениями от GitHub.
Платформа ведет борьбу со спам-ботами, которые эксплуатируют ее репутацию и отправляют пользователям сообщения с вредоносными ссылками.
Особенность этого фишинга: пользователь платформы получает письмо от GitHub. Боты добавляют вредоносные ссылки в комментариях к существующим задачам (issues) открытых проектов. И затем, эти комментарии приземляются в почту в виде нотификации к пользователям этого проекта. Дальше уже все по классике: запуск вредоноса, захват GitHub-аккаунта и публикация аналогичного комментария со ссылкой в репозиториях, которые добавил в закладки этот аккаунт.
Red Team рассматривает эту особенность как дополнительный канал доставки импланта, потому что в комбинации с техникой загрузки вредоносных файлов в GitHub CDN он позволяет уверенно обходить спам-фильтры. А Blue Team теперь внимательнее следит за почтовыми уведомлениями от GitHub.
👍3❤1
Отравление пайплайна разработки. Часть 2.
CI/CD-платформы являются приоритетной целью для атакующих, и мы уже рассмотрели типичный сценарий атаки на CI-окружение, связанный с изменением конфигурационного файла. Но пока еще не ответили на вопрос:
А вот исследователи из Open Source Security Foundation ответили. На примере коллекции наиболее распространенных атак на Github Actions, рассмотрены конкретные техники защиты от каждой проблемы. Если коротко и в формате «атака: защита»:
1. Запуск недоверенного кода в привелегированном рабочем процессе (Workflow): разделение процесса на два блока (с привелегиями и без).
2. Внедрение кода через недоверенный ввод данных, недоверенные файлы и файлы окружения: сбор параметров для Actions строку, ограничение прав на GitHub-токен до минимально необходимых.
3. Вредоносные Actions: ограничение прав на GitHub-токен до минимально необходимых, доверять только официальным Actions от GitHub (остальные - проверять на наличие уязвимостей и затем патчить, например, с помощью Dependabot).
4. Вредоносные коммиты: ограничение прав на GitHub-токен до минимально необходимых, сверять хэши Actions при обновлении Workflow.
5. Кража токенов кэша для получения контекста других рабочих процессов, использующих кэширование: не кэшировать ценную информацию, не запускать недоверенный код в контексте основной ветки.
CI/CD-платформы являются приоритетной целью для атакующих, и мы уже рассмотрели типичный сценарий атаки на CI-окружение, связанный с изменением конфигурационного файла. Но пока еще не ответили на вопрос:
Как защищаемся?
А вот исследователи из Open Source Security Foundation ответили. На примере коллекции наиболее распространенных атак на Github Actions, рассмотрены конкретные техники защиты от каждой проблемы. Если коротко и в формате «атака: защита»:
1. Запуск недоверенного кода в привелегированном рабочем процессе (Workflow): разделение процесса на два блока (с привелегиями и без).
2. Внедрение кода через недоверенный ввод данных, недоверенные файлы и файлы окружения: сбор параметров для Actions строку, ограничение прав на GitHub-токен до минимально необходимых.
3. Вредоносные Actions: ограничение прав на GitHub-токен до минимально необходимых, доверять только официальным Actions от GitHub (остальные - проверять на наличие уязвимостей и затем патчить, например, с помощью Dependabot).
4. Вредоносные коммиты: ограничение прав на GitHub-токен до минимально необходимых, сверять хэши Actions при обновлении Workflow.
5. Кража токенов кэша для получения контекста других рабочих процессов, использующих кэширование: не кэшировать ценную информацию, не запускать недоверенный код в контексте основной ветки.
1👍6❤1
Поиск секретов и уязвимостей dangling DNS в больших данных
Когда мы используем традиционные методы поиска уязвимостей, то ограничиваемся исследованием конкретной цели: платформы, приложения, веб-ресурса, сегмента сети. Но есть подход, который отличается от классического: не ограничиваться конкретной целью, а выбрать определенную уязвимость и заняться ее поиском в больших данных.
С переходом инфраструктуры в облака, второй метод может дать интересные результаты. Например, если на большом пуле IP-адресов крупных облачных провайдеров вроде Google и AWS поискать “висячие” DNS-записи (dangling DNS), которые указывают на несуществующий ресурс и доступны для захвата, то можно обнаружить много возможностей для атак subdomain takeover.
Более 78000 “висячих” DNS-записей, которые указывают на 66000 уникальных доменов верхнего уровня. Среди владельцев этих доменов есть крупные компании и бренды, а значит, злоумышленник может разместить на этих доменах свой ресурс, который будет эксплуатировать доверие пользователей.
Аналогичный подход можно применить и к поиску секретов в файлах. Если взять источник вроде Virustotal и с помощью YARA-правил поискать в нем файлы с секретами, то можно обнаружить более 15000 секретов. Среди них: 2500 ключей для подключения к инфраструктуре OpenAI, 3000 ключиков для AWS и Google Cloud.
Подход поиска уязвимостей в больших данных состоит из ключевых принципов:
* начинать исследование с уявзимости и ее особенностей, а не с цели;
* использовать все доступные источники данных, включая нетривиальные источники;
* данные, по которым ведется поиск, должны иметь связь с заданным классом уязвимостей;
* процесс поиска по большим данным должен быть масштабируемым.
Применяй этот подход, чтобы освежить свои исследования.
Когда мы используем традиционные методы поиска уязвимостей, то ограничиваемся исследованием конкретной цели: платформы, приложения, веб-ресурса, сегмента сети. Но есть подход, который отличается от классического: не ограничиваться конкретной целью, а выбрать определенную уязвимость и заняться ее поиском в больших данных.
С переходом инфраструктуры в облака, второй метод может дать интересные результаты. Например, если на большом пуле IP-адресов крупных облачных провайдеров вроде Google и AWS поискать “висячие” DNS-записи (dangling DNS), которые указывают на несуществующий ресурс и доступны для захвата, то можно обнаружить много возможностей для атак subdomain takeover.
Более 78000 “висячих” DNS-записей, которые указывают на 66000 уникальных доменов верхнего уровня. Среди владельцев этих доменов есть крупные компании и бренды, а значит, злоумышленник может разместить на этих доменах свой ресурс, который будет эксплуатировать доверие пользователей.
Аналогичный подход можно применить и к поиску секретов в файлах. Если взять источник вроде Virustotal и с помощью YARA-правил поискать в нем файлы с секретами, то можно обнаружить более 15000 секретов. Среди них: 2500 ключей для подключения к инфраструктуре OpenAI, 3000 ключиков для AWS и Google Cloud.
Подход поиска уязвимостей в больших данных состоит из ключевых принципов:
* начинать исследование с уявзимости и ее особенностей, а не с цели;
* использовать все доступные источники данных, включая нетривиальные источники;
* данные, по которым ведется поиск, должны иметь связь с заданным классом уязвимостей;
* процесс поиска по большим данным должен быть масштабируемым.
Применяй этот подход, чтобы освежить свои исследования.
👍5
Первый DevSecOps-хакатон от сообщества FinDevSecOps
На прошлой неделе мы провели первый DevSecOps-хакатон, который стал важным событием для безопасной разработки ПО в России. Мероприятие стало первым, где участникам было предложено построить пайплайн с учетом требований ГОСТ 56939.
Участие приняли 11 команд, из которых 7 дошли до финала. Студенческие команды не только успешно выполнили задания, но и качественно представили жюри свои решения. И я бы даже отметил, что сделали это не менее интересно, чем команды коммерческих организаций.
Работы оценивались по следующим критериям:
* покрытие security-проверками всех этапов жизненного цикла разработки;
* применение решений из различных практик DevSecOps;
* качество тонкой настройки инструментов для работы с ложными срабатываниями;
* соответствие предложенных решений требованиям ГОСТ 56939;
* возможности масштабирования решения и сложность его технической поддержки.
Одним из призов стал курс по безопасной разработке, который мы совместно с МГТУ им. Баумана подготовили для обучения AppSec-инженеров и security-чемпионов. Получается, что победители увезли с собой не только награды, но и новые навыки.
На прошлой неделе мы провели первый DevSecOps-хакатон, который стал важным событием для безопасной разработки ПО в России. Мероприятие стало первым, где участникам было предложено построить пайплайн с учетом требований ГОСТ 56939.
Участие приняли 11 команд, из которых 7 дошли до финала. Студенческие команды не только успешно выполнили задания, но и качественно представили жюри свои решения. И я бы даже отметил, что сделали это не менее интересно, чем команды коммерческих организаций.
Работы оценивались по следующим критериям:
* покрытие security-проверками всех этапов жизненного цикла разработки;
* применение решений из различных практик DevSecOps;
* качество тонкой настройки инструментов для работы с ложными срабатываниями;
* соответствие предложенных решений требованиям ГОСТ 56939;
* возможности масштабирования решения и сложность его технической поддержки.
Одним из призов стал курс по безопасной разработке, который мы совместно с МГТУ им. Баумана подготовили для обучения AppSec-инженеров и security-чемпионов. Получается, что победители увезли с собой не только награды, но и новые навыки.
🔥7❤2😁2🦄2👍1
Прощай CSRF: поиск и эксплуатация уязвимостей Client-Side Path Traversal
Из нетривиальных уязвимостей, о которых давно известно, но которые пока еще мало кто целенаправлено ищет - можно выделить категорию Client-Side Path Traversal (CSPT).
Исследователи хорошо знают проблемы, связанные с обходом каталога. Уязвимость path traversal позволяет использовать строки вида «../../../../../» для доступа к данным за пределами целевого каталога. В отличие от уязвимости на стороне сервера, CSPT дает атакующему возможность заставить жертву осуществлять запросы к интересным конечным точкам API. И эта возможность - первое условие для реализации атаки.
Второе условие: наличие интересного эндпоинта, к которому можно обратиться и осуществить какое-либо действие. Напоминает сценарий CSRF? Да. При этом у CSPT есть особенность: существующие механизмы защиты от CSRF-атак (например, токены) оказываются неэффективными для решения этого класса проблем.
После детального изучения этой уязвимости, находим тестовый стенд для экспериментов и инструменты для автоматизации поиска.
Из нетривиальных уязвимостей, о которых давно известно, но которые пока еще мало кто целенаправлено ищет - можно выделить категорию Client-Side Path Traversal (CSPT).
Исследователи хорошо знают проблемы, связанные с обходом каталога. Уязвимость path traversal позволяет использовать строки вида «../../../../../» для доступа к данным за пределами целевого каталога. В отличие от уязвимости на стороне сервера, CSPT дает атакующему возможность заставить жертву осуществлять запросы к интересным конечным точкам API. И эта возможность - первое условие для реализации атаки.
Второе условие: наличие интересного эндпоинта, к которому можно обратиться и осуществить какое-либо действие. Напоминает сценарий CSRF? Да. При этом у CSPT есть особенность: существующие механизмы защиты от CSRF-атак (например, токены) оказываются неэффективными для решения этого класса проблем.
После детального изучения этой уязвимости, находим тестовый стенд для экспериментов и инструменты для автоматизации поиска.
👍3👾3🔥2❤1
Фреймворк для оценки качества правил выявления угроз
Методология Detection-as-Code уверенно приземляется не только в центрах мониторинга угроз, но и в исследовательском сообществе. Использование LLM для генерации правил усиливает этот тренд. При этом, проведение анализа качества нового правила ложится на плечи аналитика. И тут каждый тестирует, как умеет или придерживается какой-то тактики.
Если тактики нет, то можно изучить фреймворк для оценки качества правил обнаружения угроз “Shannon Signal Score”. Его автор предлагает использовать объективные и субъективные метрики, учитывая специфику организации и контекст угроз. Категории метрик:
1. соответствие угрозам и охват;
2. целостность обнаружения;
3. когнитивная нагрузка и операционные затраты на обнаружение, расследование;
4. потенциальный риск;
5. практическая польза.
Для количественной оценки используются статистические показатели, а для качественной – LLM. Получилась гибкая система. Кто решит внедрить - поделитесь впечатлениями.
Методология Detection-as-Code уверенно приземляется не только в центрах мониторинга угроз, но и в исследовательском сообществе. Использование LLM для генерации правил усиливает этот тренд. При этом, проведение анализа качества нового правила ложится на плечи аналитика. И тут каждый тестирует, как умеет или придерживается какой-то тактики.
Если тактики нет, то можно изучить фреймворк для оценки качества правил обнаружения угроз “Shannon Signal Score”. Его автор предлагает использовать объективные и субъективные метрики, учитывая специфику организации и контекст угроз. Категории метрик:
1. соответствие угрозам и охват;
2. целостность обнаружения;
3. когнитивная нагрузка и операционные затраты на обнаружение, расследование;
4. потенциальный риск;
5. практическая польза.
Для количественной оценки используются статистические показатели, а для качественной – LLM. Получилась гибкая система. Кто решит внедрить - поделитесь впечатлениями.
🔥5💯1
Третья сессия на факультете стратегического управления: ключевые инсайты и заметки на полях
* Стратегия – это еще и искусство выбора. Она не только про то, куда мы идем и что делаем, чтобы достичь результата, но и о том, от каких возможностей осознанно отказываемся.
* Анализ силового поля Курта Левина. Любые индивидуальные и корпоративные изменения являются результатом двух конкурирующих сил: движущих и сдерживающих. При разработке стратегии необходимо перечислить эти силы, оценить их влияние и разобраться, какие из них можно изменить.
* Ключевые отличия в системе принятия решений предпринимателя и менеджера в период кризисных ситуаций. Пока изучал эту тему, встретил исследования, которые подтверждают гипотезу: скорость работы с негативной обратной связью у предпринимателя выше.
* На учебном модуле в Армении открыл для себя предприятие, которое cтроит солнечные электростанции. Удивительным оказался не столько масштаб строительства и инвестиций, сколько пет-проект, который основатели реализовали неподалеку от трансформаторных конструкций: используя горячий воздух от трансформаторов, наладили производство сухофруктов. Устойчивая бизнес-модель рождается на пересечении технологий и творческого подхода.
* Стратегия – это еще и искусство выбора. Она не только про то, куда мы идем и что делаем, чтобы достичь результата, но и о том, от каких возможностей осознанно отказываемся.
Пока ты не научился говорить «нет» возможностям, ты не стратег.
* Анализ силового поля Курта Левина. Любые индивидуальные и корпоративные изменения являются результатом двух конкурирующих сил: движущих и сдерживающих. При разработке стратегии необходимо перечислить эти силы, оценить их влияние и разобраться, какие из них можно изменить.
Иногда проще убрать барьеры, чем усиливать поддержку.
* Ключевые отличия в системе принятия решений предпринимателя и менеджера в период кризисных ситуаций. Пока изучал эту тему, встретил исследования, которые подтверждают гипотезу: скорость работы с негативной обратной связью у предпринимателя выше.
* На учебном модуле в Армении открыл для себя предприятие, которое cтроит солнечные электростанции. Удивительным оказался не столько масштаб строительства и инвестиций, сколько пет-проект, который основатели реализовали неподалеку от трансформаторных конструкций: используя горячий воздух от трансформаторов, наладили производство сухофруктов. Устойчивая бизнес-модель рождается на пересечении технологий и творческого подхода.
🔥5👍4❤1👌1💯1
Генеративный ИИ повышает производительность разработки. Или нет?
В одном из комментариев в моем канале в Сетке появился вопрос: “а как вы измеряете эффективность разработки?”. Вспомню ключевой тезис в дискуссии CTO Day: измеряем бизнес-результатами и скоростью выпуска новых бизнес-функций в продукте.
Встретил свежую исследовательскую работу, в которой утверждается, что использование инструментов с ИИ увеличивает производительность разработчика на 26,08%. Значит, в этой работе должны быть метрики производительности и эффективности.
Методика исследования:
* три рандомизированных контролируемых эксперимента в реальных условиях на примере трех компаний (Microsoft, Accenture, анонимная компания из списка Fortune 100). В процессе эксперимента разработчикам был случайным образом предоставлен доступ к GitHub Copilot, либо они попадали в контрольную группу без доступа.
* Анализ данных проводился с использованием двухшагового метода наименьших квадратов (2SLS). Оценки 2SLS взвешивались по разнице в использовании между экспериментальной и контрольной группами за период.
* Для оценки влияния инструмента на производительность разработчиков использовались такие показатели, как количество выполненных pull request, количество коммитов кода и количество сборок кода, а также показатели использования Copilot, такие как количество предложений и количество принятых предложений.
Вот оно! Pull request, количество коммитов кода и количество сборок — ключевые показатели для оценки. Какие есть ограничения при оценке этих метрик:
* высокая вариативность в результатах, поскольку на производительность разработчиков влияет их опыт, навыки и типы выполняемых задач. Принцип распределения разработчиков на кластеры в данном эксперименте непрозрачен.
* Эксперименты проводились в реальных рабочих условиях, где на производительность разработчиков могли влиять различные факторы, не поддающиеся контролю, например, изменения в проектах или командные взаимодействия.
Действительно ли в количестве pull requests измеряется производительность разработки — вопрос все еще открытый.
В одном из комментариев в моем канале в Сетке появился вопрос: “а как вы измеряете эффективность разработки?”. Вспомню ключевой тезис в дискуссии CTO Day: измеряем бизнес-результатами и скоростью выпуска новых бизнес-функций в продукте.
Встретил свежую исследовательскую работу, в которой утверждается, что использование инструментов с ИИ увеличивает производительность разработчика на 26,08%. Значит, в этой работе должны быть метрики производительности и эффективности.
Методика исследования:
* три рандомизированных контролируемых эксперимента в реальных условиях на примере трех компаний (Microsoft, Accenture, анонимная компания из списка Fortune 100). В процессе эксперимента разработчикам был случайным образом предоставлен доступ к GitHub Copilot, либо они попадали в контрольную группу без доступа.
* Анализ данных проводился с использованием двухшагового метода наименьших квадратов (2SLS). Оценки 2SLS взвешивались по разнице в использовании между экспериментальной и контрольной группами за период.
* Для оценки влияния инструмента на производительность разработчиков использовались такие показатели, как количество выполненных pull request, количество коммитов кода и количество сборок кода, а также показатели использования Copilot, такие как количество предложений и количество принятых предложений.
Вот оно! Pull request, количество коммитов кода и количество сборок — ключевые показатели для оценки. Какие есть ограничения при оценке этих метрик:
* высокая вариативность в результатах, поскольку на производительность разработчиков влияет их опыт, навыки и типы выполняемых задач. Принцип распределения разработчиков на кластеры в данном эксперименте непрозрачен.
* Эксперименты проводились в реальных рабочих условиях, где на производительность разработчиков могли влиять различные факторы, не поддающиеся контролю, например, изменения в проектах или командные взаимодействия.
Действительно ли в количестве pull requests измеряется производительность разработки — вопрос все еще открытый.
👍4❤1🐳1
Атаки на GitHub-разработчика в 2024 году
Тренд «Platform Engineering» стал интересен не только компаниям, которые трансформируют свои процессы, команды и инструменты согласно новым подходам. Этот тренд также интересует и злоумышленников, которые используют возможности платформ разработки для проведения атак.
В этой статье я собрал коллекцию интересных уязвимостей и методов атак на пользователей крупной платформы разработки, обзор актуальных методов атак, выявленных в 2024 году. Понимание актуальных угроз позволяет лучше разобраться в необходимости улучшения практик безопасности в такой платформе на примере GitHub. Материал будет полезен как разработчикам, так и специалистам по информационной безопасности для защиты своих проектов.
Тренд «Platform Engineering» стал интересен не только компаниям, которые трансформируют свои процессы, команды и инструменты согласно новым подходам. Этот тренд также интересует и злоумышленников, которые используют возможности платформ разработки для проведения атак.
В этой статье я собрал коллекцию интересных уязвимостей и методов атак на пользователей крупной платформы разработки, обзор актуальных методов атак, выявленных в 2024 году. Понимание актуальных угроз позволяет лучше разобраться в необходимости улучшения практик безопасности в такой платформе на примере GitHub. Материал будет полезен как разработчикам, так и специалистам по информационной безопасности для защиты своих проектов.
👍3🔥2
Технологии AutoFix: исправление 2/3 багов с первой попытки
Вендоры крупных платформ разработки и стартапы с разной степенью успеха создают технологию AutoFix. В ее основе находятся LLM, которые анализируют уязвимость и ее контекст, а затем предлагают вариант ее исправления. Насколько хорошо у них это получается можно судить по текущим результатам:
* наиболее “зрелые” модели LLM способны исправить примерно 2/3 всех обнаруженных уязвимостей с первой попытки, но использование пользовательских подсказок позволяет улучшить этот результат;
* коммерческие и открытые модели имеют схожие показатели производительности при разной стоимости эксплуатации.
То есть, использовать Autofix можно, но внедрять исправленный код в прод без дополнительной верификации нужно аккуратнее. Например, исправление проблемы, связанной со слабым шифрованием или использованием небезопасных протоколов, может привести к сбоям в работе приложения.
Есть и другие ограничения:
* сложности с зависимостями и импортами: модели часто не могут правильно обработать сложные зависимости и импорты в кодовой базе. Например, когда LLM предлагает переписать код для использования методов безопасной сериализации, но не предлагает импортировать библиотеку для этой задачи.
* LLM могут предлагать новые зависимости для проекта, которые могут принести новые уязвимости в этот проект;
* недостаточный контекст: модели часто предлагают исправления, которые не соответствуют шаблонам проектирования или общей архитектуре проекта.
С учётом этих ограничений, разработчики технологий AutoFix используют пользовательские подсказки вместе с большим контекстом о коде. Пользователь может указать предпочтительные библиотеки (например, для логирования, алгоритмов шифрования и генерации случайных чисел).
Помимо инструкций от пользователя, увеличить точность ответов помогает механизм повторных попыток. LLM генерирует несколько исправлений для одной и той же уязвимости и таким образом увеличивает шансы на получение правильного варианта.
Вендоры крупных платформ разработки и стартапы с разной степенью успеха создают технологию AutoFix. В ее основе находятся LLM, которые анализируют уязвимость и ее контекст, а затем предлагают вариант ее исправления. Насколько хорошо у них это получается можно судить по текущим результатам:
* наиболее “зрелые” модели LLM способны исправить примерно 2/3 всех обнаруженных уязвимостей с первой попытки, но использование пользовательских подсказок позволяет улучшить этот результат;
* коммерческие и открытые модели имеют схожие показатели производительности при разной стоимости эксплуатации.
То есть, использовать Autofix можно, но внедрять исправленный код в прод без дополнительной верификации нужно аккуратнее. Например, исправление проблемы, связанной со слабым шифрованием или использованием небезопасных протоколов, может привести к сбоям в работе приложения.
Есть и другие ограничения:
* сложности с зависимостями и импортами: модели часто не могут правильно обработать сложные зависимости и импорты в кодовой базе. Например, когда LLM предлагает переписать код для использования методов безопасной сериализации, но не предлагает импортировать библиотеку для этой задачи.
* LLM могут предлагать новые зависимости для проекта, которые могут принести новые уязвимости в этот проект;
* недостаточный контекст: модели часто предлагают исправления, которые не соответствуют шаблонам проектирования или общей архитектуре проекта.
С учётом этих ограничений, разработчики технологий AutoFix используют пользовательские подсказки вместе с большим контекстом о коде. Пользователь может указать предпочтительные библиотеки (например, для логирования, алгоритмов шифрования и генерации случайных чисел).
Помимо инструкций от пользователя, увеличить точность ответов помогает механизм повторных попыток. LLM генерирует несколько исправлений для одной и той же уязвимости и таким образом увеличивает шансы на получение правильного варианта.
❤2👍2🔥2💯1
Выпускной: инсайты четвертой сессии на факультете стратегического управления
Собрал заметки на полях и ключевые мысли четвертой заключительной сессии в программе MBA:
⭐️ Навык управления энергией важнее навыка управления временем.
В очередной раз эта мысль прозвучала сразу в нескольких учебных модулях.
⭐️ В модуле «Актерское мастерство для менеджера» поймал такую цитату:
Важно уметь анализировать обстоятельства, классифицировать их по группам факторов и в зависимости от этого определять сценарий.
Например, сценарий ведения переговоров. И это следующее открытие.
⭐️ Как и в кинематографе, у переговорного процесса есть свой сюжет и есть свои «шаблоны проектирования».
Цели переговоров, сформулированные по SMART, делятся на две группы: must-цели, wish-цели. Достижение первых определяет успех переговоров. Достижение вторых — степень этого успеха.
На основе данных целей формируется дерево принятия решений — то есть возможные сценарии. Подобная формализация переговорного процесса делает его более предсказуемым и контролируемым для «режиссера».
Пожалуй, план подготовки к переговорам — это ключевой инсайт этого семестра, который я вынес из модуля «Техника ведения переговоров».
Записал эту мысль в модуле «Управление знаниями», чтобы позже подробнее изучить подходы и исследования, связанные с концепцией «Adaptive Space». Они лежат в основе трансформации крупных компаний. Возможно, что-то из этих подходов окажется полезным и для личной трансформации.
Пусть 2025 год принесет больше адаптивного пространства для исследований, создания и обсуждения гипотез. А если не принесет — создадим его сами.
С наступающим Новым Годом!
Собрал заметки на полях и ключевые мысли четвертой заключительной сессии в программе MBA:
В очередной раз эта мысль прозвучала сразу в нескольких учебных модулях.
«Задача лидера — создавать избыток энергии»
«Менеджер — это режиссер, который в предлагаемых обстоятельствах организует управление вниманием»
Важно уметь анализировать обстоятельства, классифицировать их по группам факторов и в зависимости от этого определять сценарий.
Например, сценарий ведения переговоров. И это следующее открытие.
Цели переговоров, сформулированные по SMART, делятся на две группы: must-цели, wish-цели. Достижение первых определяет успех переговоров. Достижение вторых — степень этого успеха.
На основе данных целей формируется дерево принятия решений — то есть возможные сценарии. Подобная формализация переговорного процесса делает его более предсказуемым и контролируемым для «режиссера».
Пожалуй, план подготовки к переговорам — это ключевой инсайт этого семестра, который я вынес из модуля «Техника ведения переговоров».
⭐️
«Потенциал лидера определяется количеством и качеством его последователей»
⭐️
«Нужно создавать адаптивное пространство — зону, где есть возможность исследовать, оспаривать идеи»
Записал эту мысль в модуле «Управление знаниями», чтобы позже подробнее изучить подходы и исследования, связанные с концепцией «Adaptive Space». Они лежат в основе трансформации крупных компаний. Возможно, что-то из этих подходов окажется полезным и для личной трансформации.
Пусть 2025 год принесет больше адаптивного пространства для исследований, создания и обсуждения гипотез. А если не принесет — создадим его сами.
С наступающим Новым Годом!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥8🏆3❤1🤷1
Стою, жду, когда праздники закончатся 🙃
Чтобы рассказать сразу несколько новостей:
* Для авторской колонки в “Хакере” подготовил обзор перспективных исследований за 2024 год, которые точно нужно изучить, а результаты — применить в своих проектах уже в этом году. Есть что почитать на выходных.
* Опубликовал ключевые инсайты, которые накопил за период обучения на программе MBA в Президентской Академии.
* Вместе с командой завершили запись всех лекций курса по безопасности приложений и подготовились к запуску первого потока. Просто пока ждем, когда праздники закончатся.
Чтобы рассказать сразу несколько новостей:
* Для авторской колонки в “Хакере” подготовил обзор перспективных исследований за 2024 год, которые точно нужно изучить, а результаты — применить в своих проектах уже в этом году. Есть что почитать на выходных.
* Опубликовал ключевые инсайты, которые накопил за период обучения на программе MBA в Президентской Академии.
* Вместе с командой завершили запись всех лекций курса по безопасности приложений и подготовились к запуску первого потока. Просто пока ждем, когда праздники закончатся.
🔥11👍3😁1🤣1
Makrushin
Вместе с командой завершили запись всех лекций курса по безопасности приложений и подготовились к запуску
Суббота - хороший повод запустить что-нибудь. Например, авторский курс, который мы готовили с командой МГТУ им. Баумана и о котором я уже рассказывал.
В этот раз расскажу о процессе его подготовки. В цифрах:
* 24 недели от идеи до результата
* 314 слайдов и 12 студийных сессий для их записи
* 8 участников команды, которые отвечали за верстку и дизайн, запись и производство видео, составление учебной программы и клиентский опыт, разработку лендига, маркетинг и координацию всего проекта.
* курс лег в основу двух программ подготовки магистров в области ИБ. А значит, свободно доступен для студентов и выпускников НИЯУ МИФИ и МГТУ им Баумана.
Если среди моих подписчиков есть представители ВУЗов, которые хотят интегрировать этот контент в свои образовательные программы - пишите. Контакт для связи в описании группы.
В этот раз расскажу о процессе его подготовки. В цифрах:
* 24 недели от идеи до результата
* 314 слайдов и 12 студийных сессий для их записи
* 8 участников команды, которые отвечали за верстку и дизайн, запись и производство видео, составление учебной программы и клиентский опыт, разработку лендига, маркетинг и координацию всего проекта.
* курс лег в основу двух программ подготовки магистров в области ИБ. А значит, свободно доступен для студентов и выпускников НИЯУ МИФИ и МГТУ им Баумана.
Если среди моих подписчиков есть представители ВУЗов, которые хотят интегрировать этот контент в свои образовательные программы - пишите. Контакт для связи в описании группы.
🔥17😁3👍2
Как раскрасить граф активности любому пользователю 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