На эфире по автономным SOCам прозвучал тезис, что Россия 🇷🇺 на 2-3 года (оптимистично) опаздывает в части внедрения соответствующих технологий по сравнению с Западом. Подтверждаю эту мысль - больше года назад я делал обзор того, что можно было бы назвать NG SIEM и автономными SOCами. Для нашего R&D. Думаю выложить этот обзор, – он достаточно подробно раскрывает то, что сейчас делается по ту сторону океана и в Израиле в этой сфере. Да и отдельные, позитивные, наши вендора тоже движутся в этом направлении ☺️

#soc #siem

Читать полностью…

Потихонечку история с атакой на Jaguar Land Rover переходит от умозрительных к более осязаемым потерям. Согласно отчету независимого центра Cyber Monitoring Centre, атака на JLR повлияла на более чем 5000 организаций и обошлась британской экономике примерно в £1.9 миллиарда (или 2,25 миллиарда долларов) 🤑 В сентябре 2025 года производство автомобилей в Великобритании упало примерно на 27% по сравнению с тем же месяцем годом ранее. Широкая остановка производства JLR, крупнейшего британского автопроизводителя, стала ключевым фактором этого падения 📉

Ущерб носит не только прямой характер (потеря производства), но и каскадный: сбои в цепочке поставок 🏎, задержки комплектующих, финансовая нагрузка на малых и средних подрядчиков. Производство было приостановлено на несколько недель, и поставщики уже начали сокращать часы работы и даже увольнять сотрудников 🤸 JLR объявляла о том, что пока не обнаружила доказательств утечки клиентских данных, но приостановка производства и ее последствия идут дальше.

Основной удар приходится не только на JLR как компанию, но на всю цепочку поставок, что усиливает мультипликативный эффект 🐇 Даже если JLR "выдержит" благодаря большим ресурсам, мелкие фирмы-поставщики несут основной риск: кассовый разрыв, временные увольнения, потеря контракта. Отчет CMC подчеркивает: многие убытки – это упущенная выручка / остановка производства, а не только расходы по восстановлению или штрафы (в этой части много неясного до сих пор) 👨‍🦽 Сценарии "длительного восстановления" сильно увеличивают ущерб: чем дольше простои, тем выше риск: £1.9 млрд – ориентир, но диапазон ущерба может быть выше при отсроченном запуске остановленных заводов. Отдельный аналитический материал оценивал, что JLR может потерять > £3.5 млрд выручки, если простои продлятся до ноября (осталось недолго ждать), и что ежедневный убыток может составлять ~£72 млн 💷

#ущерб

Читать полностью…

Биометрия безопасная говорили они))

p.s. от подписчицы)
#meme

😎 BESSEC | 🤕Кибер КИТ

Читать полностью…

Вчера модерировал эфир AM Live про автономные SOCи. Как и всегда рекомендую посмотреть запись эфира 📺 (выложена на Youtube, VK Video, Rutube), а я наброшу несколько тезисов, которые мне запомнились по ходу дискуссии (конкретные сценарии применения LLM в разных SOCах тоже озвучивали, но это вы увидите в записи): 🤖
1️⃣ В полностью автономный SOC (без участия человека) не верит ни один эксперт! Как минимум, процесс принятия решения и процесс реагирования реализуется с участием человека; а также threat hunting и форензика.
2️⃣ На стороне MSSP/MDR автономный SOC будет строиться на базе комбайна технологий и решений, в то время как в in-house SOC эффективнее это делать на базе интегрированной data-driven платформы (озеро данных + слой аналитики + модули). И да, привязка к конкретному вендору (vendor lock-in) неизбежна.
3️⃣ Количество людей в автономном SOC не снизится, так как нужны инженеры данных, инженеры по ML, AI Red Team для проверки качества работы автономного SOC. А L1 просто поднимется на уровень выше – текущие роли будут перераспределены.
4️⃣ Автономный SOC стоит недешево и поэтому это пока удел либо очень крупных заказчиков, либо MSSP/MDR, который могут инвестировать в технологии в расчете на будущее.
5️⃣ Передача ПДн в аутсорсинговый SOC – это боль и регулируется фигово, а российские LLM-провайдеры не очень пекутся о конфиденциальности передаваемых в них данных (с юридической точки зрения).
6️⃣ Отвечает за ошибки автономного SOC должен всегда человек, как правило, руководитель SOC. Тут никакой дилеммы, как у производителей беспилотных авто, у коллег не было.
7️⃣ В обмен датасетами для обучения ML между SOCами никто не верит и не хочет этого, что в целом понятно, конкуренция-с... А вообще датасеты и качество данных – это краеугольный камень качества автономного SOC. И была подсвечена очень интересная тема – обновление моделей в ПО, поставленном вендорами своим заказчикам. Все это обман и профанация, так как все такие решения все равно ходят в вендорское облако (в этом случае обновление – не проблема). А вот когда модели будут поставляться с ПО, вот тогда обновление станет проблемой – ведь если заказчик дообучивает модель на своей инфраструктуре и данных, обновление от вендора может удалить все результаты внутреннего обучения. И как быть?
8️⃣ Переход к полностью автономным SOCам коллеги ожидают не ранее 2030 года, а то и позже.
9️⃣ Без знания ИИ сегодня никуда – и дело не в том, что он заменит человека, а в том, что без него сегодня нельзя заниматься ИБ и это точно не отдельные специалисты должны быть, а собственные знания 🤔

#soc #ии

Читать полностью…

Выступал вчера на Евразийском конгресе по защите данных (EDPC) и в секции по кибербезу прозвучала мысль, что нет методик подсчета репутационных рисков от утечек 🤔 На самом деле есть глобальное исследование Ponemon Institute, которое показывает, что репутационные издержки (например, уход клиентов и потеря лояльности, работа с негативом в СМИ и соцсетях) составляют около 40% от общей суммы потерь 🤑

При этом важно помнить, что репутационные эффекты часто отложены во времени: сразу после инцидента может быть шок-эффект, потом – уход клиентов/партнеров, снижение числа новых сделок 📉 Нужно мониторить не только момент первичной реакции на инцидент, но и средне-долгосрочный эффект. И даже учитывая "усталость" аудитории новостями об утечках – компаниям все равно нельзя расслабляться: именно "тяжелые" инциденты (с утратой финансовых данных, платежных карт, медицинских данных, массовых утечек) чаще всего приводят к сильному ущербу. Реакция рынка, общества, клиентов, СМИ и т.п. будет сильно зависеть от контекста: насколько инцидент серьезен, как компания реагирует, как с ней взаимодействуют СМИ и клиенты и т.п. 📰

