InfoSec Context

🚗 Сбор данных современными автомобилями
Глава комитета Госдумы по цифровому развитию и искусственному интеллекту Александр Сидякин предложил распространить принципы «закона Яровой» на иностранные автомобили. Инициатива предполагает проверку того, какую информацию современные машины отправляют производителям и сторонним сервисам🔎: от точных координат, записей с микрофонов и видео с видеорегистраторов до детальной телематики электронных систем. И хотя поводом стали риски при использовании таких машин госслужащими, технически эта проблема касается каждого владельца подключенного автомобиля.

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

🌍 Мировой опыт
Тема безопасности автомобилей уже давно вышла на уровень национальной безопасности и защиты приватности во всех ведущих юрисдикциях:
⏺ Европейский Союз применяет GDPR и EU Data Act, которые регулируют сбор данных строго регламентирован. Передача автомобильной телеметрии за пределы ЕС без жестких гарантий и согласия пользователя запрещена. Согласно требований UNECE WP.29 (CSMS) автопроизводители обязаны внедрять официальные системы управления кибербезопасностью транспортных средств, проходить аудит и защищать цепочки обновлений "по воздуху".
⏺ Соединенные Штаты Министерство торговли США (BIS) и профильный закон Connected Vehicle Security Act вводят ограничения на использование зарубежного ПО и аппаратного обеспечения в подключенных авто.
⏺ Китай Стандарты Министерства промышленности и информатизации требуют, чтобы все данные, собираемые автомобилями на территории страны, хранились исключительно на локальных серверах без права беспрепятственного трансграничного экспорта.

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

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

Какие практические выводы из этого можно сделать? Мы вряд ли сможем управлять разрешениями, которые имеет наш автомобиль, ну по крайней мере до выпуска для них кастомных прошивок, но для себя нужно:
⏺ Учитывать, что связка «смартфон + приложение производителя авто» часто сливает рекламным трекерам VIN-номер, e-mail, телефон и точные координаты перемещений. Предлагаю минимизировать доступы и разрешения у приложений в вашей ОС.
⏺ Загляните в дебри меню бортового компьютера. Отключите опции «улучшения качества сервиса», маркетинговой телеметрии и передачи аналитических отчетов производителю, если они есть и включены по умолчанию.

💬 Относитесь к современному автомобилю как к смартфону на колесах. Помните, что каждый сервис мультимедиа или подключенный по Bluetooth гаджет расширяет вашу цифровую поверхность атаки.

📖 InfoSec Context
| TG | Max | Web

🍕 Промежуточный итог взлома «Додо Пицца»
Продолжаем следить за историей с нашумевшим взломом «Додо» и выгрузкой 68 млн. записей клиентов. Она получила любопытное и точно необычное развитие 👨‍💻.

В Барнауле задержан предполагаемый участник группировки — Д. А. Фридман. Тверской суд Москвы отправил его под домашний арест. Мера действует до 8 декабря. Статья: 272.1 УК РФ, ч. 3 (пп. «а» и «в»), то есть незаконный оборот компьютерной информации с персональными данными.

По версии следствия, он получил доступ к данным клиентов и за вознаграждение передал их другим лицам для публикации в Telegram-канале. Название канала и сумму не раскрывают.
Отдельно «Коммерсантъ» пишет, что полный архив продали в даркнете, а деньги пришли на общий криптокошелёк группы. После задержаний пароль от него сменили.

По данным СМИ, группа состояла из четырёх человек (граждане России, Казахстана и Беларуси). Троих задержали, один пока на свободе. Вышли на них благодаря IP-адресу, который Фридман не скрыл при обращении к похищенному массиву данных 🤪.

Также, по версии следствия, отправной точкой стали корпоративные учётные данные «Додо», оставленные в открытом доступе на GitHub. Это оказался не хитрый сложный взлом, а банальная утечка секретов в репозитории.

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

Что в итоге?
Я бы выделил две глупости 😁 с обеих сторон:
1️⃣ Утечка секретов в публичные репозитории остаётся одним из самых частых и самых дешёвых для атакующего векторов. Поверка секретов в CI, ротация ключей и принцип минимальных привилегий на сервисных учётках должны быть гигиеной, а не «хорошей практикой на потом».
2️⃣ Можно отлично спланировать и месяцами готовить атаку, а попасться на одном подключении без анонимизации. Оперативная безопасность ломается не на самом сложном этапе, а на самом рутинном.

