❓Один процесс — четыре подразделения: кто отвечает за сетевые доступы?

Управление сетевыми доступами давно перестало быть только задачей настройки правил на межсетевом экране. В крупных организациях это отдельный процесс на стыке ИТ, ИБ, compliance и управления изменениями.

В отраслевых обзорах решения нашего класса (NSPM) описываются через несколько ключевых сценариев:

🔹 управление firewall policy;
🔹 сложные workflow изменения правил;
🔹 compliance-аудит и работа с несколькими производителями межсетевых экранов.

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

G2 также описывает NSPM, как класс решений для поддержания compliance и применения сетевых требований в организации.

Поэтому вопрос: «Кто пользуется такой системой?», нельзя свести к одному подразделению. Ею пользуются все участники процесса, но каждый решает свою задачу.

📖 А о том, как это происходит – в нашей сегодняшней статье

🌐 Как разделить работу подразделений в единой системе управления сетевой безопасностью?

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

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

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

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

📖 Забрать его можно вот тут

🌐 ❓Революция в кибербезопасности или конец эпохи?
Или как ИИ-модель Claude Mythos взломала АНБ США и изменила правила сетевой безопасности

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

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

В сегодняшней статье мы разберём, почему модель Claude Mythos от компании Anthropic вызвала панику в Белом доме, к чему привёл конфликт разработчика с Пентагоном, и как обычным людям и бизнесу выживать в мире, где хакером может стать алгоритм.

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

🌐 От уязвимости к маршруту атаки: почему одного знания о CVE уже недостаточно?

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

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

И это уже не теоретическая проблема. В отчёте УЦСБ SOC «Ландшафт киберугроз 2025/2026: тренды, атаки, уязвимости» среди заметных тенденций названы атаки через цепочки поставок и подрядчиков, использование известных уязвимостей для первичного доступа, а также комплексный характер атак: от шифрования и кражи данных до Ransom DDoS. По данным публикаций по исследованию, не менее 30% атак в 2025 году были связаны с компрометацией ИТ-подрядчиков, а число инцидентов с первичным доступом через уже известные уязвимости выросло на 30%.

❓И вот здесь появляется неприятный вопрос: мы правда понимаем, какие из найденных уязвимостей можно использовать в атаке прямо сейчас?

📖 Ответили на него в свежей статье

🔄 Хороший харденинг — это не чек-лист. Это процесс

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

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

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

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

🧹 Гигиена правил МЭ как метод противодействия lateral movement

Правила на межсетевых экранах обычно воспринимаются как эксплуатационная рутина.
Завести доступ, поправить объект, добавить сервис, согласовать исключение, закрыть заявку. Потом ещё одну. И ещё. Через несколько лет политика превращается в живой археологический слой: здесь следы миграции ЦОДа, здесь временный доступ подрядчика, здесь аварийное правило, здесь «не удалять, никто не знает зачем», здесь старый проект, который вроде бы уже закрыт, но лучше не трогать.

❗️Проблема в том, что для атакующего все это не архив. Это инфраструктура движения.

↔️ Lateral movement — боковое перемещение внутри сети — начинается не тогда, когда злоумышленник «магически» оказывается в критичном сегменте. Оно начинается с маршрутов, которые уже есть. С разрешений, которые когда‑то были нужны. С широких правил, которые никто не пересмотрел. С доступов, которые открывали «на время», а потом забыли. С сервисов администрирования, которые доступны чуть шире, чем должны быть.

Именно поэтому гигиена правил МЭ — это не косметика и не бюрократия. Это способ уменьшить количество дорог, по которым атакующий может двигаться после первичной компрометации.

📖 А как настроить процесс регулярной "уборки" правил, рассказываем тут

🌉 Доступ со стороны подрядчика: временный мост, который забыли разобрать

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

❗️Проблема начинается позже.

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

Через полгода уже не очень понятно, кто владелец этого доступа. Через год никто не помнит, зачем он был открыт. Через два года его боятся трогать, потому что “вдруг что-то сломается”. И так временное техническое решение превращается в постоянный маршрут внутрь инфраструктуры.