И, если обратить внимание, считать репутационные потери не так уж и сложно, – уход клиентов, 📉 снижение числа сделок с оставшимися, рост числа публикаций со знаком минус, падение курса акций, – просто это не привычные метрики, которые мы можем взять из SIEM, VM или EDR. И да, ИБшники или DPO такое обычно не делают; поэтому и кажется сложным. Но если выводить ИБ на уровень бизнеса, то, заручившись поддержкой коммерческого депратамента и PR-службы, все это можно считать 🧮

#ущерб

Читать полностью…

Все хорошо в стремлении государства бороться с утечками 🛡, только одно смущает, – смотрит оно на эту проблему слишком прямолинейно и не учитывает психологию общества субъектов ПДн. Например, есть такое понятие как синжром усталости от утечек (data breach fatigue), то есть состояние, когда у потребителей, пользователей или даже организаций снижается реакция на сообщения об инцидентах с данными 😴

Причины следующие: ✍️
➡️ Большое число утечек и фрагментарных инцидентов → "ну что, опять утечка?", "меня все равно это не коснется".
➡️ Чувство бессилия: "если даже крупные компании подвергаются, что мне-то поможет".
➡️ Перегрузка уведомлениями: уведомления об утечках, правила безопасности, смены паролей и т.п. → снижение отклика, игнор.
➡️ Адаптация: люди привыкают к тому, что "утечка данных = норма", и теряют восприятие инцидента как чего-то экстраординарного.

Для организаций этот феномен опасен тем, что даже если инцидент случается – он может не вызвать нужной реакции пользователей, перестать восприниматься как тревожный сигнал, что снижает стимулы как для улучшения защиты, так и для быстрого реагирования 😴

И есть немало исследований, которые подтверждают этот факт, например: 😑
➡️ По данным Vercara в 2024 году лишь 58% потребителей указали, что утечка данных повлияла на их доверие к бренду, тогда как в 2023 году было 62%
➡️ Согласно исследованию TIG Advisors 155.8 миллиона американцев столкнулось с утечками их ПДн, что должно было привести к десенсибилизации (снижению чувствительности) пользователей к новостям об утечках.
➡️ Организация StaySafeOnline заявляет, что пользователи при описании "data breach fatigue" указывают следующие симптомы: десенсибилизация ("О да, опять утечка"), апатия ("Что я могу сделать?"), бездействие ("Опять пароли менять? Нет сил") 😑

Что делать с этой усталостью? Варианты есть и их можно было бы назвать термином "умное защита от утечек":🤓
➡️ Мониторьте не только количество уведомлений об инцидентах, но и качество реакции на них пользователей и клиентов – как сильно они реагируют, меняют ли поведение.
➡️ Разработайте стратегию коммуникации: уведомления должны быть понятными, конкретными, с четкими действиями, минимальной "технической болтовней". Исследование по уведомлениям показывают, что многие уведомления, которые пишутся DPO или ИБшниками, длинные, сложные и пользователи не понимают, что делать (или не дочитывают).
➡️ Уделяйте внимание "умной" безопасности: не просто больше уведомлений, а выборочно, с акцентом на значимые события, и с фокусом на обучение и повышение вовлеченности. Это поможет противодействовать усталости.
➡️ Включите метрики по усталости: например, доля пользователей, которые не отреагировали на уведомление, доля, которая перешла к другому провайдеру после инцидента, изменение лояльности и доверия.
➡️ Внутри организации: обращайте внимание на сотрудников – частые требования по ИБ, обновления безопасной политики, рост фрустрации могут привести к снижению соблюдения или даже саботажу (неумышленно). Требуется баланс между безопасностью и "человеческим фактором" ⚖️

А что делать государству? А хрен знает – его действия в последнее время не всегда подчиняются логике и здравому смыслу; а уж активность РКН тем более 🤔

#утечка #персональныеданные #психология

Читать полностью…

Ольгу Бузову взломали, о чем она в шоковом состоянии сообщила в Telegram. Потерян доступ к страницам с 24 миллионами подписчиков 😲 Интересно было бы узнать детали произошедшего, но пока звезда пилит только кружочки с переживаниями о произошедшем и о том, что она держится из последних сил, скорбя о потере страницы с таким количеством подписчиков 📈

Ну а мошенники пока этим пользуются, распространяя всякое... Понять боль "актрисы" и "певицы" не сложно – по экспертным оценкам (не моим), ее годовой доход от рекламы в соцсетях составляет около 80 миллионов рублей (один рекламный пост стоит от 300 тысяч до одного миллиона рублей). Есть за что переживать... 😭

Хотя может ей действительно жалко терять контакт со своими миллионами подписчиков, с которыми она общается сама без всяких помощников и вот этого всего... Мне сложно понять ее чувства – рекламу не размещаю, миллионов подписчиков не имею. Разные у нас весовые категории ⚖️

#инцидент

Читать полностью…

Помните историю про отключение банков от СМЭВ при отсутствии аттестации ФСТЭК? 🗂 История получает свое развитие. Банки получили от Минцифры письмо, в котором говорится о риске отключения от ЕСИА при отсутствии СКЗИ класса КС3 (VPN и средство ЭП). Не знаю, что стоит за этим письмом (не инцидент же), но описанная в нем логика прослеживается достаточно давно. Например, ФСТЭК еще с 2022-го года считает, что внутренний нарушитель есть всегда, а значит по линии ФСБ 🇷🇺 – это уже модель нарушителя Н3 и средства криптографической защиты не ниже класса КС3. А в 2019-м году на Магнитке зампред ЦБ, Ольга Скоробогатова, прямо говорила, что по их мнению все банки должны использовать СКЗИ классом не ниже КС3.

Отдельной вишенкой на этом "торте" 🍰 является предупреждение от Минцифры 🔢 о том, что если кто-то не исполнит описанные требования, то доступ к ЕСИА может быть ограничен, а к нарушителю может быть отправлена проверка ФСБ 👮

Но, как мне кажется, банки 🏦 – это только начало и требование применения КС3 будет распространено на все компании, подключающиеся к ЕСИА. Что это значит для большинства компаний? Например, запрет на виртуализацию и облака, в которых КС3 просто нельзя реализовать из-за требований ФСБ к криптографии этого класса защиты. В свою очередь это приводит нас к перестройке архитектуры решений, пересмотру используемых решений, росту затрат... А учитывая, что в ЕСИА/ЕБС сегодня загоняют многих, то 🕺

#регулирование #криптография #тенденции

Читать полностью…

