НеИБи

Программирование на языке Эзопа Сегодня в кибер‑мире разразилась большая драма вокруг Palo Alto Networks. Их подразделение Unit42 обнаружило масштабную хакерскую кампанию «Shadow Campaigns», которая шпионила за правительствами и критической инфраструктурой по всему миру. В черновике отчета исследователи прямо указали на то, что за атаками стоит китайское государство, но на финальной стадии руководство компании решило «смягчить» формулировку. Вместо прямой атрибуции Китаю в публичном отчете появилась расплывчатая фраза про «государственно‑ориентированную группу, действующую из Азии». При этом в январе 2026‑го Китай уже публично критиковал Palo Alto, у компании там пять офисов и сотни сотрудников, так что риски давления и репрессий вполне реальны. Источники Reuters прямо пишут, что компания убрала указание на Китай, чтобы избежать ответных мер Пекина. Представитель Palo Alto в переписке с журналистами заявила, что «атрибуция не так важна» и что выбор формулировки якобы продиктован желанием «лучше информировать и защищать правительства». В итоге весь этот эпизод выглядит как классический выбор между честностью аналитики и бизнес‑выгодой: назвать вещи своими именами или прикрыться мягким языком, чтобы не злить китайских чиновников и не рисковать офисами, контрактами и, возможно, судьбами сотрудников. @antiinfosec

Око за око? Пока господин Свинцов изо всех сил допускает блокировку Google, а все немного посмеиваются, хочется заострить внимание на одной детальке. По отчету Google Threat Intelligence, APT-группы (APT31, UNC2970, APT42) маскируются под экспертов, генерируют код, тестируют уязвимости и обходят WAF. Google заблокировал аккаунты нарушителей. Модель применялась для анализа открытых источников, подготовки фишинговых материалов, перевода текстов, написания и корректировки кода, тестирования уязвимостей и решения технических проблем. Упомянутые в этот отчете кластеры относят к прогосударственным интересам Китая, Ирана, КНДР и России. Конечно, это просто совпадение, но забавное. @antiinfosec

2026 окончательно оформил квантовую тему в ИБ. Уже как бы не сай-фай, впрочем, пока не реалити-шоу. Никто из серьезных источников не говорит, что завтра квантовый компьютер сломает RSA или биткоин. Зато почти все в один голос говорят про инвентаризацию, криптографическую гибкость и концепцию «harvest now, decrypt later» (читай: собирай уже сейчас, потом как-нибудь с холодильником разберемся). Gartner в начале года формулирует это предельно аккуратно. Мол к 2030 прогресс квантовых вычислений сделает классическую асимметричную криптографию уязвимой. Необязательно сломает, а сделает уязвимой. И это важная разница. Отсюда и сдвиг фокуса: не паника, а учет криптозависимостей и подготовка миграций. Причем постквант всплывает не только рядом с данными, но и с IAM для AI-агентов и machine identities, потому что срок жизни этих сущностей больше одного криптоцикла. В крипте в конце 2025 также было много шума, но выводы там довольно трезвые. Риск компрометации криптографии на эллиптических кривых в 2026 признана теоретической, зато сценарий «harvest now…» уже считается практическим: трафик и подписи можно собирать сегодня, а расшифровывать — когда железо дорастет. На этом фоне появляются патенты и пилоты с постквантом в коммерческих кошельках с продающей и аккуратной формулировкой: не потому что завтра взлом, а потому что потом будет слишком поздно менять фундамент. По железу тоже без магии. Тысяча физических кубитов к 2026, постепенное снижение ошибок, utility-scale ближе к 2029. Для организации реальной битвы Шора против RSA-2048 нужны десятки миллионов логических кубитов - то есть не завтра, но уже в пределах стратегического планирования. Поэтому коридор Q-Day у всех примерно один и тот же: 2029–2035. Российский контур звучит еще спокойнее: квантовая криптография как защитная технология, подготовка заранее, без истерики. По сути тот же месседж, просто без слова Gartner. Но как же круто использовать термин «квантовый апокалипсис». @antiinfosec