💬 Хорошо, что хакер забыл про VPN kill switch. Именно такие «мелочи» чаще всего и решают исход расследований. Но домашний арест — это мера пресечения, а не приговор. Все версии пока остаются версиями следствия.

📖 InfoSec Context
| TG | Max | Web

👮‍♂️ Арест переговорщика с хакерами
Все государства понимают, что вести переговоры с вымогателями нельзя, но всегда есть люди, которые готовы помочь в ведении таких переговоров.

В США арестован Эдвард Дубровски — канадский ИБ-специалист, экс-управляющий директор компании CYPFER и автор книги «Cyber Extortion Strategic Response». Человек годами профессионально занимался тем, что помогал компаниям вести переговоры с вымогателями и организовывал выплату выкупов 💰. Теперь ему самому инкриминируют сговор с целью вымогательства в рамках масштабного расследования против группировки ShinyHunters.

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

Покупка криптовалюты для откупа от киберпреступников — это тупиковый путь, который несет в себе массу проблем:
⏺ Вы спонсируете международную киберпреступность, рискуя угодить под уголовное преследование за финансирование ОПГ.
⏺ Вы покупаете кота в мешке: нет никаких гарантий, что злоумышленники ударят по рукам, вернут данные или не сольют их, преумножив свой капитал.
⏺ Те, кто помогает оформлять эти сделки, могут быть в сговоре с вымогателями.

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

💬 Кажется, что встречать шифровальщиков подготовленными всегда дешевле, чем потом надеяться на чудо-переговорщиков и переводить миллионы в крипту.

📖 InfoSec Context
| TG | Max | Web

Bug Bounty умирает?
Два удара, которые могут поставить крест на охоте за багами, и это не обычные новости, а уже тенденция.

Мы привыкли воспринимать bug bounty как отличный открытый способ компаниям заявить о зрелости своего продукта, а исследователям получить пищу для творчества и деньги, все в выигрыше. Но сейчас эта модель взаимоотношений трещит по швам.

Удар первый: экономика не сходится.
Google отчитался о рекордных выплатах за 2025 год: $17,1 млн более чем 700 исследователям, рост на 40% год к году 😱. Казалось бы, вот оно, процветание. Но Google одновременно снизил стандартные награды за уязвимости в Chrome. Причина в том, что ИИ-инструменты сделали производство «подробных, но бесполезных» отчётов дешёвым и массовым. Компания теперь платит не за объём, а за реальную эксплуатируемость и глубокий анализ.

Параллельно Internet Bug Bounty (IBB) — программа, покрывавшая критический open-source софт, — приостановила приём отчётов. Curl убил свою bounty-программу на HackerOne ещё в январе 2026-го, так как доля валидных отчётов рухнула с ~15% до менее 5% 😤. Intel приостановил свою программу с максимальной наградой $100k. Apple ввёл лимиты на количество отчётов и 30-дневный cooldown — и реальные zero-day теперь стоят в очереди за AI-мусором.

Удар второй: ИИ наводнил отчётами, проверять их уже не успевают.
Вот некоторые сводки этого вала:
🔹 В Linux kernel количество CVE за версию выросло с ~500 (6.x) до почти 2000. Мейнтейнеры говорят прямо: «мы захлебнулись».
🔹 Google OSS VRP приостановлен минимум до Q1 2027. Причина — «значительный рост автоматизированных отправок, подавляющее большинство которых невалидны».
🔹 В Glasswing (CSA) за первый месяц ИИ-сканирования найдено 10 000+ высоких и критических уязвимостей, из которых 97 реально запатчены (около 6%).

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

Bug bounty как «демократичный способ подзаработать на поиске багов» переживает самый большой кризис. Выживут, скорее всего, только:
1️⃣ Крупные корпоративные программы с выделенным триажем (Google может себе позволить фильтровать, малый проект — нет).
2️⃣ Приватные приглашения и live-хакинг-события типа bugSWAT, где Google платит $1,6 млн за 130 отчётов на четырёхдневном ивенте.
3️⃣ Задачи с репутационным весом, где исследователь дорожит аккаунтом.

