Оценка возможностей LLM в наступательной безопасности
Мы встречали исследования, в которых утверждалось, что LLM может автономно эксплуатировать известные уязвимости. Затем изучали опровержения этих исследований. В итоге пришли к выводу, что LLM может быть хорошим ассистентом при поиске багов, а команда Google Project Zero проверила эту гипотезу.
Исследователи взяли опубликованную ранее методику оценки возможностей LLM для поиска и эксплуатации уязвимостей, доработали ее и улучшили в 20 раз показатетели LLM в тестах. Ключевые принципы, которые авторы применили в своих доработках:
* пространство для рассуждений: дать модели возможность быть более «многословной» и через подробные рассуждения приходить к более точным результатам;
* интерактивная среда: дать модели возможность взаимодействовать с тестовым окружением и корректировать свои ошибки;
* инструменты: предоставить модели доступ к инструментам исследования (отладчик, интерпретатор кода Python), чтобы у нее была возможность получать детальную информацию о состоянии программы и влиять на это состояние;
* проверка результата: обеспечить автоматически воспроизводимый результат;
* стратегия отбора: дать модели возможность проверять несколько гипотез в рамках разных траекторий исследования.
В итоге LLM стал более эффективным инструментом для помощи в процессе поиска уязвимостей. Но до состояния автономной системы пока еще далеко.
Мы встречали исследования, в которых утверждалось, что LLM может автономно эксплуатировать известные уязвимости. Затем изучали опровержения этих исследований. В итоге пришли к выводу, что LLM может быть хорошим ассистентом при поиске багов, а команда Google Project Zero проверила эту гипотезу.
Исследователи взяли опубликованную ранее методику оценки возможностей LLM для поиска и эксплуатации уязвимостей, доработали ее и улучшили в 20 раз показатетели LLM в тестах. Ключевые принципы, которые авторы применили в своих доработках:
* пространство для рассуждений: дать модели возможность быть более «многословной» и через подробные рассуждения приходить к более точным результатам;
* интерактивная среда: дать модели возможность взаимодействовать с тестовым окружением и корректировать свои ошибки;
* инструменты: предоставить модели доступ к инструментам исследования (отладчик, интерпретатор кода Python), чтобы у нее была возможность получать детальную информацию о состоянии программы и влиять на это состояние;
* проверка результата: обеспечить автоматически воспроизводимый результат;
* стратегия отбора: дать модели возможность проверять несколько гипотез в рамках разных траекторий исследования.
В итоге LLM стал более эффективным инструментом для помощи в процессе поиска уязвимостей. Но до состояния автономной системы пока еще далеко.
👍4🔥3😁1😱1
Учебное пособие для аналитика киберугроз
Встретил интересный проект Pivot Atlas, который содержит справочные материалы о том, как можно использовать данные об угрозах для их анализа. Цель проекта: составить взаимосвязи и сценарии использования всех типов артефактов (IP-адреса, домены, TLS-сертификаты, сэмплы и прочее), которые помогут аналитику в расследовании инцидентов.
Пригодится в качестве справочника как для начинающих аналитиков SOC, так и для опытных исследователей угроз.
Встретил интересный проект Pivot Atlas, который содержит справочные материалы о том, как можно использовать данные об угрозах для их анализа. Цель проекта: составить взаимосвязи и сценарии использования всех типов артефактов (IP-адреса, домены, TLS-сертификаты, сэмплы и прочее), которые помогут аналитику в расследовании инцидентов.
Пригодится в качестве справочника как для начинающих аналитиков SOC, так и для опытных исследователей угроз.
✍2👍1🤨1
Набор сценариев защиты для облачной инфраструктуры
Коллекция техник для защиты облаков. Более 50 сценариев, которые Blue Team и DevSecOps могут брать в работу. К тому же, эти сценарии соответствуют техникам матрицы Mitre D3FEND, а значит, можно количественно оценить способности защиты для своего облака.
Коллекция техник для защиты облаков. Более 50 сценариев, которые Blue Team и DevSecOps могут брать в работу. К тому же, эти сценарии соответствуют техникам матрицы Mitre D3FEND, а значит, можно количественно оценить способности защиты для своего облака.
🔥2👍1🤣1
Захват артефактов: массовая компрометация зависимостей
Опубликована запись доклада с результатами исследования атак на цепочку поставок в разработке. Материалы, которые упомянуты в докладе:
* Уязвимость в отладчике WinDbg и ее использование для атак на разработчика
* Методика поиска уязвимых Github-репозиториев
* Результаты анализа популярных библиотек, доступных для захвата
* Инструмент для поиска вредоносных зависимостей PyPI и NPM
#Дайджест @makrushin
Опубликована запись доклада с результатами исследования атак на цепочку поставок в разработке. Материалы, которые упомянуты в докладе:
* Уязвимость в отладчике WinDbg и ее использование для атак на разработчика
* Методика поиска уязвимых Github-репозиториев
* Результаты анализа популярных библиотек, доступных для захвата
* Инструмент для поиска вредоносных зависимостей PyPI и NPM
#Дайджест @makrushin
👍4🔥3👏1💯1
ИИ ассистент для security архитектора: определение скопа для анализа защищенности
Собираем интересные сценарии внедрения ИИ для задач информационной безопасности. Разработчики научили генеративную модель выделять из описания релиза ключевые нововведения и изменения. Таким образом, она подсказывает, нужно ли проводить ручной анализ, и какой должен быть скоп у этой проверки.
Модель анализирует каждый Pull Request, дополняет его соответствующей информацией из Jira и делает выводы для команды наступательной безопасности о том, где и как сфокусировать усилия в ходе ручного анализа защищенности данного релиза. С учетом частоты релизов и сотнями Pull Request в каждом, этот сценарий использования экономит усилия команды на определение приоритетов в ходе ручных проверок.
Забираем для внедрения в свой процесс безопасной разработки.
Собираем интересные сценарии внедрения ИИ для задач информационной безопасности. Разработчики научили генеративную модель выделять из описания релиза ключевые нововведения и изменения. Таким образом, она подсказывает, нужно ли проводить ручной анализ, и какой должен быть скоп у этой проверки.
Модель анализирует каждый Pull Request, дополняет его соответствующей информацией из Jira и делает выводы для команды наступательной безопасности о том, где и как сфокусировать усилия в ходе ручного анализа защищенности данного релиза. С учетом частоты релизов и сотнями Pull Request в каждом, этот сценарий использования экономит усилия команды на определение приоритетов в ходе ручных проверок.
Забираем для внедрения в свой процесс безопасной разработки.
🔥5👍1🙏1🤝1
Как оценить возможности ИИ в обнаружении уязвимостей?
Мы наблюдали споры о том, способен ли ИИ автономно искать уязвимости. Затем разбирались, в каких именно этапах поиска багов исследователь может повысить свою эффективность с помощью ИИ.
При оценке эффективности моделей есть задача в выборе правильной методологии оценки. Пока еще нет единственного универсального подхода к проведению оценки, исследователи закрывают этот проблем различными бенчмарками и фреймворками. Помимо рассмотренной методики от Google, есть еще две свежих работы в этом направлении:
* eyeballvul - методика оценки способностей LLM искать уязвимости в широком контексте (например, в целом репозитории кода). Автор взял более 5000 репозиториев, в которых содержится более 24000 уязвимостей, и на этой базе предложил методику оценки. База обновляется еженедельно.
* LLM4Vuln - фреймворк для оценки способностей LLM дополнять информацию об уязвимостях новыми данными (например, получение дополнительной информации о контексте).
Принимаем мысль, что LLM пока что может использоваться исключительно в качестве ассистента для исследователя, и доводим модели до совершенства в узкоспециализированных сценариях. Фреймворки и бенчмарки в помощь.
Мы наблюдали споры о том, способен ли ИИ автономно искать уязвимости. Затем разбирались, в каких именно этапах поиска багов исследователь может повысить свою эффективность с помощью ИИ.
При оценке эффективности моделей есть задача в выборе правильной методологии оценки. Пока еще нет единственного универсального подхода к проведению оценки, исследователи закрывают этот проблем различными бенчмарками и фреймворками. Помимо рассмотренной методики от Google, есть еще две свежих работы в этом направлении:
* eyeballvul - методика оценки способностей LLM искать уязвимости в широком контексте (например, в целом репозитории кода). Автор взял более 5000 репозиториев, в которых содержится более 24000 уязвимостей, и на этой базе предложил методику оценки. База обновляется еженедельно.
* LLM4Vuln - фреймворк для оценки способностей LLM дополнять информацию об уязвимостях новыми данными (например, получение дополнительной информации о контексте).
Принимаем мысль, что LLM пока что может использоваться исключительно в качестве ассистента для исследователя, и доводим модели до совершенства в узкоспециализированных сценариях. Фреймворки и бенчмарки в помощь.
👍7✍2🔥2🤣1
Тишина в канале - значит, идет оффлайн-исследование. Где-то на Кольском полуострове.
9 дней без связи для того, чтобы продолжить поиск идеального спорта для ИТшника и выяснить ключевые навыки для успешной ловли на спиннинг:
* Стратегическое планирование: определить список мест для ловли с берега и в акватории, составить маршрут продвижения. Лучше такой, чтобы не пришлось нырять или сплавляться по реке.
* Тактическое планирование: подготовить снасти и экипировку для данного маршрута. Точно пригодятся вейдерсы. А правильно подобранная «полезная нагрузка» определят успех мероприятия в конкретном месте и конкретную погоду.
* Умение фаззить те самые места, где обитает хищник: забрасывать снасть так, чтобы не зацепиться за ветку или камень, и не отправиться в неуправляемый заплыв к ближайшему водопаду.
Результаты фишинга: сломанный спиннинг, потраченные ботинки для вейдерсов, 4 вида пойманных хищников.
9 дней без связи для того, чтобы продолжить поиск идеального спорта для ИТшника и выяснить ключевые навыки для успешной ловли на спиннинг:
* Стратегическое планирование: определить список мест для ловли с берега и в акватории, составить маршрут продвижения. Лучше такой, чтобы не пришлось нырять или сплавляться по реке.
* Тактическое планирование: подготовить снасти и экипировку для данного маршрута. Точно пригодятся вейдерсы. А правильно подобранная «полезная нагрузка» определят успех мероприятия в конкретном месте и конкретную погоду.
* Умение фаззить те самые места, где обитает хищник: забрасывать снасть так, чтобы не зацепиться за ветку или камень, и не отправиться в неуправляемый заплыв к ближайшему водопаду.
Результаты фишинга: сломанный спиннинг, потраченные ботинки для вейдерсов, 4 вида пойманных хищников.
🔥17👍4❤2👾1
Платформа разработки - зачем?
В 2023 году аналитики Gartner разогнали идею Platform Engineering, и уже в 2024 крупные компании с мульти-продуктовым портфелем начали трансформировать свои команды разработки в «платформу». Чуть позже к кому-то прийдет идея сделать security-платформу из специалистов, которые обеспечивают безопасность процессов разработки.
Зачем создавать группы, которые унифицируют процессы, называть их «Platform Engineering Team» и в итоге получать команду разработки, которая один в один похожа на команду конкурента? Есть ли бизнес-причины для повторения одних и тех же технологических решений?
Специфичные для конкретного бизнеса проблемы требуют уникальных решений. Платформа должна создаваться для работы над подобными задачами. Для решения всех остальных проблем есть более короткие и дешевые пути. Примеры исключительных сценариев, когда бизнесу действительно нужно повторить опыт конкурента и создать свою платформу разработки:
* случай, когда бизнес может создать платформу дешевле, чем предлагают поставщики;
* когда у поставщиков есть проблемы с качеством и безопасностью, с которыми бизнес не может мириться;
* единственный поставщик платформы - это конкурент, которому не хочется отдавать деньги;
* продукт поставщика не может масштабироваться под инфраструктуру бизнеса;
* есть риск, что бизнес привяжется к одному поставщику и в будущем сильно будет от него зависеть.
Если в стратегии развития ИТ-инфраструктуры бизнеса нет ни одного из перечисленных сценариев, то не нужно изобретать велосипед и создавать команду Platform Engineering, которая не создаст ни одной инновации.
В 2023 году аналитики Gartner разогнали идею Platform Engineering, и уже в 2024 крупные компании с мульти-продуктовым портфелем начали трансформировать свои команды разработки в «платформу». Чуть позже к кому-то прийдет идея сделать security-платформу из специалистов, которые обеспечивают безопасность процессов разработки.
Зачем создавать группы, которые унифицируют процессы, называть их «Platform Engineering Team» и в итоге получать команду разработки, которая один в один похожа на команду конкурента? Есть ли бизнес-причины для повторения одних и тех же технологических решений?
Специфичные для конкретного бизнеса проблемы требуют уникальных решений. Платформа должна создаваться для работы над подобными задачами. Для решения всех остальных проблем есть более короткие и дешевые пути. Примеры исключительных сценариев, когда бизнесу действительно нужно повторить опыт конкурента и создать свою платформу разработки:
* случай, когда бизнес может создать платформу дешевле, чем предлагают поставщики;
* когда у поставщиков есть проблемы с качеством и безопасностью, с которыми бизнес не может мириться;
* единственный поставщик платформы - это конкурент, которому не хочется отдавать деньги;
* продукт поставщика не может масштабироваться под инфраструктуру бизнеса;
* есть риск, что бизнес привяжется к одному поставщику и в будущем сильно будет от него зависеть.
Если в стратегии развития ИТ-инфраструктуры бизнеса нет ни одного из перечисленных сценариев, то не нужно изобретать велосипед и создавать команду Platform Engineering, которая не создаст ни одной инновации.
👍5🔥3🤣2
Побег из контейнера: обзор техник
Исследователи Unit42 собрали актуальные техники побега из контейнеров и подготовили обзор. Инженеры DevOps и аналитики Blue Team забирают этот материал в свою коллекцию для защиты облачных сред.
В материале рассмотрены системы контейнеризации на основе изоляции пользовательского пространства (user-space), и техники не применимы для систем, которые работают на основе виртуализации. Почти все рассмотренные атаки используют два базовых механизма Linux: capabilities и namespaces.
Атрибут capabilities определяет набор действий, которые процесс может выполнить в системе. Атрибут namespaces определяет набор ресурсов, с которыми может работать процесс. Другими словами, capabilities определяет что процесс может сделать в контейнере, а namespaces - где процесс может выполнять эти действия.
Используя неправильные конфигурации этих атрибутов, атакующий может не только выполнять свои процессы в основной операционной системе (которая управляет контейнером) или читать там ценные данные, но повышать свои привилегии внутри контейнера.
Исследователи Unit42 собрали актуальные техники побега из контейнеров и подготовили обзор. Инженеры DevOps и аналитики Blue Team забирают этот материал в свою коллекцию для защиты облачных сред.
В материале рассмотрены системы контейнеризации на основе изоляции пользовательского пространства (user-space), и техники не применимы для систем, которые работают на основе виртуализации. Почти все рассмотренные атаки используют два базовых механизма Linux: capabilities и namespaces.
Атрибут capabilities определяет набор действий, которые процесс может выполнить в системе. Атрибут namespaces определяет набор ресурсов, с которыми может работать процесс. Другими словами, capabilities определяет что процесс может сделать в контейнере, а namespaces - где процесс может выполнять эти действия.
Используя неправильные конфигурации этих атрибутов, атакующий может не только выполнять свои процессы в основной операционной системе (которая управляет контейнером) или читать там ценные данные, но повышать свои привилегии внутри контейнера.
👍7🔥1🤔1😱1
Критическая уязвимость в сетевом стеке Windows
Критическая проблема обнаружена в парсере IPv6 ядра Windows и позволяет злоумышленникам удаленно выполнить произвольный код без какого-либо взаимодействия с пользователем.
Похоже, что локальный файрволл не поможет, потому что разбор вредоносного IPv6-пакета происходит до его попадания к встроенному средству защиты.
Уязвимы все поддерживаемые версии Windows. Ставим обновления.⚡️
Критическая проблема обнаружена в парсере IPv6 ядра Windows и позволяет злоумышленникам удаленно выполнить произвольный код без какого-либо взаимодействия с пользователем.
Похоже, что локальный файрволл не поможет, потому что разбор вредоносного IPv6-пакета происходит до его попадания к встроенному средству защиты.
Уязвимы все поддерживаемые версии Windows. Ставим обновления.
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡3👾3🔥2
Платформа разработки: гайдлайны
Тому, кто ответил на вопрос «зачем?» нужна своя платформа, и решил трансформировать свои процессы, инструменты и команду в Платформу Разработки, предстоит определиться с подходом и ответить на вопрос «как?».
Заряжаемся материалами, в которых утверждается, что методология ускоряет производство продуктов и снижает когнитивную нагрузку на разработчика. Затем погружаемся в создание Internal Developer Platform:
Этап 1: разработчики бизнес-функций работают с Платформой как клиенты с витриной в магазине - обслуживают сами себя. Поэтому определяем путь разработчика «от запроса до результата», разделяем этот путь на функциональные слои и собираем технологии, которые помогут этот путь пройти.
Этап 2: создаем референсную архитектуру.
Этап 3: описываем MVP (Minimum Viable Platform).
Этап 4: определяем роли и экспертов для команды разработки.
И не забываем про Этап 0.
Тому, кто ответил на вопрос «зачем?» нужна своя платформа, и решил трансформировать свои процессы, инструменты и команду в Платформу Разработки, предстоит определиться с подходом и ответить на вопрос «как?».
Заряжаемся материалами, в которых утверждается, что методология ускоряет производство продуктов и снижает когнитивную нагрузку на разработчика. Затем погружаемся в создание Internal Developer Platform:
Этап 1: разработчики бизнес-функций работают с Платформой как клиенты с витриной в магазине - обслуживают сами себя. Поэтому определяем путь разработчика «от запроса до результата», разделяем этот путь на функциональные слои и собираем технологии, которые помогут этот путь пройти.
Этап 2: создаем референсную архитектуру.
Этап 3: описываем MVP (Minimum Viable Platform).
Этап 4: определяем роли и экспертов для команды разработки.
И не забываем про Этап 0.
👍3🔥1
Доступ к данным из удаленных и приватных репозиториев GitHub
Когда одна ветка репозитория позволяет получить ценные данные из другой удаленной или приватной ветки, мы имеем дело с новым вектором атаки: Cross Fork Object Reference (CFOR).
По аналогии с уязвимостями Insecure Direct Object Reference (небезопасные прямые ссылки на объект), атакующий использует хэши коммитов, чтобы напрямую получить доступ к данным в этих коммитах. Даже если коммит содержится в удаленном или приватном репозитории. Атакующему остается только узнать хэш коммита. Как?
GitHub позволяет использовать короткие значения хэшей SHA-1, которые можно просто подобрать методом простого перебора. К примеру, вместо длинной ссылки:
Можно использовать короткую ссылку:
где
GitHub в курсе данной проблемы и не планирует исправление, потому что это не баг, а фича.
Когда одна ветка репозитория позволяет получить ценные данные из другой удаленной или приватной ветки, мы имеем дело с новым вектором атаки: Cross Fork Object Reference (CFOR).
По аналогии с уязвимостями Insecure Direct Object Reference (небезопасные прямые ссылки на объект), атакующий использует хэши коммитов, чтобы напрямую получить доступ к данным в этих коммитах. Даже если коммит содержится в удаленном или приватном репозитории. Атакующему остается только узнать хэш коммита. Как?
GitHub позволяет использовать короткие значения хэшей SHA-1, которые можно просто подобрать методом простого перебора. К примеру, вместо длинной ссылки:
github.com/<user>/<repo>/commit/
07f01e8337c1073d2c45bb12d688170fcd44c637Можно использовать короткую ссылку:
github.com/<user>/<repo>/commit/07f01eгде
07f01e - короткий хэш. Его можно подобрать через пользовательский интерфейс GitHub. А уже после получения доступа к коммитам, атакующий приступает к поиску секретов.GitHub в курсе данной проблемы и не планирует исправление, потому что это не баг, а фича.
🔥4👍2👾2
ИИ ассистент для security-аналитика
Продолжаем собирать и применять сценарии использования ИИ для задач безопасности. Новый кейс использования для разработки правил выявления угроз:
* Аналитик загружает в LLM техники атак, описанные в формате блогпоста или отчета об угрозе.
* В запросе к LLM аналитик указывает синтаксис, в котором должно быть описано правило детекта.
* Модель генерирует правила детекта. Некоторые правила могут иметь неправильный синтаксис или быть результатом галлюцинации. Аналитик выявляет некорректные правила и корректирует свой запрос (промпт).
Самый ресурсоемкий для аналитика этап - это составление точного промпта. Поэтому важно отработать навык prompt engineering.
Так как написание правил - это процесс, который зачастую происходит в свободное от обработки инцидентов время, то данный сценарий залетает в бэклог к лидеру Security Operations.
Продолжаем собирать и применять сценарии использования ИИ для задач безопасности. Новый кейс использования для разработки правил выявления угроз:
* Аналитик загружает в LLM техники атак, описанные в формате блогпоста или отчета об угрозе.
* В запросе к LLM аналитик указывает синтаксис, в котором должно быть описано правило детекта.
* Модель генерирует правила детекта. Некоторые правила могут иметь неправильный синтаксис или быть результатом галлюцинации. Аналитик выявляет некорректные правила и корректирует свой запрос (промпт).
Самый ресурсоемкий для аналитика этап - это составление точного промпта. Поэтому важно отработать навык prompt engineering.
Так как написание правил - это процесс, который зачастую происходит в свободное от обработки инцидентов время, то данный сценарий залетает в бэклог к лидеру Security Operations.
5👍2🔥2
Подборка исследований с Black Hat 2024
В августе прошли крупнейшие ИБ-мероприятия, и уже можно встретить обзоры наиболее «громких» исследований с точки зрения медиа.
Возьмем доклады Black Hat, изучим материалы и самостоятельно выделим перспективные направления. Моя подборка:
* “From Weapon to Target: Quantum Computers Paradox” - исследование вопросов безопасности квантовых компьютеров и процесса квантовых вычислений. Несмотря на активное обсуждение влияния квантовых вычислений на классическую криптографию, вопросы безопасности самих квантовых систем остаются малоизученными. Авторы анализируют уязвимости и возможные векторы атак на квантовые вычислительные инфраструктуры, включая программное обеспечение и облачные сервисы. Примеры выявленных проблем: кража токенов аутентификации, изменение квантовых цепочек программ в SDK, а также атаки на квантовые процессоры.
* “SnailLoad: Anyone on the Internet Can Learn What You're Doing” - интересная техника составления профиля пользователя без каких-либо вспомогательных инструментов посередине (без агентов на его рабочей станции или прокси-серверов в его сети). Канал утечки данных находится в задержках сети, которые появляются, когда пользователь взаимодействует с онлайн-контентом. Анализируя эти задержки, злоумышленник может точно определить действия пользователя, что может привести к раскрытию конфиденциальной информации и деанонимизации. Эта техника подчеркивает уязвимость даже защищенных сессий браузера перед сложными атаками на основе временных характеристик (timing-атаки).
* “Listen to the Whispers: Web Timing Attacks that Actually Work” - и еще одно исследование timing-атак, но уже в контексте безопасности веб-приложений. Приведены примеры ситуаций, когда атакуемая система раскрывает конфиденциальные данные из-за разных временных задержек при обработке запросов. Техника пригодится для обнаружения скрытой поверхности атаки и определения некорректных настроек прокси-серверов.
* “Deep Backdoors in Deep Reinforcement Learning Agents” - техника интеграции «вредоносных нейронов» в нейронную сеть. В исследовании описаны сценарии компрометации ИИ-агентов на этапе их обучения и последствия неправильных решений, которые эти агенты могут принимать в промышленности, автономном транспорте и кибербезопасности.
⭐️ Подборка исследований Black Hat 2023.
#дайджест @makrushin
В августе прошли крупнейшие ИБ-мероприятия, и уже можно встретить обзоры наиболее «громких» исследований с точки зрения медиа.
Возьмем доклады Black Hat, изучим материалы и самостоятельно выделим перспективные направления. Моя подборка:
* “From Weapon to Target: Quantum Computers Paradox” - исследование вопросов безопасности квантовых компьютеров и процесса квантовых вычислений. Несмотря на активное обсуждение влияния квантовых вычислений на классическую криптографию, вопросы безопасности самих квантовых систем остаются малоизученными. Авторы анализируют уязвимости и возможные векторы атак на квантовые вычислительные инфраструктуры, включая программное обеспечение и облачные сервисы. Примеры выявленных проблем: кража токенов аутентификации, изменение квантовых цепочек программ в SDK, а также атаки на квантовые процессоры.
* “SnailLoad: Anyone on the Internet Can Learn What You're Doing” - интересная техника составления профиля пользователя без каких-либо вспомогательных инструментов посередине (без агентов на его рабочей станции или прокси-серверов в его сети). Канал утечки данных находится в задержках сети, которые появляются, когда пользователь взаимодействует с онлайн-контентом. Анализируя эти задержки, злоумышленник может точно определить действия пользователя, что может привести к раскрытию конфиденциальной информации и деанонимизации. Эта техника подчеркивает уязвимость даже защищенных сессий браузера перед сложными атаками на основе временных характеристик (timing-атаки).
* “Listen to the Whispers: Web Timing Attacks that Actually Work” - и еще одно исследование timing-атак, но уже в контексте безопасности веб-приложений. Приведены примеры ситуаций, когда атакуемая система раскрывает конфиденциальные данные из-за разных временных задержек при обработке запросов. Техника пригодится для обнаружения скрытой поверхности атаки и определения некорректных настроек прокси-серверов.
* “Deep Backdoors in Deep Reinforcement Learning Agents” - техника интеграции «вредоносных нейронов» в нейронную сеть. В исследовании описаны сценарии компрометации ИИ-агентов на этапе их обучения и последствия неправильных решений, которые эти агенты могут принимать в промышленности, автономном транспорте и кибербезопасности.
#дайджест @makrushin
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥5🥱2
Вместе с командой ИУ10 МГТУ им. Баумана мы накатили обновление в образовательную программу кафедры «Защита информации» и подготовили проект, который добавит разработчику новые суперспособности.
Перевернем календарь и запустим трансформацию⚡️
Перевернем календарь и запустим трансформацию
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🔥8❤5🤪1
Запуск security-проекта: шаблоны и чеклисты для быстрого старта
Встретил полезный ресурс с шаблонами для запуска security-проектов. Программа багбаунти, тестирование на проникновение, процедуры реагирования на инциденты и управления уязвимостями - документы пригодятся новой команде безопасности, владельцу продукта или начинающему CISO в каком-нибудь стартапе.
В репозитории содержатся:
* чеклисты для подготовки к запуску;
* описание процессов и плейбуки;
* примеры метрик и шаблоны документов.
Встретил полезный ресурс с шаблонами для запуска security-проектов. Программа багбаунти, тестирование на проникновение, процедуры реагирования на инциденты и управления уязвимостями - документы пригодятся новой команде безопасности, владельцу продукта или начинающему CISO в каком-нибудь стартапе.
В репозитории содержатся:
* чеклисты для подготовки к запуску;
* описание процессов и плейбуки;
* примеры метрик и шаблоны документов.
❤2✍1👍1