Самым неоднозначным изобретением российского импортозамеса последний лет мне хочется назвать эту малопоэтичную аббревиатуру - РБПО (Разработка безопасного программного обеспечения). Так как, судя по языку, стандарт рождался за широкими лбами людей, что ведут ГОСТы и прочие «наборы инженерных практик на все случаи жизни», найти ему аналог в зарубежной ИБ-философии нелегко. Но я попробую эфемерно ухватиться за суть термина и даже не буду жаловаться на его неоднозначность. Хотя вроде уже. Когда чиновники, регуляторы и люди, которые к ним приходят с важными видом кивают на эти четыре буквы, кажется, что все будто упускают одну неудобную деталь: доверие в ИБ начинается не с софта и не с регулятора, а с кремния. Можно сколько угодно обсуждать сертификацию, реестры и методики оценки угроз, но в реальных системах корень доверия всегда физический - чип, его ядра, фаб и тестирование. И дальше уже не так важно, насколько «доверенным» объявлен софт, если все это работает поверх чужого и непрозрачного кристалла. Впрочем, это не локальная российская боль. США в последние годы открыто признают, что глобальная цепочка поставок микросхем - это нацбезопасностная проблема: аппаратные трояны, подмены, зависимость обороны и критической инфраструктуры от нескольких зарубежных производителей, плюс банальные геополитические перекрытия поставок. Отсюда CHIPS and Science Act 2022, разговоры про доверенные фабы и внезапное прозрение, что Zero Trust плохо сочетается с чипами, которые ты получаешь как черный ящик. В Европе формулируют еще жестче. Изобретатели не откручивающихся бутылочных крышек в исследовании по «железной» безопасности прямо пишут, что большинство практических методов обнаружения видят только известные классы аппаратных закладок. А хотя бы о формальных гарантиях безопасности можно говорить только, если есть доступ ко все цепочке, от архитектуры до постссиликон-тестов. На этом фоне российская дискуссия про ЭРБЭПЭО выглядит странно перекошенной. Мы спорим о том, сколько регуляторики нужно доверенному ПО, которое почти всегда разворачивается на полностью зависимом железе, собранном на чужой элементной базе. Формально это импортозамес, фактически все тот же черный ящик, просто с четырьмя красивыми буквами. И вся суверенность аккуратно заканчивается на уровне контроллера, HSM или сетевого чипа. @antiinfosec

Пока компания витают в облаках ИБ-сообщество все чаще задумывается о том, как такие воздушные замки защищать. С одной стороны, у крупных провайдеров отдельные команды ИБ, «круглосуточный» мониторинг с волшебными SLA, патчи не по праздникам и «встроенная отказоустойчивость». Если бы у ИБ средней компании был бюджет гиперскелера, она бы тоже умела так же красиво в резервирование и обновления. С другой - в облаке легко потерять рычаги. On-prem дает прямой контроль. Свои настройки, свои правила сегментации. Да и регулятору проще показать: вот стойка, вот сервер, вот где все лежит. И искать виноватых проще. Если сервер упал, вы точно знаете, кто виноват. Вы сами. Переезд в облако вообще не про отказ от ответственности. Она никуда не девается. Просто вместо «мы сами все контролируем» появляется «мы умеем проверять и дожимать подрядчика». Контракты, SLA, аудит, инцидент-менеджмент. Технические рычаги у провайдера, у вас - договорная база и способность быстро реагировать, когда что-то пошло не так. Привет, Я.Дизастер. Отдельный уровень веселья начинается с мультиоблаками. Такой подход часто продают как еще более надежный, а на практике он первым делом делает ИБ сложнее и дороже. Разные IAM, разные логи, разные интерфейсы - и внезапно никто толком не понимает, где именно лежат данные и кто к ним ходит. Безопаснее не становится, становится запутаннее. Впрочем, может злоумышленнику тоже будет нелегко, конечно. То же с аутсорсом SOC. 24на7 мониторинг, конечно заманчиво, но решения принимают внешние люди. А «быстро» не всегда значит «так, как вы бы хотели». В итоге спор небом облаком и землей бессмысленен без контекста. Ресурсы, зрелость процессов, регуляторика и готовность жить с чужими ошибками решают больше, чем сама платформа. Облако не делает ИБ автоматически лучше или хуже. Оно просто меняет тип рисков. Меньше боли с железом, но больше зависимости от поставщика, видимости и контрактов. И дальше вопрос не в том, где безопаснее, а в том, с какими рисками вы готовы жить осознанно. @antiinfosec

Вокруг Zero Trust в России — заметный «шум»: его продвигают вендоры, на него ссылаются регуляторы и ИБ-руководители, но трактовки сильно расходятся. Для кого-то это «новый стандарт де-факто», для других — ребрендинг давно известных практик. Последние несколько лет стало модно говорить, что Zero Trust «из теории превратился в тренд реальных проектов». Например, как подсчитала «Информзащита» интерес к внедрению в первом квартале 2025 года вырос примерно на 22%. Впрочем, пока этим интересом, кажется все и ограничивается. Концепцию активно обсуждают на конференциях, в медиа и блогах интеграторов, связывая с ростом целевых атак, фишинга и инцидентов по вине сотрудников. Ее позиционируют как ответ на гибридную работу, личные устройства и утечку периметра в облака. Отдельная тема — совместимость Zero Trust с 152‑ФЗ, 187‑ФЗ и приказами ФСТЭК, где уже есть идентификация, минимизация привилегий, сегментация и аудит. Прямых регламентов «про Zero Trust» пока нет, но тема входит в поле через методички ФСТЭК и Минцифры. В ряде материалов его уже упоминают как целевую архитектурную модель. Вендоры и часть экспертов видят в Zero Trust следующий логичный шаг развития ИБ-архитектуры — инфраструктурный стандарт будущего. Акцент на «снижении ущерба от инцидентов», «предсказуемое управление доступом», «встроенное соответствие регуляторам». Однако у некоторых вызывает сомнения не только новизна подхода, но и ощущение, что все это просто маркетинговая надстройка над сетевой сегментацией, с ролевым доступом и строгой аутентификацией. С одной стороны, вокруг Zero Trust формируется консенсус, будто это удобный язык для описания современной архитектуры безопасности. Как на подводной лодке: все в отсеках, которые в случае протечки (ха!) можно все быстро локализовать. С другой стороны, сохраняется разрыв между заявлениями и зрелостью внедрения. Не все компании готовы к такой масштабной перестройке процессов, а часть экспертов и вовсе не видит в подходе новизны. @antiinfosec