Был вчера на записи подкаста 🎙 про процессы и оценку эффективности SOC и зашел у нас разговор за метрики. Не успел раскрыть мысль на эфире, поэтому напишу тут. Снова про закон Гудхарта, который утверждает, что как только ты сделаешь какую-то метрику главной, она перестает быть полезной. Потому что специалисты, подрядчики или даже руководители найдут способ превратить ее в профанацию (вообще про "закон Гудхарта" я немало написал в канале) 🤷‍♀️

Если, например, сделать главной метрикой 👉 количество закрытых инцидентов, SOC начнет закрывать их быстрее – не разбираясь в сути, не устраняя первопричины и не улучшая процессы (не сразу, но начнет). Если в приоритете количество обнаруженных уязвимостей (если это включено в сервисы SOC, конечно), команда начнет искать их там, где проще, игнорируя сложные и критичные участки, целевые системы и т.п. 🤕 Или наоборот – искусственно раздувать отчеты, чтобы продемонстрировать "активность". Когда в одной компании метрикой выбрали "нулевое количество утечек", сотрудники просто перестали о них сообщать 🤐 – чтобы не портить статистику. Реальных инцидентов стало не меньше, просто они ушли в тень.

Идеальной метрики в ИБ не существует 😱 Потому что как только появляется система оценки, люди начинают играть с правилами, а не с результатом (в любой системе). Поэтому не стоит превращать киберустойчивость, доверие или безопасность бизнеса в единственную "священную метрику" 🐮 Это должно оставаться стратегической сверхцелью, которую метрики лишь приближают, но не подменяют 😵

В качестве главной метрики 🎖 разумно выбирать тактическую цель, которая помогает продвинуться к стратегической – например, долю покрытых систем мониторингом, скорость реагирования или процент пользователей, прошедших тренинг повышения осведомленности, но не сообщивших о фишинге. Но как только сотрудники научатся "играть" с этой метрикой, а они научатся, – придется искать новую ☺️ Метрики должны жить, меняться и эволюционировать вместе с угрозами, технологиями, задачами, бизнесом, иначе они сами станут самым слабым звеном.

ЗЫ. А у вас есть процесс управления измерениями ИБ? Кстати, на SOCcon тоже будем об этом говорить.

#soc #метрики

Читать полностью…

Продолжим смотреть на убытки от кибератак 🤑; на этот раз английский ритейлер Marks & Spencer (M&S), который в конце апреля 2025 года столкнулся с крупным "кибер-инцидентом", при котором были отключены онлайн-заказы по одежде, домашним товарам и средствам красоты, а также некоторые функции в магазинах, например, Click & Collect. Онлайн-заказы были приостановлены примерно на 46 дней, прежде чем M&S смогла возобновить оформление заказов на доставку 📦 При этом утекли персональные данные клиентов. По данным проведенного расследования, вход был получен через стороннего подрядчика, посредством социальной инженерии (сброс паролей через help-desk). Ну а теперь к убыткам 💸

M&S оценивает удар по операционной прибыли примерно в £300 миллионов фунтов стерлингов (≈$400 миллионов) в 2025 финансовом году из-за последствий атаки. Аналитики оценивают, что убытки уже могли составлять £60+ миллионов к маю 2025-го, с падением рыночной капитализации M&S более чем на £1 миллиард (в реальности около 700 миллионов) 📉 Снижение доступности товаров в магазинах: из-за отключения систем заказов и логистики M&S сообщала о дефиците некоторых продуктов в магазинах. Дополнительные расходы: переход на ручные процессы, замена/восстановление ИТ-систем, аудит безопасности, внешние консультации – все эти статьи количественно не явно раскрыты, но отмечены как значимые. Репутационные риски 🤠 и утрата доверия: компрометация данных клиентов (имена, адреса, история заказов) может повлечь отток клиентов, снижение лояльности и дальнейшие расходы, но оценить это можно будет позже.

Наряду с прямыми потерями есть "хвостовые эффекты" – снижение роста, изменение поведения покупателей, усиление конкурентного давления и т.п. 🛒 Кроме того, отмечается потеря эффективности цепочки поставок из-за временной нестыковки между складами, ИТ и ритейлом; частичное ручное резервирование заказов. Компании пришлось отложить часть ИТ-инициатив, чтобы перераспределить ресурсы на восстановление. После атаки Marks & Spencer объявила об увеличении бюджета кибербезопасности (цифры не раскрывались, но ожидается рост на 30–40%) 🛡

Инцидент M&S – один из крупнейших по стоимости в британском ритейле (инцидент с Co-op уступает по размере потерь) 🤑 Но этот кейс не относится к стратегическому кризису (компания осталась прибыльной и ликвидной), хотя в совокупности и потеряет (напрямую) около 0,2–0,3% годового оборота (а также около 2,5% в качестве операционного эффекта и около 6% рыночной стоимости, то есть восприятия рынком, а не денежного оттока), что представляет собой статистически умеренное воздействие, если не считать репутационных последствий и операционного эффекта ☺️ Это не системный провал безопасности, а скорее недооцененный подрядчик и человеческий фактор. Но в любом случае неприятно.

#ущерб

Читать полностью…

когда в утечке нет ред флагов
то это сразу же ред флаг

Около 40% "новых" дампов в Даркнете – это пересобранные фрагменты старых баз, к которым добавили новые метаданные и выдали за свежий взлом 👎 Почему "хакеры" все чаще объявляют о взломах и утечках, которых на самом деле не было? Я бы выделил несколько возможных причин:

➡️ Получение прибыли, так как продажа "утекших данных", как и продажа любых подделок, от фейковых ювелирных украшений до поддельного алкоголя, может приносить деньги.
➡️ Повышение узнаваемости. Хакерские группы хотят известности. Например, в марте 2024 года одна группировка заявила о взломе Epic Games, но никаких доказательств не было; позже оказалось, что они просто сделали фейк, чтобы привлечь внимание к своей деятельности.
➡️ Создание отвлекающего маневра – пока организация занята расследованием заявленной "утечки", преступники могут на самом деле проникать через другой канал.
➡️ Подрыв репутации компании. Даже обычное заявление о взломе может нанести ущерб бренду, несмотря на отсутствие утечки. Например, когда в сентябре 2023 г. заявлялось о взломе Sony, но впоследствии подтвердилось, что доказательств нет, вред все же был нанесен.
➡️ Манипулирование курсом акций. Для публичной компании новость о взломе может привести к падению стоимости акций – преступники могут организовать фейковую утечку ради спекуляций на фондовом рынке.
➡️ Сбор разведданных об ИБ-инфраструктуре. Объявление утечки может заставить компанию-"жертву" показать, как она реагирует, какие процессы задействует, что позволяет хакерам лучше спланировать реальную атаку 🤔

