🏃♂️ Бизнес, ИБ и нехватка кадров: где помогает NSPM?
Бизнес хочет быстрее внедрять изменения, команда безопасности — держать все под контролем, а кадров не хватает по обе стороны.
Именно в этой точке NSPM и автоматизация становятся не просто удобным инструментом, а способом снять часть нагрузки и сократить разрыв между запросами бизнеса и возможностями ИБ.
Как именно это происходит, разобрали в новой статье
Бизнес хочет быстрее внедрять изменения, команда безопасности — держать все под контролем, а кадров не хватает по обе стороны.
Именно в этой точке NSPM и автоматизация становятся не просто удобным инструментом, а способом снять часть нагрузки и сократить разрыв между запросами бизнеса и возможностями ИБ.
Как именно это происходит, разобрали в новой статье
🔥4❤2🥰2
🌐 Роль NSPM в корпоративном ландшафте сети: за что отвечает?
В крупной организации система защиты информации обычно состоит из набора взаимосвязанных решений: межсетевых экранов, SIEM, сканеров уязвимостей, Service Desk, CMDB, IPAM, NAC, PAM, EDR, средств управления конфигурациями, DLP, SOAR и других систем.
Каждая из них отвечает за свой слой.
SIEM собирает события безопасности. Сканер уязвимостей выявляет слабые места на хостах и приложениях. Service Desk управляет заявками. CMDB хранит сведения об активах. IPAM содержит данные об адресном пространстве. Межсетевые экраны применяют политики доступа.
❓ При этом между этими слоями часто остаётся разрыв: как фактическая сетевая связность соотносится с политикой безопасности, заявками, активами, уязвимостями и изменениями?
Сегодня рассказываем о том, как NSPM связывает между собой сетевую топологию, правила доступа, конфигурации, изменения, создавая единую точку управления ИБ в организации.
📖 Прочитать можно вот тут
В крупной организации система защиты информации обычно состоит из набора взаимосвязанных решений: межсетевых экранов, SIEM, сканеров уязвимостей, Service Desk, CMDB, IPAM, NAC, PAM, EDR, средств управления конфигурациями, DLP, SOAR и других систем.
Каждая из них отвечает за свой слой.
SIEM собирает события безопасности. Сканер уязвимостей выявляет слабые места на хостах и приложениях. Service Desk управляет заявками. CMDB хранит сведения об активах. IPAM содержит данные об адресном пространстве. Межсетевые экраны применяют политики доступа.
❓ При этом между этими слоями часто остаётся разрыв: как фактическая сетевая связность соотносится с политикой безопасности, заявками, активами, уязвимостями и изменениями?
Сегодня рассказываем о том, как NSPM связывает между собой сетевую топологию, правила доступа, конфигурации, изменения, создавая единую точку управления ИБ в организации.
📖 Прочитать можно вот тут
👍4🔥4🥰2❤1
💣👨🏻💻 MongoBleed: когда база данных становится открытой дверью для хакеров
В мире кибербезопасности есть одна непреложная истина: уязвимости не спрашивают разрешения, прежде чем появиться. Они возникают там, где их меньше всего ждут, и эксплуатируются именно в тот момент, когда организации расслабляются, полагая, что их это не коснётся.
❗️Один из недавних примеров — инцидент с критической уязвимостью в MongoDB, получившей звучное название MongoBleed (CVE-2025–14847).
Для специалистов по сетевой безопасности и кибербезопасности эта ситуация — не просто ещё один пункт в ленте новостей. Это сигнал к действию. Платформа сетевой безопасности, которую выстраивает современная компания, должна быть способна реагировать на такие угрозы не постфактум, а на опережение.
Сегодня мы подробно разберём, что такое MongoBleed, почему эта уязвимость представляет такую серьёзную опасность, какие шаги необходимо предпринять для защиты инфраструктуры.
📖 Прочитать можно вот тут
В мире кибербезопасности есть одна непреложная истина: уязвимости не спрашивают разрешения, прежде чем появиться. Они возникают там, где их меньше всего ждут, и эксплуатируются именно в тот момент, когда организации расслабляются, полагая, что их это не коснётся.
❗️Один из недавних примеров — инцидент с критической уязвимостью в MongoDB, получившей звучное название MongoBleed (CVE-2025–14847).
Для специалистов по сетевой безопасности и кибербезопасности эта ситуация — не просто ещё один пункт в ленте новостей. Это сигнал к действию. Платформа сетевой безопасности, которую выстраивает современная компания, должна быть способна реагировать на такие угрозы не постфактум, а на опережение.
Сегодня мы подробно разберём, что такое MongoBleed, почему эта уязвимость представляет такую серьёзную опасность, какие шаги необходимо предпринять для защиты инфраструктуры.
📖 Прочитать можно вот тут
🔥7👍3🥰2❤1
🚨NGINX Rift: майская критическая уязвимость в nginx
В статье разбираем, в чём именно суть проблемы, какие настройки могут оказаться под ударом и как быстро проверить свои конфигурации без лишней суеты.
🛠 Там же есть практические рекомендации, которые помогут оценить риск и закрыть слабые места.
📖 Читать разбор: CVE-2026–42945 (NGINX Rift): анализ уязвимости и практические рекомендации
🔐 Если у вас в инфраструктуре есть nginx, эту статью точно стоит прочитать.
В статье разбираем, в чём именно суть проблемы, какие настройки могут оказаться под ударом и как быстро проверить свои конфигурации без лишней суеты.
🛠 Там же есть практические рекомендации, которые помогут оценить риск и закрыть слабые места.
📖 Читать разбор: CVE-2026–42945 (NGINX Rift): анализ уязвимости и практические рекомендации
🔐 Если у вас в инфраструктуре есть nginx, эту статью точно стоит прочитать.
🔥5❤2🥰2
⚔️ Харденинг конфигураций сетевых устройств: недооценённый
рубеж защиты
В новостях о кибератаках чаще всего обсуждают уязвимости, вредоносное ПО и фишинг. Но иногда атака строится не вокруг сложного эксплойта, а вокруг плохо защищённой конфигурации сетевого устройства.
Хороший пример — недавняя история с кампанией APT28 против роутеров TP-Link и MikroTik. По данным Минюста США, злоумышленники с 2024 года использовали известные уязвимости, получали доступ к тысячам роутеров TP-Link и меняли их DNS-настройки так, чтобы DNS-запросы уходили на серверы под контролем атакующих. Это позволяло проводить атаки типа adversary-in-the-middle и перехватывать пароли, токены, письма и другие чувствительные данные.
Британский NCSC описывает похожую механику: APT28 перезаписывали DHCP/DNS-настройки на роутерах, чтобы перенаправлять трафик через контролируемые DNS-серверы и красть пароли, OAuth-токены и другие учётные данные.
На первый взгляд это история про домашние и малые офисные роутеры. Но вывод из неё шире: конфигурация сетевого устройства сама по себе является рубежом защиты. Если она настроена слабо, даже обычный роутер может стать точкой перехвата трафика и дальнейшей компрометации.
📖 Как этого не допустить, рассказали вот тут
рубеж защиты
В новостях о кибератаках чаще всего обсуждают уязвимости, вредоносное ПО и фишинг. Но иногда атака строится не вокруг сложного эксплойта, а вокруг плохо защищённой конфигурации сетевого устройства.
Хороший пример — недавняя история с кампанией APT28 против роутеров TP-Link и MikroTik. По данным Минюста США, злоумышленники с 2024 года использовали известные уязвимости, получали доступ к тысячам роутеров TP-Link и меняли их DNS-настройки так, чтобы DNS-запросы уходили на серверы под контролем атакующих. Это позволяло проводить атаки типа adversary-in-the-middle и перехватывать пароли, токены, письма и другие чувствительные данные.
Британский NCSC описывает похожую механику: APT28 перезаписывали DHCP/DNS-настройки на роутерах, чтобы перенаправлять трафик через контролируемые DNS-серверы и красть пароли, OAuth-токены и другие учётные данные.
На первый взгляд это история про домашние и малые офисные роутеры. Но вывод из неё шире: конфигурация сетевого устройства сама по себе является рубежом защиты. Если она настроена слабо, даже обычный роутер может стать точкой перехвата трафика и дальнейшей компрометации.
📖 Как этого не допустить, рассказали вот тут
🔥7
❓Один процесс — четыре подразделения: кто отвечает за сетевые доступы?
Управление сетевыми доступами давно перестало быть только задачей настройки правил на межсетевом экране. В крупных организациях это отдельный процесс на стыке ИТ, ИБ, compliance и управления изменениями.
В отраслевых обзорах решения нашего класса (NSPM) описываются через несколько ключевых сценариев:
🔹 управление firewall policy;
🔹 сложные workflow изменения правил;
🔹 compliance-аудит и работа с несколькими производителями межсетевых экранов.
Такой подход подчёркивает, что речь идёт не просто об интерфейсе для инженера, а о платформе взаимодействия разных ролей вокруг сетевой политики.
G2 также описывает NSPM, как класс решений для поддержания compliance и применения сетевых требований в организации.
Поэтому вопрос: «Кто пользуется такой системой?», нельзя свести к одному подразделению. Ею пользуются все участники процесса, но каждый решает свою задачу.
📖 А о том, как это происходит – в нашей сегодняшней статье
Управление сетевыми доступами давно перестало быть только задачей настройки правил на межсетевом экране. В крупных организациях это отдельный процесс на стыке ИТ, ИБ, compliance и управления изменениями.
В отраслевых обзорах решения нашего класса (NSPM) описываются через несколько ключевых сценариев:
🔹 управление firewall policy;
🔹 сложные workflow изменения правил;
🔹 compliance-аудит и работа с несколькими производителями межсетевых экранов.
Такой подход подчёркивает, что речь идёт не просто об интерфейсе для инженера, а о платформе взаимодействия разных ролей вокруг сетевой политики.
G2 также описывает NSPM, как класс решений для поддержания compliance и применения сетевых требований в организации.
Поэтому вопрос: «Кто пользуется такой системой?», нельзя свести к одному подразделению. Ею пользуются все участники процесса, но каждый решает свою задачу.
📖 А о том, как это происходит – в нашей сегодняшней статье
🔥4👍2
🌐 Как разделить работу подразделений в единой системе управления сетевой безопасностью?
В прошлой статье мы разобрались, почему единая система управления сетевой безопасностью в организации — это хорошо и удобно.
Благодаря ей становится видно общую картину: сетевые устройства, правила межсетевых экранов, маршруты, NAT, зоны, матрицы доступа, изменения и риски, от чего выигрывают все участники процесса.
❗️ Но у такой единой картины есть обратная сторона.
Разные подразделения начинают работать с одними и теми же данными, но с разными целями. Одни отвечают за стабильность сети, другие — за поиск рисков и построение векторов атак. Одни вносят изменения, другие могут с ними не согласиться. Одни считают правило необходимым для работы сервиса, другие видят в нём путь для горизонтального перемещения злоумышленника по сети.
Поэтому при внедрении NSPM-системы важно заранее определить не только роли в интерфейсе, но и организационную модель: кто за что отвечает, кто что может менять, кто согласует спорные решения и где проходит граница между эксплуатацией и аналитикой.
В статье составили для вас пошаговый план, чтобы распределение работы подразделений прошло как можно легче.
📖 Забрать его можно вот тут
В прошлой статье мы разобрались, почему единая система управления сетевой безопасностью в организации — это хорошо и удобно.
Благодаря ей становится видно общую картину: сетевые устройства, правила межсетевых экранов, маршруты, NAT, зоны, матрицы доступа, изменения и риски, от чего выигрывают все участники процесса.
❗️ Но у такой единой картины есть обратная сторона.
Разные подразделения начинают работать с одними и теми же данными, но с разными целями. Одни отвечают за стабильность сети, другие — за поиск рисков и построение векторов атак. Одни вносят изменения, другие могут с ними не согласиться. Одни считают правило необходимым для работы сервиса, другие видят в нём путь для горизонтального перемещения злоумышленника по сети.
Поэтому при внедрении NSPM-системы важно заранее определить не только роли в интерфейсе, но и организационную модель: кто за что отвечает, кто что может менять, кто согласует спорные решения и где проходит граница между эксплуатацией и аналитикой.
В статье составили для вас пошаговый план, чтобы распределение работы подразделений прошло как можно легче.
📖 Забрать его можно вот тут
❤3🔥3
🌐 ❓Революция в кибербезопасности или конец эпохи?
Или как ИИ-модель Claude Mythos взломала АНБ США и изменила правила сетевой безопасности
Июнь 2026 года войдёт в историю как месяц, когда искусственный интеллект пересёк невидимый Рубикон. То, о чем фантасты предупреждали десятилетиями, а эксперты по кибербезопасности шептались на закрытых конференциях, случилось наяву.
Новая нейросеть не просто написала умный код или сгенерировала реалистичное видео — она взломала самые защищённые секретные системы крупнейшей мировой державы. И сделала это не за недели, как это делали лучшие хакеры мира, а за считанные часы.
В сегодняшней статье мы разберём, почему модель Claude Mythos от компании Anthropic вызвала панику в Белом доме, к чему привёл конфликт разработчика с Пентагоном, и как обычным людям и бизнесу выживать в мире, где хакером может стать алгоритм.
📖 Прочитать полностью можно по ссылке
Или как ИИ-модель Claude Mythos взломала АНБ США и изменила правила сетевой безопасности
Июнь 2026 года войдёт в историю как месяц, когда искусственный интеллект пересёк невидимый Рубикон. То, о чем фантасты предупреждали десятилетиями, а эксперты по кибербезопасности шептались на закрытых конференциях, случилось наяву.
Новая нейросеть не просто написала умный код или сгенерировала реалистичное видео — она взломала самые защищённые секретные системы крупнейшей мировой державы. И сделала это не за недели, как это делали лучшие хакеры мира, а за считанные часы.
В сегодняшней статье мы разберём, почему модель Claude Mythos от компании Anthropic вызвала панику в Белом доме, к чему привёл конфликт разработчика с Пентагоном, и как обычным людям и бизнесу выживать в мире, где хакером может стать алгоритм.
📖 Прочитать полностью можно по ссылке
🔥4
🌐 От уязвимости к маршруту атаки: почему одного знания о CVE уже недостаточно?
Компании научились находить уязвимости. Сканеры регулярно приносят списки CVE, дашборды окрашиваются в красный, отчёты показывают критичность, владельцам систем уходят задачи на исправление. Процесс вроде бы есть: нашли, оценили, назначили, закрыли.
Но в какой‑то момент эта система перестает работать — уязвимостей становится слишком много.
Часть нельзя быстро исправить. Часть находится на системах, к которым никто не хочет прикасаться без отдельного проекта. Часть формально критична, но живёт в изолированном сегменте. А где‑то рядом есть уязвимость с более скромной оценкой, зато к ней ведёт прямой и давно забытый сетевой доступ.
И это уже не теоретическая проблема. В отчёте УЦСБ SOC «Ландшафт киберугроз 2025/2026: тренды, атаки, уязвимости» среди заметных тенденций названы атаки через цепочки поставок и подрядчиков, использование известных уязвимостей для первичного доступа, а также комплексный характер атак: от шифрования и кражи данных до Ransom DDoS. По данным публикаций по исследованию, не менее 30% атак в 2025 году были связаны с компрометацией ИТ-подрядчиков, а число инцидентов с первичным доступом через уже известные уязвимости выросло на 30%.
❓И вот здесь появляется неприятный вопрос: мы правда понимаем, какие из найденных уязвимостей можно использовать в атаке прямо сейчас?
📖 Ответили на него в свежей статье
Компании научились находить уязвимости. Сканеры регулярно приносят списки CVE, дашборды окрашиваются в красный, отчёты показывают критичность, владельцам систем уходят задачи на исправление. Процесс вроде бы есть: нашли, оценили, назначили, закрыли.
Но в какой‑то момент эта система перестает работать — уязвимостей становится слишком много.
Часть нельзя быстро исправить. Часть находится на системах, к которым никто не хочет прикасаться без отдельного проекта. Часть формально критична, но живёт в изолированном сегменте. А где‑то рядом есть уязвимость с более скромной оценкой, зато к ней ведёт прямой и давно забытый сетевой доступ.
И это уже не теоретическая проблема. В отчёте УЦСБ SOC «Ландшафт киберугроз 2025/2026: тренды, атаки, уязвимости» среди заметных тенденций названы атаки через цепочки поставок и подрядчиков, использование известных уязвимостей для первичного доступа, а также комплексный характер атак: от шифрования и кражи данных до Ransom DDoS. По данным публикаций по исследованию, не менее 30% атак в 2025 году были связаны с компрометацией ИТ-подрядчиков, а число инцидентов с первичным доступом через уже известные уязвимости выросло на 30%.
❓И вот здесь появляется неприятный вопрос: мы правда понимаем, какие из найденных уязвимостей можно использовать в атаке прямо сейчас?
📖 Ответили на него в свежей статье
👍4
🔄 Хороший харденинг — это не чек-лист. Это процесс
Харденинг сетевого оборудования часто воспринимают как набор разовых настроек при вводе устройства в эксплуатацию: сменить пароль, отключить Telnet, настроить syslog, ограничить доступ к админке. Это правильные действия, но сам подход шире.
Хороший профиль харденинга — это формализованный набор проверок, который описывает, как должно быть настроено сетевое устройство, чтобы его нельзя было легко использовать как точку входа, перехвата трафика или дальнейшего перемещения по сети.
В свежей статье мы разобрали, как собрать хороший профиль харденинга, откуда брать требования и как это должно работать на практике.
📖 Прочитать можно здесь
Харденинг сетевого оборудования часто воспринимают как набор разовых настроек при вводе устройства в эксплуатацию: сменить пароль, отключить Telnet, настроить syslog, ограничить доступ к админке. Это правильные действия, но сам подход шире.
Хороший профиль харденинга — это формализованный набор проверок, который описывает, как должно быть настроено сетевое устройство, чтобы его нельзя было легко использовать как точку входа, перехвата трафика или дальнейшего перемещения по сети.
В свежей статье мы разобрали, как собрать хороший профиль харденинга, откуда брать требования и как это должно работать на практике.
📖 Прочитать можно здесь
👍2🔥1
🧹 Гигиена правил МЭ как метод противодействия lateral movement
Правила на межсетевых экранах обычно воспринимаются как эксплуатационная рутина.
Завести доступ, поправить объект, добавить сервис, согласовать исключение, закрыть заявку. Потом ещё одну. И ещё. Через несколько лет политика превращается в живой археологический слой: здесь следы миграции ЦОДа, здесь временный доступ подрядчика, здесь аварийное правило, здесь «не удалять, никто не знает зачем», здесь старый проект, который вроде бы уже закрыт, но лучше не трогать.
❗️Проблема в том, что для атакующего все это не архив. Это инфраструктура движения.
↔️ Lateral movement — боковое перемещение внутри сети — начинается не тогда, когда злоумышленник «магически» оказывается в критичном сегменте. Оно начинается с маршрутов, которые уже есть. С разрешений, которые когда‑то были нужны. С широких правил, которые никто не пересмотрел. С доступов, которые открывали «на время», а потом забыли. С сервисов администрирования, которые доступны чуть шире, чем должны быть.
Именно поэтому гигиена правил МЭ — это не косметика и не бюрократия. Это способ уменьшить количество дорог, по которым атакующий может двигаться после первичной компрометации.
📖 А как настроить процесс регулярной "уборки" правил, рассказываем тут
Правила на межсетевых экранах обычно воспринимаются как эксплуатационная рутина.
Завести доступ, поправить объект, добавить сервис, согласовать исключение, закрыть заявку. Потом ещё одну. И ещё. Через несколько лет политика превращается в живой археологический слой: здесь следы миграции ЦОДа, здесь временный доступ подрядчика, здесь аварийное правило, здесь «не удалять, никто не знает зачем», здесь старый проект, который вроде бы уже закрыт, но лучше не трогать.
❗️Проблема в том, что для атакующего все это не архив. Это инфраструктура движения.
↔️ Lateral movement — боковое перемещение внутри сети — начинается не тогда, когда злоумышленник «магически» оказывается в критичном сегменте. Оно начинается с маршрутов, которые уже есть. С разрешений, которые когда‑то были нужны. С широких правил, которые никто не пересмотрел. С доступов, которые открывали «на время», а потом забыли. С сервисов администрирования, которые доступны чуть шире, чем должны быть.
Именно поэтому гигиена правил МЭ — это не косметика и не бюрократия. Это способ уменьшить количество дорог, по которым атакующий может двигаться после первичной компрометации.
📖 А как настроить процесс регулярной "уборки" правил, рассказываем тут
👍3
🌉 Доступ со стороны подрядчика: временный мост, который забыли разобрать
Доступ подрядчика почти всегда появляется по уважительной причине.
Нужно внедрить систему, настроить интеграцию, провести диагностику, устранить инцидент, помочь с сопровождением. Проект горит, сроки сжимаются, бизнес ждёт результата. В такой момент доступ открывают не для красоты — он действительно нужен.
❗️Проблема начинается позже.
Работы закончились. Заявку закрыли. Люди переключились на следующий проект. Подрядчик, возможно, уже давно не заходит. Но сетевое правило осталось. VPN-профиль остался. Доступ к сегменту остался. Временный мост, который строили для конкретной задачи, никто не разобрал.
Через полгода уже не очень понятно, кто владелец этого доступа. Через год никто не помнит, зачем он был открыт. Через два года его боятся трогать, потому что “вдруг что-то сломается”. И так временное техническое решение превращается в постоянный маршрут внутрь инфраструктуры.
👨🏻💻😈 В дорогу, по которой однажды может пройти уже тот, кого не ждали.
✔️ Подробный чек-лист по демонтажу подобных конструкций в сети выложили вот тут
Доступ подрядчика почти всегда появляется по уважительной причине.
Нужно внедрить систему, настроить интеграцию, провести диагностику, устранить инцидент, помочь с сопровождением. Проект горит, сроки сжимаются, бизнес ждёт результата. В такой момент доступ открывают не для красоты — он действительно нужен.
❗️Проблема начинается позже.
Работы закончились. Заявку закрыли. Люди переключились на следующий проект. Подрядчик, возможно, уже давно не заходит. Но сетевое правило осталось. VPN-профиль остался. Доступ к сегменту остался. Временный мост, который строили для конкретной задачи, никто не разобрал.
Через полгода уже не очень понятно, кто владелец этого доступа. Через год никто не помнит, зачем он был открыт. Через два года его боятся трогать, потому что “вдруг что-то сломается”. И так временное техническое решение превращается в постоянный маршрут внутрь инфраструктуры.
👨🏻💻😈 В дорогу, по которой однажды может пройти уже тот, кого не ждали.
✔️ Подробный чек-лист по демонтажу подобных конструкций в сети выложили вот тут
❤3🔥1
🌐 ❓Может ли ИИ-агент заменить NSPM?
Недавно наши партнёры, компания Айдеко, провели интересный эксперимент: использовали ИИ-агента для анализа межсетевых экранов.
Для нас эта тема особенно близка. Мы развиваем систему управления сетевыми политиками и постоянно задаёмся вопросом: где ИИ действительно помогает инженеру, а где за удобным диалогом всё равно должны стоять точные алгоритмы и расчёты.
Поэтому мы решили подробно разобрать эксперимент Айдеко и ответить на главный вопрос: может ли ИИ-агент заменить NSPM?
❗️Спойлер: на наш взгляд — нет. Но это не значит, что его роль невелика.
Коротко о том, к чему мы пришли.
🤖 ИИ-агент умеет:
• анализировать переданные ему данные;
• объяснять конфигурацию отдельного устройства;
• находить подозрительные правила и события;
• формировать гипотезы и рекомендации.
❗️но:
• зависит от качества навыка и понимания конкретного вендора.
• может ошибиться в интерпретации настроек.
• не должен самостоятельно менять боевую политику.
🌐 NSPM нужна там, где требуется:
• собрать данные со всей инфраструктуры;
• построить модель сети и рассчитать реальные доступы;
• учесть маршрутизацию, NAT, VRF и виртуальные контексты;
• смоделировать последствия изменения или удаления правил;
• получить воспроизводимый результат, которому можно доверять.
Поэтому ИИ-агент вряд ли заменит NSPM.
Зато он вполне может заменить часть сложного интерфейса, часть ручного анализа и несколько часов работы инженера. И это, пожалуй, уже достаточно серьёзный результат.
📖 Полную статью можно прочитать здесь
А мы будем рады продолжить обсуждение вместе с коллегами из @ideco_news в комментариях! Интересно порассуждать, какое будущее ИИ в управлении сетевой безопасностью.
Недавно наши партнёры, компания Айдеко, провели интересный эксперимент: использовали ИИ-агента для анализа межсетевых экранов.
Для нас эта тема особенно близка. Мы развиваем систему управления сетевыми политиками и постоянно задаёмся вопросом: где ИИ действительно помогает инженеру, а где за удобным диалогом всё равно должны стоять точные алгоритмы и расчёты.
Поэтому мы решили подробно разобрать эксперимент Айдеко и ответить на главный вопрос: может ли ИИ-агент заменить NSPM?
❗️Спойлер: на наш взгляд — нет. Но это не значит, что его роль невелика.
Коротко о том, к чему мы пришли.
🤖 ИИ-агент умеет:
• анализировать переданные ему данные;
• объяснять конфигурацию отдельного устройства;
• находить подозрительные правила и события;
• формировать гипотезы и рекомендации.
❗️но:
• зависит от качества навыка и понимания конкретного вендора.
• может ошибиться в интерпретации настроек.
• не должен самостоятельно менять боевую политику.
🌐 NSPM нужна там, где требуется:
• собрать данные со всей инфраструктуры;
• построить модель сети и рассчитать реальные доступы;
• учесть маршрутизацию, NAT, VRF и виртуальные контексты;
• смоделировать последствия изменения или удаления правил;
• получить воспроизводимый результат, которому можно доверять.
Поэтому ИИ-агент вряд ли заменит NSPM.
Зато он вполне может заменить часть сложного интерфейса, часть ручного анализа и несколько часов работы инженера. И это, пожалуй, уже достаточно серьёзный результат.
📖 Полную статью можно прочитать здесь
А мы будем рады продолжить обсуждение вместе с коллегами из @ideco_news в комментариях! Интересно порассуждать, какое будущее ИИ в управлении сетевой безопасностью.
❤2👍1🔥1🤔1
🎉 Лето в Киберкэмпе — первый летний open-air по кибербезу
17 июля Netopia и CyberCamp приглашает кибербез-сообщество на летний фестиваль в Берёзы Парк Строгино. Без душных залов и официальных дресс-кодов, с практическими кейсами, играми и отдыхом на природе.
На сцене — Алексей Шульмин, Алексей Лукацкий, Катя Тьюринг, Иван Грузд, Владислав Азерский и другие. Специальный гость — астроном Владимир Сурдин, научпоп «Заблуждения и мифы о Вселенной».
Билеты:
Стандартный
Студенческий
P.S. Едете от компании? Билеты можно оформить по счёту на юридическое лицо.
📅 Дата: 17 июля, с 12:00 до 20:-00
📍 Место: Москва, Берёзы Парк Строгино (Бесплатный трансфер от м. «Щукинская»)
🎊До встречи на CyberCamp!
17 июля Netopia и CyberCamp приглашает кибербез-сообщество на летний фестиваль в Берёзы Парк Строгино. Без душных залов и официальных дресс-кодов, с практическими кейсами, играми и отдыхом на природе.
На сцене — Алексей Шульмин, Алексей Лукацкий, Катя Тьюринг, Иван Грузд, Владислав Азерский и другие. Специальный гость — астроном Владимир Сурдин, научпоп «Заблуждения и мифы о Вселенной».
Билеты:
Стандартный
Студенческий
P.S. Едете от компании? Билеты можно оформить по счёту на юридическое лицо.
📅 Дата: 17 июля, с 12:00 до 20:-00
📍 Место: Москва, Берёзы Парк Строгино (Бесплатный трансфер от м. «Щукинская»)
🎊До встречи на CyberCamp!
👍7❤3
Кажется, мы наконец-то пришли в себя после пятницы 😄
После фестиваля сил хватило на то, чтобы собрать стенд и добраться домой. Поэтому с итогами — только сейчас.
Кибертир превзошёл наши ожидания. Почти всё время у стенда была очередь: кто-то приходил проверить меткость, кто-то возвращался за реваншем, а кто-то просто останавливался посмотреть. Было очень шумно, азартно и по-настоящему весело
Спасибо каждому, кто играл с нами, поддерживал атмосферу и уносил с собой хорошее настроение (и немного нашего мерча) 😉
Мы нашли несколько фотографий с фестиваля, но уверены, что самые интересные кадры остались у вас.
Давайте ещё немного продлим атмосферу праздника: если вы фотографировали наш стенд, кибертир или просто поймали нас в кадре, поделитесь снимками в комментариях. Будем рады снова пережить эти моменты вместе с вами! 📸
Спасибо за этот день! До новых встреч! 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍3
💣 Захватить Kubernetes и выгнать соседей: анатомия самого наглого облачного червя этого месяца
Облачная инфраструктура сегодня – это высокоорганизованная, динамичная и сложная экосистема, которая стала главной ареной борьбы в современном цифровом мире.
⚔️ Раньше мы представляли себе эту борьбу как классическое противостояние «щита и меча», где защитники противостоят злоумышленникам, но реальность оказалась куда циничней.
Теперь на облачном поле брани развернулась настоящая мафиозная война, где группировки киберпреступников сражаются не только с системами безопасности, но и друг с другом за контроль над вычислительными ресурсами.
Новый облачный червь, получивший название CAI (Cloud AI Infrastructure Attack Framework), стал ярчайшим подтверждением этого тезиса.
Он не просто заражает серверы, крадёт учётные данные и майнит криптовалюту. Он идет дальше: находит вредоносное ПО конкурентов, убивает их процессы, удаляет их файлы и выгоняет их с заражённых машин, чтобы единолично монополизировать ресурсы.
В новом техническом лонгриде мы разберём анатомию CAI, посмотрим, как работает самый агрессивный облачный червь последних недель и изучим эволюцию облачных угроз.
🛡 Ну и, самое главное, поговорим о том, как обеспечить сетевую безопасность, чтобы ваша инфраструктура не стала очередной жертвой в этой схватке.
📝 Забрать стратегию защиты можно тут
Облачная инфраструктура сегодня – это высокоорганизованная, динамичная и сложная экосистема, которая стала главной ареной борьбы в современном цифровом мире.
⚔️ Раньше мы представляли себе эту борьбу как классическое противостояние «щита и меча», где защитники противостоят злоумышленникам, но реальность оказалась куда циничней.
Теперь на облачном поле брани развернулась настоящая мафиозная война, где группировки киберпреступников сражаются не только с системами безопасности, но и друг с другом за контроль над вычислительными ресурсами.
Новый облачный червь, получивший название CAI (Cloud AI Infrastructure Attack Framework), стал ярчайшим подтверждением этого тезиса.
Он не просто заражает серверы, крадёт учётные данные и майнит криптовалюту. Он идет дальше: находит вредоносное ПО конкурентов, убивает их процессы, удаляет их файлы и выгоняет их с заражённых машин, чтобы единолично монополизировать ресурсы.
В новом техническом лонгриде мы разберём анатомию CAI, посмотрим, как работает самый агрессивный облачный червь последних недель и изучим эволюцию облачных угроз.
🛡 Ну и, самое главное, поговорим о том, как обеспечить сетевую безопасность, чтобы ваша инфраструктура не стала очередной жертвой в этой схватке.
📝 Забрать стратегию защиты можно тут
👍2
🔒 Можно ли защититься от нетиповой атаки с помощью типовых правил?
Запретить опасные порты, обновить сигнатуры, заблокировать известные домены — всё это необходимо. Но современные атаки всё чаще не пытаются проломить защиту. Они ищут то, что уже разрешено.
Именно поэтому сегодня важно не только понимать, что запрещено, но и регулярно задавать себе вопрос: что разрешено, кому и зачем?
В новой статье разбираем:
🔹️ почему типовые правила перестают быть достаточными;
🔹️ как злоумышленники используют легитимные каналы;
🔹️ почему широкие разрешения становятся главным союзником атакующих;
🔹 и как модель нормального доступа помогает заметить то, что не видно обычной фильтрации.
📖 Читать тут
Запретить опасные порты, обновить сигнатуры, заблокировать известные домены — всё это необходимо. Но современные атаки всё чаще не пытаются проломить защиту. Они ищут то, что уже разрешено.
Именно поэтому сегодня важно не только понимать, что запрещено, но и регулярно задавать себе вопрос: что разрешено, кому и зачем?
В новой статье разбираем:
🔹️ почему типовые правила перестают быть достаточными;
🔹️ как злоумышленники используют легитимные каналы;
🔹️ почему широкие разрешения становятся главным союзником атакующих;
🔹 и как модель нормального доступа помогает заметить то, что не видно обычной фильтрации.
📖 Читать тут
👍2🔥2
❓Можно ли доверять механизму, который должен доказывать доверие?
Конфиденциальные вычисления обещают защитить данные даже во время обработки, а протокол attested TLS (aTLS) — подтвердить, что вы общаетесь именно с доверенным сервером.
Но новое исследование показало: этот механизм не способен гарантировать то, что обещает. Более того, уязвимость уже получила идентификатор CVE-2026-33697 с высоким уровнем опасности, а существующие средства мониторинга сети не способны обнаружить подобные атаки.
В статье разбираем:
🔹 почему проблема оказалась архитектурной, а не реализационной;
🔹 как её пропустили даже дорогостоящие аудиты безопасности;
🔹 почему BSI призывает не считать confidential computing панацеей;
🔹 что это означает для специалистов по ИБ, архитекторов и тех, кто отвечает за безопасность облачной инфраструктуры.
Если доверие нельзя подтвердить формально, можно ли вообще на нём строить защиту?
📖 Читать тут
Конфиденциальные вычисления обещают защитить данные даже во время обработки, а протокол attested TLS (aTLS) — подтвердить, что вы общаетесь именно с доверенным сервером.
Но новое исследование показало: этот механизм не способен гарантировать то, что обещает. Более того, уязвимость уже получила идентификатор CVE-2026-33697 с высоким уровнем опасности, а существующие средства мониторинга сети не способны обнаружить подобные атаки.
В статье разбираем:
🔹 почему проблема оказалась архитектурной, а не реализационной;
🔹 как её пропустили даже дорогостоящие аудиты безопасности;
🔹 почему BSI призывает не считать confidential computing панацеей;
🔹 что это означает для специалистов по ИБ, архитекторов и тех, кто отвечает за безопасность облачной инфраструктуры.
Если доверие нельзя подтвердить формально, можно ли вообще на нём строить защиту?
📖 Читать тут
🔥4