SMS-атаки: миф или реальность?

«У меня же подтверждение по SMS — кто меня будет ломать?»

SMS-код — лучше, чем ничего, но слабее, чем аутентификатор и passkeys. Разберём, какие атаки реальны для всех, а какие — для тех, на кого целятся намеренно.

Как уводят доступ через SMS

🔹 Выманивают код — грозит всем Звонок: «Это банк, продиктуйте код» или «Мама, срочно скинь». Поддельный сайт по ссылке из SMS/мессенджера: выглядит как настоящий, но код уходит мошенникам. Не ломают систему — ломают человека. Это самый частый сценарий.

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

🔹 Перевыпуск SIM — чаще целевая атака Мошенник «забирает» твой номер (твоя SIM перестаёт работать, его — начинает) через салон связи или поддержку оператора. Это не массовка — нужны усилия, иногда деньги или связи. Применяют против тех, у кого есть что взять.

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

Когда риск выше

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

Перевыпуск SIM и перехват через сеть редки, но становятся реальнее, когда к номеру привязаны: — банк, карты, инвестиции, крипта — маркетплейсы, доставка, такси — рабочие доступы к данным или сервисам — публичность (канал, блог, медийность) — всё завязано на один номер и одну почту

Правило простое: чем больше у вас денег, важных доступов и публичности — тем выше шанс, что будут «дожимать» всерьёз.

📱 План защиты

1️⃣ Замени SMS на аутентификатор Любой известный — например, Google Authenticator, Microsoft Authenticator, Яндекс Ключ. SMS оставь только там, где альтернативы нет.

2️⃣ Код = тайна. Всегда. Никто не должен «уточнять код». Если ты сам не начинал вход и тебя просят назвать код — это развод. Не вводи код по ссылке — только в приложении или на сайте, куда пришёл сам.

3️⃣ Защити SIM от перевыпуска На Госуслугах включи запрет на оформление новых SIM-карт (раздел «Сим-карты» → «Запрет на оформление договоров связи»). Снять можно только через МФЦ — это защита от мошенников. Дополнительно: у оператора поставь кодовое слово на перевыпуск и перенос номера.

4️⃣ Включи уведомления Вход, смена пароля, смена контактов, отключение 2FA — уведомления на всё.

5️⃣ Почта — главный вход Отдельный сложный пароль + 2FA. Проверь пересылки, резервные адреса, активные сессии.

6️⃣ Максимум — passkeys Вход без пароля: подтверждение на устройстве лицом, пальцем или PIN. Самый устойчивый к фишингу вариант из массово доступных. Проверь в настройках безопасности своих сервисов.

⚡ С чего начать? Сделай пункт 4 прямо сейчас. Пункт 2 — держи как правило. Пункт 3 — сегодня.

Вывод

SMS-подтверждение — хорошо, но и не идеально.

Минимум: не отдавай коды + уведомления + защита SIM. Лучше: аутентификатор. Идеально: passkeys.

Cохрани и перешли близким — в праздники особенно актуально.

@safebdv

А вы уже перешли с SMS на аутентификатор? Напишите в комментах 👇

 

Практика Румельта для ИБ-вендоров: 3 типовых препятствия и как из них сделать стратегию

В первом посте я писал, что стратегия по Румельту — это не список целей, а способ пробить одно ключевое препятствие.

И здесь я от теории перейду к практике. Ниже три препятствия, которые я чаще всего вижу у ИБ-вендоров. Узнаете себя — отлично: это материал для диагноза.

Важно: если вы узнаёте себя сразу во всех трёх — это нормально. Но по Румельту нужно выбрать одно главное препятствие на ближайший цикл. Быстрый критерий: какое препятствие объясняет больше всего ваших симптомов одновременно?

---

Препятствие №1. Интеграции и «невидимая цена внедрения» (time-to-value убивает PoC)

Симптомы:

• PoC тянется 2–6 месяцев и “умирает по дороге”.

• Заказчик говорит: «интересно, но ресурсов нет».

• Пресейл перегружен “ручными” интеграциями и "доработкой напильником".

Механизм (диагноз):

• Ценность проявляется только после набора интеграций/настроек.

• Внедрение не повторяемое: каждый проект как новый.

• Вендор продаёт продукт, а заказчик покупает проект (со сроками и рисками).

Провокационные вопросы:

• На каком шаге PoC чаще стопорится: доступы, сбор логов, коннекторы, нормализация, правила, отчёты, интеграции с ИТ или сетью?

• Сколько человеко-дней нужно, чтобы показать первую ценность?

Пример направляющей политики:

• «Стандартизируем внедрение: типовые сценарии, готовые интеграции, шаблоны, “первая ценность за N дней”».
  Запрет: «Доработки вне roadmap — только если он становится типовым пакетом».

---

Препятствие №2. Размытый ICP и продажа “всем” (воронка полная, а побед мало)

Симптомы:

• Много лидов, низкий win-rate.

• Споры “кому это нужно” между продуктом/продажами/маркетингом.

• Продукт превращается в «комбайн» под все отрасли.

Механизм (диагноз):

• Нет жёсткого профиля “наш клиент” → нет точного ценностного сообщения → ресурсы распыляются.

• Сделки заходят в пилот без понятного критерия успеха.

• Включается иллюзия: “добавим ещё фичу — и купят”.

Провокационные вопросы:

• В каких 2–3 сегментах у вас реально повторяются сделки (быстрее цикл, выше чек, проще внедрение)?

• Какая общая черта у ваших реальных побед (а не у красивых лидов)?

Пример направляющей политики:

• «Фокус на 2–3 ICP/вертикали, где ценность проявляется быстро и повторяемо».
  Запрет: «Не делаем “универсальные фичи для всех”, если они не усиливают выбранные ICP».