👨🏻‍💻😈 В дорогу, по которой однажды может пройти уже тот, кого не ждали.

✔️ Подробный чек-лист по демонтажу подобных конструкций в сети выложили вот тут

🌐 ❓Может ли ИИ-агент заменить NSPM?

Недавно наши партнёры, компания Айдеко, провели интересный эксперимент: использовали ИИ-агента для анализа межсетевых экранов.

Для нас эта тема особенно близка. Мы развиваем систему управления сетевыми политиками и постоянно задаёмся вопросом: где ИИ действительно помогает инженеру, а где за удобным диалогом всё равно должны стоять точные алгоритмы и расчёты.

Поэтому мы решили подробно разобрать эксперимент Айдеко и ответить на главный вопрос: может ли ИИ-агент заменить NSPM?

❗️Спойлер: на наш взгляд — нет. Но это не значит, что его роль невелика.
Коротко о том, к чему мы пришли.

🤖 ИИ-агент умеет:
• анализировать переданные ему данные;
• объяснять конфигурацию отдельного устройства;
• находить подозрительные правила и события;
• формировать гипотезы и рекомендации.

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

🌐 NSPM нужна там, где требуется:
• собрать данные со всей инфраструктуры;
• построить модель сети и рассчитать реальные доступы;
• учесть маршрутизацию, NAT, VRF и виртуальные контексты;
• смоделировать последствия изменения или удаления правил;
• получить воспроизводимый результат, которому можно доверять.

Поэтому ИИ-агент вряд ли заменит NSPM.
Зато он вполне может заменить часть сложного интерфейса, часть ручного анализа и несколько часов работы инженера. И это, пожалуй, уже достаточно серьёзный результат.

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

А мы будем рады продолжить обсуждение вместе с коллегами из @ideco_news в комментариях! Интересно порассуждать, какое будущее ИИ в управлении сетевой безопасностью.

🎉 Лето в Киберкэмпе — первый летний open-air по кибербезу

17 июля Netopia и CyberCamp приглашает кибербез-сообщество на летний фестиваль в Берёзы Парк Строгино. Без душных залов и официальных дресс-кодов, с практическими кейсами, играми и отдыхом на природе.

На сцене — Алексей Шульмин, Алексей Лукацкий, Катя Тьюринг, Иван Грузд, Владислав Азерский и другие. Специальный гость — астроном Владимир Сурдин, научпоп «Заблуждения и мифы о Вселенной».

Билеты:
Стандартный
Студенческий

P.S. Едете от компании? Билеты можно оформить по счёту на юридическое лицо.

📅 Дата: 17 июля, с 12:00 до 20:-00
📍 Место: Москва, Берёзы Парк Строгино (Бесплатный трансфер от м. «Щукинская»)

🎊До встречи на CyberCamp!

💣 Захватить Kubernetes и выгнать соседей: анатомия самого наглого облачного червя этого месяца

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

⚔️ Раньше мы представляли себе эту борьбу как классическое противостояние «щита и меча», где защитники противостоят злоумышленникам, но реальность оказалась куда циничней.

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

Новый облачный червь, получивший название CAI (Cloud AI Infrastructure Attack Framework), стал ярчайшим подтверждением этого тезиса.

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

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

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

📝 Забрать стратегию защиты можно тут

🔒 Можно ли защититься от нетиповой атаки с помощью типовых правил?

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

Именно поэтому сегодня важно не только понимать, что запрещено, но и регулярно задавать себе вопрос: что разрешено, кому и зачем?

В новой статье разбираем:
🔹️ почему типовые правила перестают быть достаточными;
🔹️ как злоумышленники используют легитимные каналы;
🔹️ почему широкие разрешения становятся главным союзником атакующих;
🔹 и как модель нормального доступа помогает заметить то, что не видно обычной фильтрации.

📖 Читать тут

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

Конфиденциальные вычисления обещают защитить данные даже во время обработки, а протокол 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. По оценке исследователей, один оператор теперь способен превратить месячный набор опубликованных патчей в рабочие эксплойты за один день — без большой команды узких специалистов.

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

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