На какие признаки фейковости стоит обращать внимание?
🌟 Нет примеров данных ➡️ 🔴 высокая вероятность фейка
🌟 Нет старых следов группировки ➡️🔴 высокая вероятность фейка
🌟 Нет упоминаний в TI-источниках ➡️🟡 средняя вероятность фейка
🌟 Данные совпадают с другими утечками ➡️🔴 высокая вероятность фейка
🌟 Ошибки в форматах, фейковые поля ➡️🟡 средняя вероятность фейка
🌟 Отсутствие официальных подтверждений ➡️🟡 средняя вероятность фейка
🌟 Данные сгенерированы ИИ (однородность, фиктивные адреса) ➡️ 🔴 высокая вероятность фейка

Чтобы отличить фейковую утечку от реальной, нужно оценивать не только сами данные, но и контекст, историю источника 👀, наличие прямых и косвенных доказательств, возможность верификации и реакцию всех участвующих сторон. Иными словами, "фейковая утечка" – это скорее не технический, а информационно-психологический инцидент, и подходить к ней нужно с методами OSINT, threat intelligence и форензики одновременно 🤔

ЗЫ. Представьте ситуацию – некий месенджер 💬 заявляет о том, что у него 40 миллионов пользователей, но это неправда. Эта цифра утекает в СМИ и хакеры, желающие нажиться, создают фейковую утечку на 40 миллионов записей. И всё, все, кто вовлечен в обман и накрутки, знают, что это фейковая утечка, так как в реальности пользователей гораздо меньше! Бинго! Простой способ вывести мошенников на свет! 💡

#утечка #персональныеданные #threatintelligence

Читать полностью…

Интересные какие последствия кибератаки на Аэрофлот проявляются... 🛩 Это к разговору о том, что восстановление полетов в течение суток, конечно, хорошо. Но вот остальные внутренние процессы восстанавливаются не так быстро. Именно поэтому посчитать ущерб в день инцидента или даже через неделю невозможно 🤔

#ущерб

Читать полностью…

С упоением слежу за творчеством представителей одной питерской, широко известной в узких кругах, высшей школы по ИБ 🧠, известной по применению кротовых нор для поиска уязвимостей и проведению пентестов в национальном масштабе, фракталов, мультифракталов, вейвлетов и фильтра Калмана для обнаружения атак SYN Flood, а также выявлению аномалий в IoT на основе гиперкуба 😮 И вот новая инновационная технология – интеллектуальная система адаптивной защиты от сетевых атак на основе реконфигурации сети.

Не знаю, помните 🧠 ли вы (скорее всего нет), но в конце 90-х в США один бывший россиянин запатентовал систему динамической и практически непрерывной смены IP-адресов для защиты от атак. С тех пор на эту технологию перешли... никто, так как поддерживать эффективную маршрутизацию трафика в таких условиях практически невозможно 📇

И вот, спустя почти 30 лет, к схожей идее решили вернуться на брегах Невы, дополнив технологию искусственным интеллектом 🧠 Авторы предлагают за счет обучения с подкреплением генерить множественные топологии сети и изменять пропускную способность каналов связи, что по мнению авторов должно привести к кардинальному снижению опасности проведения DDoS-атак. Было даже посчитано значение этого снижения – 46% (почему не 146%?) 🛡

Все, атаки побеждены, критики посрамлены, хакеры остановлены, русская научная школа торжествует, диссертации пишутся, степени присваиваются... И пофигу, что на практике это все не работает. Впереди ждут новые гранты... 🤑

ЗЫ. Авторы считают, что сеть с 320 устройствами – это большая инфраструктура 🤦‍♂️

Читать полностью…

Как-то так, да...

#инцидент

Читать полностью…

Министерство госбезопасности КНР 👲 в своем канале в WeChat обвинило АНБ США в том, что оно в течение длительного времени проводило атаки против National Time Service Center (NTSC), института Академии наук КНР, обеспечивающего эталонное время и его распространение в Поднебесной 🐉

Предположительно начиная с 2022 года АНБ 🇺🇸 якобы "эксплуатировало уязвимость" в сервисе обмена сообщениями одного иностранного бренда смартфонов (какой именно бренд был использован неизвестно), чтобы получить доступ к мобильным устройствам сотрудников NTSC 📱 В период 2023–2024 годов была проведена серия атак (до 42 инструментов кибероружия, по словам Китая) на внутренние сети института и на "высокоточную наземную систему времени" ⏱

МГБ предупреждает, что Центр времени обеспечивает синхронизацию времени 🕙 для широкого круга критических инфраструктур: связь (PTP), финансы (биржевые временные метки, высокочастотный трейдинг), энергетика (синхронизация, PMU), транспорт, ИБ (регистрация и корреляция событий ИБ, PKI/Kerberos). Нарушение могло привести к каскадным эффектам. Китай 🇨🇳 утверждает, что располагает доказательствами, но пока не опубликовал их публично (возможно, ждут грядущих торговых переговоров Си и Трампа, что грозит очередным витком напряженности). При этом Китай критикует США за "двойные стандарты" – обвиняет США в том, что они сами ведут подобные операции и затем обвиняют Китай 🐲

ЗЫ. А вы защищаете свои сервисы от атак на службы точного времени? 🤔

#инцидент

Читать полностью…

Пока вы отдыхаете в свой законный выходной, у меня идет обучение 👩‍🎓 топ-менеджеров по программе MBA; читаю там модуль по кибербезу для руководителей и владельцев компаний из совершенно разных отраслей (строительство, рестораный бизнес, медицина, ритейл и т.п.) и с разной выручкой – от нескольких миллионов до десятков миллиардов. Очередной интересный опыт... 🤠

#обучение #cxo

Читать полностью…

Узнал тут про новую отечественную ИБ-ассоциацию, а она оказывается с 2022 года существует 😦 Сайт есть. Членов принимают. Протоколы собраний ведут. Моей НАИБАЛ (Некоммерческая Ассоциация по ИБ Алексея Лукацкого), с ее единственным членом, еще учиться и учиться у аксакалов... ☕️

Хотя фраза "организация, основанная с целью создания первой в России саморегулируемой организации" выглядит странно 🫤 Как и одна из частей миссии – "сокращать неоправданное вовлечение государственных регуляторов" (просится вопрос "куда?"). Зато деятельность ассоциации, которая "направлена прежде всего на создание благоприятных условий для профессиональной коммерческой деятельности членов Ассоциации" , предельно понятна и не требует пояснений. Может поэтому я и не встречал раньше ее на поле ИБ; даже с учетом того, что она разработала и утвердила систему добровольной сертификации "БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ" 🫤