---

Препятствие №3. Доверие и доказательность эффективности (без “доказуемости” нет масштабирования)

Симптомы:

• Возражения: «а вы точно детектите?», «а что с ложными срабатываниями?», «а стабильность?».

• Долгие согласования у безопасников/архитекторов/эксплуатации.

• Проигрыши “брендам” даже при сопоставимой функциональности.

Механизм (диагноз):

• Покупатель боится операционного риска из-за нестабильности: “поставим — и будем страдать”.

• Нет доказательной базы: измеримые кейсы, контрольные сценарии, эталонные тесты, референсы, эксплуатационные метрики.

• В результате покупают не продукт, а доверие к бренду.

Провокационные вопросы:

• Что для вас является доказательством: бенчмарки, сценарные тесты, референсы, метрики на проде?

• Какие 3 вопроса задают на каждой второй сделке — и чем вы отвечаете в цифрах?

Пример направляющей политики:

• «Строим доказательность: стандартные тест-сценарии, прозрачные метрики качества, референсные внедрения, эксплуатационные SLO».
  Запрет: «Не гонимся за “галочками в RFP”, если они ухудшают стабильность/качество/внедряемость».

---

Как применить это за 30 минут (мини-сессия)

1. Выберите одно препятствие из трёх (или своё).

2. Сформулируйте диагноз одной фразой:
   «Главное препятствие: ___, потому что ___».

3. Сформулируйте политику и запрет:
   «Мы делаем ___, чтобы ___; поэтому мы НЕ делаем ___».

4. Выпишите 3 согласованных действия (с владельцем и кварталом).

---

Вопрос в комментарии

Какая из трёх проблем вам ближе: интеграции/time-to-value, размытый ICP, доказательность/доверие?
Или назовите своё препятствие — я готов подумать, какая направляющая политика под него сработает. Мне интересно, ведь я только что защитил диссертацию по этой теме.

 

Стратегия по Румельту: почему у большинства ИБ-вендоров её нет

Каждый год компании тратят недели на «стратегические сессии», а потом живут как жили. Ричард Румельт дал мне инструмент, который превращает разговоры “обо всём хорошем” в конкретный план действий за 10–30 минут. Ниже — понятная схема и шаблон.

30 слайдов про «цифровой суверенитет» и 12 KPI — это не стратегия. Это PowerPoint-успокоительное, которое не управляет ни одним нашим решением.

Ричард Румельт (профессор UCLA, автор Good Strategy / Bad Strategy) предлагает простую проверку:

стратегия — это не цели, а способ пробить одно ключевое препятствие.

Хорошая стратегия — это «ядро» из трёх частей:

---

Шаг 1. Диагноз: найдите точку слома

Диагноз — это не «нужно больше внедрений». Это конкретный ответ: что именно ломается в механизме.

Задайте себе вопросы (лучше — на материале реальных сделок и внедрений):

• где ломается конверсия PoC → контракт?

• почему клиенты не продлеваются после первого года?

• во что реально упирается рост: регуляторика (ФСТЭК/ФСБ), дефицит инженеров, архитектура, партнёрский канал?

Пример (вымышленный, но узнаваемый):
«Множество PoC по SIEM застревают на интеграции с российскими системами: у заказчика нет 2–3 инженеров на 3–6 месяцев, а у вендора коннекторы делаются как кастом “вручную” под каждого. Итог: пилот не превращается в контракт».

Важно: диагноз — это механизм, а не жалоба.

Возьмите вашу последнюю потерянную сделку. На каком конкретном шаге клиент сказал “стоп”?
Это и есть точка для диагноза.

---

Шаг 2. Направляющая политика: создайте «коридор» для решений

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

Жёсткий тест Румельта: если политика ничего не запрещает — это не политика.

Пример:

«Переходим на шаблонное развёртывание и интеграции “из коробки” (API + типовые пакеты) для типовых сценариев».

Запрет: «Не делаем кастомные коннекторы вне roadmap — даже если клиент предлагает +30% к бюджету (иначе масштабируемости не будет)».

---

Шаг 3. Действия: сшейте отделы в один поток создания ценности

Третья часть — согласованные действия. Не «каждый отдел тянет в свою сторону», а один коридор.

Пример того, как это выглядит в компании:

• Продукт (Q1): создаем библиотеку Terraform/Ansible-модулей + типовые интеграции.

• Пресейл (Q1): продаём не список фич, а демонстрацию ценности для заказчика (развёртывание за часы).

• Маркетинг (Q2): описываем теперь кейсы «PoC → прод за 2 недели», а не «100500 правил/сек».

---

Быстрый тест вашей «стратегии» (3 вопроса)

➡ Можно ли одной фразой сказать, какое препятствие ломает политика?
➡➡    Если нужно 5 минут контекста — политика размыта.

➡ Сужает ли политика пространство допустимых действий?
➡➡    Если после неё “всё равно можно всё” — это халтура, а не стратегия.

➡ Она реально сшивает продукт / продажи / инженерию?
 ➡➡   Если звучит «обо всём хорошем» — это и есть “плохая стратегия”.

---

Инструмент внедрения: рабочая сессия на 30 минут

Чтобы это не осталось “умным текстом”, вот формат сессии, который реально запускается:

10 минут: каждый независимо пишет свой вариант «главного препятствия» (1 стикер = 1 препятствие).

10 минут: обсуждаем, группируем, голосуем за ОДНО препятствие.

10 минут: заполняем шаблон ниже.

---

Мини-шаблон (заполнить и повесить на стену)

Diagnosis:
«Главное препятствие: ___, потому что ___ (механизм)».

