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

ИИ‑фреймворки давно въехали в прод, но к ним часто относятся как к «научной приблуде», а не к ещё одному входу в ваши данные и инфраструктуру. Spring AI и ONNX крутятся где‑то между ML‑командами, продуктами вендоров и внутренними ассистентами, и на определённом этапе за ними перестают успевать архитектура и безопасность.

В марте в обзорах уязвимостей рядом всплыли несколько критичных багов именно в этих штуках. Там есть и SQL‑инъекции, и JSONPath‑инъекции, и обход проверки доверия при загрузке моделей. В статье разбираю, что это значит для тех, кто уже тащит ИИ в прод, и даю чек‑лист, который можно прямо отнести своей команде.

Telega обещала «тот же Telegram, только без VPN». На деле выдали MITM-комбайн с прокси в РФ, вырубленным PFS и нейросетевым Cerberus, который нюхает ваши чаты на лету. В статье разбираем, как «клиент для удобства» тихо превращается в домашний Роскомнадзор в телефоне CIO, и почему один такой апк на смартфоне топа делает бессмысленной всю вашу стратегию по ИБ.

что это за роль, зачем она появилась и кому она вообще подходит

В последние несколько лет в финтех-компаниях всё чаще появляется новая роль — BISO (Business Information Security Officer).

Когда я с этим столкнулся, я подумал только об одном: «Это просто новое модное название безопасника или всё-таки отдельная профессия?»

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

Причём особенно активно она появляется именно в финтехе.

Чтобы понять почему, нужно сначала посмотреть на то, как вообще устроена безопасность в технологических компаниях.

Почему классическая модель безопасности перестала работать

Исорически информационная безопасность в компаниях строилась довольно централизованно.

Обычно структура выглядела примерно так:

Как реально ломают бизнес через людей

tl;dr

Если коротко:

90% атак начинается с фишинга

взломать человека проще, чем сервер

одна ошибка сотрудника может открыть доступ ко всей инфраструктуре

обучение персонала — самая дешёвая защита

Теперь разберёмся как это работает на практике.

Если посмотреть на отчёты по кибербезопасности последних лет, можно заметить одну интересную вещь.

Количество атак растёт.
Сложность атак растёт.
Стоимость атак растёт.

А вот уровень защиты компаний — не всегда.

Проблема в том, что многие организации до сих пор думают о безопасности примерно так:

Исследование само тут, можно забрать, там тоже с картинками 😍

Последние пару лет в разговорах с безопасниками и топами всё чаще звучит одна и та же мысль

Мы перестали задаваться вопросом будет ли атака
Мы начали думать что будет когда она произойдёт

И это очень показательный сдвиг

Финансовая отрасль всегда была мишенью Деньги данные инфраструктура доверие Всё в одном месте Но сейчас изменилось не только количество атак Изменилась их логика

Если раньше злоумышленник пытался проникнуть в систему
то теперь он пытается остановить бизнес

И это совсем другой уровень игры

Сейчас будет неприятный текст.

Если вы ждёте очередную историю успеха в духе «был бариста — стал тестировщиком за три месяца», лучше закрыть вкладку.

Потому что проблема не в курсах. Проблема в экономике.

Если спросить любую финтех-команду, какой стандарт безопасности они используют, ответ будет примерно одинаковый: NIST, ISO 27001, CIS Controls — у кого что ближе.

Но есть нюанс.

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

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

Источник: Ассоциация_Финтех_Compliance_Control_Security_resilience_Подходы

TL;DR: Вы покупаете дорогие security-решения, но при инциденте всё равно паника и хаос? Проблема не в инструментах, а в том, что делаете не на своём уровне зрелости. Разбираем 6 уровней развития ИБ — от «всё на общих паролях» до «безопасность как конкурентное преимущество».

Типичная история: компания тратит на ИБ миллионы, покупает модные SIEM/DLP/EDR, нанимает специалистов, проводит аудиты. А потом прилетает шифровальщик — и выясняется, что бэкапы лежат на том же сервере, доступы раздавали «как у Васи, чтобы не бегать», а план реагирования существует только на бумаге.

Проблема одна: делаете не на своём уровне зрелости.

Зрелость ИБ — это не про стандарты ISO и не про сертификаты SOC2. Это способность не развалиться от типовых проблем и при этом не убить бизнес параноидальным контролем. Это баланс между «нас точно взломают» и «давайте проверять каждый клик сотрудника».

Что внутри статьи:

5 уровней зрелости — от уровня 0 («пароли в общем чате», этот уровень вообще не считаем за уровень) до уровня 5 («ИБ как фактор выигрыша тендеров»)

Портреты компаний на каждом уровне — узнаете себя в первом абзаце

Типичные факапы и почему они происходят именно на вашей стадии

Инструменты и процессы — какие имеют смысл на каждом этапе

Никаких переводов западных фреймворков. Только то, что работает в наших реалиях.

