От инженера до директора: сколько реально стоит путь в CISO

Средняя зарплата директора по информационной безопасности в Москве — 500 000 рублей в месяц. В крупном финтехе или госкорпорации вилка доходит до 1,5 млн рублей плюс бонус 30–50% от годового дохода. А топовые позиции с учётом KPI — до 2 млн рублей в месяц.

Разрыв между специалистом по ИБ (230 000 руб.) и CISO уровня топ-менеджмента — шестикратный. И это не вопрос стажа. Это вопрос смены роли и мышления.

🔑 Инженер с десятилетним опытом может провалить собеседование на CISO, если не умеет говорить с CFO на языке бизнес-потерь. А руководитель отдела с пятилетним стажем — получить оффер, потому что принёс на интервью расчёт ROI от внедрённой SIEM с конкретными цифрами.

Путь до позиции директора по ИБ в российских реалиях занимает 7–12 лет при целенаправленном движении. Западные источники называют 15–20 лет — но там другая корпоративная иерархия. В российском финтехе и e-commerce переход быстрее, если не застрять на уровне «вечного инженера».

📍 Три этапа, которые реально работают:

1. Специалист по ИБ (0–3 года) — строите техническую базу. Не просто закрываете тикеты, а копаете глубже: почему инцидент произошёл и какой бизнес-процесс допустил уязвимость. Вилка в Москве — 150 000–280 000 руб./мес.

2. Руководитель отдела (3–7 лет) — перестаёте настраивать SIEM и начинаете решать, какие логи вообще собирать и сколько это стоит бизнесу. Критический момент: если в этой точке руки тянутся к консоли — так и останетесь тимлидом с завышенным титулом. Вилка — 300 000–500 000 руб./мес.

3. CISO (7–12 лет) — здесь уже нужны кейсы по КИИ, опыт прохождения регуляторных проверок (Роскомнадзор, ФСТЭК, ФСБ) и умение защищать бюджет перед советом директоров. Вилка — от 500 000 до 2 000 000 руб./мес.

💡 Рекрутеры из Selecty фиксируют: поиск подходящего CISO затягивается на 4–6 месяцев. Рынок испытывает острый дефицит кандидатов, которые одновременно разбираются в технике, управлении и регуляторике. Это означает одно: если вы целенаправленно строите такой профиль — конкуренция за вас будет выше, чем за большинство других позиций в ИТ.

🎯 Отдельный нюанс — бонусы. Их всё чаще привязывают к конкретным метрикам: время обнаружения атак, прохождение аудитов без критичных несоответствий, снижение числа инцидентов высокого приоритета. Не абстрактное «обеспечил безопасность», а цифры для совета директоров.

Полный roadmap с разбором каждого этапа, реальными вилками и списком проектов для резюме — в статье по ссылке.

https://codeby.net/threads/ciso-kar-yera-roadmap-ot-inzhenera-do-direktora-po-ib-v-2026-godu.92945/

Почему ваш скорборд сломан: изнутри Attack-Defense CTF

Восемь часов соревнований, 24 команды — и чекер, который каждые два тика возвращает CORRUPT. Три человека дебажат Python прямо во время игры, пока участники в чате пишут, что скорборд сломан. Знакомо? Это не гипотетический сценарий — именно так выглядит реальная организация A/D CTF, когда инфраструктура не готова.

🏗 Три кита Attack-Defense

Любой A/D CTF держится на трёх компонентах. Убери один — рассыпается всё.

• Gameserver — мозг соревнования. Размещает флаги, запускает чекеры, принимает сданные флаги, рисует скорборд. Важный момент: он не запускает эксплойты — работает с сервисом как легитимный пользователь.
• Vulnbox — сервер каждой команды с набором уязвимых сервисов. Все команды получают идентичные конфигурации.
• Game network — сеть, через которую команды атакуют друг друга, а gameserver проводит SLA-проверки.

⏱️ Тики: сердцебиение игры

Игра делится на раунды-тики по 1–5 минут. За типичный восьмичасовой CTF с тиками по 2–3 минуты получается 160–240 раундов. Каждый тик gameserver размещает новые флаги и проверяет SLA.

Скоринг складывается из трёх частей: Attack Points (украл флаг), Defense Points (никто не украл у тебя) и SLA Points (сервис жив и отвечает корректно). SLA-баллы — то, что команды теряют чаще всего. Причина банальна: криво запатчили сервис, чекер перестал проходить — и минус очки каждый тик.

🌐 Сетевая изоляция: зачем нужен NAT

Типовая адресация: game network 10.0.0.0/16, vulnbox команды N — 10.0.0.N, submission-сервер — 10.0.13.37:1337. Команды подключаются через VPN — WireGuard или OpenVPN.

Критический элемент — NAT masquerading. Game router делает SNAT на весь игровой трафик: все входящие пакеты на vulnbox выглядят приходящими от одного адреса, независимо от реального источника. Без этого команды могли бы просто заблокировать чужие IP через iptables — и вся «защита» сводилась бы к одному правилу.

