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 года.