❓Можно ли доверять механизму, который должен доказывать доверие?

Конфиденциальные вычисления обещают защитить данные даже во время обработки, а протокол attested TLS (aTLS) — подтвердить, что вы общаетесь именно с доверенным сервером.

Но новое исследование показало: этот механизм не способен гарантировать то, что обещает. Более того, уязвимость уже получила идентификатор CVE-2026-33697 с высоким уровнем опасности, а существующие средства мониторинга сети не способны обнаружить подобные атаки.

В статье разбираем:
🔹 почему проблема оказалась архитектурной, а не реализационной;
🔹 как её пропустили даже дорогостоящие аудиты безопасности;
🔹 почему BSI призывает не считать confidential computing панацеей;
🔹 что это означает для специалистов по ИБ, архитекторов и тех, кто отвечает за безопасность облачной инфраструктуры.

Если доверие нельзя подтвердить формально, можно ли вообще на нём строить защиту?

📖 Читать тут

📛 Инцидент ViPNet Client 4 —повод не только установить обновление, но и ответить на несколько важных вопросов

❗️ Ситуация с VIPNet — яркая иллюстрация принципа: доверенность системы не должна означать неограниченную сетевую достижимость.

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

Наша платформа в такой ситуации позволяет дать конкретный ответ на вопросы:
🔹 До каких критичных активов существует сетевой доступ?
🔹 Какие векторы атак возможны с учётом известных уязвимостей?
🔹 Какие правила межсетевых экранов обеспечивают эти пути?

Это позволяет перейти от общей оценки угрозы к анализу конкретной инфраструктуры — без автоматических решений за заказчика, но с данными, необходимыми для быстрого и обоснованного реагирования.

📖 А подробный разбор инцидента и чек-лист по быстрому реагированию оставили здесь

🕰 Когда Rust ещё не существовал, а безопасные ОС уже были реальностью

В пятничный вечер хочется чего-то необычного. Поэтому сегодня мы тестируем новый формат и вместо очередного разбора атаки расскажем историю, в которой есть секретная ОС, Министерство обороны США, Modula вместо C и идеи, опередившие своё время на несколько десятилетий.

💻 В современном мире IT кажется, что все инновации рождаются здесь и сейчас.
Мы следим за новыми языками программирования, восхищаемся микроядрами и убеждаем себя, что концепция «безопасности по умолчанию» — достижение последних пяти-десяти лет. Особенно много шума в последние годы вокруг языка Rust, который сделал строгую типизацию и безопасность памяти не просто востребованными, а фактически обязательными для серьёзных проектов.

Но что, если задолго до того, как Rust стал мейнстримом, а формальная верификация ядер ОС превратилась в одну из самых обсуждаемых тем, Министерство обороны США уже разрабатывало операционные системы, построенные на этих принципах? Более того, это были не пыльные академические эксперименты, а реальные системы, которые стояли на страже государственной кибербезопасности и использовались в боевых и разведывательных операциях.

📂 Недавно в архивах The Unix Heritage Society (TUHS) был рассекречен и опубликован исходный код KSOS (Kernelized Secure Operating System). Это событие — не просто повод для ностальгии по ретро-вычислениям. Перед нами исторический артефакт, который позволяет увидеть, как эволюционировала информационная безопасность, как менялись подходы к построению защищённых систем и почему идеи, заложенные ещё в 1970-х годах, остаются актуальными для современных архитекторов безопасности.

В статье мы разберём историю KSOS, погрузимся в технические детали использования языка Modula вместо C. Обсудим формальную верификацию и проведём параллель между военной операционной системой сорокалетней давности и современными подходами к построению безопасных систем.

🔗 Полный текст вот тут, приятного чтения!
И будем рады обратной связи — стоит ли продолжать такие исторические материалы.

🔐 FortiBleed: десятки тысяч FortiGate оказались под угрозой

В июне 2026 года исследователи сообщили о масштабной кампании против межсетевых экранов и SSL VPN-шлюзов Fortinet FortiGate. В обнаруженной базе содержались рабочие административные и VPN-учётные данные для 74 тысяч устройств в 194 странах.

❗️При этом Fortinet подчёркивает: это не новая уязвимость FortiOS, для которой достаточно выпустить патч. В основе кампании — скомпрометированные ранее учётные данные, слабые пароли, перебор и доступные из интернета интерфейсы управления.

❓Но если злоумышленник уже получил доступ к межсетевому экрану, возникает следующий вопрос: куда он сможет попасть дальше?

В новой статье разбираем FortiBleed и показываем, как анализ сетевых политик помогает оценить последствия такой компрометации. В том числе — с помощью Netopia Firewall Compliance.

👉 Подробный разбор тут

🔐 Правила межсетевого экрана — это тоже код. Просто его исполняет сеть

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

А если добавить NAT, несколько межсетевых экранов и сложную сетевую топологию, политика превращается в настоящую распределённую программу — только без привычного IDE, тестов и code review.

В новой статье разбираемся, почему правила МЭ стоит рассматривать именно так и что общего у сетевого технического долга с мёртвым кодом, а изменение правила — с релизом в production.

📖 Прочитать полностью можно здесь

🛡 ⚔️ От N-day к N-hour: почему при уязвимости важно не только быстрее поставить патч, но и закрыть путь атаки

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