Guiding policy:
«Наш подход: ___, чтобы преодолеть ___».
«Границы: мы НЕ делаем ___, даже если ___, потому что ___».

Coherent actions:
«Действие 1 → Действие 2 → Действие 3»
(+ владелец и квартал)

---

Практика: самый честный вопрос

Что одно реально держит вашу систему прямо сейчас: рынок / продукт / цикл разработки / внедрение / канал / доверие?
Назовите одно — и проверьте: это причина или симптом.

P.S. Если у вас есть «стратегия развития СЗИ», но нет ответа на вопрос:
«Какие 3 вещи мы НЕ делаем в 2026, даже если конкуренты делают?» — у вас нет стратегии.
У вас есть новогодние пожелания друг другу.

С наступающим! 🙂

Напишите в комментариях одну вещь, которую ваша компания “перестала делать” ради фокуса — и что это дало.
Или поделитесь вашим «препятствием» — вместе подумаем, какую политику для него построить.

Как хакеры проникают в компании в 2025 году: что должен знать каждый руководител

Практическое руководство для тех, кто не хочет стать следующей жертвой

Представьте: утро понедельника, вы приходите в офис, а вся IT-инфраструктура компании заблокирована. На экранах — требование выкупа в криптовалюте. Бухгалтерия не работает, клиентская база недоступна, производство остановлено. Это не сценарий фильма — это реальность, с которой в 2025 году столкнулись тысячи компаний по всему миру.

Сегодня я запланировал рассказать вам простым языком: как именно злоумышленники попадают внутрь корпоративных сетей и что с этим делать.

Главное изменение: хакеры больше не взламывают — они входят

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

В 2025 году всё изменилось. В 79% случаев злоумышленники вообще не используют вредоносные программы. Они просто входят в систему как легитимные пользователи — с настоящими логинами и паролями ваших сотрудников.

Почему так произошло? Компании научились ловить вирусы. Антивирусы стали умнее, системы мониторинга — внимательнее. Но украденный пароль системой безопасности не распознаётся как угроза — ведь это «свой» пользователь.

Четыре главных способа проникновения

Будущая модель защиты компании от киберугроз (2025→2030): три уровня

Рассмотрите три уровня и на каждом рассмотрите важные цели

1. Стратегический уровень — что должно быть в бизнес-процессах.
2. Технологический уровень — какие технологии реально будут защищать.
3. Человеческий уровень — какие роли становятся критичными и почему.

---

1. Стратегический уровень (процессы, управление, архитектура)

1.1. Управление рисками как непрерывный процесс

1. Определить единый риск-каталог:

   • технологические риски

   • бизнес-риски

   • риски ИБ

   • риски сторонних поставщиков

2. Внедрить количественные модели оценки:

   • FAIR

   • MITRE C-SCRM

3. Ввести регулярные циклы пересмотра риска:

   • ежеквартальные «risk-adjustment cycles»

   • интеграция с бюджетированием

4. Интегрировать риск-показатели в OKR продуктов и владельцев процессов.

1.2. Процесс непрерывного обнаружения и реакции

1. Создать единую архитектуру телеметрии:

   • identity

   • endpoint

   • cloud

   • network

   • SaaS

2. Внедрить playbook-автоматизацию (SOAR 2.0):

   • ≥ 40% рутины закрыто автоматикой

3. SOC Future Model:

   • L1 исчезает → заменён ML/LLM

   • L2 = triage + hunch-based hunting

   • L3 = эксперты по TTP, облаку и identity

4. Zero-trust по умолчанию:

   • каждый доступ = проверка

   • каждый ресурс = сегмент

1.3. Процессы защиты цепочек поставок (supply-chain)

1. Полный SBOM для всех продуктов и CI/CD.

2. Политики для open source:

   • запрет «непроверенных» пакетов

   • обязательный static + behavioral анализ

3. Непрерывный monitoring third-party:

   • VRM Tier-1 → ежедневный

   • VRM Tier-2 → еженедельный

   • VRM Tier-3 → ежеквартальный

1.4. Data-centric защита

1. Классификация данных = обязательный шаг в любом проекте.

2. Data Perimeter:

   • контроль, куда данные могут уходить

   • запрет «теневых» SaaS

3. Политики идентичности для данных:

   • кто может использовать

   • кто может экспортировать

1.5. Governance для AI (новый обязательный блок)

1. Политика использования LLM / AI:

   • что можно

   • что запрещено

2. AI Risk Register.

3. Контроль промтов и логирование.

4. AI-security гейт для релизов:

   • eval модели

   • проверка на jailbreak

   • тесты на утечку информации

---

2. Технологический уровень (инструменты, которые реально будут защищать)

2.1. Identity-first Security

1. Passwordless + FIDO2

2. Continuous Adaptive Trust (CAT)

3. Machine Identity Management

4. Privilege Access Management (PAM 2.0)

Почему важно:
95% всех успешных атак в 2024–2025 мошенники подделывали учетные данные чтобы их идентифицировали как легитимного сотрудника (данные из Microsoft + CrowdStrike).

---

2.2. AI-поддерживаемые средства защиты

1. Detection AI:

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

2. Generative IR (LLM в SOC):

   • автоматический разбор инцидента

   • drafting уведомлений

3. AI-based anomaly detection (cloud + network):

   • необычные пути доступа

   • подозрительные токены

4. AI-red teaming:

   • поиск слабостей в конфигурации

   • имитация атак уровня APT

Вывод:
AI становится не «фичей», а ядром обороны.

---

2.3. Cloud Native Security

1. CSPM / DSPM / CIEM

2. Runtime-защита контейнеров

3. Identity Graph в облаке

4. Unified Cloud Threat Detection (Google / Wiz подход)