Для open-source это уже вызвало кризис, и если мейнтейнеры не могут позволить себе триаж, они скорее просто закроют программы. При этом уязвимости не исчезают — они уйдут к атакующим.

💬 Думаю, мы наблюдаем не смерть bug bounty, а некий отбор. Эпоха «отправил сканер — получил деньги» закончилась. Останутся те, кто умеет доказывать эксплуатируемость и решать проблемы, которые ИИ пока не щёлкает как орешки.

📖 InfoSec Context
| TG | Max | Web

🍕 На очереди «Додо Пицца»
Помните, мы следим за инцидентом с туроператором Tez Tour? Теперь та же самая группировка DataSuckers 👽 заявила об атаке на известную пиццерию.

По информации от злоумышленников, подготовка к атаке началась 26 сентября, а уже на следующий день они получили полный контроль над базами данных компании и выкачали несколько терабайт данных 🚰: 68 млн. записей уникальных клиентов и весь массив заказов за все 15 лет существования сети — вплоть до истории покупок и деталей о составе заказов 😳.

Служба безопасности «Додо» подтвердила факт кибератаки. Представители компании сообщили, что доступ злоумышленников к системе оперативно заблокирован, однако предупредили: в руках атакующих могла оказаться информация клиентов (имена, адреса, email, телефоны, даты рождения и история заказов).

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

🤔 Что в итоге?
Классическое начало громкого слива: хакеры заявляют о тотальной компрометации «всего и вся», а бизнес говорит о локализации и частичной утечке. Однако даже если правда где-то посередине, масштабы впечатляют❗️. Связка «телефон + ФИО + история реальных заказов с адресами» — это идеальный инструмент для киберпреступников, которые моментально поставят эти данные на поток для многоуровневых фишинговых атак и персонализированной социальной инженерии.

Тут, конечно, не затронуты «продающие» каналы компании, но репутационный ущерб налицо.

💬 Если вы активно пользовались этой доставкой, настоятельно рекомендую в ближайшие недели относиться с удвоенным скепсисом к любым звонкам и сообщениям от неизвестных. А я теперь и за этим громким инцидентом послежу 🍿.

📖InfoSec Context
| TG | Max | Web

🚧 Две недели в офлайне
В продолжение прошлого поста подведём промежуточные итоги и обсудим, почему расследование ИБ-инцидента — это не про «переустановить винду» 🌅.

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

Обычно в такие моменты у руководства и бизнеса возникает логичный и очень эмоциональный запрос к ИТ и ИБ: «Почему так долго? Накатите бэкап и включайте обратно!»

Но в реальности всё работает совершенно иначе. Полная проверка, локализация и очистка инфраструктуры после серьёзного инцидента — это физически небыстрый процесс, и вот почему:
🔺 Если просто развернуть вчерашний бэкап, злоумышленники или их автоскрипты вернутся в систему через пару минут. Закрепление в инфраструктуре могло произойти недели или даже месяцы назад, а значит, и сами бэкапы уже могут содержать закладки 🚰.
🔺 Нужно собрать и проанализировать огромные массивы логов (если они вообще велись и сохранились), проверить точки входа, учётные записи, цепочки горизонтального перемещения.
🔺 Безопасное восстановление сервиса потребует пересборки окружения, ротации всех ключей, сертификатов, паролей и токенов, а также закрытия конкретных уязвимостей, через которые пролезли атакующие.

Если инфраструктура сложная, а видимости и нормального логирования до инцидента не было — расследование превращается в археологические раскопки. И ускорить их без риска повторного взлома невозможно. А если для проведения расследования потребуется изъятие физического оборудования, то ситуация существенно усложняется.

Пока главный вывод, как всегда, в том, что к такому инциденту нужно готовиться заранее, в мирное время.
🔹 Готовьте планы восстановления. Бизнес должен заранее понимать, каков допустимый уровень простоя (RTO/RPO) и как поддерживать продажи, пока основной сайт «лежит».
🔹 Периодически тестируйте восстановления и проводите учения с бизнесом.

