Тунтсайоки - Тумча. Август 2025

Через несколько часов мой старый знакомый, поезд Москва - Мурманск, увезет меня в поход. Не уверен, что там у меня будет стабильная связь, но, в любом случае, готовить заметки я буду уже после возвращения. А сейчас делюсь нашим планом (картинка), описанием из Интернета (pdf), картой маршрута, и видео с ожидаемыми порогами.

Состав нашей группы: четыре каяка, два катамарана-четверки (К4), два катамарана-двойки (К2). Я иду тем же составом, что и в прошлом году: я, старший и младший (пассажир на нашем К4).

В этот раз наш капитан поручил мне вести дневник нашего путешествия и, затем, подготовить описание. Очень буду стараться не обмануть его доверие, поэтому, надеюсь, подробный рассказ о наших приключениях будет у меня из первых рук, конечно же, поделюсь с вами.

Будем на связи!

#здоровье

Пока я плавал по плёсо-порожистым речкам Мурманской области Роскомнадзор ввел частичные ограничения на голосовые и видеозвонки в мессенджерах Telegram и WhatsApp. Решение является мероприятием по борьбе с мошенниками, использующими эти мессенджеры для связи с жертвами, и блокировка в общем случае объясняется заботой о гражданах, несмотря на то, что теперь вместо бесплатных звонков через приложение придется чаще использовать дорожающую мобильную связь.

Ну раз Роскомнадзор считает, что мобильная связь безопасна и мошенники ее не используют для связи с жертвами (раз мобильная связь не заблокирована), то мобильным операторам следует соответствовать, а регулятору, сказав "А", следует сказать и "Б": возложить ответственность за мошенничество на мобильных операторов, т.е. сделать второй шаг в заботе о гражданах - если гражданину прозвонился мошенник, то гражданин может удобно стукнуть об этом регулятору, который обяжет оператора компенсировать ущерб гражданину.

А то выглядит как лоббирование своих интересов операторами - это и не плохо, просто получив преимущества и поддержку, нужно брать на себя обязательства и ответственность!

#РФ

Подсознательное обучение

Чем больше мы изучаем ИИ, тем больше находим сходств с "естественным интеллектом", далее буду писать ЕИ. В статье про креативность я сравнивал собственные подходы к созданию "нового" с тем, как работает LLM, и на каком-то уровне абстракции не нашел принципиальных отличий.

Но вот и новое исследование (статья, код) показывает, что Модель-ученик, обучаемая на выводе другой Модели-учителя, перенимает черты учителя, причем даже если обучающий материал не связан с этими чертами учителя. Любопытно, что пока подтверждена такая неявная передача особенностей учителя ученику только если и у учителя и у ученика используются схожие базовые модели. Исследование идет немного далее и утверждает, что выявленное "подсознательное обучение" является общим свойством нейросетей.

Приведенные результаты имеют большое значение для разработки ИИ, так как простое отсеивание некорректного поведения из данных может оказаться недостаточным для предотвращения формирования у модели нежелательных свойств, которые, безусловно, отразятся на ее выдаче. Очередная капля в важность вопроса доверенности ИИ

#ml

P&L атаки

Есть такой старый постулат, что все наши усилия в ИБ должны повысить стоимость атаки настолько, чтобы атакующему было неинтересно нас атаковать, чтобы P&L проекта атаки был отрицательным. Я не раз писал о том, что это утрверждение уже давно работает крайне плохо, однако, до сих пор в маркетинговых листовках и публикациях такое утверждение можно встретить. Вероятно, это объясняется тем, что никакие контроли безопасности (== никакие инвестиции в ИБ) не исключат полностью возможность атаки, и, как будто, порог нерентабельности атаки выглядит логичным компромиссом для объема инвестиций в эту бездонную бочку с названием "корпоративная ИБ".