Чем чреваты «письма счастья» от OpenAI? Общественность встревожена – OpenAI взломали и у нее утекли данные! Так ли это? Надо ли всем бояться, что наши запросы в ChatGPT стали достоянием гласности? Давайте разбираться. Как это часто бывает в последние годы, взломана была не сама компания, а ее подрядчик; в данном случае аналитическая платформа Mixpanel, которая 8 ноября подверглась атаке, а спустя сутки злоумышленники выгрузили наборы данных, связанных с использованием API OpenAI. Инцидент затронул только пользователей platform.openai.com, работающих через API. Компрометация включала ограниченный набор идентифицирующей информации: ▪️имя учётной записи API, ▪️e-mail, ▪️примерное местоположение (город / штат / страна), ▪️используемые ОС и браузер, ▪️связанные сайты, ▪️идентификаторы организаций и пользователей. Это типичные метаданные веб-аналитики, однако они достаточны для последующих попыток таргетированного фишинга. При этом OpenAI подчеркивает, что пользователям не требуется сбрасывать пароли или заново генерировать ключи доступа, так как ключевые и чувствительные данные сервисов компании не были затронуты: ▪️чаты, ▪️запросы и ответы API, ▪️содержимое промптов, ▪️пароли, ▪️учетные данные, ▪️API-ключи, ▪️платежные данные, ▪️государственные идентификационные данные. Сам подрядчик, Mixpanel, решил уведомить OpenAI об инциденте спустя две недели, а именно 25 ноября, признав, что атака затронула "ограниченное число клиентов". При этом компания не раскрыла технических деталей, не указала объем выгруженных данных, не описала, какие именно системы были скомпрометированы, что оставляет пространство для предположений: масштабы могут быть шире, чем заявлено. Именно поэтому после получения результатов расследования OpenAI прекратила использование сервисов Mixpanel и удалила интеграцию этой платформы из своих продуктов. Хотя утекла лишь "поверхностная" и не самая критичная информация, именно из таких данных строятся фишинговые кампании, попытки атак на учетные записи, а также атаки на администраторов крупных корпоративных заказчиков, использующих API для доступа к LLM-сервисам. Тем более что API-клиенты – это, как правило, компании или разработчики, что повышает ценность цели и открывает, в перспективе, возможности для реализации атак на клиентов этого подрядчика. Алексей Лукацкий, Chief Evangelist Officer, Positive Technologies, специально для @anti_agi

40% российских компаний интегрировали ИБ-инструменты во все процессы DevOps Агентство «Экспресс 42» представило итоги опроса о состоянии DevOps в России. Изучалось влияние опыта разработчиков на производительность команд, вопросы безопасности разработки, применение ИИ, платформенный подход и зрелость контейнерных инфраструктур. Исследование основано на опросе 3,3 тыс. человек. 35,5% из них — из Москвы, 13,8% — из Санкт-Петербурга и Ленинградской области. Некоторые выводы: • эффективность команд выросла по сравнению с предыдущим годом. Показатель рассчитывается по четырем метрикам: частоте развертывания, сроку поставки, времени восстановления и неуспешным изменениям; • в компаниях 40% участников опроса ИБ-инструменты интегрированы в весь процесс DevOps. 26,8% указали, что результат их работы им непонятен, 14,5% — что инструменты не настроены или не дают результата; • 71,4% опрошенных используют ИИ в работе. ИИ чаще всего используется для автоматической генерации кода (65,2%), создания документации (45,5%) и анализа кода на наличие ошибок (45,2%); • самыми важными факторами при выборе ИИ-инструментов респонденты назвали производительность и скорость обработки (64%), пользовательский интерфейс и удобство использования (41,2%), интеграцию и совместимость (40,9%); • доля респондентов, не использующих CI/CD, снизилась с 13,3% в 2024 году до 7,6% в 2025. Количество пользователей GitLab CI/CD увеличилось с 56,7% до 64,5%. Узнать другие результаты →

Везде знаки… Особенно, когда ты видишь такой баннер напротив здания ФСТЭК... #риски