Солдатов в Телеграм

А вы следите за бенчмарком ИИ?
А надо!

И вот на что я обратил внимание:

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

2. Волшебства не бывает, и закон сохранения здесь тоже работает: несложно посчитать, что "автономный SOC" на мощных моделях будет стоить дороже, чем "классический" SOC из команды аналитиков, так как все, что выше $1 за миллион токенов дороже "Кожаного мешка", а до полной автономии еще очень далеко, ибо даже лидер (GPT-6 Astra) полностью завершает без нарушений лишь 41,6% рабочих процессов в AutomationBench-AA, у перехваленого Claude Fable 5.1- 32,1%, у Opus 5 - 28,3%.

3. Ошибка выбора модели стоит дорого, так как цена за задачу при одинаковом интеллекте различается кратно: при 53 баллах - GPT-6 Astra - $3,26, Claude Fable 5.1 - $7,63 (+57%), при 42 баллах - GLM-5.3-Flash - $0,25 против $1,40 у GPT-5.6 Terra (в 5,6 раза).

MAX

#ml #MDR

Военные-хакеры

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

Поэтому, несмотря на то, что статью я прочитал с интересом, она не вызвала удивления. Также не вызовет удивления, если военные хакеры сдавали OSCP и тогда пособником можно уже считать не Бауманку, а Offensie Security. В общем, предлагаю быть демократичными до конца: если кому-то можно, то другим не просто можно, а даже нужно, иначе баланс в Мире нарушается и мы скатываемся к диктатуре, когда одни страны диктуют условия другим, что тоже понятно, ибо колониально-рабовладельческие привычки не побороть быстро.

#мир

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

Не знаю как вы, но лично я лучше запоминаю процесс. Со времен школы, и потом в институте, мне было проще запомнить логику и процесс вывода тех или иных законов и формул, чем их зазубрить. Эта процессная привычка у меня распространилась на любое обучение вообще, например, чтобы понимать текущие мировые события нужно хорошо знать историю, так как настоящее - следствие прошлого. Ну а чтобы понимать искусство - нужно знать и понимать историю искусства (здесь под "понимать" я имею ввиду знание ответа на вопрос: "Почему оно именно такое?"), ибо все последующие направления искусства базируются на предыдущих. Как базовая алгебра - основа понимания информатики и машинного обучения, так и история искусства - необходимая база для понимания современного искусства.

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

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

#история #искусство

Всем привет!

У меня никогда не было аккаунта в Instagram, а также в Facebook, а также в ВК и много еще где.
Но сегодня я узнал, что в Инстаграм есть некто sergey_soldatovv, с моей фотографией на аватарке. В целом, в этом ничего нет необычного, что кто-то называет аккаунт последовательностью символов, в которых можно распознать мои имя и фамилию, а фото профиля берет из Интерент, например, вот отсюда, или вот отсюда, если бы не дальнейшие события.

Этот Некто из Инстаграмма далее начинает комментировать "новости", в частности какое-то видео (ссылку на "новостной" ресурс давать не буду, ибо он не внушает мне доверия, и не доступен без VPN), где маленький мальчик едет за рулем на белой Мазде. Комментарий Некто из Инстраграма с моей фотографией в профиле буквально означает, что на видео его сын и видео надо удалить.

За этот комментарий зацепляется другой персонаж нашей истории, пытается со мной связаться, по телефону и Телеге, привожу ее ЛС мне в Телеге:

Сергей, здравствуйте, недавно общались с Вами. Елизавета журналист информагентсва Регнум.
Сейчас в сети появилось видео, на котором несовершеннолетний управляет автомобилем. В комментариях под постом <отредактировано> от вашего имени оставлены комментарии, что на кадрах Ваш сын. Расскажите, действительно ли это так и как так вышло?

Елизавета позвонила с номера московского мегафона, спросила, есть ли у меня белая Мазда, я ответил, что нет, на этом разговор был закончен. Но она не успокоилась, написала в Телегу.

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

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

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

Итого, дорогие друзья:
1. У меня никогда не было и нет аккаунта в Инстаграм. На картинке к этой заметке - не мой аккаунт.
2. Я не оставлял комментарии под видео, где несовершеннолетний едет на Мазде (и прочих комментариях с аутентификацией через Инстаграм)
3. Никто из моих детей до настоящего времени, никогда не ездил за рулем белой Мазды