Это становится must-have, потому что 70% атак в 2025 происходят через облачные misconfigurations.

---

2.4. Zero Trust Connectivity

1. ZTNA 2.0

2. SDP (software-defined perimeter)

3. Micro-segmentation в SaaS и облаке

---

2.5. Supply-chain защиты

1. SLSA 1–4

2. Behavioral контроль артефактов

3. NPM/PyPI monitoring + interdiction

4. Dependency policy-engine в CI/CD

ReversingLabs показывает:
70% supply-chain атак — это вредонос в зависимости.

---

2.6. Защита от шифровальщиков

1. Immutable backup

2. Fast restore (< 4 часа SLA)

3. Identity hardening (AD/AzureAD)

4. Network containment automation

---

3. Человеческий уровень (роли и компетенции будущего)

3.1. Identity инженеры

Самая дефицитная роль по данным CyberArk и SailPoint.

Требования:

• протоколы (OIDC/SAML/Kerberos/SCIM)

• управление токенами

• управление machine identities

• настройка адаптивного доступа

---

3.2. Cloud Security Engineers

Компетенции:

• CSPM / DSPM / CIEM

• Kubernetes runtime

• IAM в AWS/GCP/Azure

• threat hunting в облаке

---

3.3. Threat Hunters нового типа

Навыки:

• осознание TTP APT групп

• работа с огромными графами телеметрии

• работа с ML/LLM для ускорения аналитики

---

3.4. AI Governance / AI Security Engineers

Новая критичная роль.

Задачи:

• контроль использования LLM

• тестирование моделей на jailbreak

• защита данных от утечек через AI

• мониторинг промтов

• policy-based guardrails

---

3.5. SecDevOps / Supply-chain инженеры

Фокус:

• SAST + SCA (advanced)

• поведенческий анализ зависимостей

• контроль артефактов

• build system hardening

---

3.6. Digital Forensics / Incident Commanders

От них зависит уменьшение «времени жизни» атакующего в системе (dwell time).

Компетенции:

• автоматизированные расследования

• IR в облаке

• протоколы цифровой атрибуции

---

4. Итоговая модель (коротко и жёстко)

4.1. Что будет защищать нас в будущем — процессы

1. Identity-first security

2. Непрерывный threat detection (AI-assisted)

3. Защита цепочки поставок и CI/CD

4. Data Perimeter + минимизация данных

5. Governance для AI

6. Cloud-native security как «основной столб»

4.2. Что будет защищать — технологии

1. AI-поддерживаемый SOC

2. Zero Trust (ZTNA 2.0)

3. CSPM/DSPM/CIEM

4. SBOM + SLSA

5. Runtime container security

6. Identity-платформы (IAM/PAM/MIM)

4.3. Кто будет защищать — люди

1. Identity-инженеры

2. Cloud security инженеры

3. Threat hunters уровня L3

4. AI Security инженеры

5. SecDevOps инженеры

6. IR/DFIR лидеры

Почему атаки через подрядчиков стали главным риском 2025 года

За последние 10 лет мы видим сотни инцидентов в стиле SolarWinds, MOVEit, Okta, Kaseya, LastPass, 3CX.

Но если посмотреть на эти события не как на хаос, а как на данные — появляется четкая закономерность.

Вот 5 паттернов атак через подрядчиков, которые повторяются снова и снова.

---

1. Чем ближе подрядчик к “внутренностям” компании — тем выше ущерб

Самые разрушительные инциденты происходят не через «хакерский софт», а через компании, которые:

• обновляют ПО, как это было с SolarWinds, MOVEit, Log4j

• обслуживают ИТ, как это было с Kaseya и многими Managed Security Providers (MSP) через Remote Monitoring and Management (RMM)

• имеют доступ техподдержки, как это было с Okta, Twilio

• делают аудит и консалтинг, например было с Deloitte

Модель простая:
доступ подрядчика → обход всей вашей защиты → тихая компрометация.

Потому что подрядчик = “доверенный внешний сотрудник без бейджа”.

---

2. Взломы MSP и RMM создают эффект домино: один взлом → сотни компаний падают

Kaseya VSA (2021), Latitude (2023), DragonForce SimpleHelp (2025): все шаги одинаковы

1. Взламывают одного MSP.

2. Он имеет доступ к своими 100–1500 клиентов.

3. Компрометация распространяется автоматически на всех!

Это мультипликатор риска, когда одна уязвимость превращает атаку в эпидемию.

---

3. Обновления ПО — новый периметр атаки

SolarWinds → 18 000+ организаций
MOVEit → 2 773 компании, 95.8 млн человек
Log4j → затронула 93% корпоративных облаков
Codecov → скомпрометированы Atlassian, P&G, Tile, Webflow

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

---

4. Человеческий фактор подрядчиков бьёт любую технологию

Взломы Twilio, Okta, Deloitte - все три случая начинались с одного: сотрудник подрядчика попался на фишинг.

Итог:

• Twilio → доступ к данным Uber, Facebook и десятков компаний

• Okta → украдены HAR-файлы (токены сессий)

• Deloitte → доступ к глобальной e-mail инфраструктуре и данным Fortune 500

• RSA → злоумышленники получили доступ к seed values - секретным ключам, которые используются в токенах SecurID для генерации одноразовых кодов  → пришлось заменить 40+ млн токенов по всему миру

Самое уязвимое звено - не ваш сотрудник, а сотрудник подрядчика, которого вы даже не знаете.

---

5. Каскадные цепочки взломов — новый тренд 2023–2025

3CX / X_TRADER (Lazarus) и LastPass стали первым задокументированным примером: 1 атака на одного подрядчика → заражение второго подрядчика → инфраструктура основной компании.

Это новый уровень угроз: не просто supply chain, а supply-chain².

