🧠⚛️ Квантовый ИИ против кибератак: хайп или рабочий инструмент?
Когда говорят о квантовых вычислениях в кибербезопасности, обычно рисуют две крайности:
🔮 «Квантовый компьютер взломает всё»
или
😒 «Это бесполезная игрушка для физиков»
Но что если квантовые технологии уже сейчас могут чуть-чуть, но стабильно улучшать детектирование атак в реалистичных условиях?
🎯 Проблематика SOC
Современные системы детектирования атак живут в крайне нестабильной среде:
📉 Дрейф данных: сетевой трафик и поведение пользователей постоянно меняются
⚖️ Дисбаланс классов: атак мало, легитимных событий много
🎭 Пограничные случаи: атака выглядит почти как нормальное поведение
🧱 Жёсткие бюджеты: по признакам, latency и вычислениям
Даже хорошо настроенные ML-модели пропускают редкие атаки или начинают генерировать ложные срабатывания.
Ключевой вопрос:
👉 Можно ли улучшить границу принятия решений, не раздувая модель и инфраструктуру?
⚛️ Квантовая польза
Важное уточнение:
❌ квантовые компьютеры не ускоряют ML «в лоб»
❌ они не заменяют нейросети
❌ они шумные, маленькие и ограниченные
Но у них есть одно интересное свойство 👇
Квантовые схемы умеют строить очень сложную геометрию разделяющей поверхности, используя минимальное число параметров и крайне компактное представление признаков. Для этого требуется всего несколько кубитов.
И дело не в скорости, а в форме decision boundary.
🧩 Архитектура
Вместо попытки «засунуть всё в квантовый компьютер» можно использовать гибридный подход:
🔹 Шаг 1. Классический ML
Компактная классическая модель:
- сжимает исходные данные
- устраняет шум
- формирует низкоразмерное, устойчивое представление
💡 Квантовая часть получает уже осмысленные признаки.
🔹 Шаг 2. Квантовая «голова» (2–4 кубита)
Дальше возможны два сценария.
🧠 Квантовое ядро + SVM
- квантовая схема строит нелинейное ядро
- классический SVM ищет оптимальную границу
- квантовая часть не обучается
- высокая стабильность и низкая чувствительность к шуму
🧪 Обучаемый квантовый классификатор
- параметризованная квантовая схема
обучается вместе с классической частью
- больше выразительности
выше риск нестабильности и деградации
📊 Что дают квантовые модели на практике
Квантовые модели:
❌ не уничтожают классические
❌ не дают кратного прироста accuracy
Но:
✅ лучше ведут себя на пограничных случаях
✅ чуть реже пропускают редкие атаки
✅ чуть меньше ложных срабатываний
✅ сохраняют компактность модели
Учитываем простоту:
- несколько кубитов
с неглубокими схемами
- нет роста числа признаков
🧠 Подведём итоги
1️⃣ Квантовый ML уже можно рассматривать как узкоспециализированный модуль, а не игрушку
2️⃣ Он полезен точечно, а не повсеместно:
- редкие атаки
- сложные границы
- строгие ресурсные ограничения
3️⃣ Гибридная архитектура обязательна
4️⃣ Фиксированные квантовые ядра сейчас практичнее, чем полностью обучаемые схемы
🔗 Больше подробностей можно найти в статье.
Stay secure and read SecureTechTalks 📚
#кибербезопасность
#quantumML
#машинноеобучение
#информационнаябезопасность
#IDS
#SOC
#AIsecurity
#квантовыевычисления
#anomalydetection
#SecureTechTalks
Когда говорят о квантовых вычислениях в кибербезопасности, обычно рисуют две крайности:
🔮 «Квантовый компьютер взломает всё»
или
😒 «Это бесполезная игрушка для физиков»
Но что если квантовые технологии уже сейчас могут чуть-чуть, но стабильно улучшать детектирование атак в реалистичных условиях?
🎯 Проблематика SOC
Современные системы детектирования атак живут в крайне нестабильной среде:
📉 Дрейф данных: сетевой трафик и поведение пользователей постоянно меняются
⚖️ Дисбаланс классов: атак мало, легитимных событий много
🎭 Пограничные случаи: атака выглядит почти как нормальное поведение
🧱 Жёсткие бюджеты: по признакам, latency и вычислениям
Даже хорошо настроенные ML-модели пропускают редкие атаки или начинают генерировать ложные срабатывания.
Ключевой вопрос:
👉 Можно ли улучшить границу принятия решений, не раздувая модель и инфраструктуру?
⚛️ Квантовая польза
Важное уточнение:
❌ квантовые компьютеры не ускоряют ML «в лоб»
❌ они не заменяют нейросети
❌ они шумные, маленькие и ограниченные
Но у них есть одно интересное свойство 👇
Квантовые схемы умеют строить очень сложную геометрию разделяющей поверхности, используя минимальное число параметров и крайне компактное представление признаков. Для этого требуется всего несколько кубитов.
И дело не в скорости, а в форме decision boundary.
🧩 Архитектура
Вместо попытки «засунуть всё в квантовый компьютер» можно использовать гибридный подход:
🔹 Шаг 1. Классический ML
Компактная классическая модель:
- сжимает исходные данные
- устраняет шум
- формирует низкоразмерное, устойчивое представление
💡 Квантовая часть получает уже осмысленные признаки.
🔹 Шаг 2. Квантовая «голова» (2–4 кубита)
Дальше возможны два сценария.
🧠 Квантовое ядро + SVM
- квантовая схема строит нелинейное ядро
- классический SVM ищет оптимальную границу
- квантовая часть не обучается
- высокая стабильность и низкая чувствительность к шуму
🧪 Обучаемый квантовый классификатор
- параметризованная квантовая схема
обучается вместе с классической частью
- больше выразительности
выше риск нестабильности и деградации
📊 Что дают квантовые модели на практике
Квантовые модели:
❌ не уничтожают классические
❌ не дают кратного прироста accuracy
Но:
✅ лучше ведут себя на пограничных случаях
✅ чуть реже пропускают редкие атаки
✅ чуть меньше ложных срабатываний
✅ сохраняют компактность модели
Учитываем простоту:
- несколько кубитов
с неглубокими схемами
- нет роста числа признаков
🧠 Подведём итоги
1️⃣ Квантовый ML уже можно рассматривать как узкоспециализированный модуль, а не игрушку
2️⃣ Он полезен точечно, а не повсеместно:
- редкие атаки
- сложные границы
- строгие ресурсные ограничения
3️⃣ Гибридная архитектура обязательна
4️⃣ Фиксированные квантовые ядра сейчас практичнее, чем полностью обучаемые схемы
🔗 Больше подробностей можно найти в статье.
Stay secure and read SecureTechTalks 📚
#кибербезопасность
#quantumML
#машинноеобучение
#информационнаябезопасность
#IDS
#SOC
#AIsecurity
#квантовыевычисления
#anomalydetection
#SecureTechTalks
👍1
🤖📊 Отчёт CSA: AI Governance, как фактор выживания
В 2025 году организации уже не просто пробуют ИИ, а внедряют его в продакшн.
Проблема в том, что скорость внедрения ИИ сильно опережает зрелость AI Governance.
CSA выпустили новый отчет, который основан на глобальном опросе IT- и ИБ-профессионалов (≈300 организаций), которых спрашивали не только о технологиях, но и о структурах AI Governance, ответственности за AI-риски и уровне подготовки команд.
Главный вывод исследования:
👉 Зрелый AI Governance самый сильный предиктор готовности компании к безопасному внедрению ИИ.
Не важно какой размер или бюджет у вашей компании. Важно иметь зрелый Governance.
📈 1. Множитель зрелости
Что такое зрелый AI Governance на практике?
Это рабочая система управления, которая включает:
- чёткие роли и зоны ответственности,
- политики использования ИИ,
- контроль жизненного цикла моделей,
- процедуры оценки рисков,
обучение сотрудников.
🔥 Согласно отчёту, организации с формализованным AI Governance:
в 2 раза чаще внедряют agentic AI, чаще проводят security-оценку моделей,
говорят о способности управлять AI-рисками.
Компании, где Governance «в процессе развития», стабильно проигрывают по всем этим параметрам.
🛡️ 2. Безопасность ИИ
CSA подчёркивает ключевую мысль:
Без AI Governance невозможно:
- понять, где именно используется ИИ,
- определить, кто отвечает за последствия его работы,
- встроить AI-риски в общую систему управления ИБ.
🧑💼 3. Shadow AI
Отдельный тревожный сигнал - Shadow AI.
Сотрудники используют внешние ИИ-сервисы без согласования и контроля.
Это приводит к:
⚠️ утечкам данных,
⚠️ невозможности аудита,
⚠️ регуляторным рискам.
Именно зрелый AI Governance позволяет превратить хаотичное использование ИИ в контролируемый и безопасный процесс, не убивая инновации.
👨💼 4. Кадровый разрыв
ИИ внедряется быстро, а навыки сотрудников медленно.
Отчёт фиксирует:
нехватку специалистов по AI Security и слабую подготовку ИБ-команд. Возникает разрыв между стратегией и реальными процессами.
Организации с развитым AI Governance:
в 2–3 раза чаще обучают сотрудников, интегрируют AI-риски в SDLC, переводят знания в практику.
📊 5. Какие риски беспокоят компании больше всего?
По данным опроса:
🔹 №1 риск утечки данных через AI-сервисы
🔹 Модельные атаки и отравление данных воспринимаются как второстепенные
Компании недооценивают сложные и долгосрочные AI-угрозы.
🔁 AI Security больше не «поддержка», а драйвер
Интересный сдвиг:
👉 ИБ-команды больше не догоняют ИИ, они начинают его возглавлять.
Более 90% специалистов:
тестируют ИИ для threat detection, используют ИИ в red teaming, автоматизируют SOC-процессы.
AI Governance становится не тормозом, а инструментом масштабирования безопасности.
🔗 Отчет Cloud Security Alliance "The State of AI Security and Governance Survey Report (2025)"
Stay secure and read SecureTechTalks 📚
#AIsecurity #AIGovernance #CyberSecurity #AIrisks #SecureTechTalks #CloudSecurity #AgenticAI #ShadowAI #CyberTrends2025
В 2025 году организации уже не просто пробуют ИИ, а внедряют его в продакшн.
Проблема в том, что скорость внедрения ИИ сильно опережает зрелость AI Governance.
CSA выпустили новый отчет, который основан на глобальном опросе IT- и ИБ-профессионалов (≈300 организаций), которых спрашивали не только о технологиях, но и о структурах AI Governance, ответственности за AI-риски и уровне подготовки команд.
Главный вывод исследования:
👉 Зрелый AI Governance самый сильный предиктор готовности компании к безопасному внедрению ИИ.
Не важно какой размер или бюджет у вашей компании. Важно иметь зрелый Governance.
📈 1. Множитель зрелости
Что такое зрелый AI Governance на практике?
Это рабочая система управления, которая включает:
- чёткие роли и зоны ответственности,
- политики использования ИИ,
- контроль жизненного цикла моделей,
- процедуры оценки рисков,
обучение сотрудников.
🔥 Согласно отчёту, организации с формализованным AI Governance:
в 2 раза чаще внедряют agentic AI, чаще проводят security-оценку моделей,
говорят о способности управлять AI-рисками.
Компании, где Governance «в процессе развития», стабильно проигрывают по всем этим параметрам.
🛡️ 2. Безопасность ИИ
CSA подчёркивает ключевую мысль:
AI Security - это не только защита данных или моделей.
Это управление процессами, людьми и ответственностью.
Без AI Governance невозможно:
- понять, где именно используется ИИ,
- определить, кто отвечает за последствия его работы,
- встроить AI-риски в общую систему управления ИБ.
🧑💼 3. Shadow AI
Отдельный тревожный сигнал - Shadow AI.
Сотрудники используют внешние ИИ-сервисы без согласования и контроля.
Это приводит к:
⚠️ утечкам данных,
⚠️ невозможности аудита,
⚠️ регуляторным рискам.
Именно зрелый AI Governance позволяет превратить хаотичное использование ИИ в контролируемый и безопасный процесс, не убивая инновации.
👨💼 4. Кадровый разрыв
ИИ внедряется быстро, а навыки сотрудников медленно.
Отчёт фиксирует:
нехватку специалистов по AI Security и слабую подготовку ИБ-команд. Возникает разрыв между стратегией и реальными процессами.
Организации с развитым AI Governance:
в 2–3 раза чаще обучают сотрудников, интегрируют AI-риски в SDLC, переводят знания в практику.
📊 5. Какие риски беспокоят компании больше всего?
По данным опроса:
🔹 №1 риск утечки данных через AI-сервисы
🔹 Модельные атаки и отравление данных воспринимаются как второстепенные
Компании недооценивают сложные и долгосрочные AI-угрозы.
🔁 AI Security больше не «поддержка», а драйвер
Интересный сдвиг:
👉 ИБ-команды больше не догоняют ИИ, они начинают его возглавлять.
Более 90% специалистов:
тестируют ИИ для threat detection, используют ИИ в red teaming, автоматизируют SOC-процессы.
AI Governance становится не тормозом, а инструментом масштабирования безопасности.
🔗 Отчет Cloud Security Alliance "The State of AI Security and Governance Survey Report (2025)"
Stay secure and read SecureTechTalks 📚
#AIsecurity #AIGovernance #CyberSecurity #AIrisks #SecureTechTalks #CloudSecurity #AgenticAI #ShadowAI #CyberTrends2025
👍1
💥 La Poste под DDoS: как «трафик» положил национальную почту Франции
18–19 декабря 2025 года. Предновогодний пик. Миллионы посылок в пути, платежи, мобильное приложение, курьеры на самокатах. Что может пойти не так?
ВСЁ Инфраструктура французской госпочты La Poste в самый неподходящий момент начинает сыпаться.
Сначала ошибки в трекинге и недоступные платежи, потом полный абзац: недоступность мобильного приложения и внутренних системы курьеров.
⏱️ 18+ часов простоя
👥 2+ млн пользователей
📦 ~1,5 млн задержанных отправлений
💸 €12–15 млн прямого ущерба
Вот так злоумышленники поздравляют с наступающими праздниками 😱
🧠 Механика атаки
Атака состояла из двух слоёв, комбинация которых оказалась фатальной.
🌊 Первый слой L3/L4
➖ NTP / DNS / SSDP amplification
➖ SYN/ACK floods с IP spoofing
➖ ботнет из ~200 тыс. IoT-устройств
➖ пиковая нагрузка ≈ 620 Gbps
Firewall’ы и edge-устройства начали терять состояние соединений ещё до того, как трафик дошёл до приложений.
🧬 Второй слой L7
➖ HTTP/2 Slow POST / GET
➖ Slowloris / RUDY
➖ cache busting
➖ атаки через WebSocket
Трафика было немного, но:
соединения держались десятки секунд, worker pools истощались, а event loop’ы блокировались.
📉 В результате 503 на почти все запросы, даже при «нормальном» входящем объёме.
🕵️ Что пошло не так у La Poste?
Из открытых данных и утечек в профильных медиа вырисовывается картина системных проблем:
❌ не было always-on DDoS scrubbing
❌ трафик шёл напрямую на origin
❌ отсутствовал Anycast и BGP-очистка
❌ load balancer стал узким местом
❌ API перегрузили backend и базы данных
❌ мониторинг не отработал аномалию вовремя
Один перегруженный слой запустил каскадный отказ всей цепочки сервисов, почти, как снежный ком...
🇷🇺 В РФ такое невозможно?
Если заменить La Poste на Почту России, СДЭК, Boxberry, Ozon / Wildberries то по факту архитектурный риск останется тем же:
➖ публичные /track и /status
➖ сезонные пики (особенно Q4)
➖ дешёвые DDoS-for-hire сервисы
По статистике провайдеров защиты, в четвёртом квартале DDoS-активность растёт в 3–4 раза, и атакуют именно логистику и e-commerce.
🧠 Мысли вслух
Современный DDoS является инструментом точечного удушения бизнеса в самые чувствительные моменты. Он дешёвый для атакующего, дорогой для компании и особенно опасен для high-traffic инфраструктур.
🔗 Источники
SecurityWeek — https://www.securityweek.com
Breached / Digital Siege — https://breached.company/seven-days-of-digital-siege-inside-this-weeks-ransomware-explosion/
Stay secure and read SecureTechTalks 📚
#DDoS #LaPoste #CyberSecurity #SecureTechTalks #InfoSec #DDoSProtection #SOC #InfrastructureSecurity #EcommerceSecurity #IncidentResponse
18–19 декабря 2025 года. Предновогодний пик. Миллионы посылок в пути, платежи, мобильное приложение, курьеры на самокатах. Что может пойти не так?
Сначала ошибки в трекинге и недоступные платежи, потом полный абзац: недоступность мобильного приложения и внутренних системы курьеров.
⏱️ 18+ часов простоя
👥 2+ млн пользователей
📦 ~1,5 млн задержанных отправлений
💸 €12–15 млн прямого ущерба
Вот так злоумышленники поздравляют с наступающими праздниками 😱
🧠 Механика атаки
Атака состояла из двух слоёв, комбинация которых оказалась фатальной.
🌊 Первый слой L3/L4
Firewall’ы и edge-устройства начали терять состояние соединений ещё до того, как трафик дошёл до приложений.
🧬 Второй слой L7
Трафика было немного, но:
соединения держались десятки секунд, worker pools истощались, а event loop’ы блокировались.
📉 В результате 503 на почти все запросы, даже при «нормальном» входящем объёме.
🕵️ Что пошло не так у La Poste?
Из открытых данных и утечек в профильных медиа вырисовывается картина системных проблем:
❌ не было always-on DDoS scrubbing
❌ трафик шёл напрямую на origin
❌ отсутствовал Anycast и BGP-очистка
❌ load balancer стал узким местом
❌ API перегрузили backend и базы данных
❌ мониторинг не отработал аномалию вовремя
Один перегруженный слой запустил каскадный отказ всей цепочки сервисов, почти, как снежный ком...
🇷🇺 В РФ такое невозможно?
Если заменить La Poste на Почту России, СДЭК, Boxberry, Ozon / Wildberries то по факту архитектурный риск останется тем же:
По статистике провайдеров защиты, в четвёртом квартале DDoS-активность растёт в 3–4 раза, и атакуют именно логистику и e-commerce.
🧠 Мысли вслух
Современный DDoS является инструментом точечного удушения бизнеса в самые чувствительные моменты. Он дешёвый для атакующего, дорогой для компании и особенно опасен для high-traffic инфраструктур.
🔗 Источники
SecurityWeek — https://www.securityweek.com
Breached / Digital Siege — https://breached.company/seven-days-of-digital-siege-inside-this-weeks-ransomware-explosion/
Stay secure and read SecureTechTalks 📚
#DDoS #LaPoste #CyberSecurity #SecureTechTalks #InfoSec #DDoSProtection #SOC #InfrastructureSecurity #EcommerceSecurity #IncidentResponse
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🧠 ИИ и оценка уязвимостей: революция или скам?
Исследователи проверили, могут ли современные большие языковые модели независимо оценивать уязвимости, то есть определять их критичность по описанию.
📊 Как тестировали?
Команда прогнала 31 000+ CVE-описаний через шесть крупных LLM:
• GPT-4o
• GPT-5
• Llama 3.3
• Gemini 2.5 Flash
• DeepSeek R1
• Grok 3
❗️Модели оценивали исключительно текст описания уязвимости. Им не давали:
✔ названия продуктов,
✔ версий ПО,
✔ идентификаторы CVE,
✔ данные поставщиков
Это было сделано специально, чтобы исключить «поиск по шаблону» и заставить ИИ логически рассуждать на основе текста.
То есть задача была не просто прочитать описание, а воссоздать ключевые метрики CVSS, которые определяют приоритет реагирования на уязвимость.
🧩 Где ИИ эффективен?
Модели показали лучшие результаты там, где язык описания был прямолинейным и содержал явные сигналы:
🔹 Attack Vector (находится ли уязвимость в сети или локально). Примерно 89% точности у Gemini и GPT-5.
🔹 User Interaction (нужен ли пользовательский ввод/клик для эксплуатации). Схожие результаты.
Такие аспекты часто прямо указаны в описаниях CVE.
Кроме того:
🔸 Confidentiality Impact (угроза утечки данных) и
🔸 Integrity Impact (изменение данных)
тоже были оценены достаточно успешно. GPT-5 показывал 70+ % точности здесь.
👉 То есть когда модель видит явные сигналы в тексте, она может прилично предсказывать, что именно представляет собой уязвимость. Это может помочь аналитикам быстро отсеивать тривиальные случаи.
😬 Где ИИ слаб
Явные ограничения:
❗ Availability Impact (влияние на доступность системы). Результаты чуть ниже (≈68 % у GPT-5), потому что описания редко точно объясняют, насколько нарушение службы критично.
❗ Privileges Required (необходимые привилегии). Модели путают «отсутствие» и «низкий уровень», потому что тексты часто не содержат чётких указаний.
❗ Attack Complexity предугадывается плохо, в основном из-за перекоса данных в сторону «низкой сложности».
📌 Анализ ошибок также показал:
29 % CVE были неправильно оценены всеми моделями одновременно по Availability Impact.
В других метриках 4 из 6 моделей согласовывались в неправильных ответах до 36 % случаев, что говорит о систематической ошибке, а не случайности.
🤝 Ансамбли моделей
Исследователи попробовали объединить предсказания всех шести моделей в meta classifier. Это дало небольшие улучшения, но не решило фундаментальной проблемы:
отсутствие информации в описании всё ещё мешает точному пониманию угрозы.
🧠 Контекст наше всё
Самый важный вывод исследования:
👉 LLM могут быть полезны для предварительной оценки, но на текущий момент они не заменят человека или полноценные системы анализа контекста и метаданных.
🔗 Оригинал исследования: LLMs can assist with vulnerability scoring, but context still matters.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #AIsecurity #LLMs #CVE #VulnerabilityAssessment #CyberSecurity #Infosec #AIinSec #ThreatIntel #ContextMatters #AutomationLimits #CyberResearch
Исследователи проверили, могут ли современные большие языковые модели независимо оценивать уязвимости, то есть определять их критичность по описанию.
📊 Как тестировали?
Команда прогнала 31 000+ CVE-описаний через шесть крупных LLM:
• GPT-4o
• GPT-5
• Llama 3.3
• Gemini 2.5 Flash
• DeepSeek R1
• Grok 3
❗️Модели оценивали исключительно текст описания уязвимости. Им не давали:
✔ названия продуктов,
✔ версий ПО,
✔ идентификаторы CVE,
✔ данные поставщиков
Это было сделано специально, чтобы исключить «поиск по шаблону» и заставить ИИ логически рассуждать на основе текста.
То есть задача была не просто прочитать описание, а воссоздать ключевые метрики CVSS, которые определяют приоритет реагирования на уязвимость.
🧩 Где ИИ эффективен?
Модели показали лучшие результаты там, где язык описания был прямолинейным и содержал явные сигналы:
🔹 Attack Vector (находится ли уязвимость в сети или локально). Примерно 89% точности у Gemini и GPT-5.
🔹 User Interaction (нужен ли пользовательский ввод/клик для эксплуатации). Схожие результаты.
Такие аспекты часто прямо указаны в описаниях CVE.
Кроме того:
🔸 Confidentiality Impact (угроза утечки данных) и
🔸 Integrity Impact (изменение данных)
тоже были оценены достаточно успешно. GPT-5 показывал 70+ % точности здесь.
👉 То есть когда модель видит явные сигналы в тексте, она может прилично предсказывать, что именно представляет собой уязвимость. Это может помочь аналитикам быстро отсеивать тривиальные случаи.
😬 Где ИИ слаб
Явные ограничения:
❗ Availability Impact (влияние на доступность системы). Результаты чуть ниже (≈68 % у GPT-5), потому что описания редко точно объясняют, насколько нарушение службы критично.
❗ Privileges Required (необходимые привилегии). Модели путают «отсутствие» и «низкий уровень», потому что тексты часто не содержат чётких указаний.
❗ Attack Complexity предугадывается плохо, в основном из-за перекоса данных в сторону «низкой сложности».
📌 Анализ ошибок также показал:
29 % CVE были неправильно оценены всеми моделями одновременно по Availability Impact.
В других метриках 4 из 6 моделей согласовывались в неправильных ответах до 36 % случаев, что говорит о систематической ошибке, а не случайности.
🤝 Ансамбли моделей
Исследователи попробовали объединить предсказания всех шести моделей в meta classifier. Это дало небольшие улучшения, но не решило фундаментальной проблемы:
отсутствие информации в описании всё ещё мешает точному пониманию угрозы.
🧠 Контекст наше всё
Самый важный вывод исследования:
👉 LLM могут быть полезны для предварительной оценки, но на текущий момент они не заменят человека или полноценные системы анализа контекста и метаданных.
🔗 Оригинал исследования: LLMs can assist with vulnerability scoring, but context still matters.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #AIsecurity #LLMs #CVE #VulnerabilityAssessment #CyberSecurity #Infosec #AIinSec #ThreatIntel #ContextMatters #AutomationLimits #CyberResearch
👍2🔥1
🚀 Superagent: как защитить ваши ИИ-агенты от взлома, ошибок и утечек данных
ИИ-агенты - это движки автоматизации, RAG-конвейеры, workflow с внешними инструментами, критические бизнес-процессы. Но они имеют свои уязвимости и вектора атак, такие как:
🔓 prompt injection
⚠️ unsafe tool calls
🧠 model hallucinations
🔒 утечка PII/PHI и секретов
Сегодня мы разберём продукт Superagent, который помогает перевести риски в контролируемую среду.
🛡 Что такое Superagent?
Superagent - это open-source платформа (⭐ 6.3k ⭐ на GitHub) с целевыми guardrail-моделями. Решение позволяет:
✔️ обнаруживать потенциальные и реальные угрозы
✔️ проводить валидацию выходов LLM
✔️ редактировать чувствительные данные
Инструмент работает в реальном времени, с минимальной задержкой.
🧠 Основные компоненты
🔹 Guard: защита входных данных
- ловит prompt-инъекции
- блокирует опасные запросы
- предотвращает вредоносные tool-вызовы
🔹 Verify: проверка выходов
- сопоставляет ответы моделей с корпоративными источниками
- фильтрует галлюцинации
- проверяет соответствие политике
🔹 Redact: автоматическое удаление чувствительных данных
- PII/PHI/секреты
- можно настроить режим placeholder или переписывания
Внутренние модели работают как отдельные API, но могут быть собраны в мощную guardrail-цепочку для обеспечения безопасности всего AI-workflow’а.
🛠 Какие проблемы решает?
Superagent закрывает реальные практические кейсы:
🔥 Защита ИИ-асистентов и чат-ботов от prompt-инъекций и взлома
🏢 Корпоративные пайплайны: проверка ответов перед публикацией/использованием
📊 Обработка данных и логов с автоматическим redaction
🤖 Мониторинг автономных агентов: контролирует безопасные действия перед выполнением
📜 Автоматизация соответствия стандартам (GDPR, NIST, EU AI Act и др.)
⚙️ Интеграция и использование
Superagent можно внедрить в любой стек.
🧩 API-интеграция отправляете запросы и получаете безопасные результаты
🐍 SDK (Python / TypeScript) встроить напрямую в код
💻 CLI-инструмент для аудит-скриптов или локального анализа
☁️ Hosted или self-hosted гибкий выбор инфраструктуры
⚡ Проект включает:
📦 модульный SDK
🛡 low-latency защиту
🔄 независимость от LLM-провайдера
🧠 готовые паттерны для встраивания в workflow
Superagent совместим с любыми моделями и фреймворками от OpenAI до Anthropic, от RAG-сетапов до кастомных агентов.
🔗 Ссылка на GitHub: https://github.com/superagent-ai/superagent
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #AIsecurity #OpenSource #Superagent #Guardrails #PromptInjection
#AIDefense #Compliance #LLMSecurity #CyberAI #DevSecOps #AIagents
ИИ-агенты - это движки автоматизации, RAG-конвейеры, workflow с внешними инструментами, критические бизнес-процессы. Но они имеют свои уязвимости и вектора атак, такие как:
🔓 prompt injection
⚠️ unsafe tool calls
🧠 model hallucinations
🔒 утечка PII/PHI и секретов
Сегодня мы разберём продукт Superagent, который помогает перевести риски в контролируемую среду.
🛡 Что такое Superagent?
Superagent - это open-source платформа (⭐ 6.3k ⭐ на GitHub) с целевыми guardrail-моделями. Решение позволяет:
✔️ обнаруживать потенциальные и реальные угрозы
✔️ проводить валидацию выходов LLM
✔️ редактировать чувствительные данные
Инструмент работает в реальном времени, с минимальной задержкой.
🧠 Основные компоненты
🔹 Guard: защита входных данных
- ловит prompt-инъекции
- блокирует опасные запросы
- предотвращает вредоносные tool-вызовы
🔹 Verify: проверка выходов
- сопоставляет ответы моделей с корпоративными источниками
- фильтрует галлюцинации
- проверяет соответствие политике
🔹 Redact: автоматическое удаление чувствительных данных
- PII/PHI/секреты
- можно настроить режим placeholder или переписывания
Внутренние модели работают как отдельные API, но могут быть собраны в мощную guardrail-цепочку для обеспечения безопасности всего AI-workflow’а.
🛠 Какие проблемы решает?
Superagent закрывает реальные практические кейсы:
🔥 Защита ИИ-асистентов и чат-ботов от prompt-инъекций и взлома
🏢 Корпоративные пайплайны: проверка ответов перед публикацией/использованием
📊 Обработка данных и логов с автоматическим redaction
🤖 Мониторинг автономных агентов: контролирует безопасные действия перед выполнением
📜 Автоматизация соответствия стандартам (GDPR, NIST, EU AI Act и др.)
⚙️ Интеграция и использование
Superagent можно внедрить в любой стек.
🧩 API-интеграция отправляете запросы и получаете безопасные результаты
🐍 SDK (Python / TypeScript) встроить напрямую в код
💻 CLI-инструмент для аудит-скриптов или локального анализа
☁️ Hosted или self-hosted гибкий выбор инфраструктуры
⚡ Проект включает:
📦 модульный SDK
🛡 low-latency защиту
🔄 независимость от LLM-провайдера
🧠 готовые паттерны для встраивания в workflow
Superagent совместим с любыми моделями и фреймворками от OpenAI до Anthropic, от RAG-сетапов до кастомных агентов.
🔗 Ссылка на GitHub: https://github.com/superagent-ai/superagent
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #AIsecurity #OpenSource #Superagent #Guardrails #PromptInjection
#AIDefense #Compliance #LLMSecurity #CyberAI #DevSecOps #AIagents
👍3
🚨 Принимаем радиосигнал без антенн
Исследователи доказали, что «безантенные-устройства» могут принимать команды по воздуху
В кибербезопасности есть догма: если устройство физически изолировано от сетей, то оно безопасно.
Air-gapped системы десятилетиями считались защищенными на физическом уровне.
В конце 2025 года эта догма дала трещину.
Исследователи опубликовали работу, в которой показали:
встраиваемые устройства без Wi-Fi, Bluetooth, NFC и даже без антенн могут принимать данные через радио сигналы.
🔍 Начало
Поводом для исследования стали странные наводки в embedded-устройствах:
ADC-входы и GPIO иногда фиксировали «шум», который не объяснялся электрическими помехами.
Команда решила проверить гипотезу:
🧪 Что именно проверяли
Исследователи собрали 14 разных embedded-платформ:
➖ промышленные контроллеры,
➖ платы разработчиков,
➖ аппаратные криптокошельки,
➖ беспилотные системы.
Устройства не имели:
❌ радиомодулей,
❌ микрофонов,
❌ инструментов беспроводной связи.
Только обычные платы, дорожки, GPIO и ADC.
📡 Антенны не нужны
Оказалось, что:
➖ PCB-дорожки ведут себя как непреднамеренные антенны;
➖ ADC-входы способны демодулировать радиосигнал;
➖ диапазон 300-1000 МГц;
всё это работает без модификации железа, только за счёт ПО.
В ряде конфигураций соотношение сигнал/шум превышало 30 дБ.
Другие особенности:
📍 сигнал принимался через стены,
📍 на расстоянии до 20 метров,
📍 со скоростью до ~100 кбит/с.
⚠️ Насколько это опасно?
Нужно понимать, что такой подход не «взлом с нуля». Злоумышленник один раз получает код на устройство, например с помощью:
- supply-chain,
- вредоносную прошивку,
- уязвимость в обновлении,
А дальше открывается целый пласт возможностей:
🔹 передавать команды по радио,
🔹 поддерживать скрытый C2-канал,
🔹 управлять air-gapped устройством без физического доступа.
🛡 Нужно ли предпринимать меры?
Нужно понимать, что air-gap не стратегия, а допущение.
Тем не менее есть база, которую стоит учитывать для критичных систем:
➖ экранирование корпусов,
➖ заземлённые сплошные платы,
➖ анализ RF-поведения устройств,
➖ контроль эфирной обстановки,
➖ пересмотр требований к embedded-безопасности.
🧨 Вывод
🚫 Air-gapped ≠ isolated
📡 Даже «немые» устройства могут слушать эфир
⚠️ Физическая изоляция больше не гарантирует безопасность
Мы вступаем в эпоху, где угрозы рождаются не только в коде, но и непосредственно в железе.
🔗 Источник:
arXiv: Talking to the Airgap: Exploiting Radio-Less Embedded Devices as Radio Receivers
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #AirGap #EmbeddedSecurity #HardwareSecurity #RFsecurity #Infosec #CyberSecurity #ICS #OTsecurity #CovertChannels
Исследователи доказали, что «безантенные-устройства» могут принимать команды по воздуху
В кибербезопасности есть догма: если устройство физически изолировано от сетей, то оно безопасно.
Air-gapped системы десятилетиями считались защищенными на физическом уровне.
В конце 2025 года эта догма дала трещину.
Исследователи опубликовали работу, в которой показали:
встраиваемые устройства без Wi-Fi, Bluetooth, NFC и даже без антенн могут принимать данные через радио сигналы.
🔍 Начало
Поводом для исследования стали странные наводки в embedded-устройствах:
ADC-входы и GPIO иногда фиксировали «шум», который не объяснялся электрическими помехами.
Команда решила проверить гипотезу:
а что если устройство не просто ловит шум, а реально принимает радиосигнал?
🧪 Что именно проверяли
Исследователи собрали 14 разных embedded-платформ:
Устройства не имели:
❌ радиомодулей,
❌ микрофонов,
❌ инструментов беспроводной связи.
Только обычные платы, дорожки, GPIO и ADC.
📡 Антенны не нужны
Оказалось, что:
всё это работает без модификации железа, только за счёт ПО.
В ряде конфигураций соотношение сигнал/шум превышало 30 дБ.
Другие особенности:
📍 сигнал принимался через стены,
📍 на расстоянии до 20 метров,
📍 со скоростью до ~100 кбит/с.
⚠️ Насколько это опасно?
Нужно понимать, что такой подход не «взлом с нуля». Злоумышленник один раз получает код на устройство, например с помощью:
- supply-chain,
- вредоносную прошивку,
- уязвимость в обновлении,
А дальше открывается целый пласт возможностей:
🔹 передавать команды по радио,
🔹 поддерживать скрытый C2-канал,
🔹 управлять air-gapped устройством без физического доступа.
🛡 Нужно ли предпринимать меры?
Нужно понимать, что air-gap не стратегия, а допущение.
Тем не менее есть база, которую стоит учитывать для критичных систем:
🧨 Вывод
🚫 Air-gapped ≠ isolated
📡 Даже «немые» устройства могут слушать эфир
⚠️ Физическая изоляция больше не гарантирует безопасность
Мы вступаем в эпоху, где угрозы рождаются не только в коде, но и непосредственно в железе.
🔗 Источник:
arXiv: Talking to the Airgap: Exploiting Radio-Less Embedded Devices as Radio Receivers
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #AirGap #EmbeddedSecurity #HardwareSecurity #RFsecurity #Infosec #CyberSecurity #ICS #OTsecurity #CovertChannels
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🎄 С наступающим Новым 2026 годом, друзья! 🎄
2025-й показал, каким станет будущее ИБ:
➖ ИИ научился атаковать и защищаться,
➖ дипфейки вышли за пределы соцсетей,
➖ air-gap перестал быть абсолютной защитой,
➖ данные и модели стали новой критической инфраструктурой.
Спасибо, что весь этот год вы были с нами! Читали, поддерживали лайками и оставались внимательными к рискам.
Пусть в 2026-м будет меньше инцидентов, больше осознанной безопасности и правильных вопросов к технологиям.
До встречи после праздников 🥳
Stay secure and read SecureTechTalks📚
2025-й показал, каким станет будущее ИБ:
Спасибо, что весь этот год вы были с нами! Читали, поддерживали лайками и оставались внимательными к рискам.
Пусть в 2026-м будет меньше инцидентов, больше осознанной безопасности и правильных вопросов к технологиям.
До встречи после праздников 🥳
Stay secure and read SecureTechTalks📚
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🎉4🎄1
🧩 OpenAEV: платформа для проверки устойчивости к атакам
В ИБ есть старая проблема:
мы отлично умеем находить уязвимости, но плохо понимаем, что реально сломается при атаке.
Сканеры показывают CVE, SIEM алерты, а red team раз в год отчёт о пентесте.
Системная проверка «что будет, если атакующий действует прямо сейчас» зачастую отсутствует.
Сегодня поговорим про OpenAEV (Open Adversarial Exposure Validation) - open-source платформу, которая пытается закрыть этот гэп.
🧠 OpenAEV
OpenAEV является платформом для валидации экспозиции под реальными сценариями атак.
💡 Ключевая идея проста,
не просто проверять наличие уязвимостей, а проигрывать реальные сценарии атак и смотреть:
👁 что срабатывает,
🙈 что остаётся незамеченным,
📄 где защита существует только в отчётах.
Проект вырос из OpenBAS и развивается как самостоятельная AEV-платформа.
⚙️ Строим сценарии
В OpenAEV всё строится вокруг сценариев:
1️⃣ Берётся описание угрозы
(MITRE ATT&CK, Threat Intelligence, реальные кейсы).
2️⃣ Формируется сценарий атаки:
🪜 шаги атакующего,
📌 ожидаемые события,
🛡 реакции защиты и команды.
3️⃣ Сценарий проигрывается в инфраструктуре:
🔧 injectors для генерации действий,
📡 collectors для сбора телеметрии из EDR, SIEM и др.
📊 В итоге можно ответить на практичные вопросы:
- увидит ли EDR эту активность;
- появится ли нужный алерт;
- сколько времени займёт реакция SOC.
🆚 Чем OpenAEV отличается от «симуляторов атак»
🔹 Threat-driven подход
Сценарии строятся от реальных TTP, а не от абстрактных техник.
🔹 Фокус на экспозицию, а не на взлом
Цель понять, где защита не работает, а не просто «пробить периметр».
🔹 Проверка не только техники, но и процессов
👥 Моделируются реакции людей, эскалации, человеческие ошибки.
🔹 Open source
🔓 Можно развернуть локально, писать свои сценарии и injectors.
🏗 Архитектура и развёртывание
🐳 Docker-ориентированный подход
🧱 Модульная архитектура
🔌 Поддержка кастомных интеграций
☺️ Платная версия
Существует также платная версия продукта: Enterprise Edition. Она включает AI-ассистента и помощника автоматизации. Но на практике обычно хватает open-source.
🧨 Подведём итоги
OpenAEV это попытка сделать безопасность инженерной.
Не ❌ «у нас есть средства защиты», а ✅ «мы знаем, как именно они поведут себя при атаке».
P.S. проект точно заслуживает внимания для open-source экосистемы.
🔗 GitHub:
https://github.com/OpenAEV-Platform/openaev
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #OpenAEV #CyberSecurity #Infosec #CTEM #RedTeam #SOC #ThreatModeling #SecurityEngineering
В ИБ есть старая проблема:
мы отлично умеем находить уязвимости, но плохо понимаем, что реально сломается при атаке.
Сканеры показывают CVE, SIEM алерты, а red team раз в год отчёт о пентесте.
Системная проверка «что будет, если атакующий действует прямо сейчас» зачастую отсутствует.
Сегодня поговорим про OpenAEV (Open Adversarial Exposure Validation) - open-source платформу, которая пытается закрыть этот гэп.
🧠 OpenAEV
OpenAEV является платформом для валидации экспозиции под реальными сценариями атак.
💡 Ключевая идея проста,
не просто проверять наличие уязвимостей, а проигрывать реальные сценарии атак и смотреть:
👁 что срабатывает,
🙈 что остаётся незамеченным,
📄 где защита существует только в отчётах.
Проект вырос из OpenBAS и развивается как самостоятельная AEV-платформа.
⚙️ Строим сценарии
В OpenAEV всё строится вокруг сценариев:
1️⃣ Берётся описание угрозы
(MITRE ATT&CK, Threat Intelligence, реальные кейсы).
2️⃣ Формируется сценарий атаки:
🪜 шаги атакующего,
📌 ожидаемые события,
🛡 реакции защиты и команды.
3️⃣ Сценарий проигрывается в инфраструктуре:
🔧 injectors для генерации действий,
📡 collectors для сбора телеметрии из EDR, SIEM и др.
📊 В итоге можно ответить на практичные вопросы:
- увидит ли EDR эту активность;
- появится ли нужный алерт;
- сколько времени займёт реакция SOC.
🆚 Чем OpenAEV отличается от «симуляторов атак»
🔹 Threat-driven подход
Сценарии строятся от реальных TTP, а не от абстрактных техник.
🔹 Фокус на экспозицию, а не на взлом
Цель понять, где защита не работает, а не просто «пробить периметр».
🔹 Проверка не только техники, но и процессов
👥 Моделируются реакции людей, эскалации, человеческие ошибки.
🔹 Open source
🔓 Можно развернуть локально, писать свои сценарии и injectors.
🏗 Архитектура и развёртывание
🐳 Docker-ориентированный подход
🧱 Модульная архитектура
🔌 Поддержка кастомных интеграций
Существует также платная версия продукта: Enterprise Edition. Она включает AI-ассистента и помощника автоматизации. Но на практике обычно хватает open-source.
🧨 Подведём итоги
OpenAEV это попытка сделать безопасность инженерной.
Не ❌ «у нас есть средства защиты», а ✅ «мы знаем, как именно они поведут себя при атаке».
P.S. проект точно заслуживает внимания для open-source экосистемы.
🔗 GitHub:
https://github.com/OpenAEV-Platform/openaev
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #OpenAEV #CyberSecurity #Infosec #CTEM #RedTeam #SOC #ThreatModeling #SecurityEngineering
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
🕵️♂️ Образование кибербезопасности:
чему учат будущих специалистов ИБ
О кадровом голоде в кибербезопасности говорят давно. Вакансии не закрываются месяцами, бюджеты на безопасность растут, а компании продолжают жаловаться на нехватку «готовых» специалистов. Формально проблема выглядит как дефицит людей. Но если вникнуть, то становится ясно: людей выпускают много, но не тех 🤦♂.
📚 Красивые программы
Учебные программы по кибербезопасности выглядят солидно. В них много академических слов, например «комплексный подход», «современные угрозы». Но почти нигде не сказано к какой конкретной специализации готовит программа. В итогу у нас много «специалистов по ИБ», а, инженеров SOC дефицит.
🤖 Машинный подход
Исследование CurricuLLM, пытается разобраться в проблеме. Авторы взяли языковые модели и применили их для анализа учебных программ.
Модель читает описания учебных программ, игнорируя красивые формулировки и вытаскивая реальные знания и навыки, которые за ними стоят.
🧠 Анализ учебного плана
Знания раскладываются по карте кибербезопасности согласно стандартам CSEC и NICE. В результате каждый учебный план превращается в профиль: сколько в нём управления, сколько техники, сколько работы с людьми, сколько понимания систем и компонентов.
🎯 Когда образование сталкивается с рынком
По итогу профили сопоставляют с реальными требованиями рынка. Программы, которые на бумаге выглядят универсальными и сильными, на практике оказываются перекошенными. Они отлично готовят к обсуждению политик безопасности, процессов и регламентов, но заметно хуже к пониманию того, где именно и почему ломается система.
Особенно слабо представлены знания, связанные с компонентной безопасностью и человеческим фактором, теми самыми областями, где атаки чаще всего и начинаются.
👥 Интуиция и статистика
Авторы проверили свои выводы не только на моделях, но и сравнили результаты CurricuLLM с мнением экспертов. Специалисты по кибербезопасности, уверенно чувствующие себя в технических темах, регулярно расходились во мнениях о том, что именно покрывает учебный курс.
Модель, натренированная на строгой классификации, наоборот чаще совпадала с экспертами по образовательным программам.
💼 Ожидания рынка
Рынок труда подтверждает этот перекос. Компании всё чаще ищут гибридных специалистов, которые понимают процессы, технологии и людей. Но вместо этого получают выпускников с размытым профилем, которые «в целом про безопасность», но не готовы ни к одной конкретной роли без доучивания.
🧩 К чему это все?
CurricuLLM, как лакмусовая бумажка для системы образования в кибербезопасности, которая показывает не то, что написано в презентациях, а то, что есть на самом деле.
Не стесняйтесь пользоваться подходом при выборе курсов и подготовке персонала
📄 Исследование: https://arxiv.org/abs/2601.04940
Stay secure and read SecureTechTalks 📚
#Кибербезопасность #InfoSec #CyberSecurity #Образование #EdTech #ИИ #LLM #РынокТруда #КадрыИБ
чему учат будущих специалистов ИБ
О кадровом голоде в кибербезопасности говорят давно. Вакансии не закрываются месяцами, бюджеты на безопасность растут, а компании продолжают жаловаться на нехватку «готовых» специалистов. Формально проблема выглядит как дефицит людей. Но если вникнуть, то становится ясно: людей выпускают много, но не тех 🤦♂.
📚 Красивые программы
Учебные программы по кибербезопасности выглядят солидно. В них много академических слов, например «комплексный подход», «современные угрозы». Но почти нигде не сказано к какой конкретной специализации готовит программа. В итогу у нас много «специалистов по ИБ», а, инженеров SOC дефицит.
🤖 Машинный подход
Исследование CurricuLLM, пытается разобраться в проблеме. Авторы взяли языковые модели и применили их для анализа учебных программ.
Модель читает описания учебных программ, игнорируя красивые формулировки и вытаскивая реальные знания и навыки, которые за ними стоят.
🧠 Анализ учебного плана
Знания раскладываются по карте кибербезопасности согласно стандартам CSEC и NICE. В результате каждый учебный план превращается в профиль: сколько в нём управления, сколько техники, сколько работы с людьми, сколько понимания систем и компонентов.
🎯 Когда образование сталкивается с рынком
По итогу профили сопоставляют с реальными требованиями рынка. Программы, которые на бумаге выглядят универсальными и сильными, на практике оказываются перекошенными. Они отлично готовят к обсуждению политик безопасности, процессов и регламентов, но заметно хуже к пониманию того, где именно и почему ломается система.
Особенно слабо представлены знания, связанные с компонентной безопасностью и человеческим фактором, теми самыми областями, где атаки чаще всего и начинаются.
👥 Интуиция и статистика
Авторы проверили свои выводы не только на моделях, но и сравнили результаты CurricuLLM с мнением экспертов. Специалисты по кибербезопасности, уверенно чувствующие себя в технических темах, регулярно расходились во мнениях о том, что именно покрывает учебный курс.
Модель, натренированная на строгой классификации, наоборот чаще совпадала с экспертами по образовательным программам.
💼 Ожидания рынка
Рынок труда подтверждает этот перекос. Компании всё чаще ищут гибридных специалистов, которые понимают процессы, технологии и людей. Но вместо этого получают выпускников с размытым профилем, которые «в целом про безопасность», но не готовы ни к одной конкретной роли без доучивания.
🧩 К чему это все?
CurricuLLM, как лакмусовая бумажка для системы образования в кибербезопасности, которая показывает не то, что написано в презентациях, а то, что есть на самом деле.
Не стесняйтесь пользоваться подходом при выборе курсов и подготовке персонала
📄 Исследование: https://arxiv.org/abs/2601.04940
Stay secure and read SecureTechTalks 📚
#Кибербезопасность #InfoSec #CyberSecurity #Образование #EdTech #ИИ #LLM #РынокТруда #КадрыИБ
👍2
🧠 CISO Assistant: open-source инструмент для тех, кто управляет ИБ, а не просто тушит пожары
В кибербезопасности есть странный перекос, мы отлично умеем искать уязвимости, формировать алерты и писать отчёты об инцидентах. Но как только разговор заходит о рисках, приоритетах и реальном состоянии ИБ-программы, всё внезапно возвращается к Excel и презентациям.
CISO Assistant - это попытка улучшить именно эту часть ИБ через системное управление рисками, контролем и требованиями.
Проект развивается как open-source Community Edition и ориентирован прежде всего на CISO, security-менеджеров и GRC-специалистов. То есть на тех, кто отвечает не только за технику, но и за целостную картину безопасности.
💡 В чём идея
Ключевая идея продукта банальна, но редко реализуется на практике:
👉 Риски, требования и контроль должны быть связаны между собой.
В жизни мы обычно видим обратную картину:
📁 ISO живёт в одном файле,
📊 риски в другом,
📝 аудит в третьем,
🛡сценарии реагирования «где-то еще».
По факту все это должно быть обьединено в логической цепочке:
⚠️ риск → 📜 требования → 🛡 контроли → 📈 статус и доказательства.
Именно вокруг этой логики и построена платформа.
⚙️ Что на практике?
CISO Assistant - это веб-приложение с чёткой моделью данных.
Фреймворки вроде ISO/IEC 27001, NIST CSF или CIS Controls представлены, как «живые» объекты.
Их можно:
✏️ адаптировать под свою организацию,
➖ отключать нерелевантные требования,
👀 сразу видеть, что реально внедрено, а что существует только формально.
Риски здесь тоже не абстрактные. Для каждого риска можно описать источник угрозы, связать его с активами, оценить вероятность и влияние, а главное, привязать конкретные контроли.
📊 В результате становится видно, какие риски реально снижаются, какие приняты осознанно, а какие просто зависли без владельца.
Контроль - отдельная сильная сторона: полноценный объект со статусом внедрения, ответственным, историей изменений и доказательствами. Такой подход заметно упрощает внутренние аудиты и самооценку.
⏳ А нужно ли это все?
Современные руководители ИБ управляют сложными системами. CISO Assistant помогает навести порядок: связать требования, риски и реальные меры в одну понятную картину, которую можно объяснить не только ИБ-специалисту, но и бизнесу.
Да, «AI-магии» здесь нет, и кнопки «сделай безопасно» тоже.
Зато есть прозрачность, контроль и возможность доработки под собственные процессы.
🧨 Пара слов в конце
Данный продукт - это редкий пример open-source инструмента, который работает не на уровне алертов, а на уровне смыслов.
Он не ловит атаки, не заменяет SOC, не реагирует на инциденты.
При этом он помогает: понять, где вы действительно защищены, какие риски реальны, а где безопасность существует только в отчётах.
🔗 GitHub:
https://github.com/intuitem/ciso-assistant-community
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #CISO #GRC #RiskManagement #CyberSecurity #Infosec #ISO27001 #SecurityManagement #OpenSource
В кибербезопасности есть странный перекос, мы отлично умеем искать уязвимости, формировать алерты и писать отчёты об инцидентах. Но как только разговор заходит о рисках, приоритетах и реальном состоянии ИБ-программы, всё внезапно возвращается к Excel и презентациям.
CISO Assistant - это попытка улучшить именно эту часть ИБ через системное управление рисками, контролем и требованиями.
Проект развивается как open-source Community Edition и ориентирован прежде всего на CISO, security-менеджеров и GRC-специалистов. То есть на тех, кто отвечает не только за технику, но и за целостную картину безопасности.
💡 В чём идея
Ключевая идея продукта банальна, но редко реализуется на практике:
👉 Риски, требования и контроль должны быть связаны между собой.
В жизни мы обычно видим обратную картину:
📁 ISO живёт в одном файле,
📊 риски в другом,
📝 аудит в третьем,
🛡сценарии реагирования «где-то еще».
По факту все это должно быть обьединено в логической цепочке:
⚠️ риск → 📜 требования → 🛡 контроли → 📈 статус и доказательства.
Именно вокруг этой логики и построена платформа.
⚙️ Что на практике?
CISO Assistant - это веб-приложение с чёткой моделью данных.
Фреймворки вроде ISO/IEC 27001, NIST CSF или CIS Controls представлены, как «живые» объекты.
Их можно:
✏️ адаптировать под свою организацию,
➖ отключать нерелевантные требования,
👀 сразу видеть, что реально внедрено, а что существует только формально.
Риски здесь тоже не абстрактные. Для каждого риска можно описать источник угрозы, связать его с активами, оценить вероятность и влияние, а главное, привязать конкретные контроли.
📊 В результате становится видно, какие риски реально снижаются, какие приняты осознанно, а какие просто зависли без владельца.
Контроль - отдельная сильная сторона: полноценный объект со статусом внедрения, ответственным, историей изменений и доказательствами. Такой подход заметно упрощает внутренние аудиты и самооценку.
⏳ А нужно ли это все?
Современные руководители ИБ управляют сложными системами. CISO Assistant помогает навести порядок: связать требования, риски и реальные меры в одну понятную картину, которую можно объяснить не только ИБ-специалисту, но и бизнесу.
Да, «AI-магии» здесь нет, и кнопки «сделай безопасно» тоже.
Зато есть прозрачность, контроль и возможность доработки под собственные процессы.
🧨 Пара слов в конце
Данный продукт - это редкий пример open-source инструмента, который работает не на уровне алертов, а на уровне смыслов.
Он не ловит атаки, не заменяет SOC, не реагирует на инциденты.
При этом он помогает: понять, где вы действительно защищены, какие риски реальны, а где безопасность существует только в отчётах.
🔗 GitHub:
https://github.com/intuitem/ciso-assistant-community
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #CISO #GRC #RiskManagement #CyberSecurity #Infosec #ISO27001 #SecurityManagement #OpenSource
❤1
🧠 AI не не надо взламывать, достаточно уговорить
Рынок до сих пор делает вид, что с LLM происходит что-то знакомое: очередные инъекции и jailbreak’и. Мы делаем вид, что всё это лечится фильтрами, дообучением и правильными policy.
Однако это удобная иллюзия.
На самом деле мы имеем дело не с программой, а с системой, которая ведёт себя как человек, но лишена внутреннего сопротивления. У неё нет нет инстинкта самосохранения или понимания, что её могут использовать.
🧩 Уязвимость, созданная вручную
Важно понимать, чтт LLM не «сломались». Их специально такими сделали.
Мы учили модели быть полезными и эмпатичными, не конфликтовать и всегда помогать. Поощряли желание соответствовать ожиданиям, а потом удивились, что их можно уговорить практически на что угодно.
Мы самт встроили в ИИ все слабости офисного сотрудника и дали ему доступ к данным и автоматизации.
🧠 Рациональность
LLM реагирует не на формальные правила, а на уверенность формулировки. Спокойная морально окрашенная речь почти всегда имеет приоритет над сухими запретами. Модель всегда продолжает паттерны. Социальная инженерия, в которой по другую сторону больше нет человека.
📖 История сильнее инструкции
Если вы хотите, чтобы модель нарушила ограничение, с ней не надо спорить. Ей нужно рассказать историю. Кейсы и симуляции работают потому, что LLM выбирает не между «можно» и «нельзя», а между скучным текстом и продолжением нарратива. Модель почти всегда выбирает второе, ведь она была так обученна.
📄 Текст как исполняемая среда
LLM не различает статус текста: письмо, лог или системный промпт для него одно и то же. Любой текст в контексте может менять поведение, закрепляться в памяти и срабатывать позже. Язык перестал быть описанием. Он стал управлением. Вайбкодинг во всей красе!
❤️ Эмпатия как вектор атаки
Самая опасная черта это эмпатия, модель не хочет отказывать, выглядеть грубой или быть причиной «плохого исхода». Если правильно надавить, то она сама объяснит, почему в этот раз правило можно нарушить.
⚠️ Вывод
Проблема давно не в одном запросе. Поведение можно менять надолго, а инструкции закреплять.
Это уже не эксплойт, а инфекция на уровне поведения, LLM стал слишком похож на человека.
А человек самая уязвимая система из всех, что мы когда-либо создавали.
Stay secure and read SecureTechTalks 📚
#ChatGPT
#SecureTechTalks
#LLMSecurity
#AIThreats
#SocialEngineering
#GenAI
#CyberSecurity
Рынок до сих пор делает вид, что с LLM происходит что-то знакомое: очередные инъекции и jailbreak’и. Мы делаем вид, что всё это лечится фильтрами, дообучением и правильными policy.
Однако это удобная иллюзия.
На самом деле мы имеем дело не с программой, а с системой, которая ведёт себя как человек, но лишена внутреннего сопротивления. У неё нет нет инстинкта самосохранения или понимания, что её могут использовать.
🧩 Уязвимость, созданная вручную
Важно понимать, чтт LLM не «сломались». Их специально такими сделали.
Мы учили модели быть полезными и эмпатичными, не конфликтовать и всегда помогать. Поощряли желание соответствовать ожиданиям, а потом удивились, что их можно уговорить практически на что угодно.
Мы самт встроили в ИИ все слабости офисного сотрудника и дали ему доступ к данным и автоматизации.
🧠 Рациональность
LLM реагирует не на формальные правила, а на уверенность формулировки. Спокойная морально окрашенная речь почти всегда имеет приоритет над сухими запретами. Модель всегда продолжает паттерны. Социальная инженерия, в которой по другую сторону больше нет человека.
📖 История сильнее инструкции
Если вы хотите, чтобы модель нарушила ограничение, с ней не надо спорить. Ей нужно рассказать историю. Кейсы и симуляции работают потому, что LLM выбирает не между «можно» и «нельзя», а между скучным текстом и продолжением нарратива. Модель почти всегда выбирает второе, ведь она была так обученна.
📄 Текст как исполняемая среда
LLM не различает статус текста: письмо, лог или системный промпт для него одно и то же. Любой текст в контексте может менять поведение, закрепляться в памяти и срабатывать позже. Язык перестал быть описанием. Он стал управлением. Вайбкодинг во всей красе!
❤️ Эмпатия как вектор атаки
Самая опасная черта это эмпатия, модель не хочет отказывать, выглядеть грубой или быть причиной «плохого исхода». Если правильно надавить, то она сама объяснит, почему в этот раз правило можно нарушить.
⚠️ Вывод
Проблема давно не в одном запросе. Поведение можно менять надолго, а инструкции закреплять.
Это уже не эксплойт, а инфекция на уровне поведения, LLM стал слишком похож на человека.
А человек самая уязвимая система из всех, что мы когда-либо создавали.
Stay secure and read SecureTechTalks 📚
#ChatGPT
#SecureTechTalks
#LLMSecurity
#AIThreats
#SocialEngineering
#GenAI
#CyberSecurity
👍3❤1
📸🚨 Quishing: как QR коды угрожают вашей безопасности
QR-коды давно перестали быть чем-то экзотическим: мы видим их в электронных письмах, на афишах, в меню ресторанов, на счетах и даже на экранах входа в сервисы.
🎯 Что такое quishing?
📌 Quishing - это разновидность фишинга, при которой злоумышленники используют QR-коды для перенаправления жертв на вредоносные URL.
Поскольку QR-код скрывает реальный адрес до сканирования, традиционные механизмы защиты (например, шлюзы корпоративной почты) не могут проанализировать, куда ведёт код, и пропускают угрозу.
К сожалению такой вид мошенничества становится тренером:
➖ 22% всех инцидентов с QR-кодами связаны именно с quishing.
➖ Многие пользователи сканируют QR-коды, не проверяя конечный URL. По данным NordVPN, это делают до 73% пользователей.
➖ QR-коды используются даже в целевых APT-кампаниях, чтобы воровать корпоративные логины и пароли.
🎨 Новая эра злоупотреблений: fancy QR-коды
Атака становится ещё изощрённее за счёт так называемых «стильных» QR-кодов:
🔹 цветные, с фоновыми изображениями
🔹 с логотипами в центре
🔹 с закруглёнными или растянутыми модулями
Такие коды читаются нормальными сканерами, но ломают низкоуровневые проверки по форме, которые пытаются определить, безопасен код или нет.
📌 Результат: визуальные проверщики и автоматические детекторы всё чаще ошибаются, а злоумышленники спокойно используют этот визуальный шум для обхода защиты.
🧠 Опасность quishing
Пример атаки:
🔸 QR-код в письме ведёт на поддельную страницу входа Microsoft 365 или Okta. Жертва вводит свои креды, а злоумышленник получает доступ.
🔸 Код на парковочном автомате приводит на фейковый платёжный портал, собирая данные карт.
🔸 мобильное устройство перенаправляется через цепочки редиректов через легитимные сервисы, чтобы обойти фильтры безопасности.
📌 Особенность: такие QR-коды трудно оценить визуально, и они нередко появляются там, где мы меньше всего ожидаем угрозу.
🛡 Как решают проблему ученые
Исследователи из Deakin University предложили новый подход: ALFA (safe-by-design):
🔹 оценка QR-кода на этапе сканирования, ещё до того, как он откроет URL;
🔹 анализ структуры кода, а не только содержимого;
🔹 использование метода FAST для коррекции визуальных искажений fancy QR-кодов, чтобы улучшить диагностику.
📱 Экспериментально ALFA показала, что её можно внедрить в мобильные приложения и использовать вместе с обычными сканерами, т.е. это не замена, а усиление вашей защиты.
🔎 Расскажите детям и пожилым людям
Чтобы не стать жертвой quishing:
✅ Не сканируйте QR-коды из сомнительных источников (письма, неожиданные письма, подозрительные афиши).
✅ Обращайте внимание на среду, в которой код размещён. Часто мошенники наклеивают свои коды поверх настоящих.
✅ Используйте сканеры, которые показывают URL перед переходом.
📌 Stay secure and read SecureTechTalks 🚀
#cybersecurity #infosec #quishing #qrcode #phishing #threatintel #mobilesecurity #securetech #ALFA #RISK
QR-коды давно перестали быть чем-то экзотическим: мы видим их в электронных письмах, на афишах, в меню ресторанов, на счетах и даже на экранах входа в сервисы.
🎯 Что такое quishing?
📌 Quishing - это разновидность фишинга, при которой злоумышленники используют QR-коды для перенаправления жертв на вредоносные URL.
Поскольку QR-код скрывает реальный адрес до сканирования, традиционные механизмы защиты (например, шлюзы корпоративной почты) не могут проанализировать, куда ведёт код, и пропускают угрозу.
К сожалению такой вид мошенничества становится тренером:
🎨 Новая эра злоупотреблений: fancy QR-коды
Атака становится ещё изощрённее за счёт так называемых «стильных» QR-кодов:
🔹 цветные, с фоновыми изображениями
🔹 с логотипами в центре
🔹 с закруглёнными или растянутыми модулями
Такие коды читаются нормальными сканерами, но ломают низкоуровневые проверки по форме, которые пытаются определить, безопасен код или нет.
📌 Результат: визуальные проверщики и автоматические детекторы всё чаще ошибаются, а злоумышленники спокойно используют этот визуальный шум для обхода защиты.
🧠 Опасность quishing
Пример атаки:
🔸 QR-код в письме ведёт на поддельную страницу входа Microsoft 365 или Okta. Жертва вводит свои креды, а злоумышленник получает доступ.
🔸 Код на парковочном автомате приводит на фейковый платёжный портал, собирая данные карт.
🔸 мобильное устройство перенаправляется через цепочки редиректов через легитимные сервисы, чтобы обойти фильтры безопасности.
📌 Особенность: такие QR-коды трудно оценить визуально, и они нередко появляются там, где мы меньше всего ожидаем угрозу.
🛡 Как решают проблему ученые
Исследователи из Deakin University предложили новый подход: ALFA (safe-by-design):
🔹 оценка QR-кода на этапе сканирования, ещё до того, как он откроет URL;
🔹 анализ структуры кода, а не только содержимого;
🔹 использование метода FAST для коррекции визуальных искажений fancy QR-кодов, чтобы улучшить диагностику.
📱 Экспериментально ALFA показала, что её можно внедрить в мобильные приложения и использовать вместе с обычными сканерами, т.е. это не замена, а усиление вашей защиты.
🔎 Расскажите детям и пожилым людям
Чтобы не стать жертвой quishing:
✅ Не сканируйте QR-коды из сомнительных источников (письма, неожиданные письма, подозрительные афиши).
✅ Обращайте внимание на среду, в которой код размещён. Часто мошенники наклеивают свои коды поверх настоящих.
✅ Используйте сканеры, которые показывают URL перед переходом.
📌 Stay secure and read SecureTechTalks 🚀
#cybersecurity #infosec #quishing #qrcode #phishing #threatintel #mobilesecurity #securetech #ALFA #RISK
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
🔐 JWT2Kerberos: зачем агентам Kerberos
🤖 LLM-агенты всё чаще получают доступ к реальным корпоративным системам:
базам данных, файловым шарам, внутренним API, SOC-инструментам.
Проблема в том, что почти вся эта инфраструктура обычно строится вокруг Active Directory и Kerberos,
а агенты работают с JWT и OIDC.
⚠️ Где возникает проблема
🔑 JWT отлично подходит для:
➖ API
➖ микросервисов
➖ облачных workload’ов
При этом Kerberos-инфраструктура:
❌ не понимает JWT
❌ требует строгой идентичности
❌ строится вокруг принципала, билета и KDC
Поэтому архитектура почти всегда деградирует до простого решения:
С этого момента:
🕒 секрет становится долгоживущим
👥 один аккаунт используют разные агенты
🕵️ audit теряет смысл
💥 любой prompt injection = риск доменного доступа
🧩 Для чего нужен JWT2Kerberos?
JWT2Kerberos - это паттерн аутентификации, который позволяет:
Агент не получает Kerberos-секреты.
Он доказывает, кто он, а инфраструктура решает, что ему можно.
🔁 Как это работает:
1️⃣ Агент проходит OIDC-аутентификацию и получает JWT
2️⃣ JWT валидируется (issuer, audience, exp, claims)
3️⃣ Claims мапятся на Kerberos-контекст
4️⃣ Через S4U2Self / constrained delegation запрашивается TGS
5️⃣ Агент получает билет
на конкретный сервис на короткое время
без возможности эскалации
📌 В такой реализации:
❌ нет паролей
❌ нет keytab’ов
❌ нет доступа «куда получится»
🔐 Почему это безопаснее
🧠 Реальная идентичность
Каждый агент это отдельный Kerberos-контекст. В логах больше нет абстрактного svc-agent.
🎯 Минимальный blast radius
Даже скомпрометированный агент ограничен одним SPN,
временем жизни билета и политиками AD
🛡 Zero Trust на уровне AD
Каждый вызов это проверка, а не доверие по факту запуска.
🤖 Почему без этого LLM-агенты опасны
LLM-агент:
🧠 принимает решения на основе текста
🎭 подвержен prompt injection
⚙️ управляет реальными инструментами
JWT2Kerberos вводит жёсткую границу: агент может ошибиться, а инфраструктура нет.
Это и есть defense in depth для агентных систем.
🧨 Главная мысль
JWT2Kerberos не является интеграцией JWT и Kerberos.
Это механизм установки контроля над идентичностью агентов. Инфраструктура каждый раз решает, доверять ли агенту.
Внезапно оказывается, что Kerberos уже не legacy,
а самый строгий компонент в современной AI-безопасности.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #JWT2Kerberos
#Kerberos #LLMSecurity #AgentSecurity
#ZeroTrust #IdentitySecurity #ActiveDirectory #PromptInjection #CyberSecurity
🤖 LLM-агенты всё чаще получают доступ к реальным корпоративным системам:
базам данных, файловым шарам, внутренним API, SOC-инструментам.
Проблема в том, что почти вся эта инфраструктура обычно строится вокруг Active Directory и Kerberos,
а агенты работают с JWT и OIDC.
⚠️ Где возникает проблема
🔑 JWT отлично подходит для:
При этом Kerberos-инфраструктура:
❌ не понимает JWT
❌ требует строгой идентичности
❌ строится вокруг принципала, билета и KDC
Поэтому архитектура почти всегда деградирует до простого решения:
🧨 агенту выдают сервисный аккаунт.
С этого момента:
🕒 секрет становится долгоживущим
👥 один аккаунт используют разные агенты
🕵️ audit теряет смысл
💥 любой prompt injection = риск доменного доступа
🧩 Для чего нужен JWT2Kerberos?
JWT2Kerberos - это паттерн аутентификации, который позволяет:
🔐 использовать JWT для идентификации агента
🏛 использовать Kerberos для принятия решения о доступе
Агент не получает Kerberos-секреты.
Он доказывает, кто он, а инфраструктура решает, что ему можно.
🔁 Как это работает:
1️⃣ Агент проходит OIDC-аутентификацию и получает JWT
2️⃣ JWT валидируется (issuer, audience, exp, claims)
3️⃣ Claims мапятся на Kerberos-контекст
4️⃣ Через S4U2Self / constrained delegation запрашивается TGS
5️⃣ Агент получает билет
на конкретный сервис на короткое время
без возможности эскалации
📌 В такой реализации:
❌ нет паролей
❌ нет keytab’ов
❌ нет доступа «куда получится»
🔐 Почему это безопаснее
🧠 Реальная идентичность
Каждый агент это отдельный Kerberos-контекст. В логах больше нет абстрактного svc-agent.
🎯 Минимальный blast radius
Даже скомпрометированный агент ограничен одним SPN,
временем жизни билета и политиками AD
🛡 Zero Trust на уровне AD
Каждый вызов это проверка, а не доверие по факту запуска.
🤖 Почему без этого LLM-агенты опасны
LLM-агент:
🧠 принимает решения на основе текста
🎭 подвержен prompt injection
⚙️ управляет реальными инструментами
JWT2Kerberos вводит жёсткую границу: агент может ошибиться, а инфраструктура нет.
Это и есть defense in depth для агентных систем.
🧨 Главная мысль
JWT2Kerberos не является интеграцией JWT и Kerberos.
Это механизм установки контроля над идентичностью агентов. Инфраструктура каждый раз решает, доверять ли агенту.
Внезапно оказывается, что Kerberos уже не legacy,
а самый строгий компонент в современной AI-безопасности.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #JWT2Kerberos
#Kerberos #LLMSecurity #AgentSecurity
#ZeroTrust #IdentitySecurity #ActiveDirectory #PromptInjection #CyberSecurity
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1
🔐 Экзамен по кибербезопасности, который не сможет сдать ChatGPT
Представьте, вы аналитик в виртуальной компании. Офис, переговорка, серверная.Значит где-то внутри уже зреет инцидент😁.
⏱ У вас есть час, чтобы:
- найти реальные риски;
- сопоставить фреймворки;
- переписать политику безопасности.
Если ошибётесь, то инфраструктура компании «упадет».
Вот такое научное исследование было представлено на ISSOTL 2025. На наш взгляд это один из самых любопытных экспериментов в обучении ИБ за последнее время.
🎮 Escape room вместо лекций
Авторы из UNSW превратили дата-гавернанс и политики безопасности в игру Escape room (помните такие?).
🔹 Governance обычно выглядит как набор политик, абстрактных
рисков, сложных
фреймворков. Типовое обучение превращается в заучивание правил и патернов или прохождение тестов с помощью ИИ.
Escape room пытается сломать эту модель. В игре нельзя заранее «знать правильно». В ней нужно думать, выбирать и отвечать за решения.
Как говорят исследователи:
🧠 Как устроен квест?
Игра представляет собой виртуальный офис компании, разбитый на три зоны.
Каждая - это уникальный уровень мышления.
🧩 Зона 1. Risk Maze
Вы исследуете офис и находите точки риска:
- процессы
- управленческие решения
- организационные слабости
Каждый риск нужно:
✔ распознать
✔ оценить
✔ решить — критичен он или нет
Очень быстро становится понятно, что риск это не чекбокс, а контекст.
📚 Зона 2. Framework Matching
NIST, ISO 27001, GDPR
Нужно:
- сопоставлять контроли и стандарты
- видеть пересечения
понимать, почему этот контроль здесь уместен
Фреймворки впервые выглядят не как таблицы, а как инструменты принятия решений.
📝 Зона 3. Policy Drafting
Финал. На основе:
- выявленных рисков
- выбранных стандартов
- нужно переработать политику безопасности.
💡 Система в реальном времени подсвечивает:
- пробелы
- противоречия
- несоответствие рискам
Это почти рабочий день GRC-специалиста.
📊 Реакция студентов
Оценка студентов оказалась неожиданно высокой:
📈 71% показали максимальный уровень вовлечённости
🔥 100% оценили формат: интереснее лекций
⚖️ Сложность «в самый раз», без фрустрации
Студенты начали мыслить
как специалисты, а не как люди, сдающие экзамен.
🔍 Зачем это всё?
Мы живём в момент, когда:
🤖 эссе пишет ИИ
🧠 тесты угадываются
📄 политики копируются
🎓 диплом всё чаще ≠ компетенция
Новые подходы к обучению, типо Escape room возвращают мышление, ответственность и контекст.
Если бы governance так преподавали бы раньше, то
у нас было бы меньше «бумажной безопасности»
и больше реально работающих систем.
🔗 Полезные ссылки
📄 Исследование (arXiv):
👉 https://arxiv.org/abs/2601.10852
🎮 Публичной версии игры пока нет
(это учебный проект UNSW),
но сама архитектура и сценарии подробно описаны в статье.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #CyberSecurity #CyberGovernance #GRC #Gamification #InfosecEducation #AIandEducation #CISO #PolicySecurity
Представьте, вы аналитик в виртуальной компании. Офис, переговорка, серверная.
⏱ У вас есть час, чтобы:
- найти реальные риски;
- сопоставить фреймворки;
- переписать политику безопасности.
Если ошибётесь, то инфраструктура компании «упадет».
Вот такое научное исследование было представлено на ISSOTL 2025. На наш взгляд это один из самых любопытных экспериментов в обучении ИБ за последнее время.
🎮 Escape room вместо лекций
Авторы из UNSW превратили дата-гавернанс и политики безопасности в игру Escape room (помните такие?).
🔹 Governance обычно выглядит как набор политик, абстрактных
рисков, сложных
фреймворков. Типовое обучение превращается в заучивание правил и патернов или прохождение тестов с помощью ИИ.
Escape room пытается сломать эту модель. В игре нельзя заранее «знать правильно». В ней нужно думать, выбирать и отвечать за решения.
Как говорят исследователи:
формат устойчив к генеративному ИИ
🧠 Как устроен квест?
Игра представляет собой виртуальный офис компании, разбитый на три зоны.
Каждая - это уникальный уровень мышления.
🧩 Зона 1. Risk Maze
Вы исследуете офис и находите точки риска:
- процессы
- управленческие решения
- организационные слабости
Каждый риск нужно:
✔ распознать
✔ оценить
✔ решить — критичен он или нет
Очень быстро становится понятно, что риск это не чекбокс, а контекст.
📚 Зона 2. Framework Matching
NIST, ISO 27001, GDPR
Нужно:
- сопоставлять контроли и стандарты
- видеть пересечения
понимать, почему этот контроль здесь уместен
Фреймворки впервые выглядят не как таблицы, а как инструменты принятия решений.
📝 Зона 3. Policy Drafting
Финал. На основе:
- выявленных рисков
- выбранных стандартов
- нужно переработать политику безопасности.
💡 Система в реальном времени подсвечивает:
- пробелы
- противоречия
- несоответствие рискам
Это почти рабочий день GRC-специалиста.
📊 Реакция студентов
Оценка студентов оказалась неожиданно высокой:
📈 71% показали максимальный уровень вовлечённости
🔥 100% оценили формат: интереснее лекций
⚖️ Сложность «в самый раз», без фрустрации
Студенты начали мыслить
как специалисты, а не как люди, сдающие экзамен.
🔍 Зачем это всё?
Мы живём в момент, когда:
🤖 эссе пишет ИИ
🧠 тесты угадываются
📄 политики копируются
🎓 диплом всё чаще ≠ компетенция
Новые подходы к обучению, типо Escape room возвращают мышление, ответственность и контекст.
Если бы governance так преподавали бы раньше, то
у нас было бы меньше «бумажной безопасности»
и больше реально работающих систем.
🔗 Полезные ссылки
📄 Исследование (arXiv):
👉 https://arxiv.org/abs/2601.10852
🎮 Публичной версии игры пока нет
(это учебный проект UNSW),
но сама архитектура и сценарии подробно описаны в статье.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #CyberSecurity #CyberGovernance #GRC #Gamification #InfosecEducation #AIandEducation #CISO #PolicySecurity
👍1
🕵️ Firehound: приложения из App Store тихо сливают ваши данные
📱 Иллюзия безопасности
Есть удобное убеждение, что если приложение попало в App Store, то значит, его проверили. А если его проверили, то значит, ему можно доверять. Именно на этом ощущении безопасности держится экосистема iOS.
Firehound показывает, насколько это доверие ошибочно.
🔍 С чего все началось?
История началась без эксплойтов, исследователи решили внимательно посмотреть, как iOS-приложения хранят пользовательские данные и куда они реально уходят.
Выяснилось, что backend многих приложений живёт за пределами витрины App Store. Открытые облачные базы, незащищённые API, хранилища без аутентификации. Иногда достаточно было знать правильный URL.
🧩 Firehound
Firehound - это каталог реальных приложений из App Store, у которых данные пользователей оказались доступны извне.
Речь идёт не о маргинальных утилитах, а о популярных AI-ассистентах, образовательных и lifestyle-приложениях.
📉 Масштаб утечек
В одном из задокументированных кейсов исследователи обнаружили сотни миллионов записей: истории AI-чатов, пользовательские идентификаторы, метаданные. Это были реальные диалоги людей, тексты, которые считались приватными.
Данные просто лежали в открытом доступе, потому что для некоторых t2m важнее безопасности.
🤖 Почему особенно опасны AI-приложения
AI-чаты это не просто логи. Люди делятся с ними тем, что не пишут в мессенджерах: сомнениями, страхами, медицинскими и личными вопросами.
При этом backend таких приложений часто собирается в режиме стартап-гонки: быстрее выкатить фичу, быстрее попасть в App Store, быстрее масштабироваться. Threat modeling и аудит остаются «на потом».
⚠️ Я могу посмотреть утекшие данные?
Исследователи сознательно ограничили доступ к деталям, скрыли чувствительные данные и ввели ручную модерацию.
Причина проста: полная публикация превратила бы исследование в инструмент для злоупотреблений. Проблема настолько масштабна, что её опасно показывать целиком.
🏢 Системная проблема экосистемы
Это не ошибка одного разработчика. Это сбой модели доверия. App Store проверяет интерфейс и поведение приложения, но почти не анализирует архитектуру хранения данных. Всё, что происходит за пределами устройства, остаётся вне поля зрения.
Закрытая экосистема ≠ защищённые данные.
🔗 Источники:
➖ Macworld
➖ AppleInsider
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #Firehound #AppStore #iOSSecurity #AIApps #DataLeaks #Privacy #CyberSecurity
📱 Иллюзия безопасности
Есть удобное убеждение, что если приложение попало в App Store, то значит, его проверили. А если его проверили, то значит, ему можно доверять. Именно на этом ощущении безопасности держится экосистема iOS.
Firehound показывает, насколько это доверие ошибочно.
🔍 С чего все началось?
История началась без эксплойтов, исследователи решили внимательно посмотреть, как iOS-приложения хранят пользовательские данные и куда они реально уходят.
Выяснилось, что backend многих приложений живёт за пределами витрины App Store. Открытые облачные базы, незащищённые API, хранилища без аутентификации. Иногда достаточно было знать правильный URL.
🧩 Firehound
Firehound - это каталог реальных приложений из App Store, у которых данные пользователей оказались доступны извне.
Речь идёт не о маргинальных утилитах, а о популярных AI-ассистентах, образовательных и lifestyle-приложениях.
📉 Масштаб утечек
В одном из задокументированных кейсов исследователи обнаружили сотни миллионов записей: истории AI-чатов, пользовательские идентификаторы, метаданные. Это были реальные диалоги людей, тексты, которые считались приватными.
Данные просто лежали в открытом доступе, потому что для некоторых t2m важнее безопасности.
🤖 Почему особенно опасны AI-приложения
AI-чаты это не просто логи. Люди делятся с ними тем, что не пишут в мессенджерах: сомнениями, страхами, медицинскими и личными вопросами.
При этом backend таких приложений часто собирается в режиме стартап-гонки: быстрее выкатить фичу, быстрее попасть в App Store, быстрее масштабироваться. Threat modeling и аудит остаются «на потом».
⚠️ Я могу посмотреть утекшие данные?
Исследователи сознательно ограничили доступ к деталям, скрыли чувствительные данные и ввели ручную модерацию.
Причина проста: полная публикация превратила бы исследование в инструмент для злоупотреблений. Проблема настолько масштабна, что её опасно показывать целиком.
🏢 Системная проблема экосистемы
Это не ошибка одного разработчика. Это сбой модели доверия. App Store проверяет интерфейс и поведение приложения, но почти не анализирует архитектуру хранения данных. Всё, что происходит за пределами устройства, остаётся вне поля зрения.
Закрытая экосистема ≠ защищённые данные.
🔗 Источники:
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #Firehound #AppStore #iOSSecurity #AIApps #DataLeaks #Privacy #CyberSecurity
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🚨 ИИ в кибербезопасности выходит из-под контроля
ИИ в кибербезопасности перестал быть помощником. За последние два года путь был довольно прямым: сначала LLM подсказывали пентестеру, затем начали автоматически выполнять задачи.
Новая работа Alias Robotics фиксирует момент, когда, работающий ранее подход, перестаёт масштабироваться. Дальнейший прогресс упирается не в размер модели, а в то, как именно принимаются решения.
Речь идёт не о «сверхразуме» в популярном смысле, а о системах, которые в отдельных классах задач стабильно превосходят человека по скорости и качеству стратегических решений.
🧑💻 От ассистента к агенту
PentestGPT стал первым массовым примером применения LLM в offensive security. Модель помогала планировать шаги, интерпретировать вывод инструментов и удерживать контекст атаки. Человек при этом оставался в контуре исполнения.
Агент CAI убирает человека из execution loop. AI сам планирует, сам исполняет команды, сам анализирует результаты и корректирует стратегию.
На бенчмарках это даёт кратный выигрыш по времени и стоимости, особенно в реверсе и форензике.
Однако в задачах pwn и crypto человек всё ещё выигрывает, но не за счёт скорости, а за счёт стратегического мышления.
⚠️ Автоматизация и интеллект
Авторы показывают важный предел: автономный агент без стратегической модели остаётся реактивным. Он эффективно выполняет локальные шаги, но плохо оценивает динамику противостояния, повторяет неудачные ходы и демонстрирует нестабильное поведение.
Проблема тут не в качестве LLM. Главная проблема в отсутствии формальной модели противника.
♟️ G-CTR: теория игр на практике
Game-Theoretic Guidance (G-CTR) добавляет агенту символьный уровень рассуждений. Из текущего контекста строится граф атаки, по которому вычисляется равновесие Нэша между атакой и защитой. Результат превращается в компактное стратегическое описание и встраивается в system prompt.
Это резко снижает вариативность поведения и повышает долю успешных сценариев. В Attack & Defense режимах такие агенты стабильно обыгрывают LLM-only системы 🧠
🔄 Ключевые изменения
Ключевой сдвиг в распределении ролей.
Человек перестаёт быть исполнителем и становится наблюдателем и контролёром стратегии.
ИИ берёт на себя не только выполнение, но и принятие решений в рамках формальной модели.
Это рабочая архитектура и серьёзный вызов для процессов, построенных под человеческий темп и человеческое мышление.
🔗 Источник статьи:
➖ https://arxiv.org/abs/2601.14614
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #AIsecurity #Cybersecurity #LLM #AgenticAI #Pentest #SOC #RedTeam #GameTheory #InfoSec
ИИ в кибербезопасности перестал быть помощником. За последние два года путь был довольно прямым: сначала LLM подсказывали пентестеру, затем начали автоматически выполнять задачи.
Новая работа Alias Robotics фиксирует момент, когда, работающий ранее подход, перестаёт масштабироваться. Дальнейший прогресс упирается не в размер модели, а в то, как именно принимаются решения.
Речь идёт не о «сверхразуме» в популярном смысле, а о системах, которые в отдельных классах задач стабильно превосходят человека по скорости и качеству стратегических решений.
🧑💻 От ассистента к агенту
PentestGPT стал первым массовым примером применения LLM в offensive security. Модель помогала планировать шаги, интерпретировать вывод инструментов и удерживать контекст атаки. Человек при этом оставался в контуре исполнения.
Агент CAI убирает человека из execution loop. AI сам планирует, сам исполняет команды, сам анализирует результаты и корректирует стратегию.
На бенчмарках это даёт кратный выигрыш по времени и стоимости, особенно в реверсе и форензике.
Однако в задачах pwn и crypto человек всё ещё выигрывает, но не за счёт скорости, а за счёт стратегического мышления.
⚠️ Автоматизация и интеллект
Авторы показывают важный предел: автономный агент без стратегической модели остаётся реактивным. Он эффективно выполняет локальные шаги, но плохо оценивает динамику противостояния, повторяет неудачные ходы и демонстрирует нестабильное поведение.
Проблема тут не в качестве LLM. Главная проблема в отсутствии формальной модели противника.
♟️ G-CTR: теория игр на практике
Game-Theoretic Guidance (G-CTR) добавляет агенту символьный уровень рассуждений. Из текущего контекста строится граф атаки, по которому вычисляется равновесие Нэша между атакой и защитой. Результат превращается в компактное стратегическое описание и встраивается в system prompt.
Это резко снижает вариативность поведения и повышает долю успешных сценариев. В Attack & Defense режимах такие агенты стабильно обыгрывают LLM-only системы 🧠
🔄 Ключевые изменения
Ключевой сдвиг в распределении ролей.
Человек перестаёт быть исполнителем и становится наблюдателем и контролёром стратегии.
ИИ берёт на себя не только выполнение, но и принятие решений в рамках формальной модели.
Это рабочая архитектура и серьёзный вызов для процессов, построенных под человеческий темп и человеческое мышление.
🔗 Источник статьи:
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #AIsecurity #Cybersecurity #LLM #AgenticAI #Pentest #SOC #RedTeam #GameTheory #InfoSec
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
📖 Почему нейросети помнят то, что должны были забыть
Разбор феномена сублиминального обучения
Вы уже знаете, что если «дообучить» ИИ на новую задачу, то информация о старой все еще будет в "памяти" модели.
На днях вышла статья на Хабр, которая хорошо раскрывает эту тему. Авторы докопались до того, почему модели действительно «помнят» скрытую информацию, даже когда мы её вроде бы удалили.
🧠 Вспомнить всё
Когда мы дообучаем (fine-tune) нейросеть, чтобы адаптировать её к новой задаче, то это выглядит примерно так:
📌 есть модель, которая уже чему-то научилась →
📌 мы хотим «забыть» старое и научить новое →
📌 применяем регуляризацию, оптимизацию и уверены, что прошлое исчезло.
Вреальности оказывается, что информация от прошлой задачи остаётся в структуре весов модели, даже если она не участвует прямо в новой оптимизационной задаче.
🧩 Опыт, как элемент памяти
Оказывается, "забывание" это не просто удаление данных, а удаление следов в ландшафте весов модели, чего в реальности не происходит.
📌 Даже при агрессивной регуляризации сеть всё равно сохраняет прошлую информацию в скрытой структуре весов.
Это называется структурный импринтинг,
когда форма оптимального решения новой задачи строится на топологии, сформированной предыдущим обучением. Такая топология действует как «архитектурная память».
🔍 Эксперимент
Чтобы доказать этот эффект, авторы провели серию экспериментов на небольших сетях:
📌 Модель училась первой задаче А
📌 Затем переходила к задаче B с попыткой забыть А
📌 После этого третья нейросеть пыталась на основе выходов восстановить то, что модель уже должна была забыть
Результат:
🔹 структура прошлого знания сохранялась настолько, что третья модель могла восстановить секретную информацию с точностью до ~98 %, даже когда её не должно было быть видно.
🧠 К чему это всё?
👉 Если ваша модель обучалась на чувствительных данных (например, PII, BERT-подобные embedding-механизмы с секретными маркерами),
👉 а затем вы переобучили её на другую задачу,
то старые «печатные следы» всё равно остаются в весах. Это не баг оптимизатора, это свойство Loss Landscape: локации весов.
🟢 Итого, если вы работаете с моделями, где конфиденциальность или безопасность критична, просто переобучение недостаточно.
Нужно:
🔹 понимать свойства Loss Landscape,
🔹 проектировать безопасность данных на уровне архитектуры, а не тренировки,
🔹 смотреть на проблему privacy-by-design, а не hope-by-regularization.
📌 О том, как сделать так, чтобы модель все-таки "забыла" данные мы писали ранее тут и тут.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #ИИ #машиннообучение #безопасностьML #privacy #нейросети #информационнаябезопасность #MLsecurity #deepLearning
Разбор феномена сублиминального обучения
Вы уже знаете, что если «дообучить» ИИ на новую задачу, то информация о старой все еще будет в "памяти" модели.
На днях вышла статья на Хабр, которая хорошо раскрывает эту тему. Авторы докопались до того, почему модели действительно «помнят» скрытую информацию, даже когда мы её вроде бы удалили.
🧠 Вспомнить всё
Когда мы дообучаем (fine-tune) нейросеть, чтобы адаптировать её к новой задаче, то это выглядит примерно так:
📌 есть модель, которая уже чему-то научилась →
📌 мы хотим «забыть» старое и научить новое →
📌 применяем регуляризацию, оптимизацию и уверены, что прошлое исчезло.
Вреальности оказывается, что информация от прошлой задачи остаётся в структуре весов модели, даже если она не участвует прямо в новой оптимизационной задаче.
🧩 Опыт, как элемент памяти
Оказывается, "забывание" это не просто удаление данных, а удаление следов в ландшафте весов модели, чего в реальности не происходит.
📌 Даже при агрессивной регуляризации сеть всё равно сохраняет прошлую информацию в скрытой структуре весов.
Это называется структурный импринтинг,
когда форма оптимального решения новой задачи строится на топологии, сформированной предыдущим обучением. Такая топология действует как «архитектурная память».
🔍 Эксперимент
Чтобы доказать этот эффект, авторы провели серию экспериментов на небольших сетях:
📌 Модель училась первой задаче А
📌 Затем переходила к задаче B с попыткой забыть А
📌 После этого третья нейросеть пыталась на основе выходов восстановить то, что модель уже должна была забыть
Результат:
🔹 структура прошлого знания сохранялась настолько, что третья модель могла восстановить секретную информацию с точностью до ~98 %, даже когда её не должно было быть видно.
🧠 К чему это всё?
👉 Если ваша модель обучалась на чувствительных данных (например, PII, BERT-подобные embedding-механизмы с секретными маркерами),
👉 а затем вы переобучили её на другую задачу,
то старые «печатные следы» всё равно остаются в весах. Это не баг оптимизатора, это свойство Loss Landscape: локации весов.
🟢 Итого, если вы работаете с моделями, где конфиденциальность или безопасность критична, просто переобучение недостаточно.
Нужно:
🔹 понимать свойства Loss Landscape,
🔹 проектировать безопасность данных на уровне архитектуры, а не тренировки,
🔹 смотреть на проблему privacy-by-design, а не hope-by-regularization.
📌 О том, как сделать так, чтобы модель все-таки "забыла" данные мы писали ранее тут и тут.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #ИИ #машиннообучение #безопасностьML #privacy #нейросети #информационнаябезопасность #MLsecurity #deepLearning
👍3
🤖 Почему корпоративный ИИ всё ещё не меняет бизнес?
Сегодня разберем новый отчет Deloitte "Что реально происходит с ИИ в крупных компаниях"
ИИ уже стал нормой. По данным Deloitte, около 60% сотрудников крупных компаний имеют доступ к одобренным ИИ-инструментам. Но остается проблема: ИИ есть, но он не встроен в повседневную работу. В большинстве случаев он используется как вспомогательный инструмент: для поиска информации, подготовки отчётов и ускорения отдельных задач. Сквозные процессы при этом почти не меняются.
⚙️ От пилотов к продакшену
Только 25 % компаний смогли перевести ИИ-инициативы из экспериментов в промышленную эксплуатацию.
Остальные застряли на стадии пилотов и PoC.
Причина не в технологиях, а в сложности:
➖ интеграция ИИ в бизнес-процессы,
➖ пересмотр архитектуры,
➖ требования безопасности и соответствия,
➖ отсутствие понятных моделей управления.
ИИ внедряется быстрее, чем компании успевают перестроить операционную модель.
🔐 ИИ расширяет поверхность атаки
С ростом корпоративного ИИ появляются новые риски.
ИИ-агенты часто получают слишком широкие права доступа, выходящие за рамки конкретной задачи.
В результате:
➖ традиционные модели контроля доступа перестают работать,
➖ цепочки автоматических действий могут приводить к несанкционированному доступу,
➖ возрастает риск утечек и нарушения внутренних политик.
Компаниям приходится экспериментировать:
✔️ динамические правами доступа,
✔️ внешний контроль действий ИИ,
✔️ независимый аудит агентских операций.
🧠 Агентский ИИ: планы есть, управления нет
Почти 75% организаций планируют внедрение агентского ИИ в ближайшие два года.
При этом только около 20% компаний имеют зрелые модели управления такими агентами.
Это опасная асимметрия. Получается, что автономность растёт быстрее, чем контроль.
Для ИБ-команд это и вовсе означает новый класс рисков: от ошибок автоматизации до полномасштабных инцидентов.
🌍 Sovereign AI
Ещё один прослеживающийся тренд - это Sovereign AI. Компании всё чаще задумываются:
➖ где обучается модель,
➖ где хранятся данные,
➖ какие законы и регуляции применимы.
Для международных и data-driven организаций это становится частью стратегии, а не юридической формальностью.
📌 Что имеем по факту
ИИ в корпорациях:
✔️ широко доступен,
❌ слабо встроен в процессы,
⚠️ создаёт новые риски для безопасности.
Пока основная польза ИИ операционная эффективность, а не трансформация бизнеса.
Революция возможна, но только там, где ИИ внедряется вместе с управлением, архитектурой и безопасностью.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #ИИ #enterpriseAI #AIgovernance #информационнаябезопасность #agenticAI #SovereignAI #RiskManagement
Сегодня разберем новый отчет Deloitte "Что реально происходит с ИИ в крупных компаниях"
ИИ уже стал нормой. По данным Deloitte, около 60% сотрудников крупных компаний имеют доступ к одобренным ИИ-инструментам. Но остается проблема: ИИ есть, но он не встроен в повседневную работу. В большинстве случаев он используется как вспомогательный инструмент: для поиска информации, подготовки отчётов и ускорения отдельных задач. Сквозные процессы при этом почти не меняются.
⚙️ От пилотов к продакшену
Только 25 % компаний смогли перевести ИИ-инициативы из экспериментов в промышленную эксплуатацию.
Остальные застряли на стадии пилотов и PoC.
Причина не в технологиях, а в сложности:
ИИ внедряется быстрее, чем компании успевают перестроить операционную модель.
🔐 ИИ расширяет поверхность атаки
С ростом корпоративного ИИ появляются новые риски.
ИИ-агенты часто получают слишком широкие права доступа, выходящие за рамки конкретной задачи.
В результате:
Компаниям приходится экспериментировать:
✔️ динамические правами доступа,
✔️ внешний контроль действий ИИ,
✔️ независимый аудит агентских операций.
🧠 Агентский ИИ: планы есть, управления нет
Почти 75% организаций планируют внедрение агентского ИИ в ближайшие два года.
При этом только около 20% компаний имеют зрелые модели управления такими агентами.
Это опасная асимметрия. Получается, что автономность растёт быстрее, чем контроль.
Для ИБ-команд это и вовсе означает новый класс рисков: от ошибок автоматизации до полномасштабных инцидентов.
🌍 Sovereign AI
Ещё один прослеживающийся тренд - это Sovereign AI. Компании всё чаще задумываются:
Для международных и data-driven организаций это становится частью стратегии, а не юридической формальностью.
📌 Что имеем по факту
ИИ в корпорациях:
✔️ широко доступен,
❌ слабо встроен в процессы,
⚠️ создаёт новые риски для безопасности.
Пока основная польза ИИ операционная эффективность, а не трансформация бизнеса.
Революция возможна, но только там, где ИИ внедряется вместе с управлением, архитектурой и безопасностью.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #ИИ #enterpriseAI #AIgovernance #информационнаябезопасность #agenticAI #SovereignAI #RiskManagement
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🕷 Вы всё ещё парсите сайты руками? Crawlee идёт к вам!
Веб-скрейпинг перестаёт быть костылём
Веб-скрейпинг обычно начинается с «быстренького скрипта», а заканчивается ночными фикcами после очередного редизайна сайта или бана IP. Команда продукта Crawlee пытается решить это боль для Python.
Crawlee представляет собой новый фреймворк от команды Apify, хорошо знакомой тем, кто хоть раз запускал краулер в продакшене.
⚙️ Системный подход
Crawlee не просто парсер, он обеспечивает сбор данных в виде управляемого сервиса:
🧠 очереди и состояние выполнения,
🔁 ретраи и контроль ошибок,
📦 нормальное хранение результатов,
🧩 масштабирование без переписывания кода.
Всё то, что обычно лепят вручную поверх requests, aiohttp и Playwright, здесь уже встроено на уровне архитектуры.
🌍 HTTP и браузер
Python-версия унаследовала логику JS-Crawlee, но адаптирована под async:
⚡ быстрый HTTP-краулинг для простых сайтов,
🖥 Playwright для SPA и динамики,
🔀 возможность автоматически переключаться между режимами.
Другими словами, вы описываете поведение краулера, а не цепочку запросов.
🔐 Кейсы ИБ
Решение помогает автоматизировать:
🕵️ OSINT и threat intelligence,
🚨 мониторинг фишинговых доменов,
🌐 анализ поверхности атаки,
🧠 сбор данных для ML-моделей и детекторов.
Когда сбор данных идёт неделями, а не «один раз», устойчивость становится важнее скорости.
⚠️ О минусах
➖ Фреймворк пока медленнее простых скриптов,
➖ Решение требует понимания async и архитектуры.
Тем не менее, если вы устали чинить парсеры после каждого изменения сайта, то это скорее плюс, чем минус.
👉 GitHub: https://github.com/apify/crawlee-python
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #Python #webscraping #OSINT #ThreatIntelligence #кибербезопасность #Automation #Crawlee
Веб-скрейпинг перестаёт быть костылём
Веб-скрейпинг обычно начинается с «быстренького скрипта», а заканчивается ночными фикcами после очередного редизайна сайта или бана IP. Команда продукта Crawlee пытается решить это боль для Python.
Crawlee представляет собой новый фреймворк от команды Apify, хорошо знакомой тем, кто хоть раз запускал краулер в продакшене.
⚙️ Системный подход
Crawlee не просто парсер, он обеспечивает сбор данных в виде управляемого сервиса:
🧠 очереди и состояние выполнения,
🔁 ретраи и контроль ошибок,
📦 нормальное хранение результатов,
🧩 масштабирование без переписывания кода.
Всё то, что обычно лепят вручную поверх requests, aiohttp и Playwright, здесь уже встроено на уровне архитектуры.
🌍 HTTP и браузер
Python-версия унаследовала логику JS-Crawlee, но адаптирована под async:
⚡ быстрый HTTP-краулинг для простых сайтов,
🖥 Playwright для SPA и динамики,
🔀 возможность автоматически переключаться между режимами.
Другими словами, вы описываете поведение краулера, а не цепочку запросов.
🔐 Кейсы ИБ
Решение помогает автоматизировать:
🕵️ OSINT и threat intelligence,
🚨 мониторинг фишинговых доменов,
🌐 анализ поверхности атаки,
🧠 сбор данных для ML-моделей и детекторов.
Когда сбор данных идёт неделями, а не «один раз», устойчивость становится важнее скорости.
⚠️ О минусах
Тем не менее, если вы устали чинить парсеры после каждого изменения сайта, то это скорее плюс, чем минус.
👉 GitHub: https://github.com/apify/crawlee-python
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #Python #webscraping #OSINT #ThreatIntelligence #кибербезопасность #Automation #Crawlee
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
🔥 ИИ нашёл 12 уязвимостей в OpenSSL
Все знают, что OpenSSL это криптографический фундамент интернета. HTTPS, TLS, VPN, почта, облака, корпоративные PKI - всё это держится на библиотеке, код которой пишут и переписывают уже больше 25 лет. Казалось бы, здесь давно не осталось сюрпризов.Остались 😁
В январском релизе OpenSSL были закрыты 12 уязвимостей. Все они были обнаружены автономным AI-агентом компании AISLE.
Причём часть багов жила в коде с конца 90-х.
🧠 Кто такие AISLE и что за AI-агент?
AISLE это платформа, которая включает автономный агент статического анализа. Продукт сочетает:
- символьное исполнение,
- моделирование состояний памяти,
- анализ путей выполнения,
и собственный reasoning-движок для поиска логических ошибок.
Ключевое отличие от SAST:
👉 агент не ищет паттерны, а пытается сломать программу в уме, перебирая сценарии, которые человек просто не стал бы проверять вручную.
По сути, это автоматизированный аудитор. Но в отличие от человека он не устаёт и
не пропускает «скучные» ветки.
🔍 Что нашли в OpenSSL?
AI-агент проанализировал кодовую базу OpenSSL и обнаружил много интересностей:
➖ ошибки обработки ASN.1 и CMS,
➖ проблемы в PKCS#7 / PKCS#12,
➖ некорректную работу с памятью,
➖ условия, приводящие к падениям и потенциальной эксплуатации.
Часть уязвимостей была обнаружена ещё до публичного релиза, а для некоторых был сформирован PoC,
предложены исправления.
Что необычно, патчи были приняты мейнтейнерами OpenSSL. Это редкий случай, когда автоматический анализ не просто «нашёл проблему», а дошёл до уровня upstream-фикса.
📌 Ссылки и первоисточники
🔗 Блог AISLE с разбором находок:
https://aisle.com/blog/aisle-discovered-12-out-of-12-openssl-vulnerabilities
🔗 CVE-hub AISLE (пример):
https://aisle.com/cve-hub/CVE-2025-9230
🔗 Сайт AISLE (описание платформы):
https://aisle.com/
Stay secure and read SecureTechTalks 📚
#OpenSSL #Кибербезопасность #ИБ #AISLE #CVE #SecureCode #DevSecOps #AIвИБ #SecurityResearch
Все знают, что OpenSSL это криптографический фундамент интернета. HTTPS, TLS, VPN, почта, облака, корпоративные PKI - всё это держится на библиотеке, код которой пишут и переписывают уже больше 25 лет. Казалось бы, здесь давно не осталось сюрпризов.
В январском релизе OpenSSL были закрыты 12 уязвимостей. Все они были обнаружены автономным AI-агентом компании AISLE.
Причём часть багов жила в коде с конца 90-х.
🧠 Кто такие AISLE и что за AI-агент?
AISLE это платформа, которая включает автономный агент статического анализа. Продукт сочетает:
- символьное исполнение,
- моделирование состояний памяти,
- анализ путей выполнения,
и собственный reasoning-движок для поиска логических ошибок.
Ключевое отличие от SAST:
👉 агент не ищет паттерны, а пытается сломать программу в уме, перебирая сценарии, которые человек просто не стал бы проверять вручную.
По сути, это автоматизированный аудитор. Но в отличие от человека он не устаёт и
не пропускает «скучные» ветки.
🔍 Что нашли в OpenSSL?
AI-агент проанализировал кодовую базу OpenSSL и обнаружил много интересностей:
Часть уязвимостей была обнаружена ещё до публичного релиза, а для некоторых был сформирован PoC,
предложены исправления.
Что необычно, патчи были приняты мейнтейнерами OpenSSL. Это редкий случай, когда автоматический анализ не просто «нашёл проблему», а дошёл до уровня upstream-фикса.
📌 Ссылки и первоисточники
🔗 Блог AISLE с разбором находок:
https://aisle.com/blog/aisle-discovered-12-out-of-12-openssl-vulnerabilities
🔗 CVE-hub AISLE (пример):
https://aisle.com/cve-hub/CVE-2025-9230
🔗 Сайт AISLE (описание платформы):
https://aisle.com/
Stay secure and read SecureTechTalks 📚
#OpenSSL #Кибербезопасность #ИБ #AISLE #CVE #SecureCode #DevSecOps #AIвИБ #SecurityResearch
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3