Если все описанное является какой-то очередной схемой мошенничества, напиши в комментариях, кому что известно.

Всем нам добра!

#РФ #socialengineering

Корпоративный харнесс

Централизация в большинстве случаев - правильное решение, однако, практика нередко нам диктует условия, требующие более гибкого подхода, поэтому "лучшие практики" прекрасны с точки зрения академической науки, но нередко сбоят в реальных условиях. Но это не повод не изучать Best practices, ибо на их базе можно собрать комбинацию того, что будет реально работать здесь и сейчас.

Со своим архитекторно-инфраструктурным бэкграундом я, конечно же, не мог не написать статью о системном подходе к использованию ИИ для разработки ПО на производстве, тем более, что приведенные утверждения я старался снабдить ссылками на подтверждающие\поясняющие материалы, и действительно, там, "у них", приведенная мною стратегия "корпоративного харнесса", действительно, будет рабочей. Однако, как говорится, а у нас, как всегда, ситуация немного иная и "корпоративный харнесс" с сравнении "каждый сам за себя" прямо сейчас, в моменте, в РФ, возможно, и не имеет преимуществ, так как:
1. Персональные подписки сейчас значительно дешевле, чем корпоративные. Со временем, эта ситуация точно изменится.
2. С учетом их отношения к нам, практически уверен, возможны сложности с приобретением корпоративной подписки, а, если и удастся купить, совсем не исключен дефолт их по отношению к нам. Да и персональные аккаунты из одной компании в РФ, тоже могут поблокировать, надо к этому готовиться, однако, в случае утраты персональных аккаунтов, ущерб ниже.

Но ничто не помешает мне быть оптимистом, верить в мир о всем Мире и быть за все Хорошее против всего плохого, поэтому со статьей имеет смысл ознакомиться. Как обычно, буду рад вашим предложениям\замечаниям в комментариях.

MAX

#ml

Александр Трачевский. Наполеон I...

По пути из Москвы в Кисловодск в условиях серьезных сложностей с топливом на трассах M-4 и Р-217, когда на открытых АЗС только ДТ, на некоторых есть АИ-92 и крайне редко - АИ-95 (пару раз за всю дорогу видел), но очередь отбивает полностью желание даже подъезжать, мне душу грели несколько вещей:
- что у меня старая машина и можно лить любой бензин (тем более, что ранее, за это же самое я себе немного сочувствовал, воистину, пути Господни неисповедимы, который раз жизнь мне доказывает, что все что не делается - все к лучшему!)
- 2 х 20л АИ-100, слитые из бензобака еще в июне при подготовке к поездке из Кисловодска в Москву, так как заливать в канистры строго запрещали аж до скандалов
- замечательный историк и собеседник Ангелина Дронова в качестве попутчицы
- прекрасная книга Алекснадра Трачевского о Наполеоне I

Наиболее значимым из перечисленного, конечно же, была Ангелина, ибо когда еще у меня будет возможность 20 часов обсуждать историю! Все 20 часов обсуждать историю не получилось, да и не всю историю, но играющая фоном книжка Трачевского задала основные темы, и это было замечательным бонусом к самой аудиокниге. Книга настолько мне понравилась, что я решил написать про нее небольшую статью и настоятельно рекомендую к прочтению всем любителям истории.

В MAX меня тоже можно читать!

#книги #история

Пистайоки. Июль-август 2026

Как говорится, пока у нас есть зад****, найдутся на нее и приключения.

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

Владимир Семенович - бесспорный мастер слова много и точно написал про горы:

Лучше гор могут быть только горы,
На которых ещё не бывал,

И сердце готово к вершине бежать из груди.
Весь мир на ладони - ты счастлив и нем
И только немного завидуешь тем,
Другим - у которых вершина еще впереди.

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

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

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

Также прилагаю ссылки на отчеты других групп, проходивших этот маршрут ранее.
ТК МАИ 2020
Афанасенков М.А. 2000
ТК Перово 2005

Если все обойдется, ждите продолжение (трек часами сниму, заметки по маршруту сделаю, фото видео тоже должны быть)

MAX

#здоровье

Факторизация "коротких" ключей RSA

Давно мы не говорили про криптографию, время пришло.