---

Итоговая картина

Если собрать все кейсы (SolarWinds → MOVEit → Okta → Kaseya → LastPass → 3CX → Latitude → DragonForce), мы видим устойчивые закономерности:

✔ Злоумышленники бьют не по компаниям, а по экосистемам

Они выбирают точку, через которую можно войти сразу в сотни организаций.

✔ Наибольший риск — MSP, RMM, DevOps-процессы и цепочки обновлений

Код, доступ, ключи — всё там.

✔ Триггер большинства инцидентов — подрядчик с завышенными правами

И отсутствие контроля поведения: не было MFA, аудита, токенизации, принципа минимальных привилегий.

✔ Человеческий фактор подрядчика = самый частый вектор

Фишинг, украденные ключи, скомпрометированные личные аккаунты.

✔ Вторичные и каскадные компрометации — новая реальность 2025

LastPass → DevOps engineer home computer → master password
3CX → X_TRADER → build environment

---

Почему это важно директору или владельцу бизнеса

Почти все крупные инциденты последних 5 лет происходили не через вас.

Они происходили вокруг вас.
Через тех, кому вы доверяете.
Через тех, кого вы даже не контролируете.

Это и есть главная угроза 2025 года.

Стратегия восстановления доверия на рынке вторичной недвижимости РФ: Технологические решения и экономическое обоснование

 

Кризис российского рынка вторичной недвижимости: технологические решения для восстановления доверия

Масштаб катастрофы

Российский рынок вторичного жилья переживает беспрецедентный кризис доверия. В судах рассматривается порядка 250 000 дел по оспариванию прав на недвижимость, затрагивающих более полумиллиона человек. По делам об оспаривании сделок с недвижимостью удовлетворяется от 45 до 77% исков, что означает: каждый второй покупатель, столкнувшийся с судебным спором, рискует потерять всё.

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

Экономика кризиса: 3000 семей при средней цене квартиры 8 млн рублей — это 24 млрд рублей прямых потерь ежегодно. С учётом социальных издержек, судебных расходов и экономического ущерба от замораживания рынка общая цифра достигает 40-50 млрд рублей в год.

Реальные последствия: отток покупателей

Масштаб недоверия к вторичному жилью отражается в статистике покупательских предпочтений. По данным Домклик, доля готового жилья (вторички) в ипотечных сделках демонстрировала драматические колебания: в 2024 году она сократилась с 62,8% до 30,8%, что стало прямым следствием медийных скандалов с оспариванием сделок. Хотя в 2025 году сегмент частично восстановился до 56%, волатильность показывает хрупкость доверия к рынку.

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

Лица кризиса: реальные истории

Value Proposition Canvas: как показать ценности в ИТ-продуктах

Value Proposition Canvas: декомпозиция ценности и институциональная логика в сложных ИТ-продуктах

Как перевести абстрактные представления о пользе продукта в формализованную логику

Модель Value Proposition Canvas (VPC), разработанная А. Остервальдером, является важнейшим инструментом анализа ценности в продуктах, где функциональность сама по себе не является гарантией востребованности. Для сложных ИТ-продуктов — особенно в сфере кибербезопасности — это критически важно, поскольку покупатель не оценивает функцию, а оценивает институциональные последствия, которые эта функция обеспечивает.

VPC позволяет структурировать такие последствия и перевести абстрактные представления о «пользе продукта» в формализованную логику.

Модель состоит из двух частей: профиля клиента и карты ценности. Профиль клиента включает три элемента: Jobs (работы, которые нужно выполнить), Pains (страхи, боль, препятствия) и Gains (желаемые выгоды). Карта ценности описывает то, как продукт помогает выполнять работы, устраняет боли и создаёт выгоды.

В контексте сложных ИТ-продуктов Jobs, Pains и Gains имеют гораздо более строгую, институциональную природу, чем в классических B2C-сервисах.

1. Jobs: институциональные задачи, а не функции

В корпоративной ИТ-среде «работа» продукта почти никогда не сводится к отдельной функции. Клиент «нанимает» сложный ИТ-продукт для выполнения глубоких организационных задач:

• обеспечить соответствие требованиям ФСТЭК, ФСБ или Банка России;
• снизить вероятность инцидента и репутационных потерь;
• повысить эффективность SOC и снизить нагрузку на аналитиков;
• обеспечить наблюдаемость и управляемость трафика;
• сократить время расследования инцидентов;
• стандартизировать процессы реагирования.

Иначе говоря, работа продукта — это всегда институциональная трансформация, а не ограниченный технический эффект. Это делает VPC особенно полезным: она позволяет связать продукт с реальными задачами конкретного контекста эксплуатации.

2. Pains: структурные барьеры и системные ограничения клиента

В сфере сложных ИТ-продуктов Pains — это не «неудобства», а серьёзные препятствия, влияющие на устойчивость инфраструктуры:

• высокий уровень ложноположительных срабатываний;
• сложность настройки и эксплуатации;
• недостаточность компетенций внутренних команд;
• трудности интеграции с SIEM, SOAR, IRP, CMDB;
• длительные простои при обновлениях;
• рост TCO из-за неэффективной архитектуры;
• риски регуляторного несоответствия и санкций начальников.

Эти боли не являются субъективными — они институциональны, то есть закреплены в процессах, нормативных требованиях и последствиях инцидентов. Для сложного ИТ-продукта устранение pains часто определяет его рыночную жизнеспособность в большей степени, чем набор функций.

3. Gains: ценность как снижение рисков и рост управляемости

Gains в сложных ИТ-продуктах почти всегда носят характер организационного улучшения. Типичные Gains включают:

• снижение регуляторных рисков;
• повышение прозрачности инфраструктуры;
• сокращение нагрузки на SOC и NOC;
• уменьшение стоимости владения;
• прогнозируемость работы продукта;
• упрощение аудитов и аттестаций.

Здесь важно отметить: Gains не связаны с эмоциями или удобством, как в B2C, — они связаны с управляемостью, устойчивостью и предсказуемостью. Это делает VPC мощным инструментом для ориентации разработчиков и менеджеров на реальные эффекты.

4. VPC как инструмент для инженерных и продуктовых решений

В отличие от стратегических моделей, VPC работает на уровне конкретных функциональных решений:

• если основной Job — обеспечить соответствие 239-ФЗ → продукт должен включать механизмы защиты, обязательные для аттестации;
• если Pain — высокие затраты SOC на фильтрацию ложноположительных → продукт должен иметь высокоточную аналитику;
• если Gain — снижение TCO → архитектура должна обеспечивать экономию на эксплуатации.

Таким образом, VPC связывает задачи клиента с архитектурой, функциональностью, требованиями безопасности и экономикой продукта.

5. Ограничения модели VPC для сложных ИТ-систем

При всех преимуществах, VPC имеет ограничения:

Недостаточная чувствительность к регуляторным требованиям

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

Не учитывает архитектурные ограничения

Даже если клиент хочет автоматизацию или ML-аналитику, архитектура продукта может не позволять реализовать их без радикальной перестройки.

Слабая связь с процессным контуром

VPC не показывает, как продукт встраивается в процессы SOC, NOC, DevSecOps, что является ключевым в корпоративной ИТ-среде.

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

Литература:
Остервальдер А. Разработка ценностных предложений. Как создать товары и услуги, которые захотят купить. — М.: Альпина Паблишер, 2021. — 324 с.

🔥 Почему Gartner ошибся насчёт SOAR: разбор с цифрами и фактами

Gartner объявил SOAR технологией категории "obsolete" и закрыл Magic Quadrant. Индустрия в шоке, аналитики в замешательстве. Но если посмотреть на независимые исследования рынка — картина прямо противоположная. Разбираемся, где правда, а где методологическая ошибка.

📉 В чём Gartner прав (и где критически ошибся)

✅ Gartner прав: SOAR как "универсальное решение для всех компаний" действительно провалился. Завышенные ожидания 2020–2021 годов не оправдались — малый и средний бизнес не смог окупить затраты на интеграцию.

❌ Gartner ошибся: Закрытие Magic Quadrant не означает смерть рынка. SOAR не исчез — он встроился в SIEM и XDR-платформы (Palo Alto XSOAR, Microsoft Sentinel, Splunk) и стал зрелой категорией. Gartner путает взросление технологии с её устареванием.

Исторический прецедент: Точно такая же история произошла с DLP (Data Loss Prevention) в 2018 году. Gartner закрыл Magic Quadrant, объявив сегмент "мёртвым". Результат? Рынок DLP к 2024 году вырос до $2+ млрд и продолжает расти. SOAR идёт по тому же пути.

📊 Что говорят независимые исследования (спойлер: двузначный рост)

Пока Gartner рассуждает о "разочаровании", все ведущие market research агентства показывают устойчивый рост рынка SOAR:

Исследовательское агентство	Объём 2024	Прогноз 2030–2035	CAGR
Market Research Future	$2.75 млрд	$8.27 млрд (2035)	+10.5%
Grand View Research	$1.72 млрд	$4.11 млрд (2030)	+15.8%
KBV Research	—	$5.73 млрд (2032)	+16.1%
GII Research	$1.66 млрд	$3.78 млрд (2029)	+19%

Вывод: Восемь независимых агентств фиксируют рост от 8% до 19% ежегодно. Это не "умирающая технология" — это стабильно растущий рынок с чётким product-market fit в конкретных вертикалях.

🏦 Где SOAR действительно работает и окупается

SOAR не универсален — он выживает там, где автоматизация критична для бизнеса и ROI очевиден:

1. Banking, Financial Services & Insurance (BFSI) — 29% рынка

• Use case: Автоматизация AML (Anti-Money Laundering), KYC (Know Your Customer), фрод-детекция в реальном времени
• Пример: Банки Индии и Сингапура блокируют подозрительные транзакции за секунды через SOAR-плейбуки
• Compliance: PCI-DSS, SOX, MiFID II требуют автоматизированного audit trail — SOAR делает это из коробки
• ROI: Каждое выявленное мошенничество окупает затраты на интеграцию в разы

2. Government & Defense

• Статус: Обязательный элемент государственных SOC (Security Operations Center)
• Примеры: CERT-In (Индия), Digital India initiative, национальные CERT по всему миру
• Требования: Zero Trust Framework, MITRE ATT&CK mapping, threat intelligence sharing между агентствами
• Особенность: On-premises only — облачные решения неприемлемы для classified данных

3. Healthcare — самый быстрорастущий сегмент (+21.9% CAGR)

• Драйверы: Взрывной рост IoMT (Internet of Medical Things) атак, ransomware на больницы (>5 инцидентов ежедневно в США)
• Кейс: Южнокорейская сеть клиник использует SOAR для автоматической изоляции заражённых устройств (МРТ, инфузионные насосы) без остановки операций
• Результаты: MTTR (Mean Time To Respond) сократился на 40%, compliance HIPAA на автопилоте

4. MSSP/MDR — критичная инфраструктура

• Масштаб: Управление инцидентами для 500+ клиентов одновременно
• SLA требования: MTTR <30 минут — без SOAR физически невозможно выполнить
• Эффективность: Один SOAR-инженер покрывает 50–100 клиентов вместо 10–15 без автоматизации
• Пример: Zensar достигла времени ответа на фишинг <5 минут через codeless playbooks