🔍 Что происходит под капотом gameserver

На примере FAUST CTF (открытый исходный код): gameserver состоит из независимых модулей на общей PostgreSQL-базе. Checker Master — самый нагруженный: при 5 сервисах и 30 командах он запускает 150 проверок за тик. Плюс Controller, Submission и Web-интерфейс — каждый модуль независим и падает отдельно (что удобно для дебага и неудобно в три часа ночи).

Минимальный стек для 20–30 команд: gameserver просит 8 vCPU и 16 GB RAM, PostgreSQL — ещё 4 vCPU и 8 GB. И это только начало списка.

Полный разбор чекеров, написания SLA-проверок и автоматизации — в статье. Читай, если планируешь организовать собственный A/D или просто хочешь понять, почему скорборд иногда врёт 👇

https://codeby.net/threads/attack-defense-ctf-organizatsiya-ot-gameserver-do-avtomatizatsii-sla.92941/

🔓 Патч закрыл RCE, но оставил кражу хешей: как CVE-2026-32202 обманывает Windows Shell

Представьте: вы добросовестно накатили февральский Patch Tuesday, закрыли активно эксплуатируемую zero-day с CVSS 8.8, проверили — код через вредоносный .lnk больше не выполняется. Всё хорошо? Нет. Ваша машина по-прежнему отправляет Net-NTLMv2-хеш на сервер атакующего. Просто потому, что пользователь открыл папку с ярлыком.

Именно это обнаружили исследователи Akamai, тестируя фикс для CVE-2026-21510. Патч убрал обход SmartScreen и заблокировал RCE, но не тронул механизм аутентификации. Так появился CVE-2026-32202 — zero-click уязвимость Windows Shell, которую CISA 29 апреля добавила в каталог Known Exploited Vulnerabilities с дедлайном до 12 мая.

⚙️ Как это работает

Когда Windows Explorer открывает папку, он автоматически парсит все .lnk-файлы внутри — чтобы отрисовать иконки и метаданные. Если ярлык указывает на UNC-путь вроде \\attacker.com\share\payload.cpl, Shell пытается его резолвить. А резолвинг UNC-пути — это SMB-соединение с удалённым сервером и отправка NTLM-хендшейка.

Ключевой момент: всё это происходит до проверок SmartScreen и Mark of the Web. Исследователи называют это «gap between path resolution and trust verification» — окно между разбором пути и проверкой доверия. Функция ShellExecuteExW резолвит путь и инициирует соединение раньше, чем любые защитные механизмы успевают вмешаться.

Итого — цепочка атаки:

• Атакующий создаёт .lnk с UNC-путём на свой сервер
• Доставляет через фишинг, шару или USB
• Жертва просто открывает папку — даже не кликает по файлу
• Windows Shell автоматически отправляет NTLM-хеш
• Атакующий ловит хеш через Responder и делает relay или offline-брутфорс

🎯 Почему CVSS 4.3 — это обманка

Microsoft оценила уязвимость как MEDIUM (CVSS 4.3). Формально — «частичная утечка конфиденциальных данных, целостность не нарушена». Но в реальной доменной среде перехваченный Net-NTLMv2-хеш — это входной билет. NTLM Relay даёт доступ к соседним сервисам без подбора пароля. Offline-брутфорс через hashcat при слабых паролях занимает минуты. А главное — APT28 уже использовала предшественника этой уязвимости в кампаниях против Украины и стран ЕС.

Получается парадокс: неполный патч превратил критическую RCE (CVSS 8.8) в «среднюю» spoofing-уязвимость (CVSS 4.3). Стало безопаснее, но не безопасно.

Если вы администрируете Windows-инфраструктуру с NTLM — проверьте, что апрельский патч установлен. А полный разбор механики, хронологию от первой CVE до попадания в каталог KEV и рекомендации по защите читайте в полной статье.

https://codeby.net/threads/cve-2026-32202-uyazvimost-windows-shell-zero-click-krazha-ntlm-kheshei-cherez-lnk-faily.92952/

Дымовой датчик с отключённой сиреной: почему smoke-тесты не спасают без обратной связи

Пятница, вечер, деплой уходит в прод. Один flaky-тест из двенадцати снова упал, но gate пропустил сборку — порог «pass if >90%». Суббота, утро — клиенты не могут оплатить заказ. Платёжный эндпоинт прятался именно за тем тестом, который все привыкли игнорировать.

Реальная история с проекта на еженедельных релизах. Smoke-набор ловил дефект. Проблема была не в тестах, а в том, что с результатами никто ничего не делал. Уведомления летели в общий канал, мягкий порог прохождения, разбор падений — «потом».

🔥 Вот ключевая мысль: smoke-тест в CI/CD — это не отчёт, а gate. Отчёт можно проигнорировать. Gate блокирует пайплайн и не пускает сборку дальше. Разница принципиальная.