Ребята опубликовали интереснейшее исследование о новом типе слабых ключей RSA, содержащих большое количество нулей. Оказалось, что таких ключей полно ITW, причем в реализациях разных производителей.

Процитирую авторов в своем вольном переводе (с пояснениями в скобочках () и выделением, на мой взгляд, важного):

Проект badkeys - это сервис с открытым исходным кодом, который проверяет открытые ключи на наличие известных уязвимостей. В процессе разработки этого инструмента Ханно собрал огромное количество реальных ключей из открытых источников, включая журналы Certificate Transparency, сканирование TLS и SSH в масштабах всего интернета, ключи PGP и многие другие. Поиск в этом наборе данных неожиданно редких модулей RSA позволил нам обнаружить большое количество ключей, встречающихся в реальных условиях, с шаблонами, показанными на рисунке 1 (содержащими множество нулей).

Оба шаблона включают несколько регулярно расположенных блоков из одних нулей, перемежающихся, казалось бы, случайными данными. Шаблон 1 встречается в журналах CT для сертификатов, выданных нескольким крупным организациям, включая Yahoo и Verizon, а также на некоторых устройствах, работающих под управлением программного обеспечения NetApp. К счастью, срок действия этих сертификатов уже истёк, но мы всё равно поделились нашими находками с этими компаниями. Мы хотели узнать больше о том, какой продукт мог быть ответственен за генерацию этих ключей, но ответа не получили. Шаблон 2 встречается на SSH-хостах, работающих под управлением программного обеспечения CompleteFTP от EnterpriseDT. Основная уязвимость затрагивает ключи RSA, сгенерированные с использованием версий 10.0.012.0.0 (декабрь 2016 г. – март 2019 г.), и ключи DSA, сгенерированные с использованием версии 10.0.023.0.4 (декабрь 2016 г. – декабрь 2023 г.).

Эти уязвимости затрагивают небольшое количество хостов в интернете, но более интересный вывод заключается в том, что независимые криптографические реализации давали аналогичные "уязвимости" (ковычки я поставил, ибо с трудом верится в случайность генерации ключа с такой структурой нулей, как на картинках). Более того, подобные "ошибки" (аналогично) могут встречаться и в других реализациях, поэтому стоит адаптировать криптоаналитические алгоритмы под этот конкретный уязвимостей.

Статья не распространяет слухи о намеренном ослаблении криптографии, но я себе могу вполне это позволить, ибо
а) как уже отмечал, приведенные в статье паттерны нулей не выглядят как случайные
б) есть масса намеков от экспертов в контексте, что искусственное ослабление криптографии имеет место (да и сама история DES и АНБ тому красноречивое подтверждение - длина ключа оригинального предложения IBM была 128 бит, но в итоге сделали - 56)
в) уже более четверти века назад мы защищали диплом на тему криптосистем с лазейками
г) ну а маскирока закладок под уязвимости в эпоху постправды уже совсем обычное дело

MAX

#crypto

Нежелезный человек 2026

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

Подписывайтесь в MAX

#здоровье

Cyber Insights APAC 2026

В этом году конференция проходила во Вьетнаме .

На конференции рассказывал про инциденты MDR. Как и прежде, я проанализировал инциденты, которые мы наблюдали с 2020 по 2025, в каких секторах экономики, какие инциденты встречались, заметили явные параллели с ситуацией "на земле" - подобный анализ в очередной раз подтвердил, что целевые атаки и кибертерроризм (как. в общем-то, и "классический" терроризм) сегодня являются элементами современных гибридных войн, - в докладе я не произносил это явно, однако цифры и графики были вполне красноречивы.

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

#MDR #мир

Галопом по Дагестану

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

06.06 где-то в 5:30. мы выехали из Кисловодска, вечером приехали в Дербент, остановились в гостинице Метрополь. Где-то к 18 убежали на экскурсию по Дербенту. Ужинали в ресторане Родник.

07.06 искупались в море, пособирали ракушки (пляж - песок, ракушечник), отправились в Сулакский каньон (в навигатор надо забивать ресторан Аварал). В Сулакском каньоне большой туристический кластер: парк Аварал и чуть ниже - Главрыба, там можно провести целый день. Пообедали в ресторане Аварал, отправились в Махачкалу. Заселились в гостиницу Монто, поужинали в ресторане Номад.