🧠 Почему SOAR "разочаровал" — и как это решили

Корневая проблема SOAR всегда была одна: нестабильность интеграций.

Суть проблемы:

• API volatility: Поставщики постоянно меняют интерфейсы — каждый update = потенциальный breakdown коннектора
• Несогласованность схем данных: "src_ip" vs "source_ip" vs "SourceIpAddress" vs "actor.ip" — команда тратит 80% времени на маппинг полей вместо реагирования на инциденты
• Maintenance hell: Каждый новый источник = переписывание логики playbook'ов

Решение: OCSF (Open Cybersecurity Schema Framework)

Что это: Открытый vendor-neutral стандарт нормализации security-данных от AWS, Microsoft, CrowdStrike, Splunk и других industry лидеров.

Как работает:

• Унифицированные поля: все варианты IP-адресов → единый формат src_ip
• Сильная типизация: каждое поле имеет строгий тип данных, перечисление допустимых значений
• Версионирование: безопасная эволюция схем без breaking changes
• Common enumerations: стандартизированные значения для action, severity, protocol

Результаты внедрения OCSF (данные Observo AI, Cyware):

• MTTR: -45% (аналитики фокусируются на реагировании, а не на маппинге данных)
• Точность обнаружения: +35% (правильная разметка = правильные корреляции)
• Онбординг новых источников: недели → дни (80% источников нормализуются автоматически)
• Масштабируемость: одно правило работает для CloudTrail, Okta, GitHub одновременно

Критически важно: OCSF стал базовым слоем для AI SOC agents. Без нормализованных данных AI-агенты начинают "галлюцинировать" корреляции — OCSF решает эту проблему на уровне инфраструктуры.

💡 Вывод: SOAR не умер, он эволюционировал

Что произошло на самом деле:

1. SOAR как "универсальное решение" — действительно провалился. SMB и малый бизнес не могут окупить затраты на интеграцию.
2. SOAR как вертикальное решение — переживает ренессанс в BFSI (29% рынка), Government, Healthcare (+21.9% CAGR), MSSP/MDR.
3. SOAR как встроенный модуль — становится стандартной частью SIEM/XDR (именно поэтому Gartner закрыл MQ — технология стала базовой, а не standalone).
4. SOAR + OCSF + AI SOC — это не конец, а начало новой фазы. Рынок идёт к $8+ млрд к 2035 году с двузначным ростом.

Финальный тезис: Gartner зафиксировал правильный диагноз (завышенные ожидания снизились), но сделал неверный прогноз. SOAR не устарел — он встроился в фундамент автоматизированной киберзащиты следующего поколения.

📚 Источники

• Market Research Future — Security Orchestration Automation Response Market, 2025
• Grand View Research — SOAR Market Size Report, 2024
• KBV Research — Global SOAR Market Forecast, 2024–2032
• GII Research — SOAR Market Analysis, 2024
• KuppingerCole — Leadership Compass SOAR, 2024
• OCSF Project — GitHub Repository (ocsf/ocsf-schema)
• Observo AI — Customer Case Studies, 2024
• Gartner — Hype Cycle for ITSM, 2024

Теги: SOAR Cybersecurity Gartner SOC Automation OCSF AI Security SIEM XDR Security Orchestration

🛡️ Как будет выглядеть SOC будущего: 10 главных трендов

Почему традиционные подходы к киберзащите больше не работают и что делать дальше

Кибератаки усложняются экспоненциально. Если в 2024 году средний срок для перемещения в новый сегмент сети занимал 48 минут, то инструменты вроде Hexstrike-AI сокращают это до 10 минут. Традиционные Security Operations Center (SOC) физически не справляются с такой скоростью.

Эта статья — о том, как меняется архитектура защиты и почему старые подходы уже не работают.

⚠️ Критическая реальность 2025 года: Если ваше время обнаружения (TTD) превышает 1 час — вы уже проиграли. Атакующие действуют быстрее, умнее и масштабнее, чем когда-либо.

1. Time to Attack сжимается критически ⏱️

19% утечек происходят в течение первого часа после взлома

48 мин среднее время до lateral movement

51 сек минимальное зафиксированное время компрометации

Временные паттерны атак

Атакующие специально выбирают временные окна 05:00–06:00 утра, когда SOC не полностью укомплектован персоналом. Это не случайность — это стратегия.

Критический инсайт от Red Canary: 83% атакующих используют стандартные логины и пароли для входа — это не взлом в классическом понимании, а авторизация с легитимными учетными данными.

Что это означает для защиты

Защита больше не может полагаться на реактивный мониторинг. Если TTD (time to detect) превышает 1 час — компрометация уже произошла. Необходимы предиктивные механизмы:

Необходимые технологии:

• Поведенческий анализ (UEBA) — выявление аномалий до начала exploitation
• Мониторинг стадии reconnaissance — обнаружение разведки периметра
• Автоматическая корреляция событий — связывание подозрительных действий в цепочки
• Threat Intelligence интеграция — использование актуальных индикаторов компрометации

Реалистичная оценка зрелости автономных SOC: где мы сейчас

1. Текущее состояние индустрии (2024-2025)

Глобальный рынок (США, Европа)

Лидеры (топ-5% SOC):

• Автоматизация рутины L1: 60-70%
• AI-ассистирование L2: 80%
• Полная автономность: 10-15% сценариев
• Мультиагентные системы: в стадии pilot

Примеры:

• Google Chronicle + Gemini AI
• Microsoft Sentinel + Copilot for Security
• CrowdStrike Falcon Complete (AI-driven MDR)

Средний уровень (30-40% SOC):

• Автоматизация рутины: 30-40%
• AI-ассистирование: 40-50%
• Полная автономность: <5%