Главный месседж: нормально быть на уровне 2-3, если вы там стабильны и честны с собой. Гораздо хуже притворяться зрелыми на бумаге и гореть на практике. Модель зрелости — это не экзамен на оценку.

Под катом — разбор уровней с примерами, рисками и конкретными действиями. Если хоть раз ловили себя на мысли «мы вроде что-то делаем, но непонятно, достаточно ли этого» — welcome.

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

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

Привет Хабр!

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

Привет Хабр!

Года три назад я сидел на встрече с топ‑менеджментом и показывал очередной «красивый» отчёт по ИТ.Графики растут вверх и вправо, SLA зелёный, количество закрытых тикетов бьёт рекорды, релизов в месяц стало вдвое больше, чем год назад. Всё выглядело так, будто ИТ‑контур вот‑вот начнут носить на руках.

Дорогие мои дорогой Хабр! В 2026‑м почти в каждой крупной компании появился свой ИИ: чат‑бот для сотрудников, ассистент в CRM, помощник в DevOps, «умный поиск» по документации. На слайдах это выглядело как «повышаем эффективность и разгружаем людей». На практике быстро выяснилось, что один такой сервис иногда видит больше, чем любой живой сотрудник: обращения в поддержку, инциденты ИБ, договоры, переписку с ключевыми клиентами — всё это летит через один API.

Проблема в том, что защищаем мы эти штуки по старой памяти — как обычный внутренний сервис «за VPN‑ом». Логика такая: раз доступ только из корпоративной сети, значит, всё ок. Но LLM может крутиться в облаке, ходить в сторонние сервисы, дергать внутренние API и послушно выполнять любые запросы, если их правильно сформулировать. Отсюда вылезают знакомые уже истории: prompt‑injection, утечки через промпты и ответы, «внезапно» найденные в логах следы несанкционированных выгрузок.

На этом фоне Zero Trust перестаёт быть красивой теорией для CISO‑митапов. Если продолжать относиться к модели как к «чёрному ящику, который что‑то там отвечает», мы по сути открываем новый периметр атак — и для внешних злоумышленников, и для своих же людей с лишними правами. Модели и AI‑агенты становятся отдельными участниками инфраструктуры: у них есть доступы, они инициируют действия, они могут накосячить. Значит, им нужны свои роли, ограничения и прозрачный аудит.

В этой статье я разберу, как смотреть на LLM через призму Zero Trust: какие у такой системы реальные угрозы, как может выглядеть референс‑архитектура «доверенной» среды и с чего начать внедрение в живой компании. Цель простая: превратить AI‑сервисы из непонятной магии с доступом «ко всему сразу» в нормальных, управляемых жителей корпоративной ИТ‑архитектуры.
 

В любой компании справочники НСИ сначала выглядят как “ну это же просто таблицы”. Контрагенты, номенклатура, адреса, подразделения, единицы измерения, статусы. Пока людей и систем мало - всё держится на внимательности пары сотрудников и привычке “если что, поправим руками”.

ВВЕДЕНИЕ

В статье разбирается, почему роль CDTO (Chief Digital Transformation Officer, директор по цифровой трансформации) перестала быть модным западным термином и стала практическим ответом на российские реалии — импортозамещение, рост сложности IT‑ландшафта, усиление регуляторных требований и ускорение конкуренции. Автор показывает типичную картину в компаниях от 300 до 5000 сотрудников: есть множество внедрённых систем (1С, Битрикс24, облака Яндекса и VK, ClickHouse, HR‑ и аналитические решения), но нет единой стратегии, приоритизации и человека, который связывает интересы CEO, CIO, CTO, CFO и бизнеса.

Через конкретные примеры и цифры описывается цена хаотичной цифровизации: проваленные сроки проектов, технический долг, сопротивление сотрудников, неэффективные траты 15–30% IT‑бюджета и потеря доли рынка из‑за медленной трансформации. CDTO в этой логике выступает не «ещё одним айтишником», а владельцем стратегии трансформации, архитектуры, данных, процессов, команды и ROI инвестиций.

Статья даёт структурированный «путеводитель» для собственников и CEO: объясняет, чем CDTO отличается от CIO и CTO, какие функции он берёт на себя ежедневно, какой профиль кандидата искать и по каким критериям его оценивать. Отдельные разделы посвящены первым 100 дням CDTO, пошаговому roadmap трансформации на 36 месяцев, реальным кейсам российских компаний, метрикам и KPI, а также критическим ошибкам, которые чаще всего убивают трансформацию. Завершает материал практический чек‑лист: нужен ли CDTO именно вашей компании, какие есть альтернативы и в каких ситуациях промедление с назначением CDTO превращается в стратегический риск.

Привет, Хабр! Сегодня начинаем долгий и подробный разбор уровней зрелости IT-организации. Это не просто теория — это практический гайд для CTO, IT-директоров и руководителей, которые хотят понять, где сейчас находится их компания и как двигаться вперёд.

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