Если у вас нет настроенных средств защиты (SIEM/NTA/EDR) и централизованного сбора / анализа логов, то период простоя кратно увеличивается, и это нужно учитывать.

💬 В современном мире ИИ и вабкодинга инциденты будут происходить постоянно. Вопрос давно не в «взломают ли?», а «когда?» и «как?» взломают.

📖 InfoSec Context
| TG | Max | Web

📱 Внутри суперприложений
Сегодня стандартом современной мобильной разработки является экосистемный подход. Мессенджеры и экосистемные платформы давно перестали быть просто чатами — это полноценные «суперприложения» (super-apps), внутри которых живут сотни мини-приложений (mini-apps): от заказа еды и такси до банковских сервисов и игр 🎮.

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

🏗 Для обычного приложения/суперприложения из Google Play или App Store ОС смартфона изолирует его в «песочнице». Приложения физически не могут просто так залезть в оперативную память, локальное хранилище или сетевой трафик друг друга 🔒.

Но с мини-приложениями всё устроено совершенно иначе. Большинство мини-аппов запускаются не как самостоятельный нативный код, а внутри WebView — встроенного браузерного компонента основного приложения (хозяина платформы).

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

Из этой архитектурной модели и вытекают возможности хоста (владельца платформы):
1️⃣Платформа имеет полный доступ к выполнению кода внутри мини-приложения, может менять логику интерфейса или отслеживать события ввода.
2️⃣ Полный доступ к локальному хранилищу (токены авторизации, ключи API, кэш и пользовательские данные).
3️⃣ Весь трафик мини-аппа идет через сетевой стек хоста.
4️⃣ Хост способен обращаться к системным функциям ОС и делать снимки экрана или элементов интерфейса в момент ввода данных.

Недавно вышло практическое исследование на примере платформы MAX, в рамках которого исследователи проверили мини-приложения из самых разных сфер — от финансов и связи до госуслуг и медицины.

Они обнаружили ровно то, о чем я писал выше, а именно возможность:
🔹 Захвата интерфейса ввода.
🔷 Чтения данных в хранилище.
🔷 Маршрутизации трафика.

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

❗️Но они отметили, что это не специальный бэкдор, а возможности любой платформы, которыми может пользоваться хост. Точно такие же возможности технически заложены в любое суперприложение мира, будь то Telegram, WeChat и др. А вот будут ли владельцы этим пользоваться в очередном обновлении? 🤔

💬 Итого: владелец платформы — это абсолютный владелец среды выполнения. Если вы доверяете хозяину приложения, вы автоматически доверяете ему всё, что происходит и вводится внутри каждого встроенного мини-аппа.

📖 InfoSec Context
| TG | Max | Web

✈️ Начинаем разбирать инцидент с Tez Tour
Вчера, 15 сентября, появилась новость: один из крупнейших игроков туристического рынка, Tez Tour, подвергся кибератаке 🧐.

Группировка DataSuckers заявила о компрометации инфраструктуры, дефейсе главной страницы и сливе/удалении 🚰 множества данных — от бронирований до персональных данных клиентов (хакеры заявляли о цифрах вплоть до 400 млн. строк). Сама компания масштаб отрицает и заверяет, что критичных утечек нет, но так делают все 😉

Очередной классический инцидент, который заставляет вспомнить грабли веб-безопасности. Давайте кратко попробуем разобрать то, что сейчас известно.

Для подобного бизнеса веб-сайт и клиентский портал — это не просто «визитка в интернете». Он один из важнейших источников привлечения клиентов и получения данных о них:
1️⃣ Через портал идут бронирования и оплаты.
2️⃣ Точка входа для паспортных данных туристов, телефонов, email-адресов, истории поездок и токены авторизации.
3️⃣ Архитектура портала может быть разной, но она все равно выводит в сложную сеть интеграций, и достаточно одной уязвимости в устаревшем плагине или слабой учетки админа, чтобы злоумышленники провалились внутрь инфраструктуры.

На данный момент хакеры заявили о захвате серверов, зачистке дисков и уничтожении колоссального массива информации (сотни миллионов записей о бронях, логистике и клиентах). На сайте красовалась «заглушка» о том, что компания прекратила существование. И они очень красочно описывают сам kill chain.