Большинство (50-60% SOC):

• Базовая автоматизация (SOAR playbooks): 20-30%
• Пилотные проекты с AI
• Полной автономности нет

Российский рынок

Лидеры (Positive Technologies, Bizon, Solar, Angara, Innostage, Информзащита):

• Автоматизация рутины: 30-40%
• AI-ассистирование: 50-60% (в основном LLM для текстов)
• Полная автономность: <5% (только типовые кейсы)
• Собственные LLM-модели: единичные проекты

Типичный коммерческий SOC/MDR:

• Автоматизация: 20-30% (SOAR)
• AI: эксперименты, не в продакшене
• Основная работа: ручная обработка аналитиками

In-house SOC (крупный бизнес):

• Широкий разброс: от 10% до 50% автоматизации
• AI внедряется точечно (FP-handling, log analysis)
• Полная автономность: не рассматривается

Малый и средний бизнес:

• Чаще аутсорсинг базового мониторинга
• AI не применяется (дорого, нет экспертизы)

2. Барьеры внедрения автономных SOC в России

Технологические барьеры

1. Дефицит GPU-мощностей:
   • Санкции ограничили доступ к NVIDIA A100/H100
   • Российские альтернативы (Baikal, Эльбрус) не подходят для AI-задач
   • Облачные GPU-сервисы дороги и ограничены
2. Отсутствие зрелых локальных LLM:
   • YandexGPT, GigaChat, Sber AI — на ранних стадиях
   • Качество ниже GPT-4/Claude для специфичных ИБ-задач
   • Проблема fine-tuning на конфиденциальных данных
3. Фрагментированность данных:
   • Разные SIEM у разных клиентов (MaxPatrol, PT SIEM, ArcSight, Splunk)
   • Нет единой модели данных (проблема взаимодействия)
   • Низкое качество логирования в legacy-системах

Кадровые барьеры

1. Дефицит ML/AI-специалистов в ИБ:
   • ML-инженеры предпочитают BigTech (Yandex, Sber) ИБ-компаниям
   • Высокая стоимость найма (300-500K руб/месяц)
   • Длительная адаптация (6-12 месяцев до продуктивности)
2. Сопротивление изменениям:
   • Аналитики боятся потерять работу
   • Руководство не понимает ROI от AI
   • Недоверие к "черному ящику" AI-решений
3. Проблема "насмотренности":
   • Если автоматизировать L1, откуда брать L2/L3 с опытом?
   • Обучение на симуляторах не заменяет реальную практику

Регуляторные барьеры

1. Отсутствие стандартов:
   • Нет требований к explainability AI в ИБ
   • Не определена ответственность за ошибки AI
   • Неясно, как аудировать AI-driven SOC (НКЦКИ, ФинЦЕРТ)
2. Требования к трансграничной передече:
   • Запрет на передачу данных КИИ/ПДн в зарубежные облака
   • Ограничивает использование GPT-4, Claude и других лидеров рынка
   • Локальные модели пока уступают по качеству
3. Консерватизм регуляторов:
   • "Если человек не принял решение, кто несет ответственность?"
   • Требование обязательного human-in-the-loop для критичных систем

3. Прогноз развития

Краткосрочная перспектива (2025-2026)

Что точно произойдет:

• Массовое внедрение LLM-ассистентов (для анализа логов, улучшения текстов)
• Автоматизация снижения FP достигнет 40-50% в передовых SOC
• Появление первых коммерческих AI-driven MDR-сервисов в России

Что вряд ли произойдет:

• Полная автономность для сложных инцидентов
• Замена аналитиков L1 на AI (трансформация ролей, но не увольнения)
• Единые стандарты и регуляторика для AI в SOC

Драйверы роста:

• Кадровый голод (дефицит аналитиков → вынужденная автоматизация)
• Рост объемов данных (без AI не справиться)
• Снижение стоимости AI-инфраструктуры (более доступные GPU, облегченные модели)

Среднесрочная перспектива (2027-2030)

Базовый сценарий (70% вероятность):

• Автоматизация L1-рутины: 60-70%
• Мультиагентные системы для типовых инцидентов
• AI-ассистирование становится стандартом для L2/L3
• Появление новых ролей: AI Operator, AI Security Engineer

Прорывной сценарий (20% вероятность):

• Появление прорывных локальных LLM (сравнимых с GPT-4)
• Массовая доступность GPU-инфраструктуры
• Регуляторная поддержка (стандарты, льготы для AI-внедрения)
• Результат: автономность 80-90% для типовых сценариев

Пессимистичный сценарий (10% вероятность):

• Крупные инциденты из-за ошибок AI (потеря доверия)
• Жесткое регулирование (запрет автономных решений для критичных систем)
• Технологическое отставание России (санкции на AI-технологии)
• Результат: застой на уровне 30-40% автоматизации

Долгосрочная перспектива (2030-2035)

Консенсус-прогноз:

• Полностью автономный SOC (без людей) не появится — останется утопией
• Высокоавтоматизированный SOC станет нормой: 70-80% операций без человека
• Роль человека трансформируется:
  • От "оператора" к "дирижеру оркестра AI-агентов"
  • От "исполнителя" к "стратегу и креативному решателю задач"
  • От "триажера алертов" к "исследователю и архитектору"

Аналогия с другими индустриями:

• Автопилот в самолетах: 95% полета автоматизировано, но пилоты не исчезли
• Роботизированные склады Amazon: логистика автоматизирована, но супервизоры нужны
• Автономные автомобили: 10+ лет разработки, но полная автономность (level 5) так и не достигнута

Вывод: Будущее за гибридной моделью — симбиозом AI и человеческой экспертизы.