Уж сколько было попыток создания систем добровольной сертификации средств защиты информации... А все бестолку – не понимает у нас бизнес эту историю – либо обязаловка и тогда в систему сертификации ФСТЭК или ФСБ (МО и СВР оставляем в стороне), либо "зачем нам тратить добровольно деньги?" 🤔

#рынок #оценкасоответствия

Читать полностью…

"Я понял, в чем ваша беда. Вы слишком серьезны. Умное лицо – еще не признак ума, господа. Все глупости на Земле делаются именно с этим выражением. Улыбайтесь, господа, улыбайтесь!" (с) "Тот самый Мюнхгаузен"

#биометрия

Читать полностью…

Сегодня выступал на Russia Risk 2025 в секции "Киберриски и кибербез финансовых организаций" 🏦 – на тему рисков для новых технологий (ИИ, кванты, блокчейн, ЦФА, RPA, беспилотники, IoT, ESG, открытый банкинг и т.п.). Времени было немного, но презентацию сделал с запасом, чтобы потом можно было ее расширять по необходимости и в направлении угроз и в направлении безопасности для всего того нового, что применяется и может начать применяться в финансовых организациях (и не только) 🛡

#презентация #технологии

Читать полностью…

А вот кому целую платформу, ориентированную на специалистов по кибербезопасности, где можно публиковать и обмениваться "правилами обнаружения", написанных на разных форматах 🔍 – yara, sigma, zeek, suricata, nova, elastic и др. Софинансируется этот открытый проект центром реагирования на инциденты Люксембурга CIRCL и проектом Евросоюза FETTA (Federated European Team for Threat Analysis).

ЗЫ. Github проекта - https://github.com/ngsoti/rulezet-core.

#обнаружениеугроз #soc #ttp

Читать полностью…

Почему "еще один плейбук в SOAR" – это не автономный SOC? Как перейти от ручного разбора инцидентов к системе, которая сама обнаруживает, расследует и реагирует – прозрачно, предсказуемо и под контролем? Неужели и правда наступил тот момент, когда L1 не нужен? 😂

В модерируемом мной прямом эфире AM Live разберем: ✍️
➡️ Где проходит граница между глубокой автоматизацией и настоящим автономным SOC (и почему подмена понятий опасна)?
➡️ Рабочие архитектуры: overlay над текущим стеком, интегрированные платформы, эмуляция действий аналитиков. Что выбрать на старте?
➡️ Практику внедрения: период доверия к ИИ, метрики (MTTD/MTTR, доля кейсов без участия человека), стоп-кнопки и RACI для ИИ-решений.
➡️ Технологии в связке: SIEM/UEBA/SOAR/TI/LLM – кто за что отвечает, где узкие места данных, как не попасть в vendor lock-in?
➡️ Риски и соответствие: объяснимость решений, ответственность за ошибочные действия, требования регуляторов, аудит и журналирование.
➡️ И много чего еще...

Регистрируйтесь и не говорите потом, что вас не предупреждали, когда ваше рабочее место аналитика SOC займет робот! 😆

#soc #мероприятие #ии

Читать полностью…

Ника препарирует очередной инцидент с точки зрения антикризисного PR. Отечественный облачный разработчик сканера уязвимостей Metascan столкнулся с попыткой внедрением вредоносного кода в свое ПО со стороны джуна на испытательном сроке 😱 Сообщение об инциденте было опубликовано... ботом. Ну а мне в данном инциденте интересно другое.

Это, пожалуй, первый публичный пример признания такого инцидента в российской ИБ-отрасли 🥇 Будут ли из него извлечены правильные уроки другими ИБ-разработчиками, многие из которых сталкивались с компрометациями своей инфраструктуры, но почти никогда не раскрывали деталей расследования и анализа последствий действий злоумышленников? Будет ли проверка со стороны регуляторов (а не только пугалки)? Может это станет основанием для усиления контроля за подрядчиками со стороны клиентов? 🤔

Если бы я работал в компании, которая столкнулась с таким инцидентом и имела смелость признать его (а скрыть такое, честно говоря, сложно), то я бы настаивал на следующих шагах: 👣
1️⃣ Выпустить пост-анализ (Post-Incident Review), описав это без упоминания личностей, но с указанием технологий и организационных решений. Это сразу превращает уязвимость в демонстрацию зрелости инженерных практик и этики безопасности; особенно в ИБ-компании, которая занимается работой с уязвимостями.
2️⃣ Прямая рассылка клиентам – короткое, честное письмо от компании (не от бота). Молчание воспринимается как попытка скрыть что-то нехорошее; честное объяснение – как гарантия открытости и компетенций. Может она и была в случае с Metascan, не знаю, я не их клиент.
3️⃣ Использовать ситуацию, чтобы выступить с экспертным комментарием в СМИ или на конференциях. Из “жертвы” компания превращается в эксперта, пережившего реальный инцидент и готового делиться опытом. От ИБ-компании – это особенно ценно.

Раз уж история началась с сообщения от бота, то и закольцевать ее можно было бы также, красивым сообщением от бота: 🤖

"Инсайдерские угрозы – один из самых сложных вызовов в кибербезопасности. Мы сами столкнулись с этим и теперь можем со знанием дела рассказывать, как выстроить устойчивые процессы. С тех пор мы переписали не только код, но и внутренние политики. Мы проверили наш процесс CI/CD, добавили дополнительную верификацию исходного кода и усилили контроль доступа на уровне GitLab и Jenkins. Также внедряем систему peer-review на всех этапах сборки. Не только усилили контроль за кодом, но также инвестировали в культуру доверия и ответственности среди сотрудников. Все обновлено, протестировано, проверено. Ваш обновленный бот, уже прошедший испытательный срок!".

Буду следить за ситуацией... 👀

#инцидент #антикризис #supplychain #проблемыибкомпаний #devsecops

Читать полностью…

Возникла тут тема повторить успех астрологического прогноза ♌️ по кибербезу, но уже на международной арене. И уже было почти все готово, когда, внезапно, ты узнаешь, что в исламе астрология находится под запретом и страны Ближнего Востока и многие страны Юго-Восточной Азии, где сильно присутствие Позитива, могут не воспринять твоего креатива, а еще и закидать камнями или отправить в зиндан 😡 Это все к разговору о том, что занимаясь ИБ, необходимо учитывать множество культурных и религиозных особенностей мест, где этот самый кибербез и обеспечивается.

Становится более понятным, почему фотостоки и визуализация в международных компаниях типа Cisco, IBM, Microsoft и т.п. настолько выхолощены и скучны до безобразия. А чтобы удовлетворить все возможные претензии со стороны меньшинств, религиозных течений, политических партий, гендерных групп и вот это вот все 🤔 Делать уникальный контент под каждую группу они не могут (дорого и лениво), вот и сокращают издержки...