Tez Tour заявляют, что атака действительно затронула сайт, но критических признаков утечки персональных данных клиентов и партнеров нет, а ситуация находится под контролем 🧐.

Истина, возможно, где-то посередине. Но точно видно, что злоумышленники смогли вывесить дефейс сайта и он не работает уже больше суток. Обычно, если затронута только морда портала, то его возврат занимает очень мало времени. Сейчас Tez tour заявляет о необходимости дополнительных проверок, поэтому восстановление затягивается.

Какие начальные выводы можно сделать:
🔹 Первичный вход заявляется через сервис загрузки файлов, который позволил загрузить файл с php-кодом. Такая ошибка относится к трем самым популярным веб уязвимостям в OWASP TOP 10, и удивительно, что ее не нашли ранее при проверке сайта 😡.
🔹 Не выполнена должная изоляция сегментов. Веб-сервер, смотрящий в публичную сеть, не должен сам иметь доверенного доступа во внутреннюю сеть компании и к базам данных.
🔹 Резервное копирование с защитой от удаления. То, что хакеры заявляют об уничтожении бэкапов или баз данных — стандартная практика вымогателей. Изолированные, неизменяемые бэкапы — наш щит в подобных ситуациях.

💬 Я продолжу следить за развитием ситуации с Tez Tour и посмотрим, какие выводы можно будет сделать по завершении этого кейса. Будем учится на чужих граблях 😉

📖 InfoSec Context
| TG | Max | Web

🧠 Доверяй, но проверяй!
Периодически в своей деятельности использую различные ИИ-инструменты для получения выжимки информации в виде компиляции из источников или для написания кода. В обоих случаях ИИ уже не доверяю, и этому есть веская причина.

Вчера в очередной раз вспоминал нормативку по ИБ 📖, а конкретно — случаи обязательного применения сертифицированных СЗИ 🔐 для защиты ИСПДн в коммерции. Не подтвердил однозначно свои выводы и решил позвать на помощь ИИ. И тут началось самое интересное.

На все мои запросы ИИ давал однозначный ответ в необходимости применения сертифицированных СЗИ и приводил цитаты из 21 приказа ФСТЭК. Причем в самом приказе такого текста просто не было.

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

Сразу вспомнился случай, когда у криптана украли более $2,2 млн через фишинговый сайт, который ChatGPT выдавал в качестве ответа на вопрос, где обменять $FLR.

Или уж совсем удивительный случай безалаберности юристов — Верховный суд РФ признал неуважением к правосудию бездумное использование документов, сгенерированных нейросетью. Юристы должны нести ответственность за ложь и ошибки ИИ.

Поэтому давайте не будем забывать, что ИИ — это не панацея и замена работнику, а только инструмент. В работе ИБ такие ошибки теперь будут встречаться все чаще и чаще, например:
⏺ Фантомные зависимости. Нейросеть может порекомендовать для вашего проекта несуществующую библиотеку. Злоумышленники мониторят популярные паттерны запросов к LLM и заблаговременно регистрируют такие пакеты в публичных репозиториях с внедренным вредоносным полезным нагрузками.
⏺ Иллюзия безопасности в коде. Скрипты автоматизации, правила для фаерволов и др., написанные ИИ, часто содержат скрытые дефекты — жестко зашитые секреты, устаревшие криптографические алгоритмы или избыточные привилегии, которые модель подает как хороший вариант.
⏺ Вымышленные эксплойты и CVE. При реверс-инжиниринге или поиске векторов атак модель способна сгенерировать красивый, но полностью фальшивый номер CVE или описать несуществующую уязвимость функции, уводя вас по ложному следу во время инцидента.
⏺ Галлюцинации при разборе логов. Загружая дампы трафика, дампы памяти или выгрузки из SIEM-систем на анализ в LLM, легко столкнуться с тем, что модель пропускает критическую аномалию или, напротив, принимает легитимный системный сбой за целенаправленную атаку.

При этом для некоторых задач ее галлюцинации нам и не важны. Например, при генерации картинок (как в этом посте) и видео там постоянно попадаются то пятая нога у животного, то что-то выдуманное. Но для непрофессионального использования «сойдет».

