Уникальный контент про кибербезопасность от Алексея Лукацкого (@alukatsk) - мысли, полезные ссылки, комментарии к текущим событиям, юмор и мемасики. Канал личный - мой работодатель никак не влияет на то, что здесь публикуется. Рекламу не размещаю!!!
Презентация по тенденциям, которые можно учитывать или не учитывать. Читал я ее на КибеРИТорике в Питере три недели назад и первые слайды про большую войну 💪 вызвали у слушателей неоднозначную реакцию. Ну а я считаю, что достаточно странно засовывать голову в песок и не видеть определенных сигналов (их на самом деле больше, чем упомянуто в презентации), коих с момента выступления даже стало больше 🛫 В худшем случае, вы про это будете знать и, может быть, подготовитесь. В лучшем – это все окажется глупостью, несбывшимся прогнозом (хотя вы же помните про мои прогнозы) и вообще всем peace.
#презентация #тенденции
Уже несколько человек попросило мою презентацию с Boost про кибербез для веб-студий и диджитал-агентств. Выкладываю...
#презентация #devsecops
Валера издал книгу 📖, для которой перелопатил огромное количество судебных, административных и уголовных, дел и показал очень интересную сторону жизни людей, связанных и связывающих себя с ИТ и ИБ. Ну и портрет нашей судебной 🧑⚖️ и правоохранительной 👮♂️ системы тоже можно по этой книге составить.
#книга
⚠️ Вот интересно, если вы зададите себе простой вопрос:
А что если завтра я проснусь, а все ИБ-регуляторы исчезнут вместе со своими нормативами?,
Если резюмировать последнюю нормативку Поднебесной 🇨🇳 в части уведомления об инцидентах и сравнить ее с другими государствами, то мы увидим, что Китай вводит самый "жесткий по часам" режим для тяжелых инцидентов (1–4 ч). В ЕС фиксированная двухступенчатая модель (24 ч / 72 ч / ≤ 1 мес.), в США – сочетание отраслевых (24–72 ч) и публично-рыночных (Коммисия по ценным бумагам SEC – 4 рабочих дня для инцидентов, повлекших существенные материальные последствия) режимов, а в РФ – 24 ч/72 ч для ПДн плюс свои требования для КИИ (3 ч/24 ч) 💬 То есть Россия где-то схожа с Китаем во временных параметрах. И кажется мне, что курс на сокращение времени уведомления станет скоро для всех государств нормой (а значит надо будет выстраивать систему мониторинга и вот это вот все).
Китай указывает числовые пороги для градации инцидентов (ПДн / деньги / простой / дефейс), что упрощает классификацию и облегчает заполнение уведомлений. В ЕС/США/РФ критичность чаще определяется качественным показателями. Требование к подрядчикам сообщать об инцидентах у них – прям хорошая норма, которой нам так не хватает. Ransomware как отдельная строка в первичном уведомлении (указать сумму/метод/временные параметры) – это редкий для законов уровень детализации. У американцев шифровальщики упомянуты только в требованиях CISA по уведомлению об инцидентах (Cyber Incident Reporting for Critical Infrastructure Act of 2022, CIRCIA) 🇺🇸
Кстати, о США. 30 сентября истекает срок действия закона Cybersecurity Information Sharing Act 2015 (CISA 2015) 👨💻 Этот закон почти 10 лет был базовым механизмом обмена киберугрозами между бизнесом и государством в Новом Свете. Его утрата, по мнению всполошившихся экспертов:
✔ лишит частный сектор и госорганы правовых гарантий для обмена индикаторами атак и иной информацией об угрозах,
✔ подорвет реализацию AI Action Plan, где предусмотрено расширение практики обмена уязвимостями и инцидентами, связанными с искусственным интеллектом,
✔ осложнит создание центров обмена информацией об угрозах для ИИ и проведение ИИ-хакатонов.
Эксперты отмечают, что так как ИИ внедряется во все отрасли, то и безопасность его должна быть выстроена с самого начала. Для этого нужны проверенные механизмы: disclosure-программы, bug bounty, red-teaming. Без возобновления действия CISA 2015 доверие и кооперация в части обмена данными об атаках, уязвимостях и пр. окажутся под угрозой 👎
Так что, кто-то выпускает новую нормативку, а кто-то борется с тем, чтобы не отменили старую. У всех свои заботы ☕️
#регулирование #threatintelligence
В штаб-квартире ЦРУ 🇺🇸 в Лэнгли стоит известная скульптура Криптос с 4-мя зашифрованными сообщениями, три из которых были разгаданы, а вот 4-е, с момента открытия памятника 3 ноября 1990 года, так и остается неразгаданным. По поводу разгадки зашифрованного послания, автор скульптуры, Джим Санборн, ранее рассказывал, что им были приняты все необходимые меры, чтобы даже его смерть не позволила никому раскрыть полный секрет Криптоса, так как нет ни одного человека, который бы знал полное решение загадки. Он также заявил, что даже он не знает полного решения.
Но вот совсем недавно Санборн сообщил в своем письме в The Washington Post, что его все достало и он устал ждать готов выставить разгадку 🔑 4-го сообщения на аукцион, надеясь, что покупатель все-таки оставит разгадку в секрете, что сохранит ореол таинственности над Криптосом. А пока желающие, включая и подписчиков, пытаются самостоятельно разгадать 35-тилетнюю загадку. Может и вы попробуете?.. 🤔
#криптография #искусство
Финансовый регулятор Сингапура 🇸🇬 подготовил документ по рискам, связанным с дипфейками. Простенько и со вкусом – описаны основные риски (обход биометрической аутентификации, социальный инжиниринг и дезинформация), даны реальные примеры реализации этих рисков и даны рекомендации (не требования), как бороться с этим 🎭
#аутентификация #регулирование #дипфейк
💡 Идея нового мероприятия по антикризисным мероприятиям в ИБ. Оно начинается с регистрации, где каждому участнику со стороны заказчика вручается футболка с одной из двух надписей "Я бдю! Мы бдим! А ты бдишь?" или "Я бздю! Мы бздим! А ты бздишь?". И сразу всем понятно, кто стесняется признаваться в произошедшем у него инциденте, а кто нет. В конце мероприятия так и не распакованная коробка с футболками с первой надписью уезжает на склад до следующего года. Тем, кому не хватило футболок со второй надписью обещают прислать ее курьером 👕
ЗЫ. Чтобы пост был не просто хиханьки-хаханьки, поучаствуйте в опросе у Ники про наличие антикризисного плана коммуникаций на случай инцидента ИБ. Вам всего пару кликов, а отрасли статистические данные 📊
#юмор #антикризис
Видимо так совпало... Вчера днем, в Кибердоме 🏠, обсуждая варианты сотрудничества, всплыла тема с возможными моими встречами перед детьми старших классов и студентов ВУЗов, которые планируют связать свою судьбу с кибербезом. Мол, наставить их на путь истинный, показать перспективу и вот это вот все 👶
Также вчера, но после выступления на Boost'е один из участников спросил меня, какие направления ИБ я считаю наиболее перспективными, так как он среди прочего преподает для детей 👦🏻 старших классов, которые интересуются кибербезом и которых надо направить в нужное русло. А так как выпускниками они станут не раньше 2030-го года, то и направления для них будут не только типовыми (пентесты, ИБ ИИ, ИБ IoT и т.п.), но и более современные (биохакинг, web3 и вот это вот все) 🔮
Наконец, и тоже вчера, мне попалась информация о проводимой в МИФИ Национальной технологической олимпиаде по информационной безопасности для старшеклассников 🏫 Хорошее начинание, как мне кажется. Так что не могу не поддержать коллег и дам ссылку на профиль по ИБ в рамках НТО, а также примеры олимпиадных задач (первая и вторая). Если у вас есть, кому отправить эти ссылки, то не стесняйтесь 🤝 Детей, идущих в ИБ, надо поддерживать!
ЗЫ. Надо будет обновить мою презентацию, которую я перед студентами МФТИ читал – готовить новое поколение ИБшников.
#обучение #работа
Сегодня я выступал на Boost, конференции для диджитал-агентств и студий, занимающихся веб-разработкой 🖥 Времени было не так и много, всего 45 минут (но все равно не уложился, но был крайним и поэтому некритично). Так что пробежался крупными мазками по тому, что важно учитывать руководителям разработки и проектов (было специально объединено два потока, которым важна тема кибербезопасности), и почему от заказчиков все чаще и чаще возникают вопросы кибербезопасности к своим подрядчикам 🤔
Ну тут достаточно вспомнить, что последние взломы некоторых российских ИБ-компаний происходили именно через подрядчиков, ведущих сайты вендоров. Все, что хотел рассказать не успел – там только в раскрытие модели зрелости, метрик ИБ для веб-студий, процедуру оффбоардинга (именно off, а не on) и т.п. можно было углубиться на час для каждой из тем. Но может быть еще где-нибудь про это расскажу 🙊
Когда предложили выступить на Boost, сначала думал отказаться; ну где я и где разработчики сайтов 🤐 Потом сел, подумал (полезное действие, кстати) и понял, а кто, если не я. Первый сайт "Информзащиты" я запускал в конце 90-х годов (жаль, на тридцатилетие компании, которой я 8 лет отдал, не позвали, я бы там поностальгировал за бокалом коньяка). Тогда это даже был не сайт, а набор статических html-страниц, а из всей динамики – только крутящийся логотоп, отрендеренный гендиректором в каком-то графическом дизайнере 🎨 Спустя несколько лет был крупный проект по новому сайту Информзащиты, где я уже полноценно руководил проектом, выбирал студии, писал ТЗ и драл разработчиков во все дыры за полный провал сайта с точки зрения ИБ. Третий сайт, который я запускал, был посвящен совместному проекту Cisco и Positive Technologies (была и такая страница в моей истории до выхода в PT) в году, этак, 2008-м. Наконец, а 2021-м я запустил уже целиком свой сайт, а в 2025 его нахрен заблокировали по жалобе кого-то из "добрых" подписчиков. Но ничего, перееду на новую платформу, с новыми знаниями, опытом и впечатлениями. А для чего еще жить, как не ради этого. А на Boost выступил, да 💪 И вроде всем зашло.
#презентация #devsecops
На Postive Tech Day в Новосибирске я рассказывал всякое про прогнозирование 🔮 атак на компании (презентации уже выложили), в том числе и про мониторинг Даркнета, который, при должной реализации, позволяет "предсказать" готовящиеся против вас атаки. Картинка на эту тему как раз из презентации 🤔
#threatintelligence
Продолжим про адекватность требований регуляторики, но на конкретном примере 🙂 Возьмем ГОСТ 57580.1 и требование РЗИ.15 "Обучение, практическая подготовка (переподготовка) работников финансовой организации, ответственных за применение мер защиты информации в рамках процесса защиты информации" или 117-й приказ ФСТЭК с требованием (п.57) "Оценка уровня знаний должна проводиться не реже одного раза в три года или после компьютерного инцидента, произошедшего у оператора (обладателя информации)" 👨🏫
В первом случае у нас есть просто требование без указания частоты и способа подтверждения его выполнения 🤷♀️ Во втором случае ФСТЭК дает больше вариантов реализации (п.56) мероприятий по повышению уровня знаний и информированности пользователей информационных систем по вопросам защиты информации. Но как будет проверяться реализация обоих требований? 🤔 На поверхности лежит очевидный вариант – тестирование. Как это можно реализовать в условиях нехватки или отсутствия бюджета? Вручную? Ну такое себе, как мы понимаем. И вот один из подписчиков разработал и выложил (за что ему спасибо) в открытый доступ решение для автоматизации внутреннего обучения и тестирования персонала (например, по ФЗ-152) или по 117-му приказу (тесты расширяемы своими темами) 🧑💻
Приложение написано на Python/Flask и легко разворачивается в любой инфраструктуре. Ключевые возможности:
➖Полный контроль. Устанавливается на ваш сервер, данные не покидают периметр компании.
➖Встроенный прокторинг. Система отслеживает и логирует подозрительную активность во время тестов – переключение окон, попытки копирования и печати.
➖Поведенческий анализ. Автоматический поиск аномалий в результатах, таких как высокий балл при низкой вовлеченности в учебные материалы.
➖Реестр сертификатов. Автоматическая генерация и хранение уникальных номеров сертификатов для успешно сдавших тест.
➖Готовые конфигурации. Проект включает файлы для быстрой настройки под Nginx, Gunicorn и Systemd.
Очень неплохой вариант для решения... а вот для решения чего? 🤔 По сути мы говорим не о том, как повысить осведомленность пользователей и проверять ее, а о том, как подтвердить факт реализации требования регулятора. Для очень большого числа специалистов это важно, как показал и опрос и комментарии 😶 Но решает ли это задачи ИБ? Чтобы программы обучения и повышения осведомленности несли ценность, они должны эволюционировать – от ежегодной и развтригодной галочки "пройдено" 🫡 к непрерывной и постоянной практике изменения культуры ИБ, поддерживающей конкретный бизнес (поэтому это сложно учесть в нормативке, которая единая для всех).
Если отталкиваться от зрелости программ обучения и повышения осведомленности, предложенный подписчиков проект – это второй уровень, "ориентированный на нормативку", ценность которого только в выполнении требований 🫡 Давайте признаем, что мы все регулярно проходим такие дурацкие тренинги – от пожарной безопасности или охраны труда до антикоррупционной деятельности и защиты персональных данных. И проходим мы их даже не вникая в вопросы ☑️
Первый уровень зрелости программы – это когда никакой программы нет и в помине 👎 На третьем уровне мы управляем ключевыми рисками через целевые изменения в поведении работников и регулярное подкрепление через анализ обратной связи. Именно здесь вы начинаете оценивать не знания в форме тестирования, а производимые (или непроизводимые) пользователями действия (неуведомление об инцидентах, включение MFA там, где это рекомендовано, но не обязательно, использование сильных паролей и т.п.) 🔏
На следующем уровне безопасность встроена в повседневные процессы и процессы и ресурсы обеспечивают долгосрочную историю. Высший уровень – уже не обучение, а культура ИБ выровнена с целями бизнеса и рассматривается как стратегическая составляющая организации 🧐 Тут и ощущение личной ответственности (а не "отвали, это не мое дело"), и доверие команде ИБ, и релевантность форм и форматов обучения и повышения осведомленности процессам, возрастам и половиной принадлежности работников организации и т.п.
#обучение #opensource #регулирование #maturity #awareness
Кстати, о вырубании лесов 🪓 А давайте посмотрим, сколько мы их уничтожаем на бумажную безопасность? Если сложить базовый пакет требований от разных регуляторов по ИБ, которые распространяются на среднестатистическую организацию, то получится около 2000 страниц текста формата А4. Так как нормативы регулярно обновляются, появляются новые редакции, методички и т.п., то годовой объем вырастает до 4000 страниц. Если это все печатается в одном экземпляре, чтобы читать "с листа", а не с экрана, то получается, что мы убиваем ровно половину дерева 🪵, которое идет на печать 8333 листа бумаги формата А4. Увеличивая число рецензентов и читателей новой нормативки, вы увеличиваете и число срубаемых деревьев.
У нас в стране около полумиллиона компаний, которые реально занимаются хоть каким-то compliance (хотя судя по тому, что даже ИП и самозанятые начинают в чатиках по персданным задавать вопросы по соответствию, можно предположить, что это число будет расти). 500 тысяч компаний - это 250 тысяч деревьев 🌲
Знаете, что такое 250 тысяч деревьев? Это 500 футбольных полей , или территория небольшого города типа Железноводска, или половина деревьев парка Сокольники в Москве. Чтобы посадить столько деревьев, нужно было бы засадить лесом все дворы и улицы большого города вроде Тулы 🌳
Но ведь мы не только печатаем всю нормативку, но и свои пакеты документов под нее делаем внутри своих организаций (иногда до 15-30 основных документов на один НПА). Вспомню свою математическое прошлое и попробую прикинуть формулу ✍️ для расчета, чтобы и вы могли оценить, какое количество деревьев вы убили, занимаясь бумажной ИБ. Итак, исходные данные:
➡️ D – число документов в "живом" комплекте (политики/процедуры/регламенты),
➡️ P – средний объем одного документа (страниц),
➡️ V – версий в год (редакций/переутверждений),
➡️ C – сколько бумажных комплектов печатают на один документ за версию (руководство, аудит, архив, стенды/филиалы и т. п.),
➡️ N – число компаний,
➡️ α – доля компаний, которые действительно это печатают (остальные – только электронно),
➡️ δ – коэффициент двусторонней печати (δ=0,5 если печатают в двухстороннем режиме; 1 — если в одностороннем).
Тогда у нас получается: 🧑💻
➡️ Страниц/год на одну компанию = D × P × V × C × δ
➡️ Деревьев/год на одну компанию = (D × P × V × C × δ) / 8333
➡️ Деревьев/год по сектору = (D × P × V × C × δ × N × α) / 8333
Если взять среднестатистическую компанию, то получится, что:
➡️ D=80 (политики+процедуры+стандарты+формы), P=15, V=1,5 (часть документов правят), C=8 (филиалы/аудиторы/архивы/подписи), δ=0,5
➡️ Страниц/компанию: 80×15×1,5×8×0,5 = 7200
➡️ Деревьев/компанию: 7200/8333 ≈ 0,86
Для зарегулированных отраслей убитых деревьев уже будет 3,9 в год, а для хардкора (все на односторонней бумаге) – 14,4. То есть еще несколько городов было обездеревлено для соблюдения бумажной безопасности 🤔
Чувствуете, что вы 🔤🔤🔤🔤🔤🔤 легких задыхающейся планеты?
#регулирование #математика
Если продолжить вчерашнюю заметку про трату времени на compliance, то можно сделать интересные выводы: 🤔
1️⃣ Каждый регулятор по отдельности считает, что делает важное дело (и в чем-то он прав). Но регуляторы почти никогда не смотрят по сторонам и не оценивают, что делают другие регуляторы. В итоге у нас рождаются требования уведомления об утечках ПДн в 4 разных регулятора, дублирующие требования ФСТЭК и Банка России, конфликтующие требования ФСТЭК и ФСБ и т.п. 🧐 Это даже если не упоминать, что в большинстве своем служащие регуляторов не работали в организациях, для которых они выпускают или проверяют нормативку, и не понимают всей их внутренней кухни.
2️⃣ Ряд регуляторов не понимает глубинных процессов, связанных с регулируемой ими деятельностью, что приводит к бессмысленной активности, которая только всех раздражает 😭, но которая никак не влияет на область регулирование. Например, тема персональных данных. Избыточные требования привели к тому, что в согласиях на обработку ПДн указываются сотни и тысячи наименований обработчиков ПДн и, конечно же, субъект не способен их всех просмотреть и оценить, что приводит к тому, что он просто жмакает "согласен" ☑️ на все или наоборот "не согласен" и тогда при следующем посещении он получает тоже самое всплывающее окно. И достаточно один раз клацнуть "согласен", как вся идея защиты ПДн рассыпается как карточный домик – ваши данные пошли по рукам и все последующие "несогласия" уже ничего не изменят. И это я даже не говорю про отношение современной молодежи к своим персданным как к чему-то прозрачному и не слишком ценному, что и так все знают, а значит защищать такие ПДн вообще никакого смысла нет, так как субъекту это просто не надо.
3️⃣ Специалисты по ИБ-compliance занимаются тем, что борются не с реальными угрозами ИБ, а с регуляторами ⚔️ Они делают все, чтобы регулятор не наказал их работодателей за невыполнение своих же дурацких требований. А регулятор выпускает новые требования, забыв отменить предыдущие, и начинается новая гонка. А потом на новый круг, и на новый... И так бесконечно ⌛
4️⃣ Единственную форму, которую принимают регуляторы, как доказательство выполнения каких-то норм - это отчетность, как правило, в бумажной форме. И вот мы уже вырубаем леса 🏞, чтобы регуляторы получили кипу бумаги и выбросили ее за ненадобностью. Вы думаете, они вдумчиво читают каждую страницу ваших уведомлений или доказательств выполнения вами их нормативных требований?
5️⃣ Никто из отечественных регуляторов не предусматривает поэтапную 🚶♂️ реализацию требований по защите, как это, например, сделано в HIPAA, где есть так называемая 21-дневная программа, которая подразумевает трату всего 10 минут в день для выполнения базовых шагов по повышению безопасности и соответствию требованиям. Да, это минимальный порог входа и потом все равно надо реализовывать больше всего, но по крайней мере вас не сразу тыкают носом в 200-400 страниц текста, которые надо реализовать "вчера" 🫵
6️⃣ Большинство ИБшников смирилось с такой ситуацией 🤷♀️ и не особо готово что-то менять. Не на уровне автоматизации, я об этом еще напишу, а на глубинном уровне. Ну есть и есть, "а что мы можем с этим поделать". Причем все все понимают, "нам же платят за то, чтобы не было штрафов от регуляторов". Это вообще странная история. Все понимают, что регуляторы в массе своей плодят шлак, который потом и проверяют в меру своего понимания 🤦♂️ Заказчики понимают, что это шлак и что он в массе своей не работает на практике, но не готовы с этим ничего делать, предпочитая выполнять все, что требуется регуляторами.
#регулирование
По мировым и американским данным среднестатистический специалист по ИБ среднестатистической компании тратит от 7 до 10 часов в неделю 🕙 на задачи по соответствию требованиям, которые включают в себя мониторинг нормативных изменений, подготовку документации, аудиты, корректировки политик, взаимодействие с надзорными органами и другое (не беру в расчет ситуацию, когда в компании есть выделенное подразделение по ИБ-compliance). В России, с учетом цифровой зрелости этой функции я бы увеличил это значение до 10-15 часов в неделю ⌛ В моменты выпуска новых требований это значение вырастает, но если усреднить, то можно принять эти значения как факт.
Теперь давайте посчитаем. Если предположить, что выпускник ВУЗа выходит на работу в 23 года и работает до 65 (женщины до 60) и все это время он работает в ИБ в среднестатистической компании, то он потратит на бумажную ИБ от 20160 до 30240 часов, то есть от 840 до 1260 календарных суток (даже не рабочих дней). 3,5 года своей жизни, а это почти 5% от средней продолжительности в 77 лет ⌛️ (или от четверти до трети своего рабочего времени), будет потрачено на то, что не сильно приводит к результату в ИБ, так как хакеры, почему-то, не читают нормативку и ломают даже тех, кто соответствует стандартам и имеет сертификат или аттестат соответствия 🕙
Вы действительно думаете, что оно того стоит? Что именно ради этого вы учились 4, 5, 6 лет и желали наносить людям пользу? 🤔
#регулирование #рефлексия #математика #время
Подписчик, за что ему спасибо, прислал осенне-бюджетное...
#юмор
Издана моя книгу "Опасная профессия. Будни работы в сфере информационных технологий". Издана полностью за свой счет. Книга адресована широкому кругу читателей. В первой части вы найдете примеры жизненных ситуаций, приведших к возбуждению уголовных дел по компьютерным преступлениям. Во второй части рассмотрены примеры участия гражданина в следственных действиях (свидетель, потерпевший, понятой, обвиняемый и т.д.). Описаны следственные мероприятия и меры пресечения. В третьей части — примеры уголовного наказания за компьютерным преступлениям.
Бесплатная электронная версия на сайте издательства https://ridero.ru/books/opasnaya_professiya_1/#reviews
P.S. Канал как и ранее закрыт для новых публикаций.
Почему-то многие индустрии в какой-то момент времени начинают походить на чиновников и представителей государственных органов, которые начинают меряться "у кого больше" 📈 вместо того, чтобы оценивать "у кого эффективнее" или "у кого оптимальнее".
Одна компания заявляет, что на нее совершается кибератак больше, чем на Госуслуги. Другой регулятор хвалится, что в первом полугодии одного года утечек персональных данных уже больше, чем за весь предыдущий год. Вендор системы обнаружения атак утверждает, что он добавил еще стопиццот сигнатур атак в свой продукт, а производитель SIEM бравирует ростом на 146% числа корреляций 📈
И только заказчики хотят, чтобы у них было меньше - меньше атак, меньше уязвимостей, меньше утечек, меньше сработок SIEM, меньше инцидентов... 📉 И чтобы стоило это все меньше. Но цены тоже растут - на бензин, на кофе, на услуги хакерских группировок, на инструменты взлома, на средства ИБ... Так и живем в условиях разнонаправленного движения – одним нужно больше, другим меньше. И конца и края этому не видно... 🔫
#метрики
Ну как так-то? К монитору приклеен стикер с легко угадываемым логином и ооооочень сложным паролем. При этом видно окошко про подключение к удаленному рабочему столу 📱 И все это перед глазами любого посетителя. Вот даже и не знаю, жалко мне будет эту организацию, когда их взломают, или нет?.. 😔
#аутентификация
11 сентября 2025 года Администрация киберпространства Китая (Cyberspace Administration of China, CAC) утвердила "Меры по управлению отчетностью об инцидентах ИБ", вступающие в силу уже в ноябре этого года (полтора месяца на то, чтобы подготовиться к новой нормативке – очень амбициозно). Всего 14 статей и приложение с классификацией тяжести инцидентов. Основная цель нового регулирования – стандартизировать механизм сообщения о киберинцидентах, ускорить реагирование, снизить ущерб и повысить устойчивость национальной системы кибербезопасности (готовятся они к чему-то что ли?) 🇨🇳
Инцидентом ИБ считается событие, которое приводит к ущербу сети, информационной системе, данным или приложениям из-за таких факторов как атаки, уязвимости, дефекты ПО/железа, форс-мажора и прочее, и что оказывает негативное влияние на государство, общество или экономику.
Не все инциденты требуют отчета в CAC, а только те, которые достигают порогов "относительно крупный", "крупный" или "особо крупный", согласно приложению по классификации:
✔️ Масштаб влияния на жителей (например, > 50% населения провинции или >10 млн чел. – особо крупный).
✔️ Объем ПДн (≥ 1 млн; ≥ 10 млн; ≥ 100 млн записей). Обратите внимание, что китайцы начинают считать от 1 миллиона, а не 10 тысяч, как в РФ.
✔️ Простой КИИ (например, общий сбой ≥ 10 мин/1 ч/6 ч; отказ ключевых функций ≥ 30 мин/3 ч/24 ч).
✔️ Прямые убытки (≥ 5 млн / ≥ 20 млн / ≥ 100 млн юаней).
✔️ Захват/дефейс порталов властей/СМИ/крупных платформ с "широким" распространением вредного контента (порог по времени/просмотрам/репостам).
Сообщать обязаны любые "сетевые операторы" на материковой территории КНР (владельцы/операторы сетей, провайдеры сетевых услуг), включая КИИ и органы власти. В зависимости от типа оператора и уровня инцидента предусмотрены разные сроки уведомления:
✔️ КИИ: сообщить профильному ведомству и полиции "как можно скорее", не позднее 1 часа; при инцидентах уровня major/especially major – ведомство эскалирует в CAC и МВД КНР "как можно скорее", но не позднее 30 мин.
✔️ Центральные/госорганы: уведомляют свое интернет-информационное подразделение ≤ 2 ч; при инцидентах уровня major/especially major – далее в CAC ≤ 1 ч.
✔️ Иные операторы: в провинциальный интернет-регулятор ≤ 4 ч; при инцидентах уровня major/especially major – провинция эскалирует в CAC ≤ 1 ч.
Содержание уведомления (минимум): кто пострадал; что/где/когда, тип и уровень, ущерб, принятые меры и их эффективность; тренд развития и возможные дальнейшие последствия; первичный разбор причин; если возможно, то зацепки об источнике (атакующие/вектора атак/уязвимости); планируемые меры по восстановлению и взаимодействию с властями; доказательная база; для вымогателей – сумма/метод/время требований. Разрешен "урезанный" первичный отчет с досылкой деталей. Финальный отчет должен отправляться в течение 30 дней после завершения работ по расследованию.
Каналы приема уведомлений об инцидентах от граждан/организаций: единый номер "горячей линии" 12387, официальный сайт CERT (например, cert.org.cn) для отчетности, WeChat-минипрограммa "12387" (может и у нас с НКЦКИ можно будет в MAX общаться когда-нибудь), официальный аккаунт CNCERT в WeChat, e-mail и факс.
Если оператор использует сторонних поставщиков (например, услуги по эксплуатации, безопасности, обслуживанию), то оператор обязан предусмотреть в контрактах с ними обязанность своевременного сообщения о инцидентах и координации в расследовании. Эта мера направлена на то, чтобы цепочка реагирования была непрерывной, и оператор мог выполнить свои обязательства даже если часть инфраструктуры обслуживают третьи лица.
Если оператор задерживает, скрывает или лжет в уведомлении об инциденте – на него могут быть наложены штрафы; и ответственность могут нести не только юридическое лицо, но и конкретные ответственные лица. Однако если оператор смог доказать, что он применил "разумные и необходимые меры ИБ", своевременно уведомил органы и уменьшил вред – он может быть освобожден от ответственности или получить более мягкую санкцию 🐲
#регулирование #управлениеинцидентами
Депутаты продолжают настаивать на том, что если у россиянина больше 6️⃣1️⃣ банковских карт, то он мошенник и дроппер и надо с такими бороться 😡 Банк России поддерживает эту инициативу.
Интересно, регулятор же изменит свои рекомендации, в которых прямо писал про то, что клиентам банкам стоит заводить виртуальные карты 💳 в целях безопасности, снижающие риски потерь денег? А виртуальных карт только в одном банке может быть с десяток – для каждого сервиса или маркетплейса своя. Тогда, во-первых, для разных сервисов можно свои лимиты устанавливать, а во-вторых, сразу станет понятно, откуда утекли данные, если с карты вдруг начнут пропадать деньги 🤒
Но теперь, если инициатива пройдет (а сомнений в этом что-то нет), мы опять скатимся в дремучие века, когда у человека был один счет и в сберкассе. Главное, чтобы под картами в законопроекта не считали карты лояльности в различных программах и т.п., а то ведь там тоже часто деньги лежат и они часто тоже становятся целью для мошенников 💳
#регулирование #мошенничество
В комментах попросили прокомментировать тему оффбординга (offboarding) 👋, то есть управляемого "выведения" человека, аккаунта или подрядчика из вашей системы: безопасное прекращение доступа, передача дел и закрытие организационных, административных и юридических вопросов. Цель этой операции заключается в том, чтобы после ухода ничего "не висело": ни доступы, ни токены, ни незакрытые обязанности. В противном случае мы имеем нехилую такую вероятность утечек, саботажа, претензий со стороны клиента и других рисков 🔓
Когда нужен оффбординг:
➡️ Увольнение/разрыв контракта, длительный отпуск/"заморозка".
➡️ Перевод роли или уменьшение ее прав (частичный offboarding старых прав).
➡️ Завершение проекта/подрядных работ, прекращение субподряда 🔚
Триггером для оффбординга (для ИТ, ИБ, HR и, в ряде случаев, менеджера проектов) является создание тикета 🎟 "Leaver" в какой-либо внутренней системе с датой/временем увольнения/завершения проекта/смены роли, списком систем и владельцем. Сразу отмечу, что я не знаю, как на русский переводится "JML-процесс", то есть процесс жизненного цикла роли Joiner-Mover-Leaver (онбоардинг, смена роли, оффбоардинг). Поэтому использую английское название этапов этого процесса ❌
Что будет включаться в оффбординг? Начинается с доступов (ИБ/ИТ), которые надо отключать/удалить/отозвать: 🙈
➡️ Отключить SSO/MFA пользователя (IdP), VPN, почта/чат, таск-треки.
➡️ Удалить из групп/ролей в Git, CI/CD, облаке, WAF/CDN, аналитике, доменах/DNS, CRM, биллинге, менеджерах паролей.
➡️ Отозвать API-токены, SSH-ключи, персональные PAT, ключи KMS/Vault, вебхуки от имени пользователя; пересоздать общие секреты, если были доступны.
➡️ Закрыть внешние SaaS (Notion, Figma, Miro, Холст, Statuspage, мониторинг и т.п.).
➡️ В клиентском окружении надо будет также отозвать доступы (если выдавались), уведомить контакт ИБ клиента (по договору) ❌
❗️ Важно! Отзывая доступ, не забывайте, что иногда (хотя такого быть не должно) работники регистрируются в системах со своих личных аккаунтов, например, с gmail.com, так как "у меня исторически доступ к Github с личной почты". И если мы будем отзывать доступ по маске корпоративного домена, то можем упустить личные учетные записи 📬
Дальше-больше. Надо зачистить устройства и данные: 🔏
➡️ Через MDM: блокирование/очистка (wipe), инвентаризация, возврат техники и аппаратных токенов 2FA.
➡️ Передача артефактов/документов владельцу, перенос прав на репозитории/борды/ИТ/ИБ-системы/оборудование.
Изменение коммуникаций и почты. Вот этого почти нигде никогда не видел, хотя реализуется просто и дает возможность уведомить тех, кто не знает об изменениях 📨 В противном случае можно будет осуществлять фишинговые атаки от имени этого, уже не "нашего" пользователя:
➡️ Автоответчик "контакт изменился", переадресация на его заместителя на 7–14 или более дней.
➡️ Отключить личные переадресации/внешние интеграции.
Юридические и административные вопросы:
➡️ Напоминание об NDA/неразглашении, закрытие финансовых расчетов.
➡️ Акт уничтожения/возврата, отметка в реестре оффбординга, обходной лист 🤑
Проверка и закрытие темы: 😝
➡️ Выгрузка логов входов/действий за последние 7–30 дней (PAM/SIEM/DLP/IdP).
➡️ Проверка "хвостов": нет ли его e-mail в правилах, алиасах, вебхуках, не остались ли созданные ушедшим пользователем учетные записи.
➡️ Закрыть тикет с чек-листом и ссылками-доказательствами.
Частые ошибки, которые совершаются при оффбоардинге: 😱
➡️ Оставили бота/сервисный токен, созданный из личного аккаунта.
➡️ Не убрали доступ к аналитике/рекламным кабинетам и системам управления доменами.
➡️ Забыли отключить внешние SaaS (Notion/Figma и т. п.) – платежи и доступы живут.
➡️ Не сменили владение репозиториями/проектами – блокируются релизы.
ЗЫ. Уходя из Cisco, оставил всех уточек 🛁 в офисе.
#bestpractice
Чем зрелее 📈 программа повышения осведомленности по ИБ, тем более персонализированной она будет. Идея простая (я про нее писал выше). Для разных ролей хакеры используют обычно разные способы атак, а значит требуются и разные методы проверки знаний и навыков, тестирующие разные привычки и защитные меры, присущие каждой роли. Учим не всех всему одинаково, а каждого важному именно для него! 🧑💻
Как персонализировать обучение: 🤔
💡 Контент. Примеры из типичных процессов тестируемых (счета/договора для финансовых работников; pull-requests/CI – для разработчиков, резюме/вакансии – для HR, новые требования ФНС и Банка России – для бухгалтеров).
💡 Каналы. Финансистам – в почту и в корпоративный мессенджер; разработчикам – баннер в Git/CI и карточка в issue tracker; подрядчикам – портал поставщика.
💡 Частота. Ролям высокого риска нужны короткие подталкивания чаще, остальным – реже.
💡 Формат. Микровидео/чат-карточка/симуляция – выбираем по данным A/B-тестов.
Например:
📎 Для разработчиков. Основные угрозы связаны с секретами в коде, токенами, цепочкой поставок. Значит мы должны у них сформировать привычки "Не храним секреты в репо", "Подписываем коммиты", "MFA/Passkeys в Git". Как проверяем? Например, сканирование секретов, SSO+MFA к Git/CI, внедряем правило "no-push with secrets" 👨💻
📎 Для подрядчиков. Основные угрозы связаны со слабой базовой гигиеной и избыточными доступами. Хотим добиться реализации привычек "Работаем только с корпоративных устройств/VDI", "Доступ – по заявке и с конкретным сроком действия". Соответственно реализуем через JIT/JEA, VDI, изоляцию сетей, обязательный онбординг/оффбординг 🤝
📎 Для финансов/бухгалтерии. Мы боимся BEC и подмены реквизитов в транзакциях и платежных документах. Значит какие привычки нам надо формировать? Правильно. "Не платим по e-mail без независимой верификации", "Звоним по номеру из CRM, а не из письма" и т.п. Защитные меры – двойной контроль платежей, обязательный обратный звонок, белый список поставщиков и т.п. 🤑
Я думаю, суть персонализации, которая начинается на 4-м и продолжается на 5-м уровне модели зрелости повышения осведомленности, понятна из описанного. Дальше ее можно развить уже на свою организацию, свои роли, свои процессы. Это не так сложно, если просто сесть и подумать, провести декомпозицию 🤔 И не так дорого, кстати. Да, займет чуть больше времени на подготовку контента, но зато и эффект выше.
#обучение #awareness
Если вы, прочитав вчерашнюю заметку, решили: "Ну давай уже, рассказывай про пятый уровень, я сразу на него нацелюсь", то разочарую, – перепрыгнуть с первого или даже второго уровня сразу на 4-й и, тем более, пятый, нельзя. Это поэтапное движение 🚶♂️
Если цель 4-го уровня показать, что культура уже есть (и да, это не про набор мероприятий "для галочки" в отчете и по принципу "на, отвали"), то цель пятого уровня модели зрелости ↗️ программы повышения осведомленности – доказать, как именно эта культура ИБ уменьшает убытки/риски/НС, то есть связать культуру и поведение работников с бизнес-рисками и целями компании, построить цикл непрерывного улучшения и показать доказуемый вклад ИБ в снижение рисков/предотвращение недопустимого/рост устойчивости. Я бы это видел следующим образом: 🤠
💡 Внедряем метрики, синхронизированные с бизнесом 📊 Например, показываем, как именно изменение поведения работников снижает риски или предотвращает недопустимые события. Например, рост доли passkeys/MFA приводит к падению успешности подстановки учетных записей (credential-stuffing), что дает нам меньше компрометаций почты, а значит меньше денег теряем. А, например, рост доли уведомлений о фишинге приводит к сокращению времени обнаружения и реагирования и... да, снижению потерь 📉
💡 Единый дашборд, комбинирующий метрики, которые показывают, будет ли хорошо (охват passkeys, скорость реакции сотрудника на подозрительное письмо, участие в учениях) 📈 и стало ли хорошо (частота/тяжесть инцидентов с человеческим фактором, успешные BEC и т.п.), а также внедрение отчетности в формате, понятном руководству. По сути мы сшиваем имеющуюся LMS + кнопку "сообщить о фишинге" + IdP/SSO (MFA/Passkeys) + SIEM/EDR + HR.
💡 Интеграция с SOC/IR 🤝 Например, реализация кнопки "уведомить о фишинге" в почтовом клиенте, автоматическое "склеивание" одинаковых/повторяющихся оповещений об одном и том же событии в один инцидент/кейс в SIEM (автодедуп), трекинг времени от доставки сообщения в почтовый ящик пользователя до репортинга с его стороны, а также корреляция уведомлений на "человеческом" языке с техническими мерами 🎣
💡 Сегментация и персонализация: разные роли (финансы, продажи, разработка, подрядчики) – разные атаки – разные привычки/меры защиты ☝️ Учим не всех всему, а каждого важному для него. A/B-тесты форматов (например, половине финансистов показываем новую мини-симуляцию, половине – нет, а потом сравниваем TTR уведомления, % кликнувших, число эскалаций и если видим улучшение, то оставляем меру, а если нет, то меняем), частоты и каналов, чтобы увеличивать поведенческий эффект ☝️
💡 Межфункциональные антикризисные учения 👩🎓, включая PR/GR/Legal/клиентский сервис, готовые коммуникационные шаблоны внешних и внутренних сообщений, альтернативные каналы связи, упражнения "хаос-фишинг" (аналог chaos engineering, но для человеческого и почтового периметра – непредсказуемые, реалистичные симуляции фишинга, которые проверяют всю цепочку обнаружения и реагирования – от доставки письма до отчета и заведения заявки/тикета в SIEM) для проверки обнаружения со стороны работников и репортинга о таких попытках даже в условиях кризиса 💥
💡 Маппинг: привычки → цели контроля → записи в реестре рисков (если вы их ведете). Также считаем вклад программы в снижение остаточного риска/потерь (тенденции, сравнение до и после) 🧮
💡 Непрерывное улучшение за счет квартальных пересмотров метрик, пересборки бэклога инициатив, закрытия циклов обратной связи от сотрудников/менеджеров, обновления карт ключевых рисков и недопустимых событий 📇
Пример демонстрации работы программы повышения осведомленности на уровне бизнеса:
➡️ До: passkeys у 15% ключевых ролей → 12 успешных BEC/квартал, медианный ущерб 4 миллиона рублей, TTR уведомления = 45 мин.
➡️ После 2 кварталов L5: passkeys 80% → 5 BEC/квартал (−58%), ущерб 2,2 миллиона (−45%), TTR уведомления = 9 мин.
➡️ Экономия за квартал ≈ (12−5)×4М = 28М рублей + снижение вторичных потерь; стоимость инициатив (лицензии, подталкивания (nudge), время людей) 9М рублей → ROI положительный. Бинго! 🤔
#обучение #awareness #maturity
И кто теперь скажет, что я не пророк? Так что если вы думаете иногда: «Какую же чушь он написал», то знайте, это не чушь, это предвидение 🔮
#тенденции #санкции
Ну и чтобы не быть голословным 😱 Пример, что можно сделать на 4-м уровне зрелости программы повышения осведомленности, вышедшей за рамки "обучения ради обучения" и встроенной в повседневные процессы, коммуникации и мотивацию людей. Я бы это видел так: 🤠
💡 Упростить правила и убрать недовольство от обучения для галочки, переписать ключевые политики понятным языком, сделать ролевые "карточки решений" (что делать маркетологу, закуперам, разработчикам, бухгалтерам и иным ролям), встроить подсказки в интерфейсы ПО, если это внутренняя разработка ("secure by default") 🃏
💡 Интегрировать обучение в HR-цикл: онбординг с реальными кейсами, "минутка ИБ" на квартальных митингах, включение безопасного поведения в персональный план развития или систему оценку эффективности менеджеров 5️⃣
💡 Внедрить сеть чемпионов по безопасности, выбрав амбассадоров в бизнес-подразделениях (1–2% штата), дать им время и мини-бюджет на локальные активности 🏆 Не все верят в эффективность этой меры, но я был одним из первой четверки чемпионов в Cisco еще в 2008 году (даже на местной доске почета в здании службы ИБ висел) и вполне себе справлялся без принуждения.
💡 Постоянная коммуникация вместо разовых курсов: годовой календарь тем, короткие "подталкивания" (nudge) в корпоративных инструментах, позитивный tone-of-voice и сторителлинг про недопустимые события и ключевые риски 💬
💡 Поощрения и "безопасная обратная связь". Признание команд с лучшими практиками, сообщения об ошибках (без наказаний за добросовестный репортинг) 👏
💡 Совместные проекты с ключевыми функциями: HR, внутриком, закупки, DevOps/ИТ/проектный офис, чтобы безопасность стала естественной частью закупок, разработки, запуска продуктов и т.п. 👨💻
💡 Практические учения для нефункции ИБ: регулярные штабные сессии с Legal/PR/Ops по сценариям фишинга, утечкам, BEC, тренировки "как сообщать" и "что делать в первые часы" 🔥
💡 Измерения "пульса" культуры и поведения: квартальные короткие опросы (ощущение личной ответственности, доверие к ИБ, релевантность обучения) + метрики поведения (доля MFA, отчетность о фишинге, применимость шаблонов обмена данными) 🌡
Ну и как вы понимаете, это нельзя прописать в нормативных требованиях, так как далеко не все способны это реализовать; по крайней мере сразу. А вот прописать это в методичке можно было бы – тогда был бы ориентир, к которому можно было бы стремиться 🤔 И в этом, одно из серьезных отличий иностранных регуляторов от многих наших – там меньше требований и больше рекомендаций. У нас про рекомендации все забыли, считая, что их будут игнорить, и поэтому сразу херачат 200-500 требований, даже не выделив Топ10 и не предложив "правило Паретто" для них.
ЗЫ. Завтра про 5-й уровень напишу. А потом, если будет интересно, и про третий.
#обучение #awareness #maturity
Интересное nixCraft/115241270037750346">прислал подписчик (за что ему спасибо) ✉️ А вы когда получаете сообщение с домена gazprorn[.]ru о том, что на ваши акции Газпрома начислены дивиденды, или с gazprornbank[.]ru, что ваша кредитная карта заблокирована, или с gazinforrnservice[.]ru, что вас зовут послушать выступление Алексея Лукацкого на GIS Days, уверены, что это именно домены gazprom[.]ru, gazprombank[.]ru и gazinformservice[.]ru соответственно? ✉️
Вы же знаете частые комбинации, которые используют хакеры в рамках атаки тайпсквоттинг (typesquatting)? Вот самые распространенные:
➡️0 – O (ноль – прописная о)
➡️1 – l – I (цифра один – строчная L – заглавная i)
➡️5 – S / s
➡️2 – Z / z (реже)
➡️8 – B
➡️s – $ или 5
➡️i – !
➡️c – ( или <
➡️Соседние клавиши: m – n, k – j, q – w – приводят к опечаткам при ручном вводе
➡️rn выглядит как m в некоторых шрифтах
➡️vv вместо w и наоборот
➡️пропуск/удвоение символов
➡️транспозиция букв, например, examlpe вместо example 🤔
#фишинг
Мои ближайшие мероприятия (из публичных):
➡️ Boost - 23 сентября - Москва – про то, зачем заказчики требуют кибербез от разработчиков и что именно требуют
➡️ Positive Technology Day – 25 сентября – Санкт-Петербург – буду про когнитивные искажения в деятельности ИБ рассказывать
➡️ GIS Days – 3 октября – Москва – буду пророчествовать
➡️ Positive Security Day – 8 октября – Москва – открывающий keynote и модерация
➡️ MLSecOps (AM Live) – 10 октября – онлайн – модерация
➡️ Автономные SOC (AM Live) – 24 октября – онлайн – модерация
➡️ Russia Risk Conference 2025 – 24 октября – Москва – выступление про текущий ландшафт и участие в дискуссии
➡️ SOCcon (программы пока нет) – 30 октября – Минск – выступление и модерация
➡️ ИТ-Диалог 2025 – 6 ноября – Санкт-Петербург – модерация и, возможно, выступление.
Попутно вписался в пять (!) MBA-программ (и это не Masters of Beer Appreciation), где мне предложили взять модуль по кибербезу 🛡 Это помимо второго направления бизнес-образования, где топов различных компаний обучают теме искусственного интеллекта и меня туда зовут с рассказом про безопасность ИИ. Для меня это прям некий сигнал к тому, что как минимум разные учебные заведения 👩🎓 стали видеть востребованность в обучении руководителей организаций вопросам кибербеза. Не может не радовать сия тенденция.
ЗЫ. Ну и курс по SOCам, стартующий уже через пару недель, но про него я уже писал.
#мероприятие #обучение
Что объединяет пятничные взломы аэропортов 🛫 Брюсселя, Хитроу в Лондоне, Бранденбург в Берлине? То, что их никто не ломал. Взломан был поставщик системы регистрации на рейс, которая использовалась в упомянутых аэропортах, и предоставлялась компанией Collins Aerospace (ею владеет RTX/Ratheon). Классическая атака на подрядчика, через которую пострадали и связанные с ней компании 🛩
А у вас есть системы, отданные подрядчикам на аутсорс, и от которых также зависят ваши основные бизнес-процессы? Если что, то для пяти отраслей я делал такие списки подрядчиков. Если нужны для каких-то еще отраслей помимо этих пяти, пишите в комментах, заделаю и их ✍️
#sypplychain
Скоро сказка сказывается, да долго дело делается... В марте писал про свою статью про выбор накопителей 💾 и архитектур хранения событий безопасности для SIEM и SOCов. И вроде материал был написан, но все руки не доходили его вылизать и выложить. Но вроде все доделал – отправил на финальную корректуру и скоро, надеюсь, поделюсь ссылкой на сей лонгрид ✍️
#soc #статья