#культура #религия

Читать полностью…

Пишут, что Департамент здравоохранения Москвы 🏥 планирует до 2027 года сделать резервные копии всех медицинских сведений из ЕМИАС... на бумаге. Если не придираться к цитате юриста, что:

"Требования к хранению персональных данных вынуждают дублировать сведения из ЕМИАС в бумажном виде для хранения в архивах"

(таких требований в законодательстве лично мне не известно), то эта история очень показательная ☝️ Последние годы российское здравоохранение активно продвигает электронный формат медицинских документов – введены правовые нормы, разрешающие или стимулирующие отказ от бумажного документооборота, а в нормативных актах прямо указано, что при хранении электронных медицинских документов должна быть организована резервная копия и возможность восстановления. При этом эксперты критикуют избыточное дублирование бумажной и электронной формы: 📄

"Эксперты НФ призвали исключить дублирование бумажных и электронных документов в здравоохранении".

Решение Депздрава идет вразрез с трендом. Почему? Если отбросить невозможное (надо срочно потратить неизрасходованный до конца года миллиард), то видится мне несколько причин: ✍️
1️⃣ Опасение, что резервные копии (электронные) не позволяют гарантировать восстановление. На практике крупные цифровые проекты часто сталкиваются с проблемами при резервировании – устаревшие форматы, миграции, отказ оборудования, человеческий фактор. Возможно, чиновники делают бумажную копию как "страховку"; если система выйдет из строя, бумага все равно останется (если хранится будет правильно).
2️⃣ Неумение в кибербез или недоверие к тем, кто это делает. В такой ситуации, бумажная копия может рассматриваться как менее уязвимая "офлайн"-страховка (хотя у нее свои риски: пожар, истирание, контроль версий, аудит изменений и т.д.).
3️⃣ Нежелание идти в ЭДО с его непостоянными требованиями и необходимостью постоянно перевыпускать ключи ЭП. Оставлю свое же предположение без комментариев 😊
4️⃣ Переходный этап / сохранение "legacy"-процессов. Медицинские учреждения часто имеют "привычку" бумажной работы, ведения бумажных карт. И даже при электронной системе документооборота могут поддерживать бумагу "на всякий случай" или из-за сопротивления изменениям. Помню в одном госоргане бухгалтера взбунтовались при попытке перевести их на Астру. Директору поставили ультиматум: "или Астра и ты без зарплаты или мы на Винде, но все как ты привык". Директор не стал сопротивляться, хотя по бумагам там 100%-е импортозамещение операционных систем и офисного ПО 😂
5️⃣ Возможно, существует бюджет на бумагу, заинтересованные подрядчики, "архивные" услуги, что стимулирует создание бумажных копий.

Если верно любое из первых двух предположений, то это плохой знак 👎 Государство не верит в кибербез, потому что не умеет выстраивать процессы. Вот тут в новом канале по ИБ об этом тоже упоминается. Одно дело в чеклисте проставить галочку "наличие бэкапа" и совсем другое дело выстроить процесс резервного копирования с регулярной проверкой возможности восстановления данных в заданное время 👎

Возможно, госорган не в состоянии выполнить растущее число разрозненных нормативных требований по ИБ от разных регуляторов ☹️ В любом случае если это станет трендом (а вот тут Евгений пишет о схожих проблемах), то это нехорошо; я уже привык к Госуслугам (ЕМИАСом не пользуюсь – раз в год только зайду посмотреть, сколько неоказанных мне в реальности услуг на меня навесили), с ними реально стало удобно и число походов по всяким госорганам за справками сократилось многократно 📉

ЗЫ. Спасибо подписчице, что подкинула новость в комментариях 🙏

#стратегия

Читать полностью…

Благодаря ИИ современные фейковые утечки выглядят очень убедительно, а доступ к старым утечкам позволяет быть еще более похожими на настоящие данные. Каким образом можно верифицировать "фейковость" данных, которые появлялись, появляются и будут появляться в Даркнете? Позволю набросать некоторое количество возможных вариантов:

1️⃣ Семантическая проверка данных "утечки". Несоответствия в форматах: телефонные номера, почтовые индексы, форматы дат, доменные имена, идентификаторы клиентов и т.п. часто случайны или не соответствуют нормам страны или компании. Повторяемость строк: фейковые наборы часто генерирятся по шаблонам, и внутри много дубликатов или искусственных закономерностей. Неверные корреляции: например, email @company.com связан с человеком из другой страны или департамента. Например, в "утечке Sony" 2023 года журналисты заметили, что email-адреса и имена не соответствовали корпоративным форматам, и это позволило быстро усомниться в подлинности всех остальных данных.

2️⃣ Поиск совпадений с известными базами. Проверяйте, встречаются ли эти данные в ранее известных утечках (если у вас есть собственное подразделение Threat Intelligence). Если совпадения высоки, то велика вероятность, что "новая утечка" – это просто перепакованный старый дамп.

3️⃣ Проверка метаданных и контекста. Отсутствуют характерные артефакты, типичные для реальных инцидентов: имена таблиц, схемы БД, следы SQL-дампов, пути к файлам. Файлы созданы недавно, но не содержат "следов происхождения" (нет временных меток, логов, имен серверов). Объемы данных неправдоподобны – слишком ровные, без "шумов". Заявление о взломе появляется без подтверждающих скринов, POC-файлов, примеров данных. Хакерская группировка или хакер неизвестны или недавно созданы/зарегистрированы на форуме. Текст заявления полон маркетинговых фраз ("доказательство силы", "мстим корпорациям"), а не технических деталей.

4️⃣ Поведенческий анализ источника в Даркнете. Как давно создан профиль? Есть ли история продаж, отзывы, репутация? Реальные утечки обычно публикуют известные группировки или хакеры, которые предоставляют "доказательства" нефейковости данных (proof-of-life), например, 1–2% дампа выложены в открытый доступ. Например, BlackCat и LockBit почти всегда публиковали фрагменты доказательств, а фейковые "группы" типа Mogilevich или SiegeSec часто ограничивались заявлениями в Telegram. Но все это с оговоркой на "тихие утечки".

5️⃣ Проверка "канареечных токенов" (Canary Tokens). Можно заранее встроить в БД уникальные искусственные данные (email, документ, API-ключ). Если в "утечке" всплывает такой токен, значит, факт компрометации реальный. Если нет – скорее всего, данные подделаны или взяты из других источников. Но это может проверить только сама "жертва" – вовне эти хлебные крошки неизвестны.