В современных условиях "нерентабельность атаки" представляет собой не столько порог инвестиций в ИБ, а, скорее, создает состояние гонки, поскольку, как бы мы не напрягались, атаки все равно будут, только ущерб от них будет еще выше! Логика здесь следующая: чем лучше защищена инфраструктура, тем дороже атака - нужны серьезные исследования, разработка эксплоитов, инструментов атаки, возможно, лабораторные испытания этих инструментов, насколько успешно они обходят используемые СЗИ, в общем, чем выше безопасность, тем дороже атака - это полностью укладывается в постулат, с чего мы начали. Однако, атаки все равно будут, а раз они дорогие, то для обеспечения положительного P&L, профит от атаки должен быть еще больше. Профит атаки, как минимум, косвенно, отражается на ущербе для жертвы - высокий профит для атакующего означает большой ущерб для жертвы. В итоге получаем, вероятно, не очень очевидную, тем более, непопулярную, закономерность: чем больше мы инвестируем в ИБ, чем лучше защищена наша инфраструктура, тем больший ущерб мы получим от компьютерной атаки. И даже хуже: если инцидент все-таки дошел до ущерба, то все наши инвестиции в ИБ, будучи несостоятельными, тоже превращаются в ущерб...

В общем, повышением уровня безопасности мы в немалой степени сами провоцируем рост ущерба.

#vCISO #пятница

п. Яма 3 к.с. или "Как я провел лето"

Как на практике теория отличается от практики, так и наше фактическое путеществие имеет массу отличий от нашего плана, а именно:
1. Пройденный маршрут составил менее 50 км, проследить можно по Strava:
11.08.2025. День 1. 4,1 км
12.08.2025. День 2. 14,1 км
14.08.2025. День 3. 11,5 км
15.08.2025. День 4. 6,4 км
17.08.2025. День 5. 4,5 км
18.08.2025. День 6. 8,3 км
19.08.2025. День 7. Выброска катером от устья р. Тумча до п. Зареченск, ~30 км, уже в маршруте не учитывается

2. Стартовали ниже п. Перевенец, т.е. его не проходили и, предположительно, его наблюдали с ЛБ на стапеле. Стапель был преимущественно под автомобильным мостом, так как периодически лил неопределенный дождь.

3. До п. Яма шли без просмотра, поэтому с уверенностью сказать что из пройденного было пп. Падун, Водопадный, Кривой, Юрьев день, Мара и Красивый нет возможности, не сохранилось о них и фото- видеоматериала, надо было грести, а не снимать окрестную красоту 😢

Перед п. Яма была дневка, что позволило на нем вдоволь накататься всем желающим на всех плавстредствах, что было не лень затаскивать по берегу.

С виду порог не выгядит страшно, как например, п. Котел (о нем в будущих заметках), однако, при прохождении можно столкнуться с некоторыми сложностями: мощная струя от камней ПБ при падении в яму поворачивает нос налево, что в совокупности с небольшой и, как будто, нестрашной, но задерживающей, бочкой последней ступени, создает риск оверкиля через баллон. В целом, когда мы уже груженые вещами, слава Богу, без пассажира, на следующий день отправились в дальнейший путь на нашем Рафтмастере К4, мы этот риск прочувствовали на себе - мой левый баллон ненадолго застрял в бочке, а ребятам на правом баллоне даже пришлось вывешиваться, но все быстро удалось исправить.

Делюсь видосами с наших покатушек:
1. Удачное прохождение - я и Петя (капитан нашей экспедиции) на Рафтмастере К2
2. Кривое, но тоже удачное я и мой старший, Илья, на том же Рафтмастере
3. Неудачное - я и Оля на легком РИГе
4. Удачное, как демонстрация возможности успешного прохождения и на легком РИГе умелым экипажем, Илья и Лиза.

Во всех моих проходах одинаковые ошибки:
- при падении в яму надо наклоняться вперед к баллону
- грести нужно интенсивнее
На РИГе забил на неотрегулированный правый упор - он и выскочил.

На фото к этой заметке - скриншот с видео нашего неудачного прохождения, который наш капитан назвал "Как я провел лето" 😂.

#здоровье

Сегодня снова зарегистрировался на Кисловодский марафон!

В этом году он получил дополнительное слово в название - MAYRVEDA, что совпадает с названием одного местного ЗОЖного отеля, посмотрим, повысит ли это качество организации, стартового пакета или вообще чего-то.