Между публикацией исправления и его установкой остаётся patch gap — период, когда информация об уязвимости уже доступна атакующим, а часть систем продолжает работать без защиты.
Раньше этот промежуток мог измеряться неделями. Чтобы сравнить старую и новую версии продукта, найти исправленную ошибку и превратить её в рабочий эксплойт, требовались квалифицированные специалисты по реверс-инжинирингу. Теперь эта работа всё активнее автоматизируется.

В эксперименте Anthropic языковая модель самостоятельно создала восемь работающих эксплойтов для 18 изученных исправлений Firefox. При анализе 21 исправления ядра Windows модель построила восемь полноценных цепочек повышения привилегий до уровня SYSTEM. По оценке исследователей, один оператор теперь способен превратить месячный набор опубликованных патчей в рабочие эксплойты за один день — без большой команды узких специалистов.

Разработка эксплойта — не вся атака. Злоумышленнику ещё нужно найти уязвимую систему, доставить код, обойти защиту и закрепиться. Но один из наиболее дорогих этапов заметно ускоряется. И это меняет главный вопрос для защитников.
Раньше он звучал так:
❓ Насколько быстро мы можем установить исправление?
Теперь к нему добавляется второй:
❓ Насколько быстро мы можем сделать уязвимый компонент недостижимым для атакующего?

👉 Ответ на последний вопрос здесь

🌐 Сетевую инфраструктуру нельзя считать безопасной по умолчанию

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

❗️Это ещё раз напоминает о простом принципе: сетевой инфраструктуре нельзя доверять только на основании того, что она работает штатно. Её состояние нужно регулярно подтверждать проверками.

Причём проверять не отдельные устройства и не время от времени, а системно — конфигурации, изменения, соответствие требованиям и отклонения от заданного состояния.
В этом и заключается роль NSPM: превратить контроль сетевой инфраструктуры из разовой проверки в постоянный процесс.

В новом материале разбираем атаку Fire Ant и показываем, почему системный контроль конфигураций — важная часть защиты инфраструктуры.

👉 Читать полностью тут

🔎 Что, если атака начинается задолго до самой атаки?

Volt Typhoon — группировка, которую американские власти связывают с многолетней кампанией против критической инфраструктуры. Её цель — не просто проникнуть в отдельные системы, а получить доступ к сетям и закрепиться в них, оставаясь незаметной.

🕵️ Для этого злоумышленники использовали легитимные инструменты и учётные данные — то есть действия, которые сами по себе не всегда выглядят подозрительно.

❓Почему такие атаки сложно обнаружить? И что эта история показывает о безопасности сетевой инфраструктуры?

В статье разобрали историю Volt Typhoon, сценарии атак и рекомендации CISA — с акцентом на то, что происходит внутри сети после получения доступа.

👉 Читать полностью

📢 Netopia на ПРО Кибербез 2026

❓️Как привести сетевую инфраструктуру к требованиям информационной безопасности — пошагово и без попыток разобраться с сотнями настроек вручную?

29 сентября на ПРО Кибербез об этом расскажет Александр Миляр, руководитель отдела продаж Netopia.

📌 Тема доклада:
«Пошаговая инструкция приведения сетевой инфраструктуры к комплаенсу по ИБ»

На примере Netopia Firewall Compliance разберём:

🔹 почему настройки коммутаторов, маршрутизаторов и межсетевых экранов часто остаются непрозрачными для ИБ;
🔹 как проверять сетевую инфраструктуру на соответствие требованиям и рекомендациям по безопасной настройке;
🔹 какие меры можно выполнить на примере приказа ФСТЭК №117;
🔹 как подход применим к требованиям PCI DSS и рекомендациям производителей оборудования;
🔹 какие реальные задачи заказчиков решает автоматизация контроля сетевой безопасности.

🔗 Подробнее о конференции

🌆 Вечер пятницы — время разобраться, как защищать сеть без лишних простоев

🔐 Cisco развивает Live Protect Shield — механизм, который позволяет блокировать эксплуатацию некоторых уязвимостей без обновления сетевой ОС. А технология xFSU помогает сократить простой при полноценном обновлении.

Как это работает, при чём здесь eBPF и почему временная защита всё-таки не заменяет патч? Разобрали в новой статье 👇

🔗 Читать полностью тут

☕️ Приятного чтения и спокойной пятницы!

🔥 Netopia на SOC Forum 2026: раскрываем карты!

До форума осталось меньше двух недель — самое время рассказать, что мы подготовили!

🎙 28 октября в 17:30 на сцене SOC Forum выступят Павел Кириллов, технический директор Netopia, и Алексей Рабе, руководитель отдела архитектуры ИБ WB Банка.

Тема доклада:
От Syslog к смыслу: как разделить анализ сетевой безопасности между NGFW, NSPM и SIEM

Нужно ли отправлять в SIEM всё, что генерируют межсетевые экраны? На примере WB Банка спикеры разберут, как отделить действительно важные события от технического шума и распределить задачи между SOC, SIEM и средствами контроля сетевой безопасности.

💙 А ещё все два дня форума, 27 и 28 октября, Netopia будет ждать вас на собственном стенде!
Приходите знакомиться с нашей платформой, задавать вопросы команде и обсуждать задачи сетевой безопасности.

📍 Москва, Раменский бульвар, 1, кластер «Ломоносов».

🎟 Если ещё не зарегистрировались на SOC Forum — самое время это сделать!

До встречи!