Открыта регистрация на аналитическую конференцию Код ИБ ИТОГИ в Москве
🗓 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
Forwarded from AISecHub
Model Context Protocol (MCP) Security
- https://github.com/cosai-oasis/ws4-secure-design-agentic-systems/blob/mcp/model-context-protocol-security.md
- https://github.com/cosai-oasis/ws4-secure-design-agentic-systems/blob/mcp/model-context-protocol-security.md
👍1
Из не очевидных для меня моментов по модели как судье- на одном из мероприятий Александр Абрамов обратил внимание, что как судью желательно использовать модель из другого семейства. Например если модель основная квен, то судья Bert, или наоборот.
Причина - модель судья может повторить ошибки рабочей модели.
Причина - модель судья может повторить ошибки рабочей модели.
Forwarded from Всеволод Викулин | AI разбор
А судьи кто? Гайд по LLM-as-a-judge
Оценка качества — ключ к фрейморку успешного AI-проекта. Если вы не овладете этим навыком, любые ваши AI-успехи, если они и будут, окажутся только случайной удачей. Недавно в моей статье мы бегло просмотрели эту тему.
Сегодня погрузимся в самый популярный метод — оценка качества моделей “LLM-as-a-judge”. В нем вместо оценки ответов людьми мы оцениваем ответы другой "LLM-судьей". Тут обычно все шутят, что критиковать всегда проще, чем творить. Мне шутка уже надоела, но законы жанра. Извините.
Когда использовать LLM-as-a-judge?
LLM дешевле, быстрее размечает, не жульничает, но хуже следует сложным инструкциям. Из этого вытекают кейсы, когда этот подход нужно применять вместо разметки людьми.
1) Разметка не слишком интеллектуальная. Она не требует ни:
а) фундаментальных экспертных знаний
б) сложных логических рассуждений
Например, оценить, был ли ответ модели в контексте, LLM-судья может. Но проверить, логически следует ли ответ из контекста, ей будет сложно.
2) Вам нужны очень быстрые итерации.
Гонка, пожар, стартап. Если вам нужно получать оценку качества через часы, а не дни.
3) У вас нет ресурсов.
Не только денег. Обучение разметчиков это обычное преподавание. Это материалы, ответы на вопросы, тесты, экзамены. Регулярные проверки, что они все не забыли и не жульничают. Это требует много сил и отдельного штата специалистов.
Как сделать LLM-судью? Пошаговый план
1) Берем бизнес-эксперта. Человека, который понимает, когда система работает правильно. Вместе с ним прорабатываем критерии, по которым оцениваем. Например, релевантность ответа, безопасность, достоверность и тд.
2) Вместе с экспертом размечаем по критериям репрезентативную корзинку ответов модели. Репрезентативная, значит это случайное подмножество реальных запросов в нашу систему.
3) Переразмечаем, спорим, пока мы с экспертом согласованно не разметим корзинку. Так мы поверяем, что мы сами поняли критерии. В итоге у нас получается «голден корзинка» таких эталонных примеров хороших и плохих ответов.
4) На части этой корзинки тюним LLM-судью. Тестируем итоговое качество на другой части. Тюнить можно по-разному: писать промпты, разбивать задачу на подзадачи (на каждый критерий можно отдельного судью), добавлять агентность. Можно даже файнтюнить LLM. Важно делать это итеративно, как и во всем AI-проекте.
Резюме
Это не просто дешевый, быстрый в разработке подход. Он еще очень гибкий. Если вы хотите поменять критерии качества, намного проще поменять промпты в LLM, чем переучивать 50 людей размечать по-новому.
Если ваша разметка явно не противоречит 3-м пунктам из этого поста, начните с LLM-as-a-judge, а не с разметки людьми. Если не получится, вы всегда сможете часть простых задач разметить LLM, а все сложные отправить людям. Или сможете давать людям LLM-подсказки, чтобы они могли быстрее размечать.
Пробуйте, пишите промпты, замеряйте качество, задавайте мне вопросы. Если оваладете оценкой качества, тогда никакой AI вам не будет страшен.
Оценка качества — ключ к фрейморку успешного AI-проекта. Если вы не овладете этим навыком, любые ваши AI-успехи, если они и будут, окажутся только случайной удачей. Недавно в моей статье мы бегло просмотрели эту тему.
Сегодня погрузимся в самый популярный метод — оценка качества моделей “LLM-as-a-judge”. В нем вместо оценки ответов людьми мы оцениваем ответы другой "LLM-судьей". Тут обычно все шутят, что критиковать всегда проще, чем творить. Мне шутка уже надоела, но законы жанра. Извините.
Когда использовать LLM-as-a-judge?
LLM дешевле, быстрее размечает, не жульничает, но хуже следует сложным инструкциям. Из этого вытекают кейсы, когда этот подход нужно применять вместо разметки людьми.
1) Разметка не слишком интеллектуальная. Она не требует ни:
а) фундаментальных экспертных знаний
б) сложных логических рассуждений
Например, оценить, был ли ответ модели в контексте, LLM-судья может. Но проверить, логически следует ли ответ из контекста, ей будет сложно.
2) Вам нужны очень быстрые итерации.
Гонка, пожар, стартап. Если вам нужно получать оценку качества через часы, а не дни.
3) У вас нет ресурсов.
Не только денег. Обучение разметчиков это обычное преподавание. Это материалы, ответы на вопросы, тесты, экзамены. Регулярные проверки, что они все не забыли и не жульничают. Это требует много сил и отдельного штата специалистов.
Как сделать LLM-судью? Пошаговый план
1) Берем бизнес-эксперта. Человека, который понимает, когда система работает правильно. Вместе с ним прорабатываем критерии, по которым оцениваем. Например, релевантность ответа, безопасность, достоверность и тд.
2) Вместе с экспертом размечаем по критериям репрезентативную корзинку ответов модели. Репрезентативная, значит это случайное подмножество реальных запросов в нашу систему.
3) Переразмечаем, спорим, пока мы с экспертом согласованно не разметим корзинку. Так мы поверяем, что мы сами поняли критерии. В итоге у нас получается «голден корзинка» таких эталонных примеров хороших и плохих ответов.
4) На части этой корзинки тюним LLM-судью. Тестируем итоговое качество на другой части. Тюнить можно по-разному: писать промпты, разбивать задачу на подзадачи (на каждый критерий можно отдельного судью), добавлять агентность. Можно даже файнтюнить LLM. Важно делать это итеративно, как и во всем AI-проекте.
Резюме
Это не просто дешевый, быстрый в разработке подход. Он еще очень гибкий. Если вы хотите поменять критерии качества, намного проще поменять промпты в LLM, чем переучивать 50 людей размечать по-новому.
Если ваша разметка явно не противоречит 3-м пунктам из этого поста, начните с LLM-as-a-judge, а не с разметки людьми. Если не получится, вы всегда сможете часть простых задач разметить LLM, а все сложные отправить людям. Или сможете давать людям LLM-подсказки, чтобы они могли быстрее размечать.
Пробуйте, пишите промпты, замеряйте качество, задавайте мне вопросы. Если оваладете оценкой качества, тогда никакой AI вам не будет страшен.
https://blog.pcisecuritystandards.org/the-ai-exchange-innovators-in-payment-security-featuring-sisa
"...How do you see AI evolving or impacting payment security in the future?
Like any technology disruption in the past, AI is going to have its merits and challenges for payments security. The merits are many - payment fraud detection is getting better, and AI in security solutions is automating several mundane tasks, allowing cybersecurity professionals to focus on higher-value work. For example, SISA launched an Agentic SOC at RSA earlier this year, demonstrating how L1 and L2 tasks can be automated, and we’ve already seen strong adoption of this solution. We’ve also seen AI being used to write reports, review evidence, and perform many tasks that auditors typically find tedious as QSAs..."
"...How do you see AI evolving or impacting payment security in the future?
Like any technology disruption in the past, AI is going to have its merits and challenges for payments security. The merits are many - payment fraud detection is getting better, and AI in security solutions is automating several mundane tasks, allowing cybersecurity professionals to focus on higher-value work. For example, SISA launched an Agentic SOC at RSA earlier this year, demonstrating how L1 and L2 tasks can be automated, and we’ve already seen strong adoption of this solution. We’ve also seen AI being used to write reports, review evidence, and perform many tasks that auditors typically find tedious as QSAs..."
blog.pcisecuritystandards.org
The AI Exchange: Innovators in Payment Security Featuring SISA
In this edition of The AI Exchange, SISA’s Founder and CEO, Dharshan Shanthamurthy, offers insight into how his company is using AI, and how this rapidly growing technology is shaping the future of payment security.
Важно понимать, что это доклад, в своем большинстве, академического сообщества США и Великобритании. Представителей индустрии, органов власти среди авторов доклада нет.
Forwarded from AI SecOps
Обновлен Международный доклад по безопасности ИИ
Опубликовано второе обновление Международного доклада по безопасности ИИ, в котором описаны текущие меры по управлению рисками, связанными с инструментами ИИ.
Что интересно:
1. Атаки хакеров на ИИ успешны в 50% случаев: «Эшелонированная Защита» постоянно прорывается.
Несмотря на то, что разработчики ИИ внедряют стратегию «эшелонированной защиты» (defence-in-depth), комбинируя меры безопасности на этапах обучения, развертывания и мониторинга, этого часто оказывается недостаточно перед лицом изощренных злоумышленников.
Вывод: Это демонстрирует динамичный ландшафт «атака-защита»: разработчики совершенствуют методы, но хакеры постоянно находят новые способы вызвать нежелательное поведение.
2. Угроза «Отравления данных» делает атаки на ИИ невероятно дешевыми.
Источники подчеркивают опасный дисбаланс ресурсов между защитой и нападением: создание надежных систем дорого и сложно, тогда как их компрометация может быть удивительно дешевой.
Вывод: Низкая стоимость проведения атак «отравления данных» по сравнению со стоимостью разработки и поддержания надежных защитных механизмов создает серьезный риск для целостности и надежности систем ИИ.
3. Мощный ИИ с открытым кодом стал инструментом для создания незаконного контента.
Рост моделей с открытыми весами (open-weight models) — моделей, параметры которых свободно доступны для загрузки и модификации — резко изменил ландшафт рисков, поскольку контроль над ними утрачивается.
Вывод: Открытость способствует инновациям и прозрачности, но она также делает контроль за модификацией и использованием моделей практически невозможным, что подчеркивает, почему технические меры по управлению рисками для открытых моделей остаются незрелыми.
Опубликовано второе обновление Международного доклада по безопасности ИИ, в котором описаны текущие меры по управлению рисками, связанными с инструментами ИИ.
Что интересно:
1. Атаки хакеров на ИИ успешны в 50% случаев: «Эшелонированная Защита» постоянно прорывается.
Несмотря на то, что разработчики ИИ внедряют стратегию «эшелонированной защиты» (defence-in-depth), комбинируя меры безопасности на этапах обучения, развертывания и мониторинга, этого часто оказывается недостаточно перед лицом изощренных злоумышленников.
Вывод: Это демонстрирует динамичный ландшафт «атака-защита»: разработчики совершенствуют методы, но хакеры постоянно находят новые способы вызвать нежелательное поведение.
2. Угроза «Отравления данных» делает атаки на ИИ невероятно дешевыми.
Источники подчеркивают опасный дисбаланс ресурсов между защитой и нападением: создание надежных систем дорого и сложно, тогда как их компрометация может быть удивительно дешевой.
Вывод: Низкая стоимость проведения атак «отравления данных» по сравнению со стоимостью разработки и поддержания надежных защитных механизмов создает серьезный риск для целостности и надежности систем ИИ.
3. Мощный ИИ с открытым кодом стал инструментом для создания незаконного контента.
Рост моделей с открытыми весами (open-weight models) — моделей, параметры которых свободно доступны для загрузки и модификации — резко изменил ландшафт рисков, поскольку контроль над ними утрачивается.
Вывод: Открытость способствует инновациям и прозрачности, но она также делает контроль за модификацией и использованием моделей практически невозможным, что подчеркивает, почему технические меры по управлению рисками для открытых моделей остаются незрелыми.