А вообще - это прекрасная возможность подарить себе праздник, а может, даже и с пользой для здоровья (главное, с дистанцией не промахнуться, а то когда регистрируюсь, рука невольно тянется к 21 км, но я жестко пресекаю в себе эти позывы)

В прошлом году, на старте, просто в толпе заметил бывшего коллегу, написал, и, правда, оказался он. Но, к сожалению, пересечься так и не удалось. Может, в этом году исправимся. Паша, привет!

Кто еще раздумывает, а, может, тоже приобрел слот, догоняйте!

#здоровье

Вышло фундаментальное исследование наших коллег из команды TI, основанное, в том числе, и на инцидентах обнаруженных в MDR и расследованных командой DFIR.

И хочетcя дополнить прекрасное интро Никиты Назарова следующими соображениями.

Разные коллеги по индустрии фиксировали разные активности, как будто, разных группировок и выпускали об этом разные отчеты. Но для того, чтобы видеть картину более-менее целиком необходимы: обширная клиентская база, широкая телеметрия и технологичные инструменты, квалифицированная экспертная команда. Перечисленное позволяет соединять точки линиями и, как точно подмечал Сергей Александрович, видеть большое "на расстоянье".

Коллеги старалиcь сделать отчет полезным для практиков, как говорится, Enjoy!

#MDR #kaspersky

Building a Successful Career in AI Cybersecurity

SANS выпустил документ, подчеркивающий важность вполне себе глубокого погружения нас, безопасников в машобуч, и представляющий собой руководство по построению карьеры на стыке искусственного интеллекта и кибербезопасности.

Ключевые выводы из доки
1. Конвергенция AI и Cybersecurity:
Документ подчеркивает, что искусственный интеллект и машинное обучение (ML) кардинально меняют ландшафт ИБ. AI используется как для усиления защиты, так и в качестве инструмента атак

2. п. 1 объясняет растущий спрос на специалистов:
Возникает новая категория ролей, таких как "Инженер по безопасности AI/ML" или "Специалист по безопасности данных", которые требуют уникального сочетания навыков ИБ и Машобуча.

3. Из доки можно выделить необходимые навыки и знания:
Технические навыки (Hard Skills):
- Понимание основ машинного обучения и data science.
- Знание языков программирования (Python, R) и умение работать с данными.
- Опыт работы со специализированными фреймворками и библиотеками (TensorFlow, PyTorch, scikit-learn).
- Глубокие знания в области ИБ
- Понимание облачных платформ (AWS, Azure, GCP) и их систем безопасности.

Soft Skills:
- Критическое и аналитическое мышление.
- Решение сложных проблем.
- Коммуникация (способность объяснять сложные концепции AI нетехническим специалистам).
- Любознательность и постоянное стремление к обучению.

4. Рекомендации по построению карьеры:
- Начните с основ: Получите прочную базу в классической ИБ (сертификаты типа CISSP, SSCP, CCSP очень приветствуются).
- Освойте Data Science: Изучите математику, статистику и основы машинного обучения через онлайн-курсы (Coursera, edX) или практические проекты.
- Получайте практический опыт: Применяйте свои знания в реальных проектах, участвуйте в соревнованиях по анализу данных (например, на Kaggle) или в открытых source-проектах.
- Вступайте в профессиональные сообщества, посещайте конференции и общайтесь с экспертами в этой области.

С развитием технологий и ужесточением регулирования спрос на экспертов, способных обеспечивать безопасность, надежность и этичность AI-систем, будет только расти.

Документ позиционирует карьеру в сфере AI Cybersecurity как одну из самых перспективных и востребованных в технологической индустрии. Это поле требует непрерывного обучения, но предлагает уникальную возможность быть на передовой борьбы с киберугрозами нового поколения и формировать будущее цифровой безопасности.

#ml #саморазвитие #vCISO

Утечки - характеристика уровня Цифровизации!

Все много говорят о росте компрометаций и утечек, вот, например, видео в тему, утащенное у кого-то из сториз Телеги. Ну, а что это характеризует? Уровень цифровизации! Утечка означает, что бизнес-процесс оцифрован, а так как утекают практически любые данные, можно с уверенностью сказать, что цифровизация у нас близка к 100%, цель достигнута!