6️⃣ Проверка реакции компании и регуляторов. Реальные инциденты обычно сопровождаются уведомлениями от самой компании, SOC / CERT, регуляторов или клиентов. Если нет официальных заявлений в течение 48–72 часов, а только "вброс" на форумах – это сильный индикатор фейка. Но, правда, в России это не очень работает – у нас любят замалчивать все утечки.

7️⃣ Есть еще инструментальные методы автоматической проверки, но это уже тема отдельной заметки.

Все это можно включить в соответствующий плейбук и регулярно проводить киберучения на предмет проверки фейковости данных; или использовать внешний сервис Threat Intelligence / Сюрвейинг для аналогичной задачи ✍️

Но есть одно «но» у этой истории - проверить это можно только изнутри компании, подозреваемой в утечке. Снаружи большинство этих методов, кроме 4-го пункта, не очень работоспособны. А значит все зависит от желания "жертвы" заниматься этим и опубличивать 🤔

ЗЫ. Еще вот это видео с PHDays можно посмотреть – оно про тоже самое.

#утечка #threatintelligence #персональныеданные

Читать полностью…

В «Аэрофлоте» до сих пор используют симуляторы для расчёта топлива после кибератаки.

Спустя почти два с половиной месяца после масштабной хакерской атаки на IT-инфраструктуру «Аэрофлота» около половины всех рейсов авиакомпании продолжают выполняться в нарушение Федеральных авиационных правил (п. 5.26 ФАП-128) без полноценного рабочего плана полёта (OFP). А именно без расчёта по топливу, метеорологической информации, карт опасных метеоявлений и данных о ветровой обстановке по маршруту.

Причиной проблем стал взлом американской программы Sabre FPM, через которую полётные диспетчеры обсчитывали рейсы и готовили брифинг-пакеты для экипажей. Авиакомпании пришлось экстренно перейти на российскую программу «Аэролоция», которой уже более 20 лет. Это ПО имеет устаревший движок, плохо адаптировано, не подгружает погоду, маршруты и другую важную информацию. Из-за минимальной автоматизации и медлительности «Аэролоции» диспетчерам всё приходится делать вручную. На обсчёт одного рейса у них уходит около получаса, тогда как при Sabre это занимало в среднем 5-7 минут.

В результате полётные диспетчеры, которых в штате «Аэрофлота» около 40 человек, а в смене работает в среднем 6–7, физически успевают обеспечивать необходимыми документами только международные рейсы, а также внутрироссийские продолжительностью свыше четырёх часов.

Остальные же рейсы до четырёх часов — а таковых около половины — частично обсчитываются с помощью скачанных из интернета программ для расчёта брифинг-пакета и моделирования полётов в авиасимуляторах. Например, Navigraph Charts, которая совместима с Microsoft Flight Simulator, и SimBrief by Navigraph. В них содержится чёткое предупреждение: «Not for real world navigation» («Не предназначено для навигации в реальном мире»). При этом данная фраза из документов обрезается.

Пилотам на коротких рейсах предоставляют не полностью рассчитанные полётные планы, составленные на основе усреднённых OFP прошлых полётов, без актуальных опасных метео явлений и ветровых зон по маршруту. После их забивки в бортовую систему самолётовождения (FMS), по просьбе руководства лётного департамента, пилоты рассчитывают топливо либо с помощью скачанного авиасимулятора, либо «дедовским способом», увеличивая запас топлива на всякий случай на три-пять тонн. Это приводит к перерасходу авиакеросина, снижению топливной эффективности, многомиллиардным убыткам и повышенному вреду для окружающей среды, а также создаёт дополнительные риски для безопасности полётов.

Отсутствие полноценного OFP ранее привело как минимум к двум инцидентам с вынужденными посадками самолётов «Аэрофлота» на запасных аэродромах для дозаправки. 30 июля экипаж Airbus A321 (RA-73160), выполнявший рейс SU-2130 из Москвы в Стамбул, над Чёрным морем объявил «Mayday Fuel», после чего развернулся и приземлился в Сочи. По той же причине в августе ещё один самолёт вынужденно сел в Самаре. По предварительной информации, это А321neo (RA-73705), выполнявший 29 августа рейс SU-233 из Дели в Москву.

Кроме того, экипажам может не выдаваться и утверждённый полётный план (FPL). Это привело как минимум к одному инциденту: 2 сентября самолёт Boeing 737-800 (RA-73095) «Аэрофлота», выполнявший рейс SU-850 из Хабаровска в Санью, отклонился от утверждённого маршрута над Гонконгом. Причиной этого стало отсутствие у экипажа ATC FPL с утверждённым маршрутом.

При этом задолого до хакерской атаки лётного директора «Аэрофлота» Эдуарда Советкина неоднократно предупреждали о необходимости разработки отечественных продуктов для расчёта брифинг-пакетов, чтобы поскорее заменить нелицензионное американское ПО Sabre. Однако он не видел в этом острой необходимости, продолжая докладывать руководству об отсутствии проблем и угроз. Уже после кибератаки Советкину также предлагали увеличить штат полётных диспетчеров, но этого пока так и не было сделано.

✈️ Залетай на Авиаторщину

Читать полностью…

Хакеры меняют тактики ⌨️, начиная использовать инструментарий ИБ для своих нехороших целей. Например, группировка Storm‑2603, также отслеживаемая и под другими именами, предположительно из Китая 🐉, начала использовать легитимный инструмент расследования инцидентов и цифровой экспертизы (DFIR) Velociraptor против организаций-жертв для обеспечения устойчивого доступа, закрепления и последующего развертывания программ-вымогателей (ransomware) 😷

Сама по себе процедура атаки была не новой, с одним исключением – установкой устаревшей и уязвимой верси Velociraptor 🦖 0.73.4.0 с известной уязвимостью CVE-2025-6264, позволяющей повышать привилегии. Инструменты DFIR обычно используются для расследования инцидентов и сбора доказательств, что не помешало злоумышленникам перенять их и для своих целей – скрытого контроля, расширения плацдарма, обеспечения C2-каналов. При этом не забываем, что использование такого легитимного инструмента усложняет обнаружение: сигнатуры могут не срабатывать, поскольку программа сама является "нормальной", но используется злонамеренно 📞

И также совсем недавно было обнаружено, что другие хакеры начали использовать HexStrike-AI – open source ИИ-инструмент 🤖, используемый командами red team для быстрой эксплуатации недавно выявленных уязвимостей типа n-day. Исследователи из Check Point Research зафиксировали активное обсуждение в Даркнете применения HexStrike-AI для обнаружения и использования уязвимостей в Citrix NetScaler ADC и Gateway (CVE-2025-7775, CVE-2025-7776 и CVE-2025-8424), включая удаленное выполнение кода без аутентификации и установку вебшеллов 🔓

