Forwarded from Порвали два трояна
Аккурат к новому циклу бюджетирования IANS подвёз исследование о тратах на ИБ, составленное по опросу почти 600 CISO из разных стран и вертикалей бизнеса. Хотя выводы делались для западных компаний, большинство наблюдений актуальны и для наших широт.
Авторы отчёта советуют CISO внимательно смотреть на нужды бизнеса, расставлять приоритеты и соразмерять аппетиты:
#CISO @П2Т
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html
Сильный голос Google за - использовать memory safe Rust для снижения расходов на поиск, устранение и компенсирующие меры для уязвимостей. Приятный плюс - уменьшение до 4 раз количество откатов новых сборок.
Сильный голос Google за - использовать memory safe Rust для снижения расходов на поиск, устранение и компенсирующие меры для уязвимостей. Приятный плюс - уменьшение до 4 раз количество откатов новых сборок.
Google Online Security Blog
Rust in Android: move fast and fix things
Posted by Jeff Vander Stoep, Android Last year, we wrote about why a memory safety strategy that focuses on vulnerability prevention in ...
https://techcommunity.microsoft.com/blog/windows-itpro-blog/native-sysmon-functionality-coming-to-windows/4468112
В следующие релизы Win 11 и Server 2025 будет добавлен Symon, полезный инструмент для расширенного сбора логов.
В следующие релизы Win 11 и Server 2025 будет добавлен Symon, полезный инструмент для расширенного сбора логов.
TECHCOMMUNITY.MICROSOFT.COM
Native Sysmon functionality coming to Windows | Microsoft Community Hub
Learn how to eliminate manual deployment and reduce operational risk with Sysmon functionality in Windows.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1308.2pd.pdf вторая версия проекта рекомендаций быстрого внедрения треьований безопасности по фреймворку NIST CSF 2.0.
Открыта регистрация на аналитическую конференцию Код ИБ ИТОГИ в Москве
🗓 4 декабря | Начало в 9:30
📍 Palmira Business Club
Участие бесплатное по предварительной регистрации
Выглядит интересной дискуссия по итогу года от CISO лидеров рынка в РФ, секция по безопасной разработке и секция по анализу уязвимостей.
https://codeib.ru/event/kod-ib-itogi-moskva-2025-863/page/vvedenie-kod-ib-itogi-moskva-2024
🗓 4 декабря | Начало в 9:30
📍 Palmira Business Club
Участие бесплатное по предварительной регистрации
Выглядит интересной дискуссия по итогу года от CISO лидеров рынка в РФ, секция по безопасной разработке и секция по анализу уязвимостей.
https://codeib.ru/event/kod-ib-itogi-moskva-2025-863/page/vvedenie-kod-ib-itogi-moskva-2024
Интересный отчет по рынку труда в дарквебе, пригодится для учета в вашей модели нарушителя.
Основной вывод - рынок труда в Дарквебе незначительно отстаёт от общих трендов, но тренды все равно общие.
https://securelist.com/dark-web-job-market-2023-2025/118057/
Основной вывод - рынок труда в Дарквебе незначительно отстаёт от общих трендов, но тренды все равно общие.
https://securelist.com/dark-web-job-market-2023-2025/118057/
Securelist
Inside the dark web job market
This report examines how employment and recruitment function on the dark web, based on over 2,000 job-related posts collected from shadow forums between January 2023 and June 2025.
Оценка будущего AI Security.
Мне кажется, что все у направление только впереди, вопрос только в том, что через год будет запрос на скилы или чуть позже.
Мне кажется, что все у направление только впереди, вопрос только в том, что через год будет запрос на скилы или чуть позже.
Forwarded from PWN AI (Artyom Semenov)
Почему AI Security НЕ умирает?
В последние месяцы меня не покидала мысль, что направление, которое мы обсуждаем в канале, катастрофически никому не нужно. И тому есть множество причин. Бизнесу важна гонка за фичами, а не защита от adversarial-атак или инверсии моделей — как в статьях на ArXiv. Кибербезопасность в большинстве компаний сводится к борьбе с Shadow AI: предотвращению утечек через неконтролируемое использование ИИ сотрудниками.
CISO выгоднее закрыть этот вопрос с помощью DLP, забыть о нём и не возвращаться к теме ИИ. Ведь историй, связанных с реальными инцидентами, пока немного. Большинство из них, если посмотреть на AVID, относятся либо к человеческому фактору (непреднамеренное удаление/слив данных), либо к Safety (вопросы этики и вредоносного влияния чат-ботов на пользователей). Из-за этого не создаётся впечатления, что атаки на ИИ — это нечто высокотехнологичное. Следовательно, зачем тратить бюджет на защиту от adversarial-атак или чего-то подобного? Промпт-инъекции и вовсе кажутся нерешаемой проблемой в рамках текущих архитектур LLM. Модель, к сожалению, всегда можно сбить с толку — это подтверждает масса твитов от Pliny.
Я не раз вживую обсуждал с представителями рынка вопрос: «А выживем ли мы?». Многие считали, что да, ведь в тот момент зарождался рынок, порождавший LLM-файерволы и бесконечные маркетинговые лозунги о том, что ИИ нужно защищать прежде всего от утечек PII.
Но что сейчас? Вы заметили, что Claude и OpenAI уже решают эту проблему на уровне своих моделей? Да, неточно, да, не полностью — но решают. Кажется, что первая волна стартапов в сфере AI Security гибнет: кто-то проваливается под лёд, а кого-то (как ProtectAI) поглощают крупные ИБ-вендоры.
Складывается ощущение, что безопасность ИИ должна стать сервисом внутри экосистемы, а не продуктом отдельной компании. Гиганты сразу встраивают свои защитные механизмы (AWS Bedrock Guardrails, Microsoft Azure AI Content Safety, Google Cloud Security AI Framework), лишая сторонних игроков возможности снимать сливки с рынка.
ИИ в компаниях — уже не просто API над ChatGPT, а сложная инфраструктура с потоками данных и документацией. Но кадровый разрыв огромен.
Так почему я всё-таки убеждён, что мировой рынок не умирает?
Рынок AI Security не умирает — он совершает необходимую эволюцию от гипертрофированного хайпа к фундаментальной зрелости. Мы наблюдаем не исчезновение, а трансформацию: безопасность ИИ «переваривается» индустрией, переходя из слоя разрозненных продуктов в саму ткань корпоративных процессов и платформ.
Регуляторика. Давление в мире, особенно со стороны EU AI Act с его обязательными оценками соответствия и требованиями к документированию рисков, может стать мощнейшим драйвером. Бюджеты перенаправляются уже не из кибербезопасности, а из юридических и комплаенс-департаментов, поэтому общие расходы на безопасность ИИ продолжают расти.
Новые векторы атак. Переход от простых чат-ботов к агентным системам создает качественно новые угрозы. Для защиты от них уже требуются специализированные решения уровня Action Firewalls, анализирующие не только ввод и вывод, но и поведение. Их просто пока нет на рынке.
Фундаментальная потребность в доверии к ИИ никуда не исчезает. Она лишь обретает более зрелые формы: мы переходим от эпохи маркетинговых обещаний к эре институционального управления рисками, где безопасность становится не отдельным продуктом, а «невидимым», но в то же время критически важным слоем цифровой инфраструктуры. Технологии защиты никуда не денутся — они станут базовой частью всего, что мы строим с помощью ИИ.
В последние месяцы меня не покидала мысль, что направление, которое мы обсуждаем в канале, катастрофически никому не нужно. И тому есть множество причин. Бизнесу важна гонка за фичами, а не защита от adversarial-атак или инверсии моделей — как в статьях на ArXiv. Кибербезопасность в большинстве компаний сводится к борьбе с Shadow AI: предотвращению утечек через неконтролируемое использование ИИ сотрудниками.
CISO выгоднее закрыть этот вопрос с помощью DLP, забыть о нём и не возвращаться к теме ИИ. Ведь историй, связанных с реальными инцидентами, пока немного. Большинство из них, если посмотреть на AVID, относятся либо к человеческому фактору (непреднамеренное удаление/слив данных), либо к Safety (вопросы этики и вредоносного влияния чат-ботов на пользователей). Из-за этого не создаётся впечатления, что атаки на ИИ — это нечто высокотехнологичное. Следовательно, зачем тратить бюджет на защиту от adversarial-атак или чего-то подобного? Промпт-инъекции и вовсе кажутся нерешаемой проблемой в рамках текущих архитектур LLM. Модель, к сожалению, всегда можно сбить с толку — это подтверждает масса твитов от Pliny.
Я не раз вживую обсуждал с представителями рынка вопрос: «А выживем ли мы?». Многие считали, что да, ведь в тот момент зарождался рынок, порождавший LLM-файерволы и бесконечные маркетинговые лозунги о том, что ИИ нужно защищать прежде всего от утечек PII.
Но что сейчас? Вы заметили, что Claude и OpenAI уже решают эту проблему на уровне своих моделей? Да, неточно, да, не полностью — но решают. Кажется, что первая волна стартапов в сфере AI Security гибнет: кто-то проваливается под лёд, а кого-то (как ProtectAI) поглощают крупные ИБ-вендоры.
Складывается ощущение, что безопасность ИИ должна стать сервисом внутри экосистемы, а не продуктом отдельной компании. Гиганты сразу встраивают свои защитные механизмы (AWS Bedrock Guardrails, Microsoft Azure AI Content Safety, Google Cloud Security AI Framework), лишая сторонних игроков возможности снимать сливки с рынка.
ИИ в компаниях — уже не просто API над ChatGPT, а сложная инфраструктура с потоками данных и документацией. Но кадровый разрыв огромен.
Так почему я всё-таки убеждён, что мировой рынок не умирает?
Рынок AI Security не умирает — он совершает необходимую эволюцию от гипертрофированного хайпа к фундаментальной зрелости. Мы наблюдаем не исчезновение, а трансформацию: безопасность ИИ «переваривается» индустрией, переходя из слоя разрозненных продуктов в саму ткань корпоративных процессов и платформ.
Регуляторика. Давление в мире, особенно со стороны EU AI Act с его обязательными оценками соответствия и требованиями к документированию рисков, может стать мощнейшим драйвером. Бюджеты перенаправляются уже не из кибербезопасности, а из юридических и комплаенс-департаментов, поэтому общие расходы на безопасность ИИ продолжают расти.
Новые векторы атак. Переход от простых чат-ботов к агентным системам создает качественно новые угрозы. Для защиты от них уже требуются специализированные решения уровня Action Firewalls, анализирующие не только ввод и вывод, но и поведение. Их просто пока нет на рынке.
Фундаментальная потребность в доверии к ИИ никуда не исчезает. Она лишь обретает более зрелые формы: мы переходим от эпохи маркетинговых обещаний к эре институционального управления рисками, где безопасность становится не отдельным продуктом, а «невидимым», но в то же время критически важным слоем цифровой инфраструктуры. Технологии защиты никуда не денутся — они станут базовой частью всего, что мы строим с помощью ИИ.
👍1
Forwarded from Борис_ь с ml
Взгляд изнутри
На безопасность ИИ
#иб_для_ml
Работая в любой сфере, нельзя не задаваться вопросом, а что ждет меня завтра, как специалиста в таком-то деле.
В нашей зарождающейся отрасли, как и в любой, наверное, молодой сфере знаний, бытует мнение, что поезд только набирает ход, и надо в такую актуальную тему погружаться.
Но важно понимать, что безопасность ИИ не существует в вакууме. Ее развитие взаимосвязано с развитием, в первую очередь, самого ИИ, и IT-отрасли в целом. И эта взаимосвязь порождает как развивающую силу, так и тормозящую.
Факторы торможения
▶️ 80% уязвимостей возможны только для GenAI, и PredAI практически не порождает у бизнеса запрос в безопасности ИИ
▶️ Качество моделей (и систем) GenAI нестабильно и недостаточно, чтобы меры безопасности воспринимались спокойно: ИИ-гонка идет в жестких условиях, права на отставание нет
▶️ Отсутствие критичных применений ИИ-систем в бизнесе, имеющих реальные уязвимости и угрозы
▶️ Отсутствие инцидентов-пугалок со значимым ущербом, которые бы служили наглядным примером необходимости делать AI Sec (основываясь например на AIID)
Как можно заметить, каждая причина торможения вытекает из предыдущей: для AI Sec важен только GenAI, GenAI пока внедряется плохо, из-за этого поверхность атаки минимальная, из-за этого и инцидентов нет.
Так что же, все плохо? Ведь все как по классике информационной безопасности, "самый безопасный канал передачи информации - тот, которого не существует".
Например, AI-агенты, главная суть которых - совершать действия в реальном мире, в дорогих и критичных процессах ничего не делают, 80% это просто суммаризация, а оставшиеся 20% - используют исключительно инструменты получения информации. А ведь сколько различных угроз, сценариев и прочего придумано для AI-агентов...
Кажется, что безопасность ИИ обгоняет свое время. Очень странная ситуация. Однако в истории такое бывало.
Исторические примеры
— Здравоохранение. В 1847 году Игнац Земмельвейс ввёл обязательную дезинфекцию рук врачей, что сочли избыточной и оскорбительной мерой, но резкое падение смертности и последующее признание антисептики доказали её абсолютную правоту.
— Безопасность в автомобилях. В 1959 году трёхточечные ремни безопасности Volvo поначалу воспринимались как неудобная и лишняя перестраховка, но последующая статистика спасённых жизней сделала их и другие решения пассивной безопасности отраслевым стандартом.
— И таких примеров много: безопасность ядерной энергетики, защита от стихийных бедствий.
Какие же позитивные факторы остаются у безопасности ИИ, с точки зрения ее роста?
Факторы роста
⚡️ Появляются новые, более перспективные архитектуры, чем LLM. Я считаю, что в развитии AI есть четыре перспективных направления сейчас:
— совмещение диффузионных и трансформерных архитектур (1, 2, 3),
— построение моделей без разделения на обучение и инференс (спайковые нейросети - 1, 2, или например Google NL), что намного более похоже на естественный интеллект.
— кардинальное уменьшение размеров моделей. Пример - SLM, (1, 2, 3, 4)
— переход от предсказания токенов к предсказанию смысла ответа (модели семейства JEPA от группы Ле Куна)
⚡️ Применение ИИ явно будет требовать развития его влияния на реальный мир: роботы, биоинженерные системы (нейроинтерфейсы и пр.), космические аппараты, и многие другие направления. Утверждать, что ИИ так и останется "читателем" статей, вряд ли кто-то готов.
⚡️ Стране необходим суверенный ИИ. Об этом и Президент заявил на AI Journey в ноябре 2025, и это отражается в позиции регулятора: приказ ФСТЭК №117, разработка ГОСТов совместно с ИСП РАН, деятельность форума ТДИИ.
Вывод
Исторические примеры показывают нам, что безопасность может обгонять бизнес, и далеко не всегда это ошибочная перестраховка. Я верю, что AI Sec в будущем будет точно так же спасать жизни, как в свое время гигена и автомобильные ремни. Тем более что этому сопутствуют несколько значительных факторов роста технологий.
P.S. Тема возникла из последних разговоров с друзьями, и из опыта за год работы в сфере. Накопилось. Артем тоже высказался по этой теме, рекомендую ознакомиться.
На безопасность ИИ
#иб_для_ml
Работая в любой сфере, нельзя не задаваться вопросом, а что ждет меня завтра, как специалиста в таком-то деле.
В нашей зарождающейся отрасли, как и в любой, наверное, молодой сфере знаний, бытует мнение, что поезд только набирает ход, и надо в такую актуальную тему погружаться.
Но важно понимать, что безопасность ИИ не существует в вакууме. Ее развитие взаимосвязано с развитием, в первую очередь, самого ИИ, и IT-отрасли в целом. И эта взаимосвязь порождает как развивающую силу, так и тормозящую.
Факторы торможения
Как можно заметить, каждая причина торможения вытекает из предыдущей: для AI Sec важен только GenAI, GenAI пока внедряется плохо, из-за этого поверхность атаки минимальная, из-за этого и инцидентов нет.
Так что же, все плохо? Ведь все как по классике информационной безопасности, "самый безопасный канал передачи информации - тот, которого не существует".
Например, AI-агенты, главная суть которых - совершать действия в реальном мире, в дорогих и критичных процессах ничего не делают, 80% это просто суммаризация, а оставшиеся 20% - используют исключительно инструменты получения информации. А ведь сколько различных угроз, сценариев и прочего придумано для AI-агентов...
Кажется, что безопасность ИИ обгоняет свое время. Очень странная ситуация. Однако в истории такое бывало.
Исторические примеры
— Здравоохранение. В 1847 году Игнац Земмельвейс ввёл обязательную дезинфекцию рук врачей, что сочли избыточной и оскорбительной мерой, но резкое падение смертности и последующее признание антисептики доказали её абсолютную правоту.
— Безопасность в автомобилях. В 1959 году трёхточечные ремни безопасности Volvo поначалу воспринимались как неудобная и лишняя перестраховка, но последующая статистика спасённых жизней сделала их и другие решения пассивной безопасности отраслевым стандартом.
— И таких примеров много: безопасность ядерной энергетики, защита от стихийных бедствий.
Какие же позитивные факторы остаются у безопасности ИИ, с точки зрения ее роста?
Факторы роста
— совмещение диффузионных и трансформерных архитектур (1, 2, 3),
— построение моделей без разделения на обучение и инференс (спайковые нейросети - 1, 2, или например Google NL), что намного более похоже на естественный интеллект.
— кардинальное уменьшение размеров моделей. Пример - SLM, (1, 2, 3, 4)
— переход от предсказания токенов к предсказанию смысла ответа (модели семейства JEPA от группы Ле Куна)
Вывод
Исторические примеры показывают нам, что безопасность может обгонять бизнес, и далеко не всегда это ошибочная перестраховка. Я верю, что AI Sec в будущем будет точно так же спасать жизни, как в свое время гигена и автомобильные ремни. Тем более что этому сопутствуют несколько значительных факторов роста технологий.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Порвали два трояна
This media is not supported in your browser
VIEW IN TELEGRAM
Эксперты «Лаборатории Касперского» начали подводить итоги года — в этом году ключевые тенденции, значимые события и прогнозы на 2026 сгруппированы по отраслям.
Начнём с финансовой отрасли.
Злоумышленники освоили атаки на цепочку поставок, где компрометация подрядчиков иногда приводила к последствиям даже для национальных платёжных систем (злоупотребление системой PIX в Бразилии).
Преступные группы всё чаще совмещают физические и цифровые методы для повышения эффективности мошенничества, например подкупают инсайдеров в атакуемой компании. В целом киберпреступность и традиционная организованная преступность постепенно сливаются.
#статистика @П2Т
Please open Telegram to view this post
VIEW IN TELEGRAM
https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-regulation-proposal
Опубликован проект правок в GDPR.
Основные планируемые изменения:
1. Если у конкретного контроллера нет возможности на основе данных нет возможности идентифицировать субъекта ПДн - данные не персональные.
2. Увеличение срока уведомления до 96 часов.э с 72.
3. Чуть более явное описание использования данных для ИИ, в частности снят запрет для использования спецкатегорий ПДн для нужд ИИ.
4.Облегчено требование по наличию баннеров если, например, куки технические или для нужд безопасности.
Опубликован проект правок в GDPR.
Основные планируемые изменения:
1. Если у конкретного контроллера нет возможности на основе данных нет возможности идентифицировать субъекта ПДн - данные не персональные.
2. Увеличение срока уведомления до 96 часов.э с 72.
3. Чуть более явное описание использования данных для ИИ, в частности снят запрет для использования спецкатегорий ПДн для нужд ИИ.
4.Облегчено требование по наличию баннеров если, например, куки технические или для нужд безопасности.
Shaping Europe’s digital future
Digital Omnibus Regulation Proposal
The Digital Omnibus proposal includes a set of technical amendments to a large corpus of digital legislation, selected to bring immediate relief to businesses, public administrations, and citizens alike, and to stimulate competitiveness.
👍1
Forwarded from Листок бюрократической защиты информации
Рекомендации от спуфинг атак.pdf
178.5 KB
На сайте ФСТЭК России опубликованы Рекомендации по настройке механизмов безопасности почтовых сервисов от атак, связанных с подменой отправителя (спуфинг-атак), предназначенные для предотвращение «фишинговых» атак, связанных с подменой отправителя.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Солдатов в Телеграм
How to build AI agents into your SOC
Одним из положительных моментов путешествий является избыток свободного времени в аэропорту. На этот раз, по пути домой в столицу, мне наконец-то удалось закончить ознакомление с замечательным гайдом от Red Canary по созданию надежных и эффективных AI-агентов для интеграции в операционную работу SOC. Тема мне небезразлична, поэтому поделюсь мыслями из доки. Сразу замечу, что если вы уже имеете хоть какой-то практический опыт написания агентов, хотя бы на уровне упомянутого здесь курса, то дока покажется вам скучной, но для начинающих джедаев материал может стать неплохой базой, упорядочивающей понимание и перечисляющей очевидные грабли, которые можно обойти.
Мы все немного скептически относимся к формализации процессов, и я сам нередко пропагандирую fuckup-driven management, однако, в случае передачи чего-либопрограммному болвану AI-агенту, никакая формализация не может быть лишней. Основной тезис документа: надежность важнее новизны, поэтому ключ к успеху лежит не в использовании самой передовой модели, а в построении детерминированных рабочих процессов, строгих ограничений и постоянном измерении результатов. Документ содержит не только теоретические основы, но и практические примеры на Git, а кто любит за трапезой посмотреть что-то полезное есть видео на Youtube Elevate and empower your SOC with AI.
Ключевые принципы построения надежных AI-агентов
1. Структура и Детерминизм. Большие языковые модели по своей природе вероятностны и могут давать разные результаты при одних и тех же входных данных. Для SOC это недопустимо, так как критически важна повторяемость, поэтому Канарейки рекомендуют использовать детерминированную оркестрацию в сочетании с ограниченным рассуждением агентов: задачи разбиваются на явные, небольшие шаги, а агенты используются только там, где их вероятностная природа может приносить пользу (например, для анализа и корреляции), а не для принятия ключевых решений.
2. Дизайн системы, а не одной модели. Ценность извлекается из взаимодействия дизайна workflow, защитных механизмов и выбора моделей, т.е. вместо одного "универсального" агента следует строить сложные системы из простых, узкоспециализированных компонентов. Четкое выделение простых детерменированных шагов для агента прекрасно бьется и с мнением моих друзей, съевших не одну собаку на автоматизации SOC с помощью AI-агентов.
Документ разбирает кейс автоматизации анализа данных OSQuery с конечных точек. В частности, Аналитик может тратить 30+ минут на полуручной разбор десятков JSON-файлов, тогда как AI-агенты могут сократить это время до 2 мин. Для этого создаются несколько узкоспециализированных агентов, каждый из которых отвечает за свою категорию данных OSQuery, например, агент программного обеспечения, агент файловой системы, агент пользователей и групп, агент WMI-событий, и т.п. Для оркестрации используются специализированные агенты, запускаемые параллельно, а их результаты затем агрегируются в единый отчет. Для управления таким workflow используются фреймворки вроде LangGraph.
В документе также освещаются вопросы выбора и оптимизации моделей и безопасности. Интересно почитать о том, как Канарейки пишут об использовании агентов у себя, конечно, по возможности, счищая весь налет маркетинга. В целом, ребята не испытывают беспокойства, используя доступные из облака LLM, поэтому клиентам Red Canary, возможно, имеет смысл обратить внимание на то, что их данные доступны помимо MSSP (Канарейки) и IaaS (Microsoft), но и провайдерам LLM (OpenAI, Google), в общем, поверхность атаки расширяется.
#ml #MDR
Одним из положительных моментов путешествий является избыток свободного времени в аэропорту. На этот раз, по пути домой в столицу, мне наконец-то удалось закончить ознакомление с замечательным гайдом от Red Canary по созданию надежных и эффективных AI-агентов для интеграции в операционную работу SOC. Тема мне небезразлична, поэтому поделюсь мыслями из доки. Сразу замечу, что если вы уже имеете хоть какой-то практический опыт написания агентов, хотя бы на уровне упомянутого здесь курса, то дока покажется вам скучной, но для начинающих джедаев материал может стать неплохой базой, упорядочивающей понимание и перечисляющей очевидные грабли, которые можно обойти.
Мы все немного скептически относимся к формализации процессов, и я сам нередко пропагандирую fuckup-driven management, однако, в случае передачи чего-либо
Ключевые принципы построения надежных AI-агентов
1. Структура и Детерминизм. Большие языковые модели по своей природе вероятностны и могут давать разные результаты при одних и тех же входных данных. Для SOC это недопустимо, так как критически важна повторяемость, поэтому Канарейки рекомендуют использовать детерминированную оркестрацию в сочетании с ограниченным рассуждением агентов: задачи разбиваются на явные, небольшие шаги, а агенты используются только там, где их вероятностная природа может приносить пользу (например, для анализа и корреляции), а не для принятия ключевых решений.
2. Дизайн системы, а не одной модели. Ценность извлекается из взаимодействия дизайна workflow, защитных механизмов и выбора моделей, т.е. вместо одного "универсального" агента следует строить сложные системы из простых, узкоспециализированных компонентов. Четкое выделение простых детерменированных шагов для агента прекрасно бьется и с мнением моих друзей, съевших не одну собаку на автоматизации SOC с помощью AI-агентов.
Документ разбирает кейс автоматизации анализа данных OSQuery с конечных точек. В частности, Аналитик может тратить 30+ минут на полуручной разбор десятков JSON-файлов, тогда как AI-агенты могут сократить это время до 2 мин. Для этого создаются несколько узкоспециализированных агентов, каждый из которых отвечает за свою категорию данных OSQuery, например, агент программного обеспечения, агент файловой системы, агент пользователей и групп, агент WMI-событий, и т.п. Для оркестрации используются специализированные агенты, запускаемые параллельно, а их результаты затем агрегируются в единый отчет. Для управления таким workflow используются фреймворки вроде LangGraph.
В документе также освещаются вопросы выбора и оптимизации моделей и безопасности. Интересно почитать о том, как Канарейки пишут об использовании агентов у себя, конечно, по возможности, счищая весь налет маркетинга. В целом, ребята не испытывают беспокойства, используя доступные из облака LLM, поэтому клиентам Red Canary, возможно, имеет смысл обратить внимание на то, что их данные доступны помимо MSSP (Канарейки) и IaaS (Microsoft), но и провайдерам LLM (OpenAI, Google), в общем, поверхность атаки расширяется.
#ml #MDR
YouTube
Elevate and empower your SOC with AI
#aiagent #ai #securityoperations #cybersecurity #cybersecurityexperts
Chapters:
00:00 - 25:22: Demo of Red Canary's AI powered SOC
25:23 - 59:37: Q&A with Brian and Jimmy
Follow us:
https://www.twitter.com/RedCanary
https://www.linkedin.com/company/redcanary…
Chapters:
00:00 - 25:22: Demo of Red Canary's AI powered SOC
25:23 - 59:37: Q&A with Brian and Jimmy
Follow us:
https://www.twitter.com/RedCanary
https://www.linkedin.com/company/redcanary…
Forwarded from Солдатов в Телеграм
HowToBuildAIagentsIntoyourSOC_RedCanary.pdf
3.6 MB
Red Canary. How to build AI agents into your SOC