Как я отмечал на конференции Сбера 7 лет назад, наше стремление к тотальной цифровизации имеет и оборотную сторону. И проблема здесь концептуальная: цифровизация всегда увеличивает поверхность атаки. Информационные системы (ИС) очень сложны, поэтому чтобы как-то с ними справляться, мы разбиваем их на уровни, вроде, инфраструктуры и приложений, а каждый уровнь у нас содержит чудовищное количество компонентов, каждый из которых может, в свою очередь, переиспользовать другие компоненты, и все они поддерживаются и развиваются разными командами. Даже в функционально несложных ИС мы можем насчитать сотни и тысячи компонентов, где компрометация каждого - потенциальный риск взлома всей ИС, - этакая гипертрофированная цепочка поставок и повсеместные доверительные отношения... ну а как еще? Если нет возможности во всем разбираться самому (== все делать самостоятельно), приходится доверять поставщикам и партнерам, а по факту - фиксируем рост атак на цепочку поставок и доверительные отношения.

Что делать? Наверно, повторю то же, что писал про автоматизацию, но это не будет лишним.
1. цифровизировать нужно только то, где это принципиально необходимо
2. минимизировать количество зависимостей, тем более зависимостей от неконтролируемых разработок (например, не производимых в стране)
3. иметь наготове бэкап-план работы "без цифровизации", т.е. каждый цифровизированный процесс должен иметь BCP его работы в условиях когда цифровая его реализация невозможна (банально, нет света, связи, цифровые данные потерты)
4. чтобы п. 3 работал, полезно проводить учения, ну и DRP надо бы иметь, ибо, поработав с бумагой и карандашом, надо когда-то вернуться к привычной цифровой реализации

#управление #пятница #РФ

На выходных удалось немного найти время на интересное, делюсь полезными находками

1. Отличная серия онлайн-мероприятий о практическом использовании машобуча в кибербезе. Можно зарегистрироваться и принять участие (я зарегистрировался, но в итоге смотрел в записи).
Релевантные моим проиводственным интересам:
David Kennedy - AI-Assisted SOC Automation and Threat Analysis
Randy Pargman - AI-Assisted Malware Reverse Engineering
Jonathan Cran - Intelligent Threat Intel Tooling
Также, есть выпуски про Offensive и про риски и инфобез вообще - не смотрел

2. В продолжение прокачивания темы AI-агентов поизучал LangGraph: Build AI Agents and Chatbots with LangGraph - "галопом по Европам", но, в качестве быстрого погружения, курс неплох. В процессе выполнения лаб понял, что я не настолько здорово знаю Python, поэтому в ближайшее время решил подтянуть свои способности в питонизации (пишите, если интересно, какие курсы про Python я смотрел, с удовольствием поделюсь мнением), а затем, снова вернуться с AI-агентам, но уже поиграться с доступными локальными моделями.

Всем счастливой недели!

#саморазвитие #ml

В больших AD-лесах админы часто «забывают» или ошибочно настраивают списки контроля доступа (ACL), не желая заморачиваться с чётким разделением и выдачей прав. В таких списках могут оставаться широкие разрешения для Everyone/Authenticated Users/Domain Computers, причём с расширенными правами на чувствительные объекты.

Это не мелочь: именно список DACL в nTSecurityDescriptor определяет, кто и что может делать с объектом. Но есть проблема: такие списки прав указаны для каждого отдельного субъекта (нет одной таблички), GUID’ы прав нечитабельны, а определения дескрипторов безопасности (SDDL) тяжело смотреть глазами.

Наш эксперт Александр Родченко написал утилиту ParseJsonWithSDDLs для решения этой проблемы. Основная идея: показать, какими правами обладают «все», то есть достаточно большой и потенциально неограниченный круг субъектов (анонимы, аутентифицированные пользователи, все ПК и т.д). Другими словами, утилита отвечает на вопрос: «Есть ли у нас в домене какие-то объекты, с которыми может сделать что-то любой пользователь?»

Функционал, реализованный в программе:

— парсит SDDL из nTSecurityDescriptor, вычленяет «широкие» ACE и показывает их в удобном виде (читаемые имена субъектов и объектов, декодированные GUID расширенных прав);
— умеет сама выгрузить весь лес и трасты в JSON (LDAP paging + SecurityDescriptorFlagControl для DACL), если у вас нет готовых экспортов ваших доменов; в некотором роде это работа SharpHound с опцией "вместе с DACL", но в данном случае автор сам реализовал это в коде;
— даёт HTML-сводку и при желании CSV для дальнейшей аналитики/хантинга.

Что даёт использование утилиты?

Это закрывает типовой класс конфиг-дефектов, про которые Microsoft годами пишет в своих рекомендациях по безопасности AD. Прогоны такой утилитой часто приносят «бесплатные» находки перед аудитами и пентестами. Примеры находок приведены на скриншотах выше:

(1) объект, который может изменить любой ПК — и никто не не знает, для чего это нужно; у клиента это был объект, относящийся к системе корпоративной печати,
(2) очень странный объект групповой политики — это заявка на повышение привилегий в домене,
(3) очень неправильно настроенные разрешения создавать общие папки: на самом деле, дали возможность создать объект-корень FTRoot (новый namespace) и создать под ним любые FTDfs-объекты — ссылки (на любой сервер) и их Target-списки.

Утилиту можно скачать в репозитории автора на Гитхабе:
https://github.com/gam4er/DACLPlayground/tree/master

SANS SOC Survey 2025

Как-то мы пропустили, но в июле у SANS вышел их ежегодный обзор по SOC, из которого неплохо прослеживать чем сейчас болеет индустрия

В какой-то момент времени я приостановил чтение этих отчетов (разве что только в рамках подготовки к AM Live 😁), ибо из года в год SOC-и воюют с одними и теми же проблемами: перегрузкой алертами, текучкой персоанала, нехваткой кадров, реактивностью и слабой интеграцией новых технологий, причем, 2025 не исключение, поэтому в этой заметке я подсвечу на что сам обратил внимание.

- 79% SOC-ов работают круглосуточно. Вопрос, на который не нашел ответ: "Как оставшиеся защищают свои инфраструктуры в нерабочее время?", - видимо, выключают все на ночь.
- 42% используют AI/ML-инструменты "из коробки" без настройки. В целом, этим объясняется низкая удовлетворенность машобучем, которая прослеживается на протяжении всех лет упоминания ML/AI в этом отчете. Мне подумалось, что это тот самый случай, когда, если что-то используешь бездумно, то его широкое распространение, напротив, имеет негативные последствия.
- 73% организаций разрешают удалённую работу. Все-таки, это можно считать победой кибербезопасности, ибо в 2025-м году удаленный доступ действительно можно сделать безопасным, а именно проблему ИБ я считаю основной в вопросе удаленной работы, что касается эффективности - писал здесь.
- 72% аналитиков полагаются на опыт и интуицию, а не на структурированные методы анализа TI - это просто вишенка на торте, причем, я тоже могу это подтвердить! За время работы SOC вырабатывается определенное "чутье", интуиция, работающие несравненно лучше любого продвинутого генеративного ИИ.
- по технологиям: EDR/XDR — лидер по удовлетворённости (~ рынок дозрел), а AI/ML - на последних местах (~ еще зеленый), SIEM - критически важен, но нередко используется неэффективно (~ повышение сложности требует вызревания UX).
- растет использование облаков
- развивается вопрос карьерного роста аналитиков SOC как инструмента удержания

В целом, направления развития понятны:
- ML/AI/DL, чтобы наконец-то выжать эффективность
- развитие кадров\карьерный рост\мотивация\удержание, выше писал про особую интуицию - это очень важно и такой опыт очень долго и дорого получать, важно чтобы такие профессионалы не терялись

#MDR

npm debug and chalk packages compromised

Очередной эпичный supply chain через node.js

Разборы доступны здесь:
раз
два

История

а вот совсем недавно рассуждали 😢

#dev #vCISO #MDR

Картинка того, как выглядит в телеметрии MDR эмуляция обсуждаемой вчера эксплуатации