HexStrike-AI позволяет значительно сократить время от обнаружения уязвимости до ее эксплуатации 🤕 – с нескольких дней до нескольких минут. И использование этого, в целом легального инструмента, демонстрирует не только активное освоение хакерами ИБ-инструментария, но и переход к атакам в реальном времени с помощью ИИ. В этом случае стандартный цикл (сканирование → разработка → внедрение) превращен в минутный процесс. Следовательно окно для патчинга существенно сокращается, а сама атака становится доступной более широкому кругу злоумышленников, снижая порог их входа 😂

Ну и как вы понимаете, это далеко не единственные примеры. В 2023-м году один российский антивирус использовался хакерами для атак на организации (и не исключаю, что до сих пор используется), в 2022-м тот же НКЦКИ 🗂 писал об уязвимостях в российском VPN-клиенте, позволяющем злоумышленникам обходить защитные механизмы. Так что вспоминаем "доверяй, но проверяй", ZeroTrust внедряй! 🤔

#хакеры #тенденции

Читать полностью…

Не знаю, как часто вы задумываетесь о кибербезопасности системы точного времени ⏳, но я вот поднял свои записи и решил поделиться мыслями на это счет (ну чтобы моя заметка про инцидент в Китае была дополнена и рекомендациями по ИБ, которые можно взять и применить на практике). Итак:

1️⃣ Архитектура и сегментация 🤬 Необходимо разделить инфраструктуру времени на логические/физические зоны (сами эталоны, оборудование и сети, которые распространяют время, например, NTP-сервера, потребители времени). Эталоны (атомные часы, рубидий, OCXO, локальные генераторы) – уникальная и критическая часть всей схемы; если офисный ноутбук попадет в сеть эталона, простая компрометация пользователя может привести к вмешательству в "источник истинного времени" ⏱ Большинство потребителей, конечно, первые два компонента не использует, но задуматься о резервировании как минимум NTP-серверов стоит.

2️⃣ Чтобы предотвратить удаленную компрометацию эталона через обычные IP-каналы необходимо организовать либо гальваническую развязку (air-gap) или установить однонаправленный диод данных для сегмента с эталонами ✂️ Опять же, при владении этим самым эталоном.

3️⃣ Криптография и протоколы времени (NTP / NTS / PTP) 🔐 NTP/PTP – протоколы синхронизации; NTS (NTPsec, RFC 8915) – защищенная надстройка для NTP; PTP имеет профили для высокоточного распределения времени и может поддерживать аутентификацию/шифрование на канальном уровне (MACsec) или TLS-туннелях. В противном случае незашифрованный NTP /PTP легко подделать / перехватить 🔍

4️⃣ Мониторинг времени как "сигнала безопасности" ⏰ Манипуляция временем дает "скрытый" эффект – нарушения в логах, верификации сертификатов PKI, финансовых системах – и может быть признаком целенаправленной атаки. Поэтому необходимо отслеживать метрики времени (offset, jitter, delay, переключения GM) как отдельный источник телеметрии и использовать их для обнаружения инцидентов ⏱

5️⃣ Идентификация аномалий PTP / NTP ⌛ Подмена grandmaster’a или появление "левых" NTP приводит к определенным шаблонам в пакетах. Поэтому стоит присмотреться в NTP/PTP-сообщениях на следующие параметры: Announce/Sync/Follow_Up (PTP), Path Delay, а для NTP – Stratum, RefID, Kiss-of-Death, Leap Indicators. Но важно помнить, что тот же PTP критичен к задержкам и поэтому инспекция должна быть аккуратной; ну и multicast учитывать также. Тут хорошо подойдут решения класса NTA. NGFW/IPS могут распознавать NTP, но PTP уже не понимают и тем более не оценивают логику (Stratum jump, Leap Second Spoof) 🛰

6️⃣ Управление ключами и доступом (HSM, RBAC). Компрометация ключей NTS/PTP дает возможность выдачи ложных аутентифицированных сообщений о времени, что требует хранения секретов/ключей в аппаратных криптографических модулях HSM и RBAC для управления GM, а также оффлайн-хранения критичных конфигураций 🛂

7️⃣ Про безопасность мобильных устройств говорить не буду (это только в кейсе с китайцами было актуально), а вот про киберучения сказать надо – необходимо хотя бы иногда отрабатывать сценарии "подмена времени", например, "прыжок времени" или "левый GM" 👨‍🎓 Особенно если вы субъект КИИ и ваше оборудование требует точного времени для своей работы.

#supplychain #стратегия

Читать полностью…

Давайте определимся с тем, надо ли сообщать о фейковых утечках ПДн или нет? 🤔 Ряд комментаторов к вчерашним постам про "фейковую утечку" из мессенджера MAX (тут и тут) заявляют, что это не нужно, а уведомлять необходимо только о реальных инцидентах. Так вот разочарую – закон гласит обратное. В приказе Роскомнадзора от 14.11.2022 №187 четко написано (п.16): ✏️

"В указанном случае [неподтверждения оператором факта неправомерной или случайной передачи (предоставления, распространения, доступа) персональных данных, повлекшей нарушение прав субъектов персональных данных, и (или) неустановления принадлежности скомпрометированной базы данных, содержащей персональные данные] к дополнительному уведомлению оператором прикладывается акт о проведенном внутреннем расследовании, подтверждающий отсутствие факта неправомерной или случайной передачи (предоставления, распространения, доступа) персональных данных, повлекшей нарушение прав субъектов персональных данных, и (или) неустановления принадлежности скомпрометированной базы данных, содержащей персональные данные, соответствующему оператору в деятельности такого оператора."

Ну и чтобы дважды не вставать. В случае обнаружения скомпилированной базы ПДн из ранее зафиксированных утечек уведомлять РКН тоже надо (п.17): 📝

"В случае установления оператором, Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций или иным заинтересованным лицом факта неправомерной или случайной передачи (предоставления, распространения, доступа) персональных данных, содержащихся в базе данных, характеристики которых полностью соответствуют ранее скомпрометированной базе данных, оператором направляется уведомление, предусмотренное частью 3.1 статьи 21 Федерального закона "О персональных данных"."

Так что о каждом фейке надо сообщать 🎭 Да, это тоже потенциальный вектор для атаки на организацию, о чем РКНу говорили еще на этапе публичного обсуждения проекта приказа. Но кто у нас слушает экспертов?

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

#регулирование #утечка #персональныеданные #управлениеинцидентами

Читать полностью…

Имидж "резидента пяти разведок и агента шести держав" прочно прилип и не отпускает 🫡

#юмор

Читать полностью…