08.06 завтрак в гостинице, экскурсия по Махачкале, обед в ресторане Папаха. Отправились в горы - глэмпинг Рамина Гуниб. Заселились, попели песни под гитару.

09.06 завтрак в глэмпинге, отправились на водопад Тобот. Там пока еще инфраструктура строится, но уже есть неплохой ресторан и там у нас был запланирован прыжок на веревке. Глубина ущелья - около 100 м, расстояние свободного падения - около 70 м. Я не прыгал, но запланировал это сделать в Сулакском каньоне, там мне показалось живописнее. Отправились в Осетию. Навигатор посоветовал поехать через горы, дорога очень красивая, однако, местами грунтовка, местами нас преследовал дождь... в общем, машину было не узнать. По пути обедали в ресторане Эверест в поселке Ботлих. В Осетии остановились в Арт отеле Фиагдон, но было уже почти 22, поэтому красоты не было видно.

10.06 завтрак в отеле, посещение SPA: поплавали в бассейне, позагарали с видом на живописные горы, попарились в сауне. В 12:00 отправились в Кисловодск. Обедали в уже хорошо знакомом нам кафе Баксан Лофт, в поселке Баксан, КБР. Около 19 прибыли в Кисловодск.

#РФ

Корпоратив\Тимбилдинг - это не только игра ради игры, и из него нужно извлекать общекорпоративную пользу. Рассуждения на эту тему начал в новой статье.

#управление

ConceptUML: Semantic-Driven unsupervised ML

Уже достаточно давно мы обсуждали, что есть два сценария мониторинга: alert-driven и hypothesis-driven threat hunting, и, как будто, эти сценарии закрывают потребности даже продвинутого SOC. Однако, ничто не стоит на месте, тем более, что появился значимый бустер в виде машобуча, и поэтому я пребываю в активном поиске подходов, альтернативных к alert-ам и хантингу гипотез. Это показалось перспективным - ConceptUML: Multiphase unsupervised threat detection via latent concept learning, Hidden Markov Models and topic modelling .

В публикации авторы предлагают семантическое обнаружение, ConceptUML - полностью несупервизорный фреймворк для выявления горизонтальных перемещений на основе аномалий, взятых из гетерогенных логов (!). Если кратко по сути, то модель не ищет сигнатуры и не строит\проверяет гипотезы - она сама "понимает" смысл событий и сравнивает его с паттернами атак из открытых баз знаний (MITRE ATT&CK и CAPEC aka "Капец"), причем это работает на неразмеченных, ненормализованных сырых логах, и при этом может находить zero-day сценарии.

Фреймворк работает в три этапа:
1. Извлечение скрытых концептов из логов с помощью Sentence-BERT и неотрицательного матричного разложения (NMF, Non-negative Matrix Factorization).
2. Кластеризация через скрытую марковскую модель (HMM, Hidden Markov Model) и расчёт атак-скора на основе семантической близости к MITRE ATT&CK и CAPEC.
3. Тематическое моделирование (topic modelling) подозрительного кластера для точного выделения вредоносных фрагментов логов (опционально).

В результате на реальных датасетах (включая Windows Event Logs и LMD-2023, есть ссылочка на их git) ConceptUML показал 92,5% качества обнаружения при ошибке всего 8,14%. В статье есть ссылки на другие решения, работающие на базе выявления аномалий, утверждается, что в данном фреймворке качество выше.

Доку приложу, а то, вдруг, заблэклистится, как, кстати, многие ссылки из References.

PS: Не менее важная фича фреймворка - потребление логов без предварительной нормализации, что очень привлекательно для SIEM-ов, а для систем с нормализацией при запросе (типа Splunk) - отличная возможность радикально повысить производительность. А при необходимости (для chain of custody) хранения первоначальных логов - экономия на хранении. В общем, как будто, нормализация и вообще соблюдение схемы данных начинают уходить в историю.

Мы в MAX.

#MDR #ml

SOC-CMM Maturity report

SOC-CMM - прекрасный старт для [само]оценки зрелости SOC. Фреймворк вполне можно расширить, добавив собственных требований и критериев, и\или скорректировав предложенные автором.