eventtype_str - название события
file_path, filecmdline - потомок
processfilepath, processcmdline - родитель
parentprocessfilepath, parentprocesscmdline - родитель родителя

Главный вектор атаки – выполнение вредоносного кода на этапе preinstall. Здесь стандартный мониторинг EPP/EDR (рабочих станций разработчиков и CI/CD-серверов) позволит обнаружить любой подозрительный по поведению процесс, инициированный из node_modules/.bin или напрямую из пакета NPM. В этом случае задача сводится к стандартной – контроль запусков подозрительных процессов с плохой или неопределенной репутацией.

На картинке запускали powershell.

Сухой остаток: supply chain звучит страшно, но стандартные инструменты мониторинга это прекрасно обнаруживают, ну а то, что мы всегда уязвимы, мы знали и ранее.

#MDR

Conferences

Хороший репозиторий

#саморазвитие

Потенциал злоумышленника

Один мой старый приятель, тоже безопасник, поинтересовался вопросом оценки потенциала атакующего - нет ли каких-то общеизвестных\широкопризнанных фреймворков на этот счет. Может, плохо искали, но мы ничего не нашли, а значит, это повод задуматься о вопросе. Поток своего сознания на этот счет я изложил в статье.

Следующим шагом, конечно же, надо пособирать все эти capabilities атакующего в эксельку-калькулятор и предложить свою CMM для атакующего (по аналогии с этой). Если для такого калькулятора найдется производственная необходимость, обязательно этим займусь и поделюсь!

Ну а пока:
- подписывайте какие еще capabilities атакующего, помимо перечисленных в статье, следует учесть в калькуляторе
- пишите ваше обоснование производственной необходимости подобного калькулятора и нужна ли нам CMM для атакующего - это добавит мотивации инвестировать время в разработку такого калькулятора (пока особого практического смысла я не придумал)

#vCISO

Безумный Max

Тут проскакивала новость, что в Github появился репозиторий безопасного мессенджера Maх, на момент этой публикации – удален. А в Интернете не утихают публикации о небезопасности Max и его чрезмерных способностях по контролю нарушению приватности пользователей, поэтому появление, как будто, свободно доступного и безопасного Max пришло очень во время. Вероятно, все еще сильна логика "если opensouce, то безопасно", ибо великое множество независимых экспертов может спокойно провести исследование кода на предмет отсутствия закладок ошибок. Особое умиление вызывает наличие в статье скриншота с VT, мол, вот и куча антивирусных движков проверили, ВПО нет. Давайте разбираться.

Я из тех, кто верит в эффективность подхода прозрачности, когда заинтересованная сторона может самостоятельно убедиться в отсутствии НДВ. Упрощенным вариантом подтверждения прозрачности является доступность исходного кода и, следовательно, возможность его независимого анализа, т.е. с этой точки зрения opensource, действительно, выглядит безопаснее (сценарий, когда исходный код используется и злоумышленниками для поиска векторов эксплуатации не будем сейчас рассматривать). Однако, известно немало историй, когда открытость кода не гарантирует безопасность и спустя много лет находились серьезные уязвимости: Heartbleed не замечали в коде около двух лет, Shellshock – около 25 лет, Log4Shell – обнаружили спустя 8 лет, Dirty cow – существовала в ядре Linux с 2007 и была обнаружена только в 2016,… и этот список можно продолжать.

Но в нашем случае ситуация еще хуже: в каком-то Git-репозитории выложили код, и здесь же утверждается, что он супер-безопасен. Лично для меня утверждение о безопасности в соцсети не является весомым, тем более, что я никогда не видел троянов, доступных для скачивания, где тут же утверждалось, что это ВПО со всеми вытекающими 😂. Скорее всего, в данном случае, не этот сценарий, однако я на считаю разумным скачивать что-то малоизвестное с Github и устанавливать (даже если сам собрал из исходников). Вопрос доверия в ИБ принципиален – нельзя обеспечить безопасность без доверия, а любое ПО из недоверенного источника нельзя считать безопасным. Вопрос доверия также является базой для ответственности: если я качаю ПО и ставлю его себе на телефон, я хочу, чтобы оно работало, и чтобы за его работу кто-то нес ответственность. Поэтому важно ставить ПО не только из доверенных источников, но и от надежных производителей, которые способны нести ответственность за свой продукт.