Gate отвечает на один вопрос: сборка достаточно здорова, чтобы двигаться дальше? Если нет — пайплайн встаёт, разработчик получает уведомление. Если да — запускаются тяжёлые тесты: интеграционные, E2E, нагрузочные.

⚙️ Что именно ловит smoke, чего не поймают юниты:

• Сервис не стартует после деплоя (сломанный Dockerfile, пропущенная миграция)
• Критические эндпоинты отдают 404 или 500
• Переменные окружения не подтянулись — секреты, feature-флаги, connection strings
• Зависимости недоступны: база, кэш, внешний API

Юниты проверяют код в изоляции. Smoke проверяет задеплоенную систему в конкретном окружении. Поэтому smoke-checkpoint ставится после деплоя в staging, а не на этапе сборки.

📍 Три точки, где smoke даёт максимум:

1. После деплоя в staging — ловит проблемы конфигурации и маршрутизации
2. Перед промоушеном в прод — go/no-go gate, потому что staging и prod всегда отличаются по инфраструктуре
3. На canary-подах при progressive delivery — до увеличения трафика

Теперь про сам набор. 5–10 проверок, не больше. Видел suite на 40 тестов, который выполнялся 12 минут. Через месяц его перестали ждать и начали скипать. Весь smoke должен укладываться в 5 минут.

Минимум для любого проекта:

• GET /health — сервис жив
• POST /auth/login — авторизация работает
• Главный read-эндпоинт — данные отдаются
• Главный write-эндпоинт — запись проходит
• DB-probe через healthcheck — миграции применились

И важный нюанс: API-проверки стабильнее и быстрее UI-тестов в smoke. Сломана кнопка, но API работает — дефект, но не smoke-level блокер.

🎯 Главный вывод: smoke без жёсткого gate и разбора падений — дымовой датчик с отключённой сиреной. Фиксирует проблему, но никто не реагирует. В полной статье — конфиги для GitLab CI и GitHub Actions, метрики качества обратной связи и антипаттерны из реальных пайплайнов.

https://codeby.net/threads/smoke-testirovaniye-i-kachestvo-obratnoi-svyazi-ot-progona-do-deistviya-v-ci-cd.92953/

Бэкдор, который выживает после обновления прошивки — разбираем механику FIRESTARTER

Представьте: федеральное ведомство США, Cisco Firepower на периметре. Обнаружена компрометация — накатили патчи, обновили прошивку, перезагрузили устройство. Всё по процедуре. Через шесть месяцев атакующие снова внутри. Без эксплуатации новых уязвимостей. Устройство считалось чистым.

Группировка UAT-4356 (Storm-1849) использовала имплант FIRESTARTER — и его механика персистентности заслуживает отдельного разговора.

🔥 Как это работает

FIRESTARTER — ELF-бинарь, живущий внутри LINA-процесса (ядро ASA: инспекция пакетов, VPN, firewall-правила). Монолитная архитектура LINA — идеальная среда для имплантации, потому что любая модификация изнутри невидима для штатной диагностики.

show version — штатная прошивка. show running-config — тишина. Syslog — тоже тишина.

Весь трюк построен на файле CSP_MOUNT_LIST — он определяет, какие компоненты монтируются и запускаются при загрузке. Вот что делает FIRESTARTER при каждом выключении:

• Перехватывает SIGTERM через callback-функции
• Копирует себя в резервную локацию, замаскированную под штатный лог платформы
• Дописывает себя в CSP_MOUNT_LIST для автозапуска
• После загрузки — восстанавливает оригинальный файл, убирая следы

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

⚡️ Почему патч не помогает

При firmware upgrade устройство выполняет graceful shutdown. FIRESTARTER перехватывает сигнал завершения, сохраняется, прописывает автозапуск — и после загрузки на новой прошивке имплант снова активен. Патч закрыл дверь, а гость уже внутри.

Начальный доступ шёл через связку CVE-2025-20362 (обход авторизации, CVSS 6.5, без учётных данных) + CVE-2025-20333 (buffer overflow, CVSS 9.9, RCE от root). Первая открывает замок, вторая даёт полный контроль. Обе в CISA KEV с сентября 2025 года, дедлайн на патч — один день.

🔍 На диске всего два артефакта: /usr/bin/lina_cs и /opt/cisco/platform/logs/var/log/svc_samcore.log. Негусто для threat hunting. А на legacy-устройствах ASA 5500-X группировка использовала ещё и буткит RayInitiator — persistence через ROMMON, где даже полная переустановка не гарантирует очистку.

Что из этого следует? Обновление прошивки без forensic-анализа — не remediation, а самоуспокоение. Если на периметре стоит Firepower с exposed WebVPN, одного патча мало — нужна проверка целостности файловой системы и анализ CSP_MOUNT_LIST в момент между shutdown и boot.

Сталкивались с персистентностью на сетевых устройствах в своей практике?

Полный разбор механики с деталями по Ghidra-анализу и IOC — в статье на форуме.

https://codeby.net/threads/firestarter-na-cisco-asa-kak-b-ekdor-perezhivayet-patchi.92961/