Начиная с прошлого года Роб стал публиковать любопытные отчеты о зрелости SOC по миру. За вычетом небольшого маркетингового налета и очевидных очевидностей, вроде "зрелость SOC растет только у тех, кто целенаправленно этим занимается" или "растет спрос на сертификацию SOC-CMM" (хотя, в Саудовской Аравии, например, это, действительно, нередко требуется), можно почерпнуть полезные знания, как будто, SOC-CMM неплохо дополняют отчеты SANS: если SANS в общем случае отвечает на вопрос: "Чем занимаются современные SOC", то SOC-CMM поможет с ответом на вопрос: "Как SOC должны развиваться", что для нас, SOCоразвивателей очень важно.

Свежий отчет

Что мне бросилось в глаза.
1. Большой бюджет не означает, что у SOC большая зрелость, а вот с ростом штата в SOC зрелость растет. Это удивительное наблюдение, к которому есть вопросы, особенно в условиях, что любой SOC - гибридный .
2. Как бы много не говорили про автономные SOC-и и ИИ , результативность ИИ пока крайне умеренная.
3. В условиях самооценки наблюдается тенденция к завышению уровня зрелости, а при внешней оценке картина более объективна. По-хорошему, исходя из принципа, что "сам себя я знаю лучше, чем кто-либо другой", должно быть ровно наоборот, что подтверждается высокой эффективностью внутренних команд безопасности.
4. Европа - проблемный регион. Европа имеет самое долгое время найма аналитиков, и самую низкую продолжительность работы в SOC.
5. Governance - главная проблема, а не ложные срабатывания, и не "алерт фатиг", хотя эти, общепринятые, проблемы SOC также указаны, но помимо этого перечислены: нечеткое распределение ответственности, отсутствие формальных циклов анализа результативности и улучшений, слабая связь с бизнесом и рисками.

в MAX

#MDR

Harness

В ИИ все очень динамично. Даже не знаю, сколько нужно времени, чтобы всё это просто прочитать, не говоря уже о том, чтобы попробовать.
Если вы, как и я, много думаете об AI-агентах и пытаетесь строить автономные SOC-и, то для нас появился новый концепт - Agent Harness.

В 2026 году это понятие стало одним из ключевых в инженерии агентов. Простыми словами: Agent Harness - это "обвязка", которая превращает сырую LLM в полноценного, управляемого, наблюдаемого и предсказуемого "сотрудника". Это не просто вызов модели через API, а целый слой (или набор слоев, ибо здесь мы снова изобрели архитектуры фон Неймана, но уже для AI-агентов):
- Контроль инструментов (tools) и прав доступа
- Управление памятью и контекстом
- Проверяемость (traceability) каждого шага
- Безопасное исполнение кода и действий

Agent Harness радикально снижает требования к "интеллекту" модели за счёт инженерной обвязки. На простых, структурируемых задачах (извлечение данных, вызов API, форматирование) удовлетворительный результат можно получить даже на локальной 8B-модели. Неплохая метафора в тему:

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

Ссылки по теме, для быстрого погружения с элементами hands-on:
Harnesses in AI: A Deep Dive
What is an Agent Harness? and How to build a great one!


Но также хочется, традиционно, погадать на кофейной гуще 😂. Несложно заметить закономерность, что всё новое в AI-агентах сначала массово появляется в разработке кода. Отсюда следует, что доля нового кода (greenfield, тесты, boilerplate), написанного LLM с доработкой человеком, превысит 50% уже через полтора года. Конторы, пишущие код без агентов, отстанут навсегда.
Сейчас устойчиво мнение, что из соображений безопасности собственная разработка кода недопустима с облачными моделями. И итоге, ставим слабые локальные модели на слабое железо, результат никуда не годный, убивающий всю идею на корню.
Но конкуренция заставит выбирать: или ты используешь мощную модель (хоть облачную, хоть локальную) и выигрываешь в продуктивности, или тебя вытесняют. Да, это расширяет поверхность атаки, ибо это новый доверенный поставщик, а никакая безопасность невозможна без доверия.
Очевидный прогноз - рынок расколется: критическая инфраструктура и defence пойдут в дорогой on‑prem с GPU-кластерами (там уже Llama‑400B локально), а коммерческий сектор - в гибрид (как и для SOC): локальный guard + облачная LLM.

Я в Max

#ml

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

Если коротко, я пытаюсь рассматривать направление как цельный модуль с фокусом на его внешние проявления, выраженные в KPI, метриках, внешних взаимодействиях, тогда как лидер направления отвечает за внутреннюю организацию, чтобы целевые KPI и метрики выполнялись, а внешние коммуникации работали как договорились.
Конструктивная критика и предложения приветствуются.