Нейросети всегда идут по пути наименьшего сопротивления, если им не указать что-то конкретное в промте. Поэтому доверять им что-то ответственное без перепроверки — это лотерея, где на кону стоит ваша безопасность и репутация. LLM оптимизированы под правдоподобность текста, а не под фактическую истину. Они не «знают» матчасть, а прогнозируют статистически вероятные цепочки токенов, из-за чего формулируют опасные ошибки с абсолютной, железобетонной уверенностью.

💬 ИИ — это эффективный ко-пилот, ускоряющий рутину, но финальная ответственность остается на человеке. Готовьте ИИ правильно!

📖 InfoSec Context
| TG | Max | Web

👮‍♂️ Как вам приручить MITRE ATT&CK
Фреймворк MITRE ATT&CK давно стал стандартом де-факто в мире кибербезопасности, но многие компании до сих пор воспринимают его как сложную «таблицу с кучей квадратиков». На деле это единый словарь и карта, описывающая поведение реальных злоумышленников. Чтобы понять её суть, предлагаю попробовать кратко в ней разобраться на живых примерах.

Фреймворк MITRE ATT&CK делится на три ключевых понятия:
🔹 Верхний уровень — Тактика (Tactic) — зачем злоумышленник это делает (цель). Например: Initial Access (Получение доступа) или Execution (Выполнение кода).
🔹 Подуровень — Техника (Technique) — как он это делает (метод). Например: Phishing (T1566) или Command and Scripting Interpreter: PowerShell (T1059.001).
🔹 Процедура (Procedure) — конкретная реализация в инфраструктуре. Например: хакеры прислали бухгалтеру письмо с вредоносным файлом .iso на корпоративную почту.

Как внедрить применение матрицы у себя:
1️⃣ Инвентаризация и маппинг.
Сопоставьте текущие правила детектирования в вашем SIEM, EDR и сетевых экранах с матрицей ATT&CK. Определите, какие именно техники вы реально отслеживаете, а где у вас «слепые зоны». Для визуализации и разметки покрытия удобно использовать инструмент ATT&CK Navigator.
Пример: Вы видите, что у вас настроен детект на запуск PowerShell с подозрительными ключами (техника T1059.001). Значит, этот элемент в матрице ATT&CK у вас «закрыт». А вот техники обхода сетевых экранов могут быть слепой зоной. Для наглядности такой разметки удобно использовать инструмент ATT&CK Navigator.

2️⃣ Фокус на релевантных угрозах
Не пытайтесь закрыть все 600+ техник сразу — это тупик и вам не хватит ресурсов. Изучите отчеты Threat Intelligence по вашей отрасли (финансы, ритейл, промышленность).
Пример: Если на ваш сектор чаще всего нападают через фишинг с вредоносными вложениями и компрометацию учетных записей VPN, сфокусируйтесь в первую очередь на техниках T1566 (Phishing) и T1078 (Valid Accounts).

3️⃣ Постоянное улучшение
Превратите матрицу в рабочий чек-лист ИБ-отдела. По итогам каждого аудита или инцидента пишите новые правила корреляции, закрывающие конкретные пробелы.

4️⃣ Проверяйте
Если у вас есть ресурсы, то организуйте совместные тренировки атакующих и защищающихся.
Пример: Пускай условный атакующий 🧐имитирует технику Lateral Movement через протокол RDP (T1021.001), заходя с рабочей станции рядового сотрудника на сервер. Задача — зафиксировать это средствами ИБ 😎 и проверить, сработало ли оно и выдало ли нужное событие.

Сама матрица все время прирастает новыми процедурами и техниками и действительно сложно читается. Поэтому для лучшего ее понимания можно применить документ Best Practices от CISA. Также PT ведут у себя русскоязычный ее вариант, да с упором на свои СЗИ, но все же ее может быть удобнее использовать.

💬 Внедрение у себя MITRE ATT&CK переводит безопасность из абстрактного «мы ставим антивирус» в измеримый процесс управления рисками. Начните с малого: возьмите один типичный сценарий атаки на вашу компанию и разберите его по косточкам с помощью этой матрицы.

📖 InfoSec Context
| TG | Max | Web