С учетом всего написанного, я не вижу аргументов в пользу использования "появившегося вчера безопасного WhiteMax с Github" вместо "Max от VK из официального магазина приложений".

#РФ

12 сентября

Евгений Валентинович буквально снял с языка!

Для меня Pink Floyd тоже воспоминания о школе, именно там я более-менее регулярно играл Wish you were here, и вот уже несколько десятков лет, как эта вещь у меня не в активе, и на периодических посиделках с гитарой я ее не играю, как и многие десятки замечательных вещей, ушедших в историю моего беззаботного детства!

Но сегодня - это знак, знак оглянуться назад, вспомнить прошлое и оживить эту замечательную композицию: вот она, записанная только что, прямо за столом перед компом на мобильный телефон. Годы стерли умение ее играть и петь, но не изменили моего отношения к ней - на любой радиостанции, когда бы я ее не услышал, я несказанно рад, а губы неосознанно повторяют:

How I wish, how I wish you were here
We're just two lost souls
Swimming in a fish bowl
Year after year
Running over the same old ground
What have we found?
The same old fears
Wish you were here

Но 12.09 для меня не простой день еще потому, что это день рождения моей замечательной супруги.
В этот особенный день мне хочется пожелать нам всем любви, выдерживающей испытания временем, любви что становится только глубже и ценнее с каждым годом, подобно великой вещи "Wish You Were Here", которую вот уже 50 лет миллионы людей по всему миру слушают с любовью и нежностью к тем\тому, кого\чего нет рядом.

Wish you were here можно отнести и к нашему прошлому, которе не вернуть, и нам жаль, что оно не с нами, а наше "сейчас" - это не "тогда", жаль что обремененные настоящими знаниями мы тогда что-то не ценили... - это ощущение характерно для любого прошлого, а наше настоящее стремительно превращается в прошлое, поэтому давайте ценить все, что с нами происходит, чтобы не жалеть о прошлом, а в будущее смотреть с оптимизмом!

#музыка

Когда AIOps становится AIУпс

Как только новая технология обретает популярность, сразу появляются техники атак на нее. Поэтому большое количество уязвимостей не всегда означает, что ПО дырявое (ну разве что толко Adobe - исключение), но точно, что оно - популярное. Автономные SOC-и набирают популярность, вот и атак на AI-агентов все больше придумывают. В этой связи рекомендую ознакомиться с исследованием моего друга и коллеги Мохамеда Гобаши из команды GERT о вредоносных MCP-серверах, а я расскажу, в общем-то об инъекциях, но на современный лад.

Статья "When AIOps Become "AI OOPS" (прямая ссылка на pdf, статья в The Register) представляет первое в своём роде исследование безопасности систем AIOps (~ агентских систем), которые используют большие языковые модели для автоматизации обнаружения и расследования инцидентов, и реагирования на них.

Авторы показывают, что злоумышленники могут манипулировать событиями телеметрии, чтобы "обмануть" AI-агента и заставить его выполнить вредоносные действия по "исправлению" проблемы.
В статье авторы предложили методологию и инструмент "AIOpsDoom" для проведения атаки на агентскую систему, которая может обмануть AI-агента, заставив его выполнить вредоносное действие, подставив в телеметрию ложные артефакты.
Кроме того, здесь же авторы предложили и защиту - "AIOpsShield", которая санитизирует подставленные системой, аналогичной AIOpsDoom, вредоносные данные.
В общем, ребята разобрали агентские системы в хвост и в гриву, причем, и в AIOpsDoom, и в AIOpsShield также используются LLM, хотя и не в качестве основного компонента.

Исследование лишний раз подтверждает, что ML/DL/LLM - это такой же инструмент, как, например, любой язык программирования, который может использоваться и для автоматизации (AI-агенты), и для автоматизации атак на автоматизацию (AIOpsDoom), и для автоматизированного обеспечения безопасности (AIOpsShield), и если ранее мы работали с Host IDS и Network IDS, то вот они уже и AI IDS.

#ml