Max

#управление

Блокировки соцсетей

Многие в моем окружении не понимают причин блокировки Телеги. Это - огромная проблема, которую надо решать, как-то объяснять людям, ибо причины - на поверхности, ну или у меня небольшая профессиональная деформация. К моему величайшему сожалению, мне не удалось найти каких-либо адекватных официальных объяснений от РКН или кого-либо, осведомленного от первого лица, поэтому в новой статье делюсь исключительно своим пониманием ситуации.

Max

#РФ #мир

Демоны в DAEMON Tools

Анализируя природу критичных инцидентов мы отмечали спад человекоуправляемых атак на телекомы с одновременным ростом для ИТ и дали объяснение - смещение фокуса с доверительных отношений на цепочку поставок.

Вот очередное подтверждение: DAEMON Tools software infected – supply chain attack ongoing since April 8, 2026

#MDR

На днях обнаружена серьёзная уязвимость CVE-2026-31431 (CopyFail) в ядре Linux, которая эксплуатируется во всех основных дистрибутивах. Уязвимость позволяет локальному непривилегированному пользователю получить права root.

Суть узявимости:

Криптографический алгоритм authencesn во время работы использует часть выделенной памяти в качестве «черновика» и записывает четыре байта прямо в страницы кеша файла. Это даёт атакующему возможность модифицировать кеш любого читаемого файла.

Эксплоит представляет собой 732-байтный Python-скрипт, который последовательно вызывает операции AF_ALG и splice для записи четырёх контролируемых байт в кеш, например, setuid-приложения. В результате модифицируется исполняемый код в памяти и запускается шелл с рутовыми правами.

Что делать:

Рекомендуется в первую очередь обновить ядро, а если это невозможно — отключить модуль algif_aead (интерфейс AF_ALG для AEAD).

Как детектировать атаку:

Артефакты запуска исходного эксплоита на Python можно увидеть на скриншоте выше. Запуск отслеживается по характерным командным строкам:

sh -c -- su
sh -c -- newgrp
sh -c -- passwd
sh -c -- gpasswd
sh -c -- sudo
sh -c -- chfn
sh -c -- umount
sh -c -- mount
sh -c -- fusermount3
sh -c -- chsh
sh -c -- su

Аналогичные строки могут быть и с другими setuid-файлами.

Можно отслеживать атаку и по характерной цепочке процессов: python запускает shell.

Также рекомендуется контролировать:

— создание сокета AF_ALG (интерфейс к криптографическому API ядра Linux) непривилегированными пользователями,
— использование системного вызова splice(), который позволяет перемещать данные между двумя файловыми дескрипторами (например, из файла в пайп или из сокета в файл) внутри памяти ядра.

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

Автономный SOC

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

Но сегодняшняя заметка о том, что мне все-таки придется заняться построением автономного SOC, как минимум на бумаге, а в самом успешном случае и пропилотировать его на себе.

Поскольку не хочется изобретать велосипеды, а стоять на плечах гигантов, в этой заметке (и в комментариях к ней) соберу материалы, для собственного внимательнейшего изучения (благо перелет из APAC до Москвы очень долгий).

Прежде всего, - основная концепция, скелет, и о ней я уже писал. Фундаментальная проблема применимости AI в безопасности - в безопасной управляемости и сдерживании галлюцинаций LLM. Попробовать адресовать вопросы безопасности помогут ALUSKORT (IJAM Journal) и Управляемая автономия: Agent-Lock (NDSS Symposium), а также - доверенная автономия.

Ну а для пополнения личного каталога аргументации, а также для эффективного приземления полета мысли о том, что AI нас всех заменит, во вложении прилагаю доку от нелюбимого мною, но регулярно знакомящегося с его новинками, Гартнера, датированную декабрем 2024 года с кричащим названием: Predict 2025: There Will Never Be an Autonomous SOC - ну, как обычно, характерные для Г. очевидные очевидности, которые, ввиду своей незатейливости, а также размытости формулировок, сложно оспаривать.

Что ж попробуем приблизиться к ASOC насколько это возможно в реальных условиях. Руководство требует нереальной эффективности, надо выкручиваться.

Эта же заметка в MAX.

#ml #MDR