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

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

Mistral выпустила Le Chonk — модель, которую можно скачать и развернуть на собственной инфраструктуре. Французская компания утверждает, что после доработки она сравнялась с ведущими китайскими разработками или превзошла их в программировании и кибербезопасности. Но главный спор вокруг релиза касается контроля: кто должен распоряжаться ИИ, когда от него зависит защита корпоративных систем?

Почему приложение тормозит, хотя код работает как надо? Когда микросервисы начинают создавать больше проблем, чем решать? И насколько далеко можно зайти с автоматизацией разработки с помощью ИИ-агентов? В ноябре преподаватели OTUS разберут эти и другие вопросы на 52 бесплатных демо-уроках. В дайджесте — расписание занятий по восьми ИТ-направлениям: от программирования и архитектуры до машинного обучения, информационной безопасности и управления.

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

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

Типичная история: маркетинг на скорую руку поднял лендинг под акцию, разработчики открыли тестовый контур наружу, чтобы коллегам было удобнее проверять код. Никто не делал ничего плохого, но в инвентаризацию эти ресурсы не попали. Служба ИБ узнаёт о них постфактум, а нередко уже после инцидента. Классические инструменты тут не помогают: SIEM работает с известными источниками логов, NGFW фильтрует трафик через известные шлюзы. Актива, которого нет в реестре, они просто не видят. 

В такой ситуации компания становится легкой добычей для злоумышленника. Зачем ломиться через бетонные заборы информационной безопасности, если можно зайти в приоткрытую дверь? Именно так рассуждают хакеры. Поэтому компании важно закрыть все подобные двери, а для начала — найти их с помощью решения класса EASM.

Под катом рассказываем, как устроен наш EASM, как мы боремся с ложными срабатываниями и что оказалось самым сложным в разработке (и стоило нам немало бессонных ночей). Вэлком!

Автор: Дмитрий Квашнин, ведущий инженер-эксперт Innostage

Привет, Хабр!

В первой части статьи мы проверили производительность PT NGFW версии 1.10.3. Измерили скорость установления TCP-соединений, количество одновременных сессий и пропускную способность на профиле EMIX при разных наборах включённых функций.

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

Поэтому вторым этапом мы провели функциональное тестирование той же версии PT NGFW. Мы проверили возможности межсетевого экрана и системы управления: от фильтрации трафика и обнаружения атак до журналирования, разграничения доступа, резервирования и интеграций с другими системами.

23:14. Ночная смена в SOC — центре мониторинга, где аналитики круглосуточно разбирают сигналы о возможных атаках. Аналитик смотрит в экран шестой час. За смену пришло больше 400 алертов, первые полсотни оказались ложными. Он это понял быстро, а система — нет: система продолжает присылать предупреждения с той же частотой и с той же пометкой «высокая важность». К 340 алерту рука тянется к кнопке «Закрыть» раньше, чем глаза дочитывают текст. На 388 аналитик пропускает реальную атаку.

Разбор инцидента займет неделю, а то и больше. Вывод будет стандартный: человеческий фактор. Аналитик не среагировал, значит, нужно усилить контроль, дописать регламенты, провести обучение.

Никто не посмотрит на экран, перед которым аналитик просидел шесть часов.

Современная ИТ‑индустрия уперлась в итерационный тупик. Мы сжигаем гигаватты энергии на серверных фермах, забиваем ядра процессоров тяжелыми legacy‑алгоритмами сложности O(N²) и бесконечно плодим прослойки абстрактного софта. Как результат — интерфейсы и игры умудряются тормозить даже на мощном флагманском железе. Но что, если поток данных — это не просто мертвый набор байт, а физическое поле векторов давления среды?

В этой статье представлен полный разбор неделимого 4-элементного вычислительного конвейера, работающего по принципу децентрализованного сжатия хаоса на базе фрактальной формулы 2N+1. Весь контур — от считывания контекста до финального действия — спроектирован, оптимизирован и протестирован в консоли Termux на обычном Android‑смартфоне, доказывая: для реализации автономных сверхбыстрых систем безопасности и обработки медиапотоков больше не нужны датацентры.

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

В этой статье мы собрали отдельные тезисы спикеров по разным темам, от способов сэкономить на ИБ до связи ИИ и SOC. Любое из заинтересовавших вас выступлений можете просмотреть целиком. О том, как прошёл студенческий день, читайте в нашем прошлом обзоре.

Прошла неделя с «чёрной среды» 21 октября, когда европейские правительства экстренно гасили свои веб-сервисы из-за критического RCE в ядре PHP (CVE-2026-109618 / 19). Первая волна паники и ночных патчей улеглась, и самое время признать главное: инцидент PHP2Shell — это не просто очередной громкий баг. Это водораздел, разделивший кибербезопасность на «до» и «после».

Впервые в истории уязвимость уровня CVSS 10.0 в элементе инфраструктуры, удерживающем ~70% веба, была найдена ИИ-моделью нового поколения в рамках автоматического аудита.

Давайте разберем, почему правила игры изменились навсегда и как индустрии придется адаптироваться к реальности, где нейросети ищут zero-day быстрее, чем люди пишут код.

Проблема парсинга multipart/form-data в PHP годами оставалась в «слепой зоне». Этот кусок кода не трогали десятилетиями из-за священной коровы PHP — обратной совместимости. Человек, глядя на этот код, подсознательно доверял ему: «Раз оно работает с 2000-х и до сих пор не упало, значит, там всё проверено».

ИИ-модели (в данном случае GPT-5.6 Sol от Calif и наработки Wiz) лишены человеческих когнитивных искажений и авторитетов. Нейросеть просто скормила ядро PHP математической модели, построила граф зависимостей и нашла пограничное состояние (edge case), при котором обработка POST-запроса приводила к переполнению буфера до того, как управление передавалось самому веб-приложению.

Главный вывод: ИИ доказал, что «проверенный временем код» — это миф. Нейросети стали идеальными археологами уязвимостей.

У меня круглосуточно работают агенты мониторинга: они собирают бюллетени безопасности и сверяют их с тем, что стоит на серверах. В октябре они подняли сводку: 15 уязвимостей за месяц, все «critical» и «high» — PHP, Nginx, Node.js, Next.js, Java, GitLab. Я проверил каждую строку руками: что это на самом деле, задевает ли меня и чем это лечится.

Итог: две строки меня действительно задели — Node.js был не обновлён четыре дня, а заплатки Nginx не стояли, хотя автообновление включено. Две строки оказались не тем, чем кажутся. А PHP-уязвимости меня не задели по самой простой причине: PHP на сервере нет.

В статье — разбор всех 15 с командами проверки и лечения, почему я снял с сайта все сторонние скрипты и не оставил ни одного инлайн-скрипта, строгая CSP целиком, дыры, которые я нашёл у себя за два месяца, и чек-лист.

Когда инфраструктура начинает тормозить или что-то ломается после очередного деплоя, важно быстро найти причину и понимать, как её устранить. Для этого нужны знания, которые выходят за рамки привычного стека инструментов. Собрали 14 бесплатных уроков для инфраструктурных инженеров — от диагностики сетевых проблем и восстановления LVM до Kubernetes, CI/CD и DevSecOps, с разбором конкретных задач и практических подходов к их решению.

С 30 сентября по 2 октября в Санкт-Петербурге и в Москве прошёл IX Ежегодный форум по информационной безопасности и ИТ GISDAYS 2026. Форум собрал 250 тысяч человек онлайн и более трёх тысяч человек офлайн: партнёров, представителей органов власти, бизнеса, отраслевых специалистов, студентов. Три дня были посвящены поиску работающих решений для защиты государства, корпораций и критической инфраструктуры перед лицом постоянно усложняющихся угроз.

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

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

27 октября 2026 года Митчелл Хашимото выпустил эмулятор терминала с GPU-ускорением — Ghostty 1.4.0. За релизом стоят семь месяцев работы, 172 контрибьютера и 2889 коммитов. В тестах команды на macOS пропускная способность ввода-вывода выросла на 25–55%, а сжатие текстовой истории сократило занимаемую ею физическую память на 70–90%.

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

Наша группа продуктовых исследований регулярно тестирует классические средства сетевой защиты информации — NGFW, IPS. Для этого существуют давно отработанные практики. Например, практически все методики проверки NGFW в зарубежных и отечественных компаниях опираются на стандарты RFC 9411 и RFC 2544 от Internet Engineering Task Force.

К сожалению, с NDR всё иначе: открытых стандартов нагрузочного тестирования для этого класса СЗИ, кажется, просто не существует, а готовые сценарии от NGFW для них не совсем подходят. Поэтому мы разработали собственную методику и делимся ею с ИБ-сообществом.

В этой статье мы не сравниваем конкретные NDR между собой и не доказываем, что один продукт «быстрее» другого. Цель другая: показать воспроизводимый подход к нагрузочному тестированию NDR. Материал пригодится инженерам ИБ, архитекторам SOC, специалистам по тестированию СЗИ, пресейлам и техлидам — всем, кому нужно получить реальные цифры устойчивости NDR под нагрузками, а не «маркетинговую» пропускную способность.

Разберем, чем такое тестирование отличается от классических испытаний NGFW и IPS, как собрать стенд, какие метрики снимать на стороне самого NDR и почему недостаточно статистики генератора трафика. Покажем, как формулировать критерии прохождения теста и как отделять ограничения продукта от ограничений стенда. В конце покажем практический пример того, как методика помогает найти узкое место в производительности NDR. 

В июне 2026 года был опубликован список из 71 уязвимости в экосистеме Spring. Из них 31 получила уровень опасности High, 36 — Medium и четыре — Low. Для сравнения: за весь 2025 год было обнаружено 16 уязвимостей.

Из общего списка уязвимостей мы выбрали три, в которых сочетаются относительно понятный путь до уязвимого кода и серьёзные последствия. Нас интересовало, как ошибка проявляется в распространённых сценариях: при обработке JSON Patch, аутентификации через LDAP и передаче сообщений через Kafka.

Разберём чуть подробнее три самые интересные (по нашему мнению) уязвимости.

Искусственный интеллект ускоряет приоритизацию и сам находит уязвимости (Google Big Sleep предотвратил реальную атаку). Но те же технологии вооружают злоумышленников и сжимают окно реакции до часов. А еще ваши собственные AI-системы становятся целью - со своим OWASP Top 10 и уязвимостями в протоколе MCP - и часто работают у вас в тени, вне поля зрения ИБ. Разбираем